The Agent Workbench, and the reasons for its shape

The workbench in one paragraph

The Agent Workbench runs one agent job in your browser: a records agent moves 42 customer accounts from Sam Ortiz, who left the company, to Dana Reyes, then emails each customer their new contact. You drive it through four stages. You shape the plan, approve one version of the request, watch the run and pause it, then review the receipt and roll back the change you can roll back.

Each panel is a shipped component from the pattern library, wired on the Interaction Contract, a shared event model. A simulated runtime plays the server, so nothing leaves the page. You can install the same components into your own app with the command under each stage.

The problems it solves

Agents now change real data on your behalf. A coding agent edits files and runs commands; a business agent updates records and sends email. People who answer for that work run into the same four gaps, whatever the product.

Blind approval

A yes or no button with no plan behind it. You approve an intent, and the agent decides the details after you click.

Scope creep

The agent holds a key to the whole database for a job that needs two fields on one object.

Drift during the run

The data changes while the agent works. A person edits a record, and the agent either overwrites them or stops without saying so.

No record afterwards

Once the run ends, you cannot show a colleague what you agreed to, what ran, and what you can still take back.

The people it serves

The workbench speaks to four readers at once, and each one reads a different stage first.

Product designers

see the moments where a person needs to decide, and the words each moment uses, in a flow that works at phone width and with the keyboard alone.

Engineers building agents

get the event log, the request and receipt records, and an install command per stage. The contract tells them which part runs on their server.

Data owners and admins

see the grant: the object, the fields the agent may read, the two it may write, and the line that denies the rest.

Leaders, security and compliance

get a receipt that checks itself and an audit log they can file, with the deviation and the rollback written into it.

Data, the job and the person: setting the level of interaction

The workbench sets how much it asks of you by looking at three things together. The data is the object, its fields and the records in play. The job is the outcome you need, here a hand-over after someone leaves. The person is you, the one who answers for the change.

A small, reversible change to a few fields can run on one approval. This job writes to 42 records and then sends email, which no one can recall, so the workbench asks for more: a plan you can trim, an approval tied to one request version with a 90 second window, a pause point before the emails go out, and a receipt at the end. The stronger the consequence, the more of the run you see and decide.

Read only

The agent reads and reports. No gate; the trace is enough.

Reversible writes to a few records

One approval, scope once, with the change listed field by field.

Bulk writes with a side effect

Plan, approval with expiry, a pause before the side effect, a receipt and a rollback. This is the job the workbench runs.

The four stages and their reasons

Plan comes first because a person can trim a list faster than they can correct a run. You exclude records, see each field before and after, and accept one numbered version of the plan.

Approve comes second, and it approves a request the server issued for that exact plan version. A new version asks again. You pick a scope, once or this session, and the request expires if you walk away. The receipt reads Verified only after the server stores your decision.

Execute shows the live trace with secrets masked in each tool call. Pause lets the step in flight finish and holds before the next one, so you can stop before the emails. If a person edits a record mid-run, the agent skips it and says so; the workbench calls that a deviation and carries it to the receipt.

Review checks the whole log: the plan you accepted, the approval that points at it, the steps that ran under it, and the deviation. Then you roll back the field change. The emails stay sent, and the receipt names them as the part no one can undo.

1. 1 Plan

   Exclude records and see the fields that change.

   npx shadcn@latest add https://agentsandhumans.ai/api/registry/plan-preview.json PlanPreview source PlanPreview in Storybook

2. 2 Approve

   Pick the scope before the request expires, and keep the receipt.

   npx shadcn@latest add https://agentsandhumans.ai/api/registry/approval-gate.json ApprovalGate source ApprovalGate in Storybook

3. 3 Execute

   Watch the live trace, pause it, and see where the agent left the plan.

   npx shadcn@latest add https://agentsandhumans.ai/api/registry/progress-trace.json ProgressTrace source ProgressTrace in Storybook
   npx shadcn@latest add https://agentsandhumans.ai/api/registry/interruption.json Interruption source Interruption in Storybook

4. 4 Review

   Check the receipt, then undo the part that can be undone.

   npx shadcn@latest add https://agentsandhumans.ai/api/registry/agent-workflow.json ReviewReceipt source ReviewReceipt in Storybook
   npx shadcn@latest add https://agentsandhumans.ai/api/registry/recovery.json Recovery source Recovery in Storybook

The same moments in Claude, Kiro and Codex

Agent-first products draw these lines in different places, and the workbench lets you compare them on one job. Claude Code can show a plan before it edits, asks before it runs a tool, lets you allow an action once or keep a rule for it, and keeps checkpoints you can rewind. Kiro writes requirements, a design and a task list you review before it codes, and offers a supervised mode next to autopilot. Codex runs work in a sandbox under an approval mode you choose and hands back a diff to review.

Each product covers the plan, the permission, the run and the review in its own way. The workbench names those four moments, gives each a component and an event, and lets your app keep the same record whichever agent does the work.

Trust you can check: audit log, share and rollback

Trust in an agent comes from a record you can check after the fact. Each component writes to one Interaction Contract log: the plan proposed and accepted, the approval requested and granted, each step, the pause, the deviation, the review, and the rollback. Events carry correlation ids, so the approval points at the plan and each step points at the plan step it ran.

You can download the run as an audit log in JSON, with the grant, the request, the server receipt and the events in order, and share it with a reviewer, a ticket or your own log store. Rollback uses the same record: the workbench reverts the actions marked reversible, confirms what it reverted, and lists what stays.

Least privilege on objects and fields

The agent gets the smallest grant that does the job. In the workbench that means one object, Account; read access to four fields; write access to two, owner and renewal contact; and nothing on any other object. The plan stage shows the grant before you accept, the request carries it into the approval, and the audit log keeps it beside the events.

A grant this narrow limits the damage a wrong plan can do, and it lets a data owner approve the job by reading one short list. Your server enforces the grant; the workbench shows you the grant your server will enforce.