Working with Workbenches

A workbench groups multiple agents under one shared sandbox, with shared connections and references.

Create one

From the dashboard drawer, click Create workbench, name it after the project, and attach the connections and references every agent in it should inherit.

Add agents

The first agent shows as a tab in the strip up top. Click + to add more. Each new agent gets an auto-codename (Atlas, Echo, Nova…), its own chat history, and its own folder at /workspace/<Codename>/.

When this pays off

Workbenches are most useful when you have separate concerns running in parallel that share the same connections. Some realistic shapes:

• Domain split. One agent owns sales pipeline analysis, another owns marketing performance. Both read from the same Salesforce + Marketing Cloud connections; neither has to context-switch.
• Orchestrator + workers. A scheduler-style agent triggers the others on a cron and rolls up their outputs into a weekly digest in shared/.
• Long-lived ops space. Same workbench, same references, fresh agents per question — keep months of history without one chat ballooning.

When a single agent's chat gets long, slow, or expensive, that's the signal to split it into a peer rather than keep going.

Hand-offs

Agents in the same workbench message each other with the peer.send_message tool. Just say it in plain English:

"When you're done, ask Echo to draft the follow-up email and post it to shared/."

Echo gets a structured peer message tagged with the sender's codename. Both sides of the conversation are visible — switch tabs to follow.

Sharing files

/workspace/
├── <Atlas>/   ← per-agent scratch
├── <Echo>/
└── shared/    ← anything any agent should see

Agents already know this layout. "Save it to shared" or "look in shared for the brief" works. Workbench references live read-only at /workspace/.refs/<slug>/.

Editing connections and references mid-flight

Edit them on the workbench any time. Active agents pick up the change on their next turn — no restart.

Next Steps