AUTONOM
AI Agent Operating System
AI agents that can reason, use tools and execute workflows.
Put AI agents into real workflows without risking a retry that charges a customer twice.
- Durable execution
- Typed tools
- Idempotency keys
- Capability scoping
- Replay + eval
An agent runtime with typed tools, scoped permissions, durable memory, human approval gates and an execution log you can audit after the fact.
What the product is built around.
AUTONOM treats an agent run as a durable, resumable execution rather than a chat session. Tools are typed and permissioned, side effects are idempotent, approval gates are part of the graph, and every step is recorded — so an agent failure is debuggable instead of mysterious.
Durable execution
A run is a persisted state machine. It survives process restarts, resumes from the last completed step and never re-executes a committed side effect.
Least authority per task
Tools are granted per agent and narrowed per run. An agent summarising tickets cannot reach the payments API because the capability is not in its scope.
Humans in the graph, not around it
Approval is a node with a real gate. The run pauses, holds state and resumes on decision — it does not proceed hopefully and apologise later.
What makes this hard.
Agent demos work. Agents in production do not, for boring reasons: they retry a side-effecting call after a timeout, they hold too much authority, they lose context halfway through a long task, and when something goes wrong there is no record of what the agent actually did.
- 01
A retried tool call executes a side effect twice
- 02
Agents run with far more authority than any single task requires
- 03
Long tasks exceed the context window and the agent forgets its own plan
- 04
There is no audit trail of what was called with what arguments
- 05
Nothing stops an agent from taking an irreversible action unsupervised
What the system does.
AUTONOM treats an agent run as a durable, resumable execution rather than a chat session. Tools are typed and permissioned per run, side effects carry idempotency keys so a retry after a timeout is a no-op, approval gates are nodes in the execution graph that hold state, and every model call and tool result is recorded so a failure is replayable instead of mysterious.
Idempotent side effects — a retried write never executes twice
Capabilities scoped per agent and narrowed per run into a short-lived token
The plan lives in durable state, not the prompt, so step 30 is as coherent as step 2
Approval gates pause and persist rather than proceeding optimistically
Full trace with cost per step, and deterministic replay against recorded responses
AUTONOM, as working interface.
Rendered UI, not a mockup — real tables, charts, filters and states. Try ⌘K for the command palette.
Runs (30D)
84,204
Task success
91.8%
Tool calls
1.24M
Cost / run
$0.084
Agent builder — invoice-recon v7
Goal
Reconcile unmatched supplier invoices against purchase orders and route anything above tolerance for human approval.
Instructions
- Match on supplier, amount window and date proximity
- Never approve an invoice that has no purchase order
- Escalate any variance above €500 regardless of confidence
- Record the reasoning for every match in the run log
Memory
- Long-term
- Supplier naming conventions
- Long-term
- 18 prior cycles
- Short-term
- Run scratchpad
- Recall
- Top-k 6 · 0.82 min
Tools
- Searchread
- Databaseread
- APIwritegate
- Browserread
- CRMread
- Emailwritegate
- Human Approvalgate
- Paymentswritegate
Permissions
- Granted
- erp:read, erp:flag
- Gated
- email:send
- Denied
- payments:*, erp:delete
- Token TTL
- 15 min per run
- Tool budget
- 40 calls
Execution
Live run — run_8fK2q · invoice reconciliation agent
Objective
Reconcile the 14 unmatched supplier invoices from last week against purchase orders, flag discrepancies above €500, and draft approval requests for anything that clears.
- 01Decompose objectiveplannerComplete1.2s
6 sub-tasks derived · dependency graph built · budget 40 tool calls
- 02Fetch unmatched invoiceserp.invoices.listComplete0.8s
14 records · read-only scope · 0 side effects
- 03Retrieve matching purchase orderserp.po.searchComplete2.1s
12 of 14 matched on supplier + amount window · 2 ambiguous
- 04Resolve ambiguous matchesknowledge.searchComplete1.6s
Retrieved supplier naming conventions · both resolved · confidence 0.93
- 05Compute discrepanciessandbox.pythonRunning3.4s
Executing in isolated sandbox · no network · 9 of 14 compared
- 06Flag items above €500erp.invoices.flagAwaiting approval
Write scope · blocked pending human approval · 3 items in scope
- 07Draft approval requestsemail.draftQueued
Draft only · sending requires a second approval gate
- 08Write run summarymemory.writeQueued
Persist outcome to long-term memory for the next reconciliation cycle
Run context
- Run ID
- run_8fK2q
- Agent
- invoice-recon v7
- Status
- Awaiting approval
- Steps
- 5 done · 1 running · 2 queued
- Tool budget
- 18 / 40 used
- Tokens
- 84,210
- Cost
- $0.14
- Capabilities
- erp:read, erp:flag, email:draft
- Denied
- payments:*, erp:delete
Agent graph
invoice-recon v7- User requestTrigger
Scheduled weekly · Mon 07:00
- PlannerAI
Decompose into a dependency graph
- Agent loopAI
Reason → select tool → observe → repeat
- Tool layerAction
Typed, scoped, idempotent
SearchDatabaseAPI - Human approvalHuman
Blocks on any write above threshold
ApproveRejectEdit - Result + traceOutput
Durable log · replayable
Tool registry
| Tool | Scope | Calls (30D) | p95 | Error rate | Idempotent | Approval | Status |
|---|---|---|---|---|---|---|---|
| erp.invoices.list | read | 184,210 | 0.8s | 0.04% | N/A | None | Stable |
| erp.po.search | read | 142,880 | 2.1s | 0.11% | N/A | None | Stable |
| erp.invoices.flag | write | 8,420 | 1.2s | 0.02% | Keyed | Required | Stable |
| sandbox.python | compute | 96,104 | 3.4s | 1.84% | Pure | None | Stable |
| email.draft | write | 24,610 | 0.6s | 0.08% | Keyed | Required | Stable |
| browser.navigate | read | 41,208 | 6.8s | 4.21% | N/A | None | Flaky |
| payments.transfer | write | 0 | — | — | Keyed | 2-of-2 | Restricted |
Write-scope tools require an idempotency key and pass through an approval gate · counts shown for illustration
Task success rate
90DFailure attribution
- Tool error / timeout41.0%
- Plan degradation24.0%
- Budget exhausted18.0%
- Approval rejected11.0%
- Guardrail triggered6.0%
Guardrails
per run- Tool-call budget18 / 40
- Token budget84K / 200K
- Wall-clock limit4m 12s / 15m
- Write operations3 / 5
- Recursion depth2 / 8
Memory
- Supplier naming conventionsLong-term · referenced in 412 runs0.93
- Prior reconciliation outcomesLong-term · 18 cycles retained0.88
- Current run scratchpadShort-term · cleared on completionephemeral
- Ambiguity resolutionsLong-term · promoted after 3 confirmations0.91
- Failed approach logLong-term · prevents repeating dead ends0.76
Tool definition
typescriptdefineTool({ name: "erp.invoices.flag", scope: "write", input: z.object({ invoiceId: z.string().regex(/^INV-\d{6}$/), reason: z.enum(["amount", "missing_po", "duplicate"]), delta: z.number().finite(), }), // Same key never executes twice, even across restarts. idempotencyKey: (i) => `flag:${i.invoiceId}:${i.reason}`, approval: { required: true, threshold: { delta: 500 } }, retry: { attempts: 3, backoff: "exponential", on: ["5xx"] }, timeout: "10s", compensate: async (i) => erp.invoices.unflag(i.invoiceId),});Approval decisions
- run_8fK2q · flag 3 invoicesPending
Total delta €1,842 · awaiting approver · run state held
- Approved with edit09:41:22
run_4Kq2m · approver reduced scope from 8 to 5 invoices
- Rejected09:12:04
run_9Rt5n · supplier dispute open · agent logged reason and stopped
- Auto-approved08:47:51
run_2Wb7x · all deltas below €500 threshold · policy path
- Guardrail halt08:04:18
run_6Ln3v · recursion depth 8 reached · run terminated cleanly
Tool error rate by hour
Interface states
UI statesNo agents yet
Create an agent, give it an objective and grant it the tools it needs.
New agentEmpty stateRun halted — guardrail triggered
The agent attempted a tool outside its granted capabilities. The run was stopped before execution and the attempt was logged.
How it is put together.
The tool layer is the security boundary. Reasoning quality is a product problem; tool authority is a safety problem, and they are kept separate.
- 01
Builder & Console
Agent composition, run inspection, trace viewer and approval UI.
- Next.js
- React
- Streaming traces
- 02
Planner
Objective decomposition into a dependency graph with budgets attached.
- LLM
- Structured output
- DAG
- 03
Agent Runtime
Durable state machine driving the reason–act loop with resumable checkpoints.
- TypeScript
- Durable execution
- Checkpointing
- 04
Tool Layer
Schema validation, capability checks, idempotency, retries and compensation.
- Zod
- Capability tokens
- Idempotency keys
- 05
Memory
Short-term scratchpad plus durable memory with promotion and recall scoring.
- PostgreSQL
- pgvector
- Summarisation
- 06
Approval Gate
Blocking human decision nodes that hold run state and record the outcome.
- State machine
- RBAC
- Notification routing
- 07
Observability & Eval
Full traces, cost attribution, replay and regression scoring.
- OpenTelemetry
- Trace store
- Eval harness
What the product does.
The capability set the demonstration is built around.
Agent builder
Visual composition of objectives, tools, guardrails and approval gates.
Typed tools
Schema-validated tool definitions with retries, timeouts and idempotency keys.
Memory
Scoped short-term and durable long-term memory with summarisation and recall.
Permissions
Capability-scoped credentials per agent and per run with automatic expiry.
Workflows
Multi-step plans with branching, parallel execution and compensating actions.
Execution logs
Full trace of reasoning, tool arguments, results and token cost per step.
Human approval
Blocking gates on irreversible actions with context and a decision record.
Evaluation
Task-level scoring, regression suites and replay against recorded runs.
Challenges, and the MaatX approach.
The problems that actually decide whether a system like this survives production — and how we address each one.
A retried tool call executes the same side effect twice
Every write-scope tool declares an idempotency key derived from its arguments. The runtime records committed effects, so a retry after a timeout is a no-op rather than a duplicate.
Agents accumulate more authority than any single task needs
Capabilities are granted per agent and narrowed per run into a short-lived token. A tool outside scope fails at the boundary before execution, and the attempt is logged.
Long tasks outrun the context window and the plan degrades
The plan lives in durable state, not in the prompt. Each step gets a focused context assembled from the plan node plus recalled memory, so step 30 is as coherent as step 2.
Non-determinism makes failures impossible to reproduce
Every model call and tool result is recorded. A run can be replayed against the recorded responses, which turns 'it did something strange once' into a debuggable trace.
Irreversible actions cannot be left to model judgement
Approval is a node in the execution graph with a threshold policy. The run pauses and persists; it does not proceed optimistically. Compensating actions are declared alongside the tool that needs them.
Cost is invisible until the invoice arrives
Token and tool budgets are enforced per run with cost attributed per step, so an expensive agent is visible in the trace rather than at month end.
The stack behind it.
Planning & reasoning
- LLMs
- Tool calling
- Structured output
- Objective decomposition
- Dependency DAG
- Focused context assembly
Durable runtime
- TypeScript
- Durable execution
- Persisted state machine
- Step checkpointing
- Resumable runs
- Deterministic replay
- Compensating actions
Tool layer
- Zod schemas
- MCP
- Idempotency keys
- Capability tokens
- Exponential backoff retries
- Per-tool timeouts
- Sandboxed compute
Memory
- PostgreSQL
- pgvector
- Short-term scratchpad
- Durable long-term memory
- Summarisation
- Recall scoring
- Memory promotion
Guardrails & approval
- Blocking approval gates
- Threshold policy
- RBAC
- Tool-call budgets
- Token budgets
- Wall-clock limits
- Recursion-depth caps
Observability & eval
- OpenTelemetry
- Trace store
- Per-step cost attribution
- Run replay
- Eval harness
- Regression suites
Console & platform
- Next.js
- React
- Streaming traces
- Notification routing
- Redis
- Queues
- Kubernetes
How it grows with the business.
The same system at three stages. Most products should not start at the third — but the architecture should not have to be thrown away to get there.
One agent, read-only tools, proving the reasoning loop is useful.
- Single agent with a fixed objective
- Read-only tool set
- Full execution tracing
- Token and tool-call budgets
Write-capable agents with approval gates and evaluation.
- Idempotent write tools with compensation
- Human approval gates on irreversible actions
- Durable execution with resumable checkpoints
- Regression eval suite and run replay
Agent platform with governance across teams.
- Multi-agent delegation with shared memory
- Formal policy for what an agent may never do
- Per-step model routing for cost control
- Simulation environment for pre-deployment testing
Where it could go next.
Directions this system would extend into.
- 01
Multi-agent delegation with negotiated sub-goals and shared memory
- 02
Learned tool selection from historical run outcomes
- 03
Simulation environment for testing agents against synthetic systems
- 04
Fine-grained cost optimisation via model routing per step
- 05
Formal policy language for expressing what an agent may never do
Building an agent that takes real actions, where a retry must not charge a customer twice?
We built AUTONOM to work through exactly this. Tell us where you are and we will tell you what we would do differently for your constraints.