← cd ..
04/01/2026

% cat The Path to Autonomous Agents Was Mapped Decades Ago. Nobody Noticed.

Watch on YouTube →

If you’re building autonomous AI agents, you already know the feeling. The technology is extraordinary — and maddeningly insufficient for the job. Context windows are larger than ever, but your agent still loses the thread on long tasks. Reasoning is sharper — but the hallucinations that slip through look more real than the data. You build a harness — constraints, verification loops, evaluation layers — and the agent gets better. Then the edge cases multiply. Then the real-world integrations start failing in ways no test suite anticipated. You’re solving a puzzle that keeps adding pieces.

This is exactly what I was going through at Rishon, building agents that handle real business operations autonomously — hours-long phone calls with real people, real money on the line. Everything you’re using, I’m using. Planning, orchestration, evaluation, harness design. All essential. But the relief came from somewhere else entirely — from an approach that was mapped out decades ago, in fields that have nothing to do with AI.

Turns out, decades of building software before AI existed were the best preparation for this moment. The hard problems in autonomous agents — coordination, control, graceful handoff — aren’t new. They just have new names. That’s what this post is about.

Consider a different frame. When you chat with AI, you guide it constantly — and it works. The common discussion about agents focuses on making them function without that guidance. But what if we flip the question? Instead of asking how to make agents autonomous, we study what we actually do when we guide them. We observe our own behavior. We identify the patterns. And then we replace those patterns, one at a time, with their programmatic equivalents.

That changes everything. What you observe, what you build, and how you get there.

In my previous post, I explored why telling AI what you want is the hardest part of the stack — natural language is ambiguous, AI doesn’t share your common sense, and the gap between what you said and what it understood only shows up in the output. That problem doesn’t go away when you make the agent autonomous. It gets worse — because there’s nobody there to catch the drift.

What I want to explore now is what happens when you stop trying to solve that problem in one shot — and instead study how people solve it in practice, one conversation turn at a time.

The Control Protocol You Didn’t Know You Had

When you chat with AI effectively, you’re performing a specific set of recurring control moves. You don’t think of them as “control.” They feel like conversation. But watch yourself next time.

You steer: “No, focus on X instead.” You correct: “That’s wrong, here’s why.” You gate: “Looks good, go ahead.” You inject context: “You should know that our client requires…” You evaluate: “This isn’t good enough because…” You decompose: “Let’s break this into smaller pieces.” You prioritize: “Do the critical part first.” You recover: “You went off track. Let’s go back.”

Eight moves, give or take. Finite. Observable. Recordable. And you do them every day.

Now it gets interesting. Those eight moves are the specification for what an autonomous control system needs to do. Not some abstract autonomy framework cooked up in a research lab. The concrete moves you already make, in the conversations you already have, with the AI you already use.

So the question shifts. It’s not “how do we invent autonomous control?” It’s “how do we replicate the control we’re already exercising — without being there?”

What Toyota Knew That We Keep Missing

The instinctive next step is documentation. Have your best AI operators write down what they do. Formalize the chat patterns. Create a guide.

It won’t work. I covered the reasons at length — the specification problem, the rules trap, the constraint gap. The short version: people can’t articulate their own tacit knowledge. The FBI spent $170 million on the Virtual Case File system. It failed because two teams used identical words to mean different things — and neither side could explain the gap. Asking your best operators to write down their chat moves falls into the same trap. They’ll give you a sanitized, after-the-fact rationalization of what they actually do.

There’s a better pattern. It’s seventy years old.

Taiichi Ohno, the architect of the Toyota Production System, had a principle he called genchi genbutsu — literally, “go and see for yourself.” He made new engineers at Toyota spend their first day standing on the production floor. Not reading manuals. Not attending orientation. Standing and watching. Observing how experienced workers actually moved, actually decided, actually recovered from problems. Only by witnessing the work directly could you understand it — because the person doing it carries knowledge they can’t put into words.

Fujio Cho, Toyota’s chairman, distilled it to six words: “Go see, ask why, show respect.”

Applied to AI: don’t ask your best chat operators to write a guide. Record their sessions. Watch what they actually do. The patterns will emerge — richer, more honest, and more accurate than anything written from memory.

I call this “chat replay” — treating your best human-AI conversations not as throwaway interactions, but as a data source. They contain the implicit control protocol that makes the human-AI loop work. Start there.

But it goes further. The process doesn’t have to stay manual. You can use AI itself to analyze recorded sessions and extract the recurring patterns — not just as a Markdown file, but as structured knowledge. Decision trees, instruction sets, even dependency graphs reflecting which moves tend to follow which. Start by hand — watch, learn, tag. Then progressively let AI take over the extraction. I’ll come back to where this leads at the end of the post. It’s powerful.

The Tools Are Here. The Protocol Is New.

Once you’ve identified the patterns, something surprising happens. Every human chat move already has a programmatic equivalent sitting in the agent engineering toolbox.

Steering — routing and orchestrator logic. Correcting — evaluator-optimizer loops. Gating — checkpoint gates and approval queues. Injecting context — RAG and dynamic context engineering. Evaluating — LLM-as-judge and automated evals. Decomposing — prompt chaining and task decomposition. Prioritizing — orchestrator-workers with priority logic. Recovering — state checkpoints and rollback mechanisms.

In my harness engineering post, I described the four functions every harness performs: Constrain, Inform, Verify, Correct. If you haven’t read it — a harness is the system wrapped around the AI model. The constraints, the feedback loops, the verification and correction mechanisms that keep it productive. Those four functions are the same building blocks. What’s new here isn’t the components. It’s the requirements methodology. Instead of designing a harness from abstract architectural principles, you design it by observing what humans actually do — and replacing those specific moves, one at a time, with their programmatic equivalents.

The harness isn’t a cage for the agent. It’s a replacement for you.

When I designed the Rishon AI Developer Agent, I didn’t sit down and ask “what does an autonomous coding agent need?” I mapped how experienced architects work through a system design. They start with core entities and relationships. Then they flesh out attributes, one entity at a time. Then they think about user-facing functionality. Then automations. Then security. Then localization. Each of those is a move in the design conversation — and each became a phase in the harness, with its own context, its own constraints, its own validation loop. The multi-phase process isn’t arbitrary architecture. It’s a formalized version of what a skilled human does in a design session — extracted through observation, encoded into the system.

Decades of Practice, Hiding in the Wrong Aisle

The problem of replacing skilled, real-time human guidance with something more scalable isn’t new. At least three domains come to mind — and each validates a different aspect of this approach.

A Switch Would Kill. They Built a Dial.

Here’s a question for you. How long did it take commercial aviation to go from “the pilot does everything” to “the autopilot handles most of the flight”?

Forty years. And they’re still not done.

Cockpit automation didn’t replace the pilot all at once. It replaced specific control tasks — holding altitude, following a heading, managing descent rate. Each function was automated separately, validated separately, integrated separately. The pilot retained authority over judgment calls: when to deviate from the flight plan, when to override automation, when to take manual control in turbulence or emergency.

One detail matters more than the rest. The level of automation in a modern cockpit isn’t a switch. It’s more like a dial. The pilot always retains the authority to select the appropriate level for the current situation. Routine cruise at 35,000 feet? Full automation. Approach in bad weather with a crosswind? More manual control. Emergency? Hands on the stick.

That’s the model for AI agents. Automate the predictable moves first — the ones that play out the same way every time. Keep the human for the ones that require judgment. Let the ratio shift as trust builds and capability proves itself. No big bang. No target date for “full autonomy.” A dial.

The Seat Next to the Expert

Now consider how a call center trains new agents. They don’t hand them a Standard Operating Procedures binder and say “good luck.”

Three phases. First — shadowing. The new agent sits next to an experienced one, listening to live calls. They don’t participate. They observe. They absorb the rhythm — how the expert handles an angry customer, when they escalate, how they navigate a complex billing dispute, what they say when they don’t know the answer. This is genchi genbutsu with a headset on.

Second — supervised calls. The new agent takes calls while a trainer listens in. The trainer intervenes when needed — corrects a wrong answer, adds context the new agent doesn’t have, steers toward the right resolution. This is human-in-the-loop in real time.

Third — solo with monitoring. The agent handles calls independently. But random calls are recorded and reviewed. Quality assurance catches patterns, flags drift, provides feedback. Autonomous with oversight.

Two things about this model matter for our purposes. First, responsibility releases per skill, not globally. The new agent might handle billing questions solo while still supervised on escalation calls. The handoff is granular.

Second — and this connects directly to the genchi genbutsu principle — the best call centers write their SOPs after the observation phase, not before. Organizations that build onboarding this way — from observed practice rather than top-down mandates — report three times higher adoption rates and 70% faster time to productivity. The tacit knowledge surfaces through observation, not introspection. Documentation is a byproduct of watching. Not a substitute for it.

The Blackboard Had It First

The most explicit theoretical framework for this gradient comes from the classroom.

Teachers have a name for the pattern: the Gradual Release of Responsibility. It comes from a simple observation by Lev Vygotsky, the Soviet psychologist — there’s a gap between what a learner can do alone and what they can do with guidance. The teacher’s job isn’t to lecture from the front of the room. It’s to stand in the middle — between what the student can do alone and what they can’t yet. Provide just enough support for the student to take one more step on their own. Then let go.

In practice, it looks like this. “I do” — the teacher demonstrates while students observe. “We do” — teacher and students collaborate, sharing control. “You do” — students work independently while the teacher monitors.

Two insights from this map directly to AI agents. First — you can only release responsibility for what you’ve explicitly scaffolded. You can’t skip from “I do” to “you do.” The “we do” phase — where human and agent share control — is where the automated replacements get calibrated and validated. Agent produces, human evaluates, agent improves, human confirms. Skip that phase, and you’re deploying automation you haven’t tested.

Second — the release is per skill, not global. A student who’s mastered arithmetic still needs scaffolding when they hit algebra — new abstractions, new rules, a different way of thinking. You don’t release all of math at once. You release what’s been proven.

Look at all three domains side by side, and the same structure stares back at you. Aviation. Call centers. Education. Different vocabularies. Same pattern. Same gradient.

Maybe the Human Was Never Supposed to Leave

Most discussions of human-in-the-loop treat it as a temporary safety measure — something you tolerate until the agent is “smart enough” to go solo. I covered the security rationale in an earlier post — for high-stakes actions like financial transactions or customer communications, the agent pauses and waits for human approval before proceeding. That’s the security case.

But through the lens we’ve been building here, human-in-the-loop is something more fundamental. It’s the transitional state in the gradient — and for some moves, the permanent state.

Here’s why. The human control moves aren’t equally automatable. Some are highly predictable: “the code doesn’t compile, here’s the error” triggers the same correction loop every time. Automate that on day one. Others are pure judgment: “this design approach feels wrong for our architecture” requires taste, domain expertise, organizational context. Those might never be fully automated — and they don’t need to be.

This is also how you handle the long tail. In my previous post, I used the US tax code as an example — 70,000 pages of regulations, the vast majority of which covers situations most people never encounter. The predictable mainstream cases? You can count them. The edge cases are infinite. The conventional approach is to try encoding every edge case in advance. That’s futile. You’ll never finish. And what you miss is often the case that matters most.

The approach I’m describing handles the long tail differently. Automate the head of the distribution — the frequent, predictable moves. Keep the human for the tail — the rare, novel, judgment-heavy ones. Let the boundary shift as you accumulate more data and more patterns prove automatable. You never try to get the tail to zero. You just keep shrinking where humans are needed.

Now flip the lens. Most enterprises frame AI as a cost-savings play — do the same work with fewer people. But the hybrid model opens a different door entirely. If AI handles the bulk of the work and humans only handle the long tail, you haven’t just cut costs. You’ve removed the bottleneck on scale. The same team that used to handle a hundred cases can now handle a thousand — because the agent does the predictable nine hundred and the humans focus on the hundred that need judgment. That’s not a 10% efficiency gain. That’s a 10x revenue opportunity with the same headcount.

This isn’t theoretical. Built, a construction lending platform, deployed AI agents for loan administration. A team of ten now handles ten times the volume. They didn’t cut headcount by 90%. They turned a cost center into a growth engine.

The economics flip. Keeping humans in the loop isn’t a concession to imperfect automation. It’s the architecture that lets you scale.

If your AI strategy starts and ends with headcount reduction, you’re optimizing a budget line. You’re not rethinking what the business can do.

This isn’t a transition plan with a target date for full autonomy. It’s the operating model. The ratio shifts over time. The hybrid structure stays.

Simple Workflows Bend to AI Easily. Enterprise Operations Don’t.

So where does this get hard? Enterprises run on process. The way they operate — their workflows, their decision chains, their accumulated practices — is their core competency. It’s what makes them competitive. And most of it is undocumented. It lives in people’s heads, in muscle memory, in “the way we do things here.” According to Pew Research, 79% of US workers don’t use AI much or at all. Among companies, 88% have adopted AI in some form — but only 6% report meaningful business results. The technology isn’t the bottleneck. The gap is between having AI and actually integrating it into how the business runs.

The friction is real, and it’s rational. Risk aversion — because a misstep in a customer-facing process has real consequences. Practices that nobody’s written down — because they never needed to be. Existing software that can’t be replaced overnight — no sane CTO rips out every enterprise system to start fresh. And above all, the need to keep a well-oiled machine running. For most enterprises, AI is a cost-savings measure. For the ones paying attention, it’s a scaling engine. Either way — not an invitation to redesign how the business operates.

Gartner predicts 40% of enterprise applications will embed task-specific AI agents by the end of 2026, up from less than 5% in 2025. That’s an eight-fold jump. And yet most of those deployments remain at the lowest autonomy levels — task completion with heavy human oversight. The ambition outpaces the method.

The conventional agentic AI pitch asks enterprises to take a leap of faith: hand processes to an autonomous system and trust that it works. Even with guardrails, that’s a hard sell in a Fortune 500 boardroom — and it should be.

The approach I’m describing proposes something entirely different. Don’t start differently. Start by watching.

And this is a point worth expanding. “Chat with AI” sounds natural to a software engineer — we live in terminals and text interfaces. But a bookkeeper lives in spreadsheets, a claims adjuster lives in a case management system, a register operator lives in a POS terminal. Adding a chat window to that isn’t an upgrade. Those tools are purpose-built for the job. Chat isn’t. Asking them to start chatting with an AI assistant is already a big change. But you don’t have to start there. You can observe how they work with their existing tools. Which buttons they press. Which screens they navigate. Which forms they fill out, in which order, with which hesitations. You’re not observing control moves over AI — you’re observing the decisions and judgment calls that the AI will eventually need to replicate. The raw material is different. The extraction process is the same.

Record that. Analyze the patterns. Find the twenty percent of decisions that cover eighty percent of the work — and build automated equivalents. Deploy them alongside the existing process, and measure. If they perform as well as the human judgment they replace — release them. If not, roll them back. No revolution. No faith-based deployment. Incremental, data-driven, and reversible.

This addresses the real enterprise concerns.

Risk — you never deploy more automation than you’ve validated. The blast radius of a single automated move is bounded. The human is still there if it fails.

Continuity — the humans aren’t displaced overnight. Their role evolves gradually from operator to supervisor to exception handler. Each transition happens only when the data supports it. There’s a part that rarely makes it into the AI strategy deck: every time you lay off experienced staff, you lose the tacit knowledge they carry. The judgment calls, the workarounds, the edge-case instincts that no one ever wrote down — gone. The gradient captures that knowledge before it walks out the door.

Compliance — you have a complete audit trail of what was automated, when, with what performance, and what stays under human control. You can show it to a regulator. Try doing that with “we deployed an autonomous agent.”

Most people miss the strategic angle. The way an enterprise operates IS its core competency. The decision chains, the judgment calls, the exceptions that only the veteran staff know how to handle — that’s the business. Klarna learned this the hard way. In 2024, they announced that AI had replaced 700 customer service agents — two-thirds of all conversations automated, $40 million in projected savings. The headlines were glowing. Within a year, customer satisfaction had deteriorated, the CEO publicly admitted that “cost unfortunately seems to have been a too predominant evaluation factor,” and the company was rehiring — recruiting, onboarding, and training new staff at a cost that exceeded the original savings. They’d optimized for case closure. Their customers needed judgment.

When you observe those patterns and automate based on what you see — not what you assume — you’re not just automating tasks. You’re turning your operational intelligence into a durable asset. One that knows which moves to automate and which ones to leave in human hands. That’s something no competitor can replicate by buying a better model.

Hunt the Hunter

Earlier, I said the observation doesn’t have to stay manual — that you can use AI to extract knowledge from recorded sessions. Time to pull that thread.

Once you’re recording sessions, you don’t need humans to hunt for automatable patterns. AI doesn’t just perform the work — it can observe the work. Analyzing sessions, identifying recurring moves, extracting what it finds. Not just into a Markdown file the model reads — but into structured knowledge. Decision graphs. Instruction sets. Dependency maps of which moves follow which, under what conditions. Complex knowledge, in whatever format best captures it.

Once the AI can extract the patterns, it can identify which ones are candidates for automation — the frequent ones, the predictable ones, the ones that play out the same way every time. Then it can generate an automated replacement — anything from a carefully engineered prompt to a hard-coded harness with its own evaluation loop. And once the replacement exists, it can validate it against historical data: does the automated version produce the same outcome the human did?

What you end up with is a self-improving loop. The agent watches how a human works with it. It extracts knowledge from that collaboration. It proposes its own automation. It validates against real data. And gradually, it absorbs more of the human’s role — not because someone programmed it to be autonomous, but because it learned from its own operational history.

This is the most practical path to genuine autonomy I’ve encountered. Not making the agent smarter in a vacuum — but giving it a mechanism to learn from the people who already know how to control it. The recorded sessions become the training data for the agent’s own control system.

The harness learns to build itself.

At Rishon, this is the direction we’re heading — harnesses that learn from their own operational data, not just from rules someone wrote in advance. It’s early. But the foundation is the gradient we’ve been discussing throughout: observe, extract, replace, validate, release. Then repeat — with the AI handling more of the observation and extraction each time around.

Batteries Not Included. Humans Are.

Everyone wants to skip to the finish line — fully autonomous agents, running for days, solving problems no human anticipated. We’ll get there. But the road doesn’t run through making agents smarter in isolation.

It runs through understanding what we do when we work with them. Watching ourselves operate. Extracting the knowledge. Replacing the patterns one at a time. Validating each replacement against reality. Keeping the human where judgment still matters. And eventually, letting the agent drive the observation process itself.

The path to autonomous AI may be the most human-centered engineering discipline we’ve ever built. It starts not with the machine, but with us — watching ourselves work, more carefully than we ever have before.

I’ve been building this way at Rishon, and I’m learning something new every week. If this resonates, I want to hear about it. What domain are you in? Is the gradient hiding in yours? What patterns are you already automating — even if you didn’t call it that?

Drop a comment.

Cheers!

References

Industry and Technical

Manufacturing and Operations

Education