Services · 01
AI Systems & Agents. The model proposes. A check decides.
Production AI systems, with validation and control around the model. Not a demo that works on a clean example, and not a wrapper around somebody else’s API.
What I build here
The model is one component of a system.
I design and build systems where a model is given a job and a boundary: what feeds it, what it is allowed to reach, what checks its answer, what is logged, what a person is asked to approve, and what happens when it is confidently wrong.
Where behaviour has to be deterministic, I write deterministic code. That is not a limitation on what I will build. It is the position that makes the rest of it trustworthy: a system that reaches for a model only where judgment is genuinely required is a system whose model calls can be defended one by one.
Agents
An agent is a loop. A loop needs a wall around it.
An agent is a model that is allowed to act, look at what happened, and decide what to do next. That loop is what makes it useful on work nobody can specify in advance. It is also the whole of the risk, and the two are the same property: a system that chooses its own next step is a system whose next step you did not choose.
So I build them the way I build everything else on this page, which is walls first. The paragraph above is not an argument against agents. It is the reason one can be trusted with a real account: the parts that must behave the same way every time are code, and the loop is the part that is allowed to think.
- 01 Declared tools, and nothing outside the list LIMIT
- 02 A bounded number of turns, so it stops instead of spiralling LIMIT
- 03 Retrieval over a corpus you control, not a model’s memory of one LIMIT
- 04 A check between the agent and anything it writes LIMIT
- 05 A run log detailed enough to reconstruct the decision afterwards LIMIT
Where more than one model is involved, the routing between them is a design decision rather than a preference: the fast one for volume, the careful one for the calls that are hard to take back. Where the input matters more than the model, which is most of the time, the work is context engineering. Deciding what the model is allowed to see, in what order, and what has been kept out of its way on purpose.
And the way anybody finds out whether it works is a set of cases with known answers, run again after every change. A demo is one case that went well.
Three more, and they are capabilities rather than arguments. I work with MCP at both ends, the servers that expose a tool and the clients that consume it. I build chat assistants and bots, on the same terms as everything else on this page: what they may do on their own, what they have to ask about first, and what is written down afterwards. And voice, where this site has a built example rather than an assertion: speech transcribed on the machine it arrived on, because the material was not allowed to leave it.
Open the diagram description
A dark diagram in two parts. On the left and in the centre, a large rectangle drawn in bright acid green stands for the wall built around an agent. Inside the wall, three boxes sit in a row and form a repeating cycle. The first box reads: Model decides the next step. An arrow points right to the second box, which reads: Tool runs. Another arrow points right to the third box, which reads: Result comes back. From the third box a long arrow drops down, travels back along the floor of the wall to the left, and turns up into the first box, so the three steps run again. A small line of text under that return path reads: repeats until a stop condition. The wall has five gates cut into its edges, each one a small opening carrying a number. Two gates sit on the top edge and three sit on the bottom edge, and each gate is one limit on what the loop may touch. Gate zero one is declared tools, and nothing outside the list. Gate zero two is a bounded number of turns, so it stops instead of spiralling. Gate zero three is retrieval over a corpus you control. Gate zero four is a check between the agent and anything it writes. Gate zero five is a run log detailed enough to reconstruct the decision. On the right, outside the wall, a box reads: Anything hard to undo, with the examples sending, paying and deleting. An arrow points down from that box into a second box, which reads: A person, who approves it or does not. A dashed warm gold line leaves the cycle, heads towards those two boxes, and stops dead just short of the wall at a short bar marked no direct path, so the loop never reaches them by itself. The closing line reads: The model proposes. A check decides.
Drawn from this page’s own copy. It is the shape I build to, not a picture of any one client’s system.
What it solves
Work that has to be read before it can be done.
- 01 Read messy email, documents, images or PDFs SUITED
- 02 Extract structured fields from unstructured text SUITED
- 03 Classify and route incoming work SUITED
- 04 Turn a sentence a person typed into a structured record SUITED
- 05 Draft a response for review SUITED
- 06 Check one input against another and report where they disagree SUITED
- 07 Work that takes several steps, where the next one depends on the last SUITED
I do not put a model where a deterministic rule is simpler, cheaper and easier to verify. A rule that always does the same thing is not a lesser answer than a model that usually does.
The operating principle
“The AI step is the easy part.”
Calling a model is an afternoon. What takes the work is everything that has to be true around it before anybody can rely on the answer, and that part is ordinary engineering done properly.
What the production-grade version looks like
Five controls, and none of them is about the prompt.
- 01 Make duplicate events safe REQUIRED
- 02 Retry slow or unavailable APIs REQUIRED
- 03 Keep secrets out of workflow nodes REQUIRED
- 04 Log every run and alert on failures REQUIRED
- 05 Keep a person in the loop for risky calls REQUIRED
There is a sixth that is not on the list because it is not a control, it is a boundary: a model is never the last step before something is filed under somebody’s name.
Hands-on
What I personally do.
Design the system and the boundary around the model. Build the workflows and the custom code either side of it. Build the validation step that can refuse. Wire up the run logging and the alert. Handle the secrets. Write the review path and the documentation the team runs it from.
Also, and this is a capability rather than a disclaimer: review discipline on AI-written code. I use AI coding tools every day, and nothing they produce reaches a real account without being read line by line, tested against safe fake data, and dry-run first.
The proof
Four model nodes, and one of them only says no.
On the flagship system, four model nodes do two different jobs. Two read documents, one image and one PDF. A third turns a free-form Slack message into structured JSON. The fourth is a validation chain that compares what a person wrote against what was actually attached, and refuses the ones that do not agree.
On a smaller build, the whole model runs on the device the audio is already on, because the material was somebody’s private correspondence and no version of sending it to a service was acceptable.
Where the model decides, and where it does not
The validation chain, the boundary around it, and what happens to the cases it refuses.
n8n Cloud · Gemini · Validation gatesVoiceInbox
Transcription that never leaves the machine, with the one API key in the system keychain.
Tauri · Rust · On-device / local inferenceWorked example
Document intake that routes itself.
The workflow reads the email, pulls the attachment, extracts the fields it needs and routes the document. A model handles the messy text that plain rules would miss, and anything it should not decide goes to a person instead of being guessed at.
Advice, before or instead of a build
Sometimes the useful answer is that you do not need the build.
Architecture and advisory is one of the three ways I work, and on AI it is the one people ask for first. Review what you already have, find the real constraint rather than the loudest symptom, and design the approach. Nothing gets built until you decide it should be.
An audit of an AI or automation system somebody else built asks the questions I would ask about my own. What is the model actually deciding. What would catch it being confidently wrong. What is logged, and who is alerted when a run fails. Where do the secrets live. What happens to the work in flight when it stops.
It produces a list with severities and what I would change first, not a score. Consulting is how I enter this practice rather than a separate product with its own price list, so if the review ends with me saying there is no build worth doing, that is a finished piece of work rather than a lost sale.
What next
Scope, then a fixed number.
Most first projects fall between a two-week scoped build and a two-month one. The number is fixed against a written scope after a discovery call, so you approve it before anything is built. What moves it inside that range, in full.
Where a person is still reading
What is a person reading by hand?
Tell me what arrives as messy text or documents before anything can happen. I will tell you whether a model helps, and where a plain rule would be safer.
Ask Dan on WhatsApp (opens in a new tab)or email dan@burdetsky.xyz