AI agents that can be trusted with real actions.
Most agent demos work because nothing they do matters. The engineering starts when an agent can move money, email a customer or change a record — and a retry must not do it twice.
Why agents break in production.
An agent that reasons well in a notebook fails on the boring things. Every one of these is a systems problem, not a prompting problem, and each is why an agent that demos beautifully cannot be given write access.
A retried tool call executes the same side effect twice
The model does not know the first attempt half-succeeded. Without an idempotency key derived from the arguments and a record of committed effects, a transient timeout becomes a duplicate charge.
The agent accumulates more authority than any task needs
Handing one agent every credential is convenient and indefensible. Capabilities have to be granted per agent and narrowed per run into a short-lived token, so a tool outside scope fails at the boundary rather than after the fact.
Long tasks outrun the context window and the plan degrades
If the plan lives in the prompt it decays as the prompt fills. It has to live in durable state, with each step given a focused context assembled from its own plan node.
Non-determinism makes failures impossible to reproduce
Without recorded model calls and tool results there is no debugging, only re-running and hoping. Recording them turns 'it did something strange yesterday' into a replayable run.
Irreversible actions get left to model judgement
Some decisions should never be autonomous. Approval belongs in the execution graph as a node that pauses and persists the run, not as a prompt asking the model to be careful.
Cost is invisible until the invoice arrives
Token and tool budgets enforced per run, with cost attributed per step, make an expensive agent visible in a trace instead of in a monthly bill.
How we build one.
An agent runtime is a distributed system with a model in it. We build it as one: durable state, typed boundaries, explicit permissions and a full execution record.
- 01
Planner
Objective decomposition into a dependency graph with budgets attached, so scope and cost are bounded before the first call.
- Task graph
- Budgets
- 02
Agent runtime
A durable state machine driving the reason–act loop, with resumable checkpoints so a failure at step nine resumes at step nine.
- Durable execution
- Checkpoints
- 03
Tool layer
Schema validation, capability checks, idempotency keys, retries and compensation. Every tool is a typed contract with declared side effects.
- Typed tools
- Idempotency
- Compensation
- 04
Memory
A short-term scratchpad alongside durable memory with promotion and recall scoring, so context is assembled rather than accumulated.
- Recall scoring
- Promotion
- 05
Approval gate
Blocking human decision nodes that hold run state and record the outcome. The run pauses; it does not proceed optimistically.
- Threshold policy
- Audit trail
- 06
Observability and eval
Full traces, cost attribution, replay and regression scoring, so a change to a prompt or a model can be measured rather than argued about.
- Traces
- Replay
- Regression eval
We have already built this.
AUTONOM is our agent operating system: typed tools, scoped permissions, durable memory, human approval gates and an execution log you can audit after the fact. It is a MaatX demonstration rather than a client deployment, and every mechanism described above is running in it. Open it and judge the engineering.
Questions we get asked.
How is this different from wiring up a framework?
A framework gives you the reason–act loop. It does not give you idempotent side effects, capability scoping, durable plan state, approval gates or replay — and those are what decide whether the agent can be trusted with write access. We use frameworks where they help and build the parts they leave out.
Can an agent be safe if it takes irreversible actions?
Only by not deciding them autonomously. We model approval as a node in the execution graph with a threshold policy: below the threshold the agent proceeds, above it the run pauses and persists until a human decides. The judgement stays with the person; the bookkeeping stays with the system.
How do you stop an agent racking up cost?
Token and tool budgets are enforced per run and cost is attributed per step. An expensive agent shows up in the trace of the run that caused it rather than in the monthly invoice.
What does an engagement look like?
Usually Discovery and Architecture first — one to three weeks to decide how the agent should be structured, which actions need approval and where the trust boundaries sit. That produces an architecture you could hand to any competent team. Build follows if you want us to do it.
What it costs, and what you are agreeing to.
The commercial answers in one place, so none of them has to wait for a call.
Typical route in
AI Engineering
Typically $25,000–120,000
Scoped per system
Retrieval that stays grounded, agents that are replayable, and evaluation that runs before anything ships. The model is one component with a contract, not the product.
A starting point for the scope described, not an estimate for your project. Ongoing engineering runs at $75 per hour blended.
Who owns what you build?
You do. On full payment of the fees for an engagement, the intellectual property in everything built specifically for you is assigned to you.
Our pre-existing tools, libraries and internal infrastructure stay ours — but where a deliverable uses them, you get a perpetual, worldwide licence to run, modify and extend it. Nothing we hand over needs us to keep operating it. Open-source and third-party components keep their own licences, and we tell you which ones and what they require.
We also will not name you as a client, describe your project, or publish a case study about it without your written agreement.
What happens if it does not work out?
Either of us can end an engagement with 30 days written notice, or immediately if the other commits a material breach and does not remedy it within 15 days. You pay for work properly performed up to that point, and we hand over completed work along with every deliverable you have paid for.
Two limits worth stating before you ask. We are engineers, not advisers: nothing we deliver is legal, regulatory, tax or financial advice, and a system built to your specification is not an opinion that it is lawful in your jurisdiction. And where our work includes reviewing or auditing code, the findings cover the scope and time agreed — an absence of findings is not a guarantee that nothing is there.
What do you need from me to start?
Not a specification. Discovery exists precisely because most people do not have one — an idea, or a technical problem you cannot yet size, is enough to begin.
What the work does assume: timely access to the people, systems, credentials and environments it touches; decisions and approvals at roughly the pace the timeline assumes, since delays on your side move both dates and cost; and that you have the right to give us whatever you give us, including data, code and third-party material.
Why you rather than the alternative?
Against hiring a senior engineer in-house: sourcing one takes months and commits you permanently. Discovery runs 1–3 weeks, and you keep the architecture whichever way you then go — including if the answer is to make that hire.
Against the cheapest contractor available: you will pay less per hour. Our argument is that the architecture decision is the one that is expensive to reverse, which is why we sell it first, separately, and at a price you can say yes to before committing to a build.
Against a larger firm: there is no account layer. The people who scope the work are the people who build it.
And when not to hire us: if a no-code or off-the-shelf tool still fits what you are doing, stay on it. We are worth paying once you have hit a ceiling you cannot engineer around from where you are.
These are summaries. The binding version of the ownership, exit and liability terms is in our Terms of Service. A person reads every enquiry. We usually reply within a few hours.
Start a technical assessment
Building an agent that takes real actions, where a retry must not charge a customer twice?
Send us the architecture or the problem. We will come back with the technical risks we can see and a sensible path forward, free, and tell you if we are not the right people for it.