Connect a system, say what the agent may do in it, and ask. It looks things up itself, works out the steps, and puts every change in front of a person before it happens. Every change leaves a receipt.
Quickstart: run one governed action end to end →An agent works inside what you allow. When you connect a system you tick the actions the agent may use there, and which of them only read. That list is the limit: the agent can plan a job from those actions and from nothing else.
Looking is free, changing is not. An action you marked as only reading runs on its own, and each look is recorded. Anything that changes something is proposed, approved by a person, checked in the system afterwards, and given a receipt.
Playbooks are optional. A playbook is your team’s own way of doing one job: when it applies, the steps, the limits on each value, and when to stop and ask. Where you have written one that covers a request, the agent follows it. Where you have not, it plans the job from the allowed actions and shows you the plan. A playbook can’t be approved until it declares the tools it may use.
Sign up and create an agent. Four steps, and only the first three are needed.
Chat is where the work happens. Say what you need the way you would tell a colleague.
QuickBooks Online. The agent reads a client’s bills, vendors and uncategorized expenses only where an owner has switched that on for that client. It can suggest a category for an expense; a person approves it. What it is shown.
Voice, in preview. Press Talk to speak to the same agent and hear it answer. An owner sets a voice up first. Nothing is approved by voice: a change waits under Approvals, as it does when typed. What that involves.
Connect your coding agent to conxtagents over MCP and work with your agent from the tools you already use.
Over MCP you can read the team’s playbooks and memory, propose new ones, and ask for an action: list_actions shows what the playbooks allow, propose_action sends a request, and get_action_status says whether it is waiting, done (with its receipt) or refused, with the reason.
A key can propose, never approve. Approving a playbook or an action is always a signed-in person in the dashboard, or an owner’s standing permission for that one action.
Free during the beta.
Write a whole agent’s playbooks in one Markdown file and import it from the dashboard. Write Use when in the words real requests use, so requests match the right playbook, and list what it May use.
Imported playbooks land as proposed. They govern nothing until a person approves them in the dashboard.
The rule holds whether work arrives through the dashboard, your systems or MCP: the agent proposes, a person approves, and only then does anything change. Reading runs on its own, and is recorded. A request that needs several changes is shown as one plan, which can be approved once; each change still runs only as listed, after the one before it was confirmed. After every change the agent reads the system back, and the receipt says what it found. An owner can let one specific action run on its own once it has a clean record; the receipt then names that permission.
Read the governance model →Your own systems send requests with an inbound key from Settings: POST /ingest/request, or /ingest/request/test to see what would happen without storing anything. The Quickstart walks through it.
Send a request →