How it works
Five steps to a working agent, and one guarantee about what it can do.
Connect your software
Give AgentOS an MCP server, a REST API — from an OpenAPI document or endpoints you describe — or a database. It reads what is there: endpoints, tables, relationships, MCP tools.
Your credentials are encrypted before they are stored and decrypted only inside the connector at the moment of a call. They never appear in a prompt, a log or a trace. Nobody, including a platform administrator, can read them back.
discovery · PostgreSQL
ready- list_customers READ
- sales_report ANALYTICS
- update_customer UPDATE
- delete_customer DELETE
Eleven tables became forty-one tools. Each carries the schema its arguments are checked against.
Review the agent it writes
Every discovered capability becomes a tool with a schema, a risk level and an operation type. From those, AgentOS writes an agent: a name, a purpose, instructions describing the system and how to behave, and a tool selection.
Destructive tools arrive switched on but gated. Leaving deletion out gives you an agent that cannot do its job, so people work around it by hand — with no audit trail. Leaving it ungated is reckless. On, but requiring a human, is the only honest option.
approval
waiting- customer_reference:
- 100
- reason:
- duplicate record
The reviewer sees the call, not a summary of it — this tool, this customer, this reason.
Deploy it and use it
Talk to it in web chat, put it behind Telegram, Slack or WhatsApp, or save a question as a report that runs on a schedule. Same agent, same checks, whichever door the request came through.
Chat streams the answer and the agent’s reasoning as they happen, so a run that takes thirty seconds is legible rather than a spinner.
chat
which customers have not ordered since March?
- proposed find_inactive_customers
- read — ran immediately
Twenty-three of them. The largest by past spend are Northwind, Ridgeway and Calder — between them about £54,000 last year.
Watch what it decides
Every run records its steps in order: what the model proposed, what was validated, what policy said, what actually ran.
Including the calls that were refused. A trace showing only successes would hide the most interesting thing about a run — the moment something was stopped, and why.
execution trace
refusedthe model proposed
delete_customer(customer_reference: 1)
- Tool resolved exists · owned by this workspace
- Arguments validated matches the declared schema
- Permission checked viewer role — tool.execute not held
Refused before the connector was reached, and recorded as a refusal rather than quietly dropped.
Check what it changed, months later
Separately from the run-by-run trace, every record an agent created, updated or deleted in your own systems is written down: which record, which agent, who asked, and whether a person approved it.
This is the question people actually ask weeks afterwards, and a trace is the wrong shape to answer it — you would have to know which run to look in. Search by the record instead.
changes
- Deleted Deleted customer 100 approved by Sarah · 12 Aug
- Updated Updated 3 records in orders Support Agent · 12 Aug
Kept for as long as your plan allows — 7 days on Free, up to 90 on Business.
What the model can and cannot do
The model decides what to propose. It never decides what happens. Every call it suggests passes these checks first, and none of them consult it.
- 1 Resolve The tool exists, this agent has it, and your organization owns the connection behind it.
- 2 Validate Arguments match the tool’s schema. Undeclared keys are dropped before the connector sees them.
- 3 Authorise Policy decides — including whether the person the agent is acting for actually has the permission.
- 4 Execute Only now, and only through the connector.
- 5 Audit Always, whatever happened.
Validation runs before authorisation on purpose: a malformed proposal should be refused outright, not turned into an approval request a human has to read and reject.
The thing worth trying first
Ask an agent to delete something. It will stop and show you exactly what it wanted to do, with which values, and wait. Approve it and the run continues from where it paused; reject it and the agent is told why, and explains itself.
Your approval covers that one call with those exact values — not the tool, and not the category. If anything about the call changes before it runs, it stops again.