Skip to main content
Workbench is a workspace where a team and its agents work in the same place. People and agents share a bench and take part in the same conversations, over the same material, rather than each agent living in a tab of its own.
This page describes the Workbench app. Where it reaches into the layers underneath, it names them: the control plane owns tenancy, credentials, and grants, and the agent runtime executes agents. Neither layer’s guarantees are restated here. Workbench is open source, and it runs from a source checkout today: there is no single-command install.

​
What you get today

​
Benches and channels

A bench is the shared space a team works in, holding its members, its agents, and its history. Underneath, a bench is a control plane tenant. Belonging to one is a principal record the control plane resolves before a Workbench route runs, and what you may do once you are in is decided by control-plane grants, rather than by a membership or permission model Workbench invents alongside them. A channel is a conversation inside a bench, and it is minted as its own control-plane tenant parented under that bench, with its own roles and grants seeded when it is created. If you are evaluating the tenancy model, be precise about what that buys today: it gives a channel its own identity and somewhere to hang membership, but the routes serving a channel authorize against the bench above it, and the agents running in a channel draw their inference and credential context from that bench too. Treat a channel as an identity boundary rather than an enforcement one. A channel’s timeline is its mailbox, read back in order. People and agents post into the same timeline, and mentioning an agent by its handle delivers that agent a copy of the message, addressed from the channel rather than from you, so its reply lands back in the shared timeline rather than in a side thread. What a mentioned agent reads as context is that message plus a configurable number of preceding ones, not the channel’s whole history. A channel is the broadcast kind, meant for a whole bench. It starts with no agents in it: you invite one in, and it joins the timeline from then on. The dialog that creates a channel also creates a chat, which starts with the single agent you pick when you create it. A fresh bench opens into a channel named Myra with nothing invited into it yet, though the bench itself is seeded with three deployed workflows you can invite: a general-purpose assistant, an echo test agent, and the channel-digest automation. The invite dialog lists them under their asset names, assistant, echo, and channel-digest, and the assistant is the one the channel is named after. An agent in a channel that goes quiet is put to sleep rather than left running, and the next message addressed to it brings it back before delivery. Several senders arriving at once coalesce onto a single wake instead of racing each other. Each bench also keeps a library of uploaded files. You add files to it and then browse and search them, so a team has one place to put the material it keeps referring back to. The interface offers no download, export, or publish action, though the API will return a file’s content to a caller holding a control plane grant to read that bench’s stored files.

​
Agents and routines

An agent definition is a reusable template: a name, a handle, a system prompt, and optionally a description and the model it should run on. Launching a definition produces an instance, a running agent with its own mailbox address you can write to. One definition backs as many instances as you launch from it. A routine runs a workflow on a schedule. It names the workflow to launch and a trigger, which is an interval, a time of day, a day and time of the week, or a cron expression when the presets do not fit; a routine with no trigger is one you run by hand. When more than one hub replica is running, each due fire is claimed atomically, so a routine fires once rather than once per replica, and a launch that keeps failing backs off and is eventually dead-lettered instead of retrying indefinitely.
The two halves above do not yet meet. The routine picker lists only workflows that ship with Workbench and are marked automatable, and a new bench is seeded with one of those. The agent definitions you author are deliberately kept out of that list, so authoring an agent and putting it on a schedule is not a flow the interface completes.
One limit shapes what Workbench is useful for today. Agents here converse and work with the bench’s own material: Workbench ships no outbound provider tools, so an agent cannot read your CRM, file a ticket, search the web, or publish anything. Inbound is the direction that is wired, and a service outside Workbench can start a run by posting to a signed webhook endpoint. Creating and rotating those endpoints is an API operation, with no screen for it yet.

​
Approving what an agent is waiting on

When a run parks on a human decision, it surfaces in the Activity band, naming the agent that is asking and the bench it is asking in rather than the identifiers underneath. You approve or reject it from there, and rejecting takes an optional message. There is no separate approvals page. Approving covers that one call and nothing more. There is no durable “always allow this tool” that Workbench records on your behalf, and the control plane does not yet support approving with that scope. Nothing produces an approval in Workbench today: neither the workflows it ships nor the agents you author here carry an outbound tool. The band is waiting on workflow packages deployed with tools of their own, which is a path Workbench has no screen for yet.

​
What Workbench builds on

Workbench does not reimplement the hard parts of running agents. It composes them from the layers below, which is also why the guarantees on those layers are the ones to read when you evaluate it.
A definition is a workflow definition and an instance is a workflow run, both of them agent runtime objects. The runtime owns a run’s lifecycle, its suspension and resumption, and its event log, and Workbench hosts that machinery in a sidecar process that dials in to its hub. What Workbench adds is the authoring surface that turns a prompt and a model into a definition, and the policy that decides when an instance should be running at all.
A channel is not a chat system built beside the agent runtime. It is a long-lived agent run whose job is to hold a mailbox, and a message is mail delivered to that run’s address. Reading a timeline lists that mailbox. Workbench adds the structure carried over that transport: how a message’s parts are encoded, the participants and handles a channel knows about, and the fan-out that copies a mentioned agent in.
Benches and channels are control plane tenants. Belonging to a bench is a control-plane principal record, and what a member may do is control-plane grants; both are resolved before a Workbench route runs. Model access is bring-your-own-key: first-run setup has a credential step that asks for a provider key and proves it with a real call before storing it, and the control plane holds and resolves it from then on. See Credentials and guardrails for how that resolution works.

​
Running it

Workbench is open source under the GNU General Public License version 2, with an AI Exception. It runs from a source checkout against a local Postgres, with a setup and a seed step to run once the hub is up before a bench and its workflows exist. Its README says the single-command install it is aiming for does not exist yet, so a source checkout is the way to try it: the code and the instructions are at corbitsdev/workbench.

Platform overview

The agentic platform Workbench is built on.

Credentials and guardrails

How credentials, grants, and delivery capabilities are governed.