MeshMesh
Core Concepts

Workbenches

A long-lived workspace where one or more agents share the same filesystem, connections, and references.

A workbench is a long-lived workspace that hosts one or more agents. Every agent inside shares the same filesystem, connections, and references.

When to use one

Use a workbench when you want separate concerns running side by side instead of one agent juggling everything. A long single-agent run gets slow and expensive; splitting the work across focused agents keeps each conversation tight and lets them run in parallel.

A few realistic shapes:

  • One agent owns sales pipeline analysis, another owns marketing performance, an orchestrator agent checks both on a schedule and posts a weekly summary.
  • One agent maintains your data model, another runs ad-hoc queries on it — same connections, separate jobs.
  • A long-lived "ops" workbench you keep coming back to over weeks: same connections, same references, fresh agents per question.

For a one-off question, a standalone agent is still the right shape.

Agents and codenames

Each agent in a workbench has its own chat and history but lives in the same sandbox. New agents get an automatic codename (Atlas, Echo, Nova…) that's unique to the workbench and used as their identity in the UI and in peer messages.

Shared workspace

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

Agents are told about the layout in their system prompt: drop drafts in your own folder, drop hand-offs in shared/. References attached at workbench level are materialised into /workspace/.refs/<slug>/ and read-only.

Peer messaging

Agents in the same workbench can message each other with the peer.send_message tool. A message from Atlas lands in the recipient's chat tagged with the sender's codename, so the receiver knows it's a hand-off, not a user instruction.

Peer messaging is workbench-only. Standalone agents have no peers.

Connections and references

Connections and references live on the workbench, not the individual agent. Every agent inherits the set on its first turn, and edits propagate to all active agents on their next turn. Configure the project once instead of per agent.

Workbench vs single agent

Single agentWorkbench
SandboxPer taskShared
FilesystemPer taskShared (/workspace/<agent>/ + shared/)
ConnectionsPer taskOn the workbench
ReferencesPer taskOn the workbench
PeersNoneOther agents in the workbench

Next Steps