The design agent

The design agent builds and changes an environment with you: it interviews you about a process, writes workflows, cases, hook scripts and skills, validates what it wrote, and reads past sessions and decisions to explain or fix them. It runs on a model the platform supplies, so it works in every environment, whether or not the agent has a model provider of its own, and the platform pays for it.

Open it with AI in the top bar. The Design agent panel sits beside the page, which keeps working; drag its border to resize it, or collapse it to a narrow rail. Sending it a message needs workflows:write on the agent (a Maintainer), and AI is shown only with it. Each turn acts with the permissions of the member who sent the message: it changes only the paths they may write, so a Maintainer’s turn can rewrite workflows but not a connection definition (see The design agent acts as you).

Threads

The design agent’s work is kept in threads. Sending the first message starts one, New thread starts another, and Thread history lists the ten most recently active. An empty thread opens on four choices under “How would you like to start?”: import your process files, discover a process from your connected systems, refine an existing workflow, or ask a question. A choice fills the composer with a prompt to edit and send; importing files also opens the file picker.

Each message becomes a turn that runs in the background. Its text streams in, and every tool call it makes shows as a card that expands to the tool’s identifier and details. Stop cancels the turn.
The message carries the page you have open, so “this workflow” and “here” mean what you see.
Attach files with the paperclip or by dropping them; the agent reads them from its thread’s scratchpad/attachments/.
A file the agent links in a reply downloads from the panel, and an image it embeds is shown.
The agent can send you to a page: a workflow’s editor, a turn in the session view, the Sessions page or a decision.
A failed turn keeps the transcript of what it did above its error, and a following message in the same thread continues from it.

What it reads and writes

The design agent works in a workspace of its own, laid out as fixed paths:

Path	What it holds	Access
`agent/`	The environment’s draft: `agent/AGENTS.md`, `agent/workflows/...`, `agent/skills/...`	Read and write; writes are draft changes
`agent/sessions/`	What the environment’s sessions wrote	Read only
`data/`	The environment’s Storage, the folders workflows mount	Read only
`AGENTS.md`	The design agent’s own instructions	Read only
`skills/`	The harness’s `archmax-harness` authoring skill, matching the installed harness version	Read only
`scratchpad/`	Durable files of this thread, your attachments among them	Read and write
`tmp/`	Scratch for one turn, size-capped, gone when the turn ends	Read and write

The platform adds skills of its own for the design agent, such as skill-creator on authoring a skill, read-only like the harness’s.

Everything it writes under agent/ is a pending change of the environment, exactly like an edit in the editor: nothing reaches production until you publish, and Discard undoes it. Your open page follows its writes while the turn is still running, and unsaved edits you have staged in the editor or the case editor are kept rather than replaced.

It authors a workflow by writing agent/workflows/<name>/workflow.yaml (with WORKFLOW.md as prose beside it) and then validating that file with validate_workflow, which also reports the problems of the workflow’s cases, hook scripts outside the workflow’s hooks/ directory, and skill slugs the environment does not provide. Hook scripts go in agent/workflows/<slug>/hooks/, scripts a session runs in agent/skills/<slug>/scripts/.

Past sessions, turns, decisions and their evidence are read through read-only tools that return the same data the session view shows, so the agent can find a failing turn, read its trace and variables, and work out the shape of a trigger’s payload.

Where it runs

Each turn runs in a worker: a process of its own that holds none of the platform’s secrets and none of the environment’s credentials. The agent and its file tools run there, and reach the workspace above only through the platform’s dispatcher:

The dispatcher writes agent/ only where the member who sent the message may write, and refuses any other write.
The dispatcher makes every model call, with the model’s key, which never reaches the worker. It checks the daily budgets before each call.
The tools that read sessions and decisions, validate a workflow or ask for an allowance run in the dispatcher, as the member who sent the message.
A tool invoke_tool calls, or a trigger sample_trigger samples, runs in a worker of its own that receives only that one connection’s credential.

Stop cancels the turn. A turn that has not stopped ten seconds later has its worker ended. A worker that fails fails its turn with a message naming why, and what the turn already changed is kept.

Connection tools and allowances

The design agent reaches the environment’s connections through five tools: list_connections (connections with their tools’ and triggers’ names), describe_tool and describe_trigger (one schema at a time), invoke_tool (calls a tool) and sample_trigger (fetches recent payloads of a polling trigger, or of a callback trigger whose piece can read recent events, without deploying anything).

invoke_tool and sample_trigger are offered only to a turn whose sender holds workflows:use on the agent, and they never run without that member’s allowance. The turn pauses and the panel shows a Tool permission prompt naming the tool, the connection and the input. Only the member who sent the message can answer it; anyone else reading the thread sees the prompt without its buttons:

Deny: the call fails with an error saying you denied it, and the turn continues.
Allow once: this call runs.
Always allow: this call runs, and later calls of the same tool on the same connection, in this agent and environment, run without asking.

A prompt left unanswered for five minutes counts as denied, and so does stopping the turn.

Usage and daily budgets

Under each settled turn the panel shows the tokens it used (input plus output); pointing at the line shows the input, the output, and the share of the input read from or written to the prompt cache. That count is the design agent’s usage. No amount of money is shown anywhere, and the design agent’s cost is not part of your agent’s spend.

What the design agent may use per UTC day is capped by two budgets, one for the organization and one for each member, counting against the member who sends the message rather than whoever created the agent. The operator sets both (see the config). Once either is reached:

sending a message is refused with a notice naming whose daily limit was reached and that the design agent is available again after midnight UTC;
a turn still queued fails before it starts;
a running turn stops after its current model call, and everything it already changed is kept as pending changes.

Context budget

What the design agent sends a model is kept small by construction:

Its connection tools are always the same five, so the number of tool schemas it carries does not grow with the environment’s connections; a schema enters the context only when describe_tool or describe_trigger fetches it.
Every tool schema a model sees, the design agent’s and a workflow agent’s alike, is a projection of the one the editor shows: editor-only keys, labels that restate a property’s name and redundant option lists are dropped, and a tool’s model-facing description is used where it has one.
Oversized tool results are offloaded by the agent runtime to the thread’s large_tool_results/, where the agent can read them back.
On a Claude model the stable prefix of every model call, the tool schemas and the system prompt, is sent for prompt caching (see prompt caching).

One turn may take a bounded number of steps, set in the config rather than by the environment. A turn that reaches it fails with a message saying so; what it changed is kept, and “continue” in the same thread carries on.