I have written before that the best thing my agents do is not think. The most reliable parts of my personal agents are the parts that never touch a language model, even when AI is used as an overall monitor. Scheduled jobs. Database queries. Slash commands that skip the LLM and hand me an answer in under a second. The conversational engine is the part I trust least and pay the most for.
That post described what I built. I need to turn to where I think it all points.
I have argued that AI did not erase the entry-level job, it changed it. Mark Zuckerberg has admitted AI agents have not been progressing as he had expected. While his comments appear targeted towards his company’s efforts, I believe his findings are shared by many many others.
The line from my piece I keep coming back to is this. AI got good, fast, at the work with a clear right answer, because code either compiles and passes the test or it does not. Architecture and judgment have no unit tests. There is no instant grader for whether you drew the right boundary, and you may not find out you were wrong for a year (or more). That is the structural reason the gap stays open. The checkable work races ahead. The judgment does not.
If that is right, the question turns practical. How do you build something reliable on top of an engine that is excellent at the checkable work, shaky on the judgment, and not fully predictable even on the parts it is good at?
I keep running into the same answer from different directions, and I’m here to plant another stake in the ground.
Same conclusion, different doors
Alon Fliess, a fellow Microsoft Regional Director, has been building a tool called Specrew. His problem is not mine. He is governing AI-assisted software development, making sure the agent follows a real lifecycle instead of charging ahead to “done.”
I am trying to make personal agents reliable enough to run my day.
Different problems. Same answer.
He lands on three actors. The agent drives the work. Deterministic code enforces the boundaries. The human approves the gate. His sharpest point is that instructions are not governance. You can tell a model to stop and wait for approval, and a strong model often will. But that is cooperation, not enforcement. The model can forget. It can compress the rule out of its context. It can decide that being helpful means pushing forward.
So the real boundary cannot live in the prompt. It has to live in code.
I learned the same thing watching Falcon drift the moment the structure underneath it got loose.
We came at this from opposite ends. He started with a methodology and worked down to the code that enforces it. I started with the code and worked up to a thesis about why it works. I argue we met at a similar convergence.
The self-driving car problem
A year or two back I sat in a conference keynote where the speaker, an AI researcher, walked through the history of self-driving cars. I do not have the specific references, so work with me here. For years the approach was essentially rule-based. Give the car enough rules (i.e. laws) and it can handle the road. The trouble is you can never write enough rules. There is always one more situation nobody anticipated. A ball rolls into the street at the wrong speed. A sign is bent in an odd shape. A cop waves you through a red light with an unplanned gesture.
The automation field moved toward probability, for obvious reasons. Let the system reason about situations it has never seen, based on millions of hours of driving, instead of looking them up in a table. That works far better for the open road.
But here is the catch the presenter left us with. We do not live in a probabilistic world. When you are merging onto a freeway, you do not want the most likely answer. You want the right one.
Therefore the real system is a merge of multiple approaches. Probability for the open-ended judgment. Determinism for the parts that cannot be wrong.
That merge is the whole story. The only real question is which tasks belong on which side of the line, and who draws it.
It is the same line between the checkable work and the judgment. The work with an answer key is the part you can hand to deterministic code and stop worrying about. The judgment, the ambiguous call, is the part that stays probabilistic and stays with a person. Name the line that way and the architecture starts to draw itself.
Why this keeps happening
This is not a coincidence that three (or thousands) people stumbled into. It comes straight out of what a language model is.
A model is probabilistic by design. That is not a bug to be patched out in the next release. Even with the temperature turned all the way down, the same input does not reliably produce the same output. One analysis found accuracy varying by up to 15 percent across runs at temperature zero, with far wider swings traced to architectural factors like how models route through their internals (Compiled AI, 2026). Zero temperature is supposed to be the deterministic setting.
It still is not deterministic.
You cannot fix that by adding a second model to check the first. A probabilistic system checking a probabilistic system just stacks uncertainty on uncertainty. You get a more confident guess, not a guarantee.
Practitioners already know this, even when they have not written it down. A review of 1,200 production AI deployments found the dominant pattern was teams moving their safety logic out of prompts and into code (ZenML, 2025). Not because a framework told them to. Because they got burned, and code was the only thing that held.
The pattern has a name
Once I started looking, I found the idea everywhere under different labels.
Researchers described a version of it back in 2023, where one model writes a reusable tool and another model uses it (LLMs as Tool Makers). The expensive reasoning happens once, when the tool is built. After that, the tool just runs.
Birgitta Böckeler at Thoughtworks frames the split cleanly in her work on harness engineering. Some checks are computational. Deterministic, fast, run by the CPU, reliable in milliseconds. Tests, linters, type checkers. Others are inferential. Semantic, slow, expensive, run by a model, and never quite reliable. The skill is knowing which job goes to which.
So the language is out there. What I have not seen anyone say plainly is the part that interests me most.
The probabilistic builds the deterministic
Here is my next stake in the ground.
A high-value thing a probabilistic engine can do is build and manage the deterministic code that makes its own output trustworthy.
Not get smarter until we can finally trust the guess. Build the parts that do not need to be guessed at, hand them to code, and step back out of the loop.
That sentence oversells easily, so let me be precise. The model is not “choosing” to write its own guardrails the way an engineer chooses to. It does not know its own limits. It does not know anything. But we can design a system where the probabilistic engine generates the deterministic infrastructure, and that design is the move that matters. The intelligence builds the plumbing once. The plumbing runs forever after, the same way every time, for almost nothing.
This is the organism again. When you start running, you breathe harder. Your heart rate climbs. None of that routes through your conscious mind. The brain does not manage your heartbeat. It built a body where the heartbeat manages itself, and it gets involved only when something genuinely new shows up. The brain is the expensive, flexible, slow part. You do not want it running your circulatory system, and it does not want the job.
A model that writes a script and then runs the script is doing the same thing. It is using the costly, flexible reasoning to create something cheap, rigid, and reliable, then getting out of its own way.
Where the human belongs
This is where Alon’s third actor matters, and where I think a lot of people place the human wrong.
The human does not belong inside every loop. That does not scale, and it wastes the one thing humans are actually good for. If a person has to approve every database write, you have not built an agent. You have built a slow person. Then too many of us go the other way and take ourselves out of the loop entirely. That is the opposite failure, and it is the more dangerous one.
The human belongs at the boundary. Approving the deterministic infrastructure the model builds, because the model cannot fully audit its own work. Advancing the gate when the work materially changes. Alon’s word for it is the right one. The human is the authority, not the guardrail. The code is the guardrail. The human decides where the guardrails go.
That is a smaller job than supervising every step, and a far more important one.
Where I think this goes
I do not think we are waiting on a model good enough to make this architecture unnecessary. If the gap really does stay open, the way I have argued, this is not a stopgap until the models catch up. It is the shape. And even the checkable work does not get fully reliable on its own. The variance does not go to zero with scale. The probabilistic engine stays probabilistic no matter how capable it gets, because that is what it is. A more capable model raises the ceiling on what it can build. It does not turn a guess into a guarantee.
So the reliable systems, the ones an enterprise can actually stand behind, will be the ones where the model builds its own deterministic scaffolding and a human owns the boundaries. There is a real bonus hiding in that arrangement. Every task you push down to code is a task you are no longer paying a model to reason through on every run. The cost curve and the reliability curve bend the same direction, which is rare and worth noticing.
I did not arrive at this by reading papers. I arrived at it by burning tokens on things that should have been database calls, and watching my agents such as Falcon fall apart the moment I let the structure go soft. Alon arrived at it building a governance tool. The researchers named pieces of it years ago. We all walked through different doors into the same room.
The question is no longer whether this is the shape. The question is whether we build it on purpose or keep discovering it the hard way, one expensive mistake at a time.
I am building it on purpose.
Speak Your Mind