Managing Resources

A Resource is a thing your agent needs to do its job — a database, a folder of files, eventually other shapes. When your dataset runs, your agent sees a Sandbox: a per-rollout, reproducible copy of the Resource, so "what were my last five orders" returns the same answer every time.

The Resources tab is where you register them, name them, and take them down. It is intentionally thin — the interesting plumbing is invisible by design.

The Resources list

The tab opens on a grid of cards. Each card shows:

• An icon and kind. A file icon for a document library, a database icon for a Postgres database.
• The name you gave it. Kept short so it's scannable.
• An optional description. The second line, if you wrote one when registering.

Above the grid, a search field filters by name; a dropdown filters by kind (Document library, Database, or all). If you haven't registered anything yet, the tab shows an empty state with an Add your first resource button; otherwise Add a resource sits in the top-right.

Clicking a card opens its detail page.

Registering a new Resource

Add a resource opens a single form with two sections.

Kind and name

Two large cards at the top let you pick:

• Document library — a folder of PDFs, markdown, or text files your agent reads.
• Database — a Postgres database we can read from.

Below the picker, you give the Resource a name (required) and an optional short description. The name is what shows on the list and is what you'll refer to in briefs, so pick something you'll recognize a month from now — "Customer support handbook", "prod-catalog-ro".

Advanced configuration

The advanced section is collapsed by default, and most customers don't open it. When expanded, it offers three fields, all JSON:

• Schema. For a database, the DDL shape we should work with. For a document library, usually left as {}.
• Default contents. For a document library, a manifest of files; for a database, any default seed rows you want every Sandbox to start from.
• Notes. Free-form metadata — anything you want attached for your own reference.

Every JSON field validates on submit. If something is malformed, the error points at the specific field.

Add resource creates it and drops you on the detail page.

Inspecting a Resource

The detail page shows:

• Kind and name at the top, with the description beneath and a Delete action in the corner.
• Editable name and notes. You can rename a Resource or update its notes without re-registering.
• Default contents, editable. Same JSON editor as the register form, for tweaking the starting state every Sandbox gets.
• The Resource ID. A short identifier used in API traces and logs — you won't need it day-to-day but it's there.

Delete opens a confirmation. Deleting a Resource doesn't affect datasets already generated; those artifacts are already on disk. Datasets mid-flight that reference the Resource may be affected, so the dialog warns you.

What the UI doesn't expose

A few things are deliberately kept out of the UI:

• Per-rollout Sandbox URLs. When your agent runs, it connects to a Sandbox URL injected into its environment at rollout time, not something you look up in the browser. This is how reproducibility works — each rollout sees its own isolated copy. See Resources and Sandboxes for the full model.
• Branching and copy-on-write details. How we make a fresh Sandbox fast on every rollout is an implementation detail; the UI shows the Resource, not the mechanism.
• Network calls to external services. If your agent calls an HTTP API or a SaaS product, we don't sandbox that today — reproducibility applies to Resources you've registered. Roadmap.

Feature parity

Everything on these pages is available from the terminal:

• datagen resources list — the grid view.
• datagen resources create — the register form.
• datagen resources get — the detail page, as JSON or a text table.
• datagen resources delete — the delete action.
• datagen resources templates / materialize — spin up a realistic starter Resource from a template. The UI doesn't currently surface templates; if you want a quick realistic Postgres Sandbox, the CLI is the faster path.

See CLI reference → resources for flags and examples.

Next step