For the last two years I have written most of my code with agents. All the harnesses: Claude Code, Codex, Copilot, Cursor, in different combinations, on real systems. I keep distilling the patterns that reduce defects most cheaply and putting them back into how I work. Somewhere in that loop I noticed the asymmetry that became Aient.
A coding agent acts on your volition. You ask it to do something and it does it, sometimes brilliantly. But someone has to ask. Production never asks. It fails at 03:12 on a Tuesday, quietly, in a code path nobody is thinking about, and the asking gets done by a pager and a tired human. The fixing, by that point, is the easy part. The noticing and the context are the parts nobody had built an agent for.
The gap nobody was watching
Agentic engineering has crossed into the early majority; the way engineers write code has visibly changed. Agentic operations barely has early adopters, and for a defensible reason: historically you did not give agents the keys to a running system. So the field split. Agents got very good at making changes, and everything upstream of the change (detecting that something is wrong, deciding it matters, assembling the context) stayed manual.
Watch what actually happens on call. The alert fires. An engineer reconstructs the situation from logs, traces, metrics, a deploy list and a hunch. Then, only then, does the fixing start. That reconstruction is exactly the kind of work an ever-watching system should do before any human arrives.
So Aient is two things fused together: a telemetry system and an agent harness. It ingests logs, traces and metrics (the three pillars of observability, reinterpreted for agentic execution), coalesces the error signals in them into problems, which is a research problem in its own right, and pulls anomalies out of the derived metrics as a second signal. Where a failure resolves to code, it links the source in, so the agent starts from telemetry and code together instead of a stack trace and a prayer.
I taught it how I debug
The harness is optimised for one job, remediation, and it carries hard-won lessons from my own debugging: how to decompose a problem and in what order; when to jump between metrics, traces and logs; how to read the historical threads other agents have left behind, because the history of your system is evidence too. The exceptions that recur are grouped as occurrences of one problem, and duplicate detections of the same fault fold into a canonical one, so the agent sees one case file rather than a stack of alerts. Aient drafts its own memories and skills as it works with your organisation (you approve what gets kept, so the knowledge stays curated), and your feedback steers what it does next.
The output of all this machinery is deliberately boring: a pull request you can review.
Human-in-the-loop is a confidence level, not a principle
While we were preparing this post, Anna asked me whether the human in the loop was a principle I wanted to keep. No. Preferably everything would be automatic. The human is there because confidence has to be earned before an agent touches production on its own, and confidence is built from evidence, not vibes.
So Aient accumulates evidence, rung by rung. Today, after you merge a fix for a crash-class problem, it verifies by watching production for the problem to recur, and reopens it if it does. That is honest but simplistic: maybe nobody triggered that code path again. The stronger, causal rung, confirming the failing path keeps being exercised and no longer fails, is what we push towards wherever the bug allows it. Every rung is exposed in the product. Problems read like incident reports: what we saw, why it seems wrong, the likely root cause, the proposed fix, the evidence for it, and after the merge, the proof.
When the evidence is strong enough for your taste, there is a toggle that merges for you. Vibe-coding a side project, you might tick it on day one; the latest models may well be better than you are at fixing your mistakes, and you know it. Running a company's production system, you probably will not tick it for a long while, and you should not. The toggle is not the point. The evidence that would justify it is.
Aient fixes Aient
I care about defect-free code slightly more than is reasonable, so Aient runs on itself. It is a multi-tenant, highly concurrent, distributed agent system written as crash-only software on Restate, and that style of system only works if you are disciplined about invariants. Ours are documented, and every time we break one anyway, we write a post-mortem the agents read, so the same lesson is not relearned by hand. When Aient finds a problem in Aient, it opens the pull request, and I review it like anyone else's.
What it will not do
Aient does not scan your codebase and refactor it uninvited. There is no bonanza mode. It is runtime-analysing software: it works from telemetry rather than symbolic analysis, listens to your system, and fixes the flaws your users actually trigger. Not every bug deserves fixing; a race that only appears under load you do not have can wait, and the crash your customers hit today cannot. That bias makes it useful precisely where letting an agent loose feels reckless: legacy systems, intricate systems, the ones with history.
The method underneath is old. Hypothesis, data, conclusion, run continuously against production, with a pull request at the end. The Air Force version works too: observe, orient, decide, act. Either way, the point is the same. The agents we had waited to be asked. The one I wanted was already looking.