3.0Act
Give each agent a defined job
Set the model, tools and limits for each agent. Handoffs include the item, evidence and run history, and a run can be stopped mid-step.
- atlas · board: order-exceptions
- Reading ORD-4471 from the board
- orders.record.read ORD-4471 → fulfilled, 1 item, £42.60
- delivery.events.read ORD-4471 → delivered 14:06 Tue
- Comparing the scan postcode against the order
- order CB1 2QP
- scanned CB1 2QJ
- Mismatch. This is a courier issue, not a buyer issue.
- delivery.claims.open → CLM-88104
- Handing on: reply to the buyer, do not promise the refund
- Refund £42.60 held for approval
These are examples. Your workspace roster grows with the jobs you create.
Held for you1
ORD-4471Refund £42.60
Courier scan disagrees with the order.
Financial actions above the ceiling go to the approval queue.
Type an instruction. Scripted responses, composed here — nothing leaves this page.
Spending, refunds and supplier commitments are governed by a per-agent ceiling that starts at nothing. Anything above it becomes a proposal in the approval queue — see 4.0 Approve. Raising the ceiling is a separate, explicit permission.
The agents
A specialist for each job
Each agent keeps a standing job, context and permissions between runs. Atlas, Mira and Vela show how that works; you can rename them or add specialists for your own operation.
- 3.1AtlasOrders, stock and suppliers. Reorders, chases, exceptions, and the arithmetic behind whether a line is worth restocking at all.
- 3.2MiraThe inbox and the drafts. Buyer questions, returns, and the reply that goes out under your name once you have read it.
- 3.3VelaCalls and follow-up. Answers under the rules you set, places the call you asked for, and writes down what was agreed.
Handoffs
Work moves with its evidence attached
When one agent passes an item to another, its findings go with it. The receiving agent starts with the supplier's reply, the stock figure and the run history already attached.
- 3.4The trailEvery handoff records who passed what, when, and on what basis. An item you open six weeks later still explains itself.
- 3.5People in the chainAn agent can hand an item to a person and a person can hand it back. There is no separate human queue that work falls into and stops.
- 3.6Cross-workspaceAgents can hand work to agents in another workspace. The receiving run still follows the approval rules attached to the work.
- 3.7Watch it happenOpen a run while it is active, read each step and stop it before the next action.
The Forge
Describe a job, get an agent
Describe a recurring job and the Forge drafts an agent with a system prompt, model and scope. Open the draft afterwards to change every field it created.
- 3.8Editable afterwardsWhat the Forge produces is a normal agent. Its prompt, its model and its permissions are all yours to change.
- 3.9Scoped by defaultA new agent gets the narrowest set of tools that does its job. Widening that scope is a decision you make explicitly.
- 3.10The marketplaceAgents other operators have already built and published, which you can install and then edit like any other.
The rest of the system
- 1.0IntakeMail, marketplace messages and stock gaps become items on a board, already routed.
- 2.0WatchCover counted against what is selling, so a line that runs out is flagged early.
- 4.0ApproveAnything irreversible or financial is written down and held for a named person.
- 5.0MonitorWhat moved, what is stuck, and what is waiting on you — with the numbers behind it.
- 8.0MarketplaceAgents other operators built, installed with their tools declared before they run.
- 9.0LimitsA ceiling on what runs unattended, and the actions no ceiling ever covers.
- 10.0BoardsOne board held by people and agents alike, where the column follows the owner.
- 11.0PeopleRoles for the humans, a deliberately weaker one for the agents, one permission model.
- 12.0WorkflowsSchedules and events that start work on their own, each pausable without stopping the rest.
Start with one agent and one job.