Bounded autonomy
Each tool gets the least authority it needs, with approval gates for irreversible actions.
AI systems / Agents
Agents built around consequences.
Drag or use arrow keys to orbit
AI agents
Tool-using agents with permissions, stop conditions, evaluation, and human review where actions matter.
What we build
Useful from
day one.
ClaudeOpenAIMCPPython
Evaluation before trust
Real tasks, adversarial inputs, and failure recovery become repeatable tests.
A visible decision trail
Every tool call and outcome can be inspected when a workflow needs explanation.
The route to production
Clear steps.
Visible progress.
Discover
We map the real workflow, risks, users, and success measure before choosing an implementation.
Build
Working software lands in visible increments, with the hardest assumptions tested first.
Prove
We validate against production-shaped data, failure paths, performance, and real use.
Ship
Deployment, monitoring, documentation, and a clean handover are part of the build.
Verified client reviews
In their words.
“Rapid and great work, with high technical knowledge. Highly recommend.”
“I recommend him due to his thoroughness and quality.”
Before you ask
Questions,
answered.
When is an agent the right answer, and when is a workflow cheaper?
If you already know the sequence of steps, write the workflow. It is cheaper, faster and debuggable, and it does not surprise you. An agent earns its cost only where the next step genuinely depends on what came back from the last one, and where the space of tasks is too wide to enumerate. Selling an autonomous agent for a job a deterministic workflow does better is the most common waste in this field.
How much autonomy do you give an agent?
As little as the job allows. Every tool gets the least authority it needs, irreversible or billable actions sit behind an approval gate, and the agent's permissions are scoped per user rather than inherited from a service account that can see everything. Autonomy is something a system earns by passing evaluations, not the default setting on day one.
How do you test something non-deterministic?
In two layers. Deterministic integration tests record the model's responses once and replay them, so your agent loop, tool dispatch and tools still execute for real while the model's answers come off a recording — fast, free and stable enough to run on every commit. Our open-source cassette does exactly that. Quality is a separate question, answered by evals scored against live model output on their own cadence.
What do you evaluate — the answer, or how it got there?
The trace. For an agent, the final answer can be right for the wrong reasons and wrong for recoverable ones, so the evaluation set scores the path: which tool it chose, what it passed, how it handled a failed call, and whether it stopped when it should. Real tasks and adversarial inputs go in the set, and it is what tells you a change is an improvement rather than a hunch.
What stops an agent looping forever?
An explicit stop condition, designed before the loop is. Budgeted steps, a definition of what done looks like, and a path for giving up and handing back to a human with what it learned. Agents that run away are almost always agents that were never told what finished means.
How many tools should an agent have?
Fewer than feels natural. Three well-shaped tools beat thirty thin ones: the model picks correctly more often, the traces are legible, and you are not paying for thirty schema descriptions in the context window on every single turn. Tools are designed around the task the agent performs, not mirrored one-to-one from your endpoints.
What happens when a tool call fails?
The agent should handle it the way good software handles an error: a failed call, a malformed input or a concurrent user must not produce a confident, wrong action. Tools return typed errors the model can read and act on, retries are bounded, and anything the agent cannot resolve is escalated with the context a person needs to finish it.
Can we see what the agent did?
Yes — every tool call and outcome is inspectable. That trail is what makes an agent defensible when someone asks why an action was taken, and it is also the raw material for improving it: the failure patterns you can see are the ones you can fix. An agent that cannot explain itself cannot be trusted with anything that matters.
Can it use the systems we already run?
That is usually the whole job. We connect agents to existing APIs and internal systems through typed, permissioned tools — often an MCP server where the tools should be reusable across clients — so the agent works inside your current stack rather than requiring a parallel one.
Why does an agent need maintenance after launch?
Because it is not a static artefact. Models are updated and reason differently, your own APIs change their responses, and users keep finding inputs nobody imagined — something that worked in March can misbehave in June with no change on your side. Without evals, monitoring and an owner, an agent degrades quietly. Plan for the upkeep, not just the build.
From the journal
Further reading.
Start with a paragraph, a Figma, or a Loom.
Build this properly.Reply within one business day · one clear scope · one fixed number