Research
Agent systems
Where we have formed views about building agents that act on real systems without becoming a liability.
The question we keep returning to
An agent is only useful when it can act, and only safe when its ability to act is bounded. Almost every design decision in this area is a position on that trade.
The industry default is one capable assistant with broad access. We have consistently found narrow specialists easier to reason about, easier to test, and considerably easier to explain to a client who has to sign off on what it may change.
What we have concluded so far
- Scope is a design artefact, not a prompt instruction. An agent without a tool cannot misuse it, which is a stronger guarantee than asking it not to.
- Handover has to be a designed behaviour with its own success criteria, not the branch taken when nothing else matched.
- Read-only by default, with write access granted per tool and usually behind a confirmation, has cost us far less rework than the reverse.
- A transcript of every tool call is worth more than any amount of prompt engineering when something goes wrong.
- Confident wrong answers are the failure mode that matters. Grounding responses in retrieved records makes them checkable, not correct.
Open questions
How to evaluate an agent whose value is in the actions it takes rather than the text it produces. Standard benchmarks do not cover this well, and per-project evaluation sets are expensive to build.
How much autonomy is appropriate before a human confirmation step stops being a safeguard and starts being ignored.
Start here
Tell us what is slow, manual, or breaking.
Answer a few questions and get a written brief back — scope, proposed architecture, and what it would take to build.