Every agent I’ve ever built is a loop wearing different clothes. Strip away the framework, the model, the marketing, and what’s left is something that observes, decides, acts, and then looks again at what it changed. The whole field is an argument about what goes in each of those steps. So when people ask what an agent is, I’ve stopped reaching for a definition and started drawing a circle.

This is a piece about that circle: where it came from, what sits around it, the shapes it takes, and the one version of it, borrowed from a fighter pilot, that I’d actually design around.

The oldest idea in the field

The loop predates the word “agent” by decades. Norbert Wiener’s cybernetics in the 1940s was about exactly one thing: feedback. A system senses the world, compares it to a goal, acts to close the gap, and senses again. A thermostat is the canonical example and it is, technically, an agent. It perceives temperature, decides against a setpoint, and acts on a furnace. A dumb one, with a fixed policy, but the structure is all there.

By the time Russell and Norvig wrote *Artificial Intelligence: A Modern Approach* in the 1990s, the definition had hardened into something you’ve probably seen: an agent is anything that perceives its environment through sensors and acts on it through actuators. Perception in, action out, repeat. Reinforcement learning drew the same picture and made it the whole game. An agent and an environment pass observations and actions back and forth, the agent learning a policy that makes the loop pay off over time.

Then language models walked into the decide step. ReAct and the agent loops that followed kept the exact same shape (assemble context, reason, pick an action, execute it, observe the result, feed it back) and swapped the policy for a model that can read and write natural language. That’s the entire novelty. Not a new structure. A new thing sitting in an old seat.

The loop hasn’t changed in eighty years. What changed is that a model now fits in the decide step, and that most of the work is feeding it.

The loop and the harness

The loop is the engine. The harness is everything bolted around it.

The model only sees what the harness lets it observe and can only do what the harness lets it act on. Tools are the sensors and the actuators. Memory is what survives between turns. Context assembly is the thing that decides, every single iteration, what the model gets to look at before it reasons. Gates are where the loop is allowed to touch the real world and where it has to stop and ask. None of that is the model. All of it determines whether the model is useful.

So most of building an agent is building the harness, not picking the model. I’ve watched a capable model fail because it couldn’t see the thing it needed, and a smaller one succeed because the harness put the right three files in front of it at the right moment. The model is the part everyone talks about. The harness is the part that decides whether the loop closes or spins.

The loop has shapes

Once you start seeing loops, you notice they aren’t all the same.

The control loop is the thermostat: a fixed policy, no learning, fast and reliable inside its lane and useless outside it. Most of production software is control loops, and that’s correct. When a switch statement does the job, you don’t put a model in the seat.

The agent loop is the control loop with a model in the decide step. It trades determinism for range. It can handle inputs you didn’t enumerate, and in exchange it can be wrong in ways you didn’t enumerate either.

The reason-act loop (ReAct and its descendants) splits “decide” into thinking and doing, and crucially adds observe the result of my own action as a first-class step. That observation is what separates an agent from a very long prompt. Without it, the model is guessing into the void. With it, the loop can correct.

Then there are the loops inside the loop. A sampling loop runs the same step several times and judges the spread. I built one of these for judged self-consistency on a single model, and the lesson was that the loop, not the model count, was doing the work. A multi-agent system is loops nested in loops: an orchestrator’s loop dispatches a task, and the agent that receives it runs its own loop to completion before the outer one continues. And around all of it is the human loop, where a person on the merge button is a gate inside the largest loop in the system, the one that decides whether what the machine produced should actually ship.

Naming the shape matters because it tells you what to optimize. A control loop wants reliability. An agent loop wants better orientation. A sampling loop wants a good judge. A multi-agent loop wants a clean contract between the loops. Pick the wrong optimization and you’re tuning a part that isn’t the bottleneck.

The loop that’s about winning

The most useful version of the loop didn’t come from AI at all. It came from John Boyd, a US Air Force colonel who, in the early 1970s, was trying to explain why American pilots in Korea won dogfights they arguably shouldn’t have. His answer was a loop: Observe, Orient, Decide, Act. OODA.

Most people who cite it get it wrong in two ways. First, they draw it as a tidy circle, when Boyd’s real diagram is a tangle of feedback paths with one stage doing most of the work. Second, they think it’s about speed. It isn’t, quite. It’s about tempo: cycling through your loop faster and more relevantly than the thing you’re competing against, until you’re acting on a picture of the world it hasn’t caught up to yet. Boyd called it getting inside the opponent’s loop.

And the stage doing the work is Orient. Observe just gathers raw input. Decide and Act are almost mechanical once the first two are right. Orient is where you take what you observed and run it against everything you already are (your experience, your model of the situation, your context) and turn data into a read on what’s actually happening. Boyd thought orientation was the whole ballgame, and anyone who has debugged an agent knows he was right. The model rarely fails at Decide or Act. It fails because it was oriented wrong: it was looking at a stale file, missing the one constraint that mattered, carrying context from a task that ended an hour ago. Bad orientation, confident action.

That reframes the entire job. When I work on an agent, I am almost never improving its ability to decide or act. I’m improving Orient: what it observes, how that gets synthesized, what it remembers, how I measure whether its read of the situation matches reality. Context engineering, memory, evaluation are all orientation work. The flashy part of an agent is the act. The leverage is one step earlier.

Automating intelligent systems

Here’s how I use this. When I design a system meant to act on its own, I draw its OODA loop and ask, for each stage, two questions: what’s automated, and what’s gated.

Observe is the harness: the tools, the context assembly, the retrieval. Automate it aggressively, because the loop can’t be better than what it sees. Orient is the model plus everything I feed it, and it’s where I spend most of my effort, because it’s where the system is most often wrong and where improvement compounds. Decide is the model’s call, and for a well-oriented loop it’s cheaper and safer than it looks. Act is tool execution, and it’s where I put the gates. The loop runs free right up until it would change something that’s expensive to undo, and there it stops for a human.

That’s the dark-factory model stated as a loop. The agents own a full OODA cycle for producing a mergeable change. They observe the codebase, orient against the task and the conventions, decide on an approach, and act by writing and reviewing it. The human owns a slower, outer loop: not “is this line right,” but “is this loop pointed at the right thing at all.” Two loops at two tempos, and a gate between them.

The goal of the whole arrangement is the thing Boyd was after — tempo. A system worth automating is one that can cycle faster than its problem changes. Get that, and the machine is acting on a current picture of the world while the problem is still catching up. Miss it, and you’ve built something that confidently solves the situation it was in five minutes ago.

That’s what’s in a loop. The model is one corner of it, the corner everyone stares at. Almost everything that decides whether the system works lives in the other three, and in how fast you can get around the circle. Build the harness, obsess over orientation, gate the act, and turn the loop faster than the competition can. The rest is which model you drop into the seat.

If you want to see one wired up, that’s what I build protoAgent for: an open, A2A-native substrate that keeps the boring parts of the loop stable (the agent loop, tool calls, memory, evals, the release pipeline) so forking an agent comes down to which model goes in the seat. Take it, fork it, point it at your own problem: github.com/protoLabsAI/protoAgent.

Threads pulled here: Norbert Wiener’s cybernetics (https://en.wikipedia.org/wiki/Cybernetics) and the feedback loop; Russell & Norvig’s (https://aima.cs.berkeley.edu/) sensors-and-actuators agent; the reinforcement-learning agent and environment loop; ReAct; and John Boyd’s OODA loop (https://en.wikipedia.org/wiki/OODA_loop).

A Parable

Two organizations. Same industry. Same market pressure. Same mandate from the board: “We need AI.”

Org A watches what Org B is doing. The influencers say Org B is building a sidewalk — a nice, visible path forward. So Org A builds a sidewalk too. Fast. They slap concrete down as quickly as possible. Investors love it. The board is thrilled. “Look how fast we’re moving. We’re crushing Org B.”

But Org B isn’t building a sidewalk.

They’re building a conveyor belt.

It looks slower from the outside. There’s no ribbon to cut, no demo to show off at the next all-hands. They’re calibrating motors, testing load capacity, making sure every person in the organization understands what happens when the switch flips. It’s unglamorous work. Nobody writes a LinkedIn post about linting standards.

Org A is miles ahead — or so they think. They’re already spending the money they haven’t made yet, high-fiving over quarterly reports, dreaming of unicorn valuations.

Then they hear a sound from across the street. A celebration.

Org B slots in the final piece, flips a switch, and everything starts moving. Not one thing. Everything. Simultaneously. Continuously. Without anyone pushing it.

Org A stares at their sidewalk. People are still walking on it. Manually. One step at a time.

Now they have a choice: rip up the sidewalk and start building a conveyor belt from scratch, or try to chisel out the sloppy concrete and retrofit something that was never designed to move on its own.

Neither option is good. Both are expensive. And Org B’s belt is already running.

The Wrong Conversation

The entire industry is having the wrong conversation about AI.

“We need agents.” “We need copilots.” “We need a chatbot for our customers.” These are feature requests dressed up as strategy. They’re the sidewalk.

The actual challenge was never the AI. Agents aren’t hard. You can spin one up in an afternoon. The hard part — the part that leadership doesn’t want to fund because it doesn’t photograph well — is everything underneath.

It’s the automation architecture that lets systems talk to each other without a human in the middle. It’s the data modeling that ensures every agent, every pipeline, every service is working from the same source of truth instead of hallucinating its own. It’s the organizational readiness — the part where you actually prepare your people for a world where their job shifts from doing the work to guiding the systems that do it. It’s the design standards and code quality practices that determine whether an AI agent produces something shippable or something that has to be rewritten by hand. And it’s the cultural shift — the hardest one — from measuring output by hours worked to measuring it by systems orchestrated.

That’s the conveyor belt. And it’s invisible.

The Blueprint Was Already Written

In September 2022, Robb Wilson published The Age of Invisible Machines — a blueprint for hyperautomated ecosystems of intelligent digital workers. Two months later, ChatGPT dropped and the world lost its mind.

I’d already read the book. It laid out exactly what was coming: interconnected automations, conversational AI as infrastructure, organizations becoming self-driving. Not one flashy chatbot — an entire ecosystem of invisible systems working in concert. Wilson called them “invisible machines” because the point was never for humans to see them work. The point was for humans to stop working.

That framing changed how I thought about everything. While everyone else was scrambling to figure out what a large language model even was, I was already shaping the skillsets for that future. Building RAG pipelines, orchestrating multi-agent systems, designing the kind of infrastructure that Wilson described — the boring, critical, invisible stuff that actually makes organizations move.

Three years later, I have an autonomous AI development studio with a team of specialized agents that ship production code while I sleep. 3,750 commits. 1,300+ pull requests. 430,000 lines of TypeScript. One human.

That didn’t happen because I chased the hype. It happened because I followed the technology.

The New Job

Here’s the part that sounds like science fiction but is already real: your job is no longer to do the work. Your job is to guide the systems that do the work, verify the output, correct where it’s wrong, and feed those corrections back in so the system improves itself.

That’s it. That’s the entire shift.

Here’s what that looks like in practice. An AI agent on my team picks up a feature, writes the code, opens a pull request. CI runs. The linter catches something. The agent reads the failure, fixes it, pushes again. If the PR gets review feedback, the agent addresses it. If it fails twice, the system escalates to a more capable model and tries a different approach. My role is to set the standards, review the output, and correct the system where it drifts. Every correction makes the next run better. The system learns.

But none of that works without the invisible infrastructure. Linting standards. Design rules. Consistent data models. Pipeline architecture. Organizational discipline. The kind of investment that doesn’t show up in a demo but determines whether your conveyor belt runs or jams.

The Race to the Bottom

I’ve been talking about this for years. Stop what you’re doing. Pay attention. Learn how these systems work. Not the surface-level prompt engineering — the actual architecture underneath.

But people are too distracted by the shiny things. Every week there’s a new model, a new wrapper, a new startup claiming they’ve solved AGI with a React app and a system prompt. The influencers chase it. The investors fund it. The sidewalks multiply.

There is a stable path forward. It requires work, foresight, patience, and collective collaboration. It means investing in the invisible infrastructure that nobody wants to fund because you can’t put it in a pitch deck.

So here’s what you do Monday morning: audit your automation layer. Can an AI agent plug into your system tomorrow and start shipping work? If the answer is no — if there’s no consistent data model, no CI pipeline, no design standards, no clear interface between human review and machine execution — then you don’t have infrastructure. You have a sidewalk.

The organizations that figure this out will flip their switch and watch everything move. The ones that don’t will be standing on their sidewalk, wondering why they’re still walking.

The age of invisible machines is already here. The question is whether you’re building one, or just pouring concrete.

Now it’s here, and they’re not ready.

The shift isn’t coming. It shifted. While you were debating whether AI could “really” write production code, the ground moved under you.

Here’s what the landscape looks like right now:

From above, the big labs are shipping. Not demos. Not blog posts about what’s “possible.” Shipping. Anthropic released Claude Code — an autonomous coding agent that writes, tests, and commits production software. Google and OpenAI are doing the same. These teams produce more working code in a day than most mid-size companies ship in a quarter. They have the models, the talent, and the infrastructure to move at a speed that makes your sprint velocity look like a rounding error.

From below, the one-person startups are eating your lunch. And here’s the part that should keep you up at night — they’re powered by the same talent that walked out of your building. The engineers who left in 2023 and 2024 while companies chased the hype cycle, trying to “pivot to AI” without understanding what that actually meant. Those people didn’t disappear. They learned to orchestrate. Now one person with the right systems ships what your team of forty can’t.

You are being squeezed from both directions, and the window to respond is closing fast.

The middle is dying. Not slowly. Not in some theoretical future state. Right now. If you’re a 50-200 person company still running the 2019 playbook — two-week sprints, manual code review, feature factories staffed by humans doing work that machines do better and cheaper — you are already behind. You just don’t see it in your quarterly numbers yet. You will.

What does “move fast” actually look like?

I’ll tell you what it looks like for me. I define features on a Kanban board with acceptance criteria and dependency chains. AI agents claim those features, work in isolated git worktrees, and ship through the same CI pipeline any human engineer would — linting, type checking, tests, code review, auto-merge. If they fail, they retry with more context or escalate to a more capable model. If they succeed, the PR lands on main while I’m asleep.

2,600+ commits. 580+ pull requests. 370,000 lines of production TypeScript. One architect directing AI execution.

That’s not a decade of work. That’s a few months. And every month, the tools get better, the models get smarter, and the gap between “people who get it” and “people who don’t” gets wider.

The companies that survive the squeeze will be the ones who stop debating whether this is real and start rebuilding how they work. The playbook exists. The question is whether you’ll run it before or after your competitors do.

The squeeze doesn’t wait. Sign up below to make sure you don’t get left behind.

Subscribe now

500+ PRs. 700 commits. 366K lines. 12 days.

Those numbers aren’t hypothetical. They’re from production repositories with CI pipelines, branch protection, code review, and real users. The git log doesn’t lie.

The Journey Here

I’ve been building AI systems for three years. Not using AI tools — building AI systems. RAG pipelines with LangChain and Pinecone. Multi-agent research platforms with knowledge graphs handling thousands of nodes. Generative gaming engines. I was copy-pasting code into 4K context windows and telling anyone who’d listen that this was going to change everything.

Before that, I spent 6 years as a software architect — design systems for Fortune 500 clients, AI integration lead at a SaaS platform. I got good at holding systems in my head. Data flows, failure modes, the places where abstractions leak.

AI tools 10x’d my workflow. I could ship in a week what used to take a month. But I was still the bottleneck — just a faster one. Then the question shifted. Not “how can AI help me code faster?” but “what if I designed a system where I don’t need to code at all?”

The insight wasn’t technical. It was organizational. An architect’s leverage comes from the quality of their design, not the speed of their typing. AI agents are — right now, today — capable of being those engineers. But only if you build the right scaffolding around them.

I didn’t stumble into this. I’ve been building toward it for three years.

The Architecture

The system is called protoLabs. Here’s how it works:

The Board. Everything starts with a Kanban board of features. Each one has a title, description, acceptance criteria, complexity rating, and dependency chain. I define these. This is where my architecture work lives.

Agent Assignment. When a feature moves to in-progress, an AI agent claims it. The agent gets the feature spec, project context, and the full codebase. Not a vague prompt — a scoped assignment with clear boundaries.

Worktree Isolation. Each agent works in an isolated git worktree — a completely separate working directory. Agents can’t step on each other. They can’t corrupt main.

CI Validation. Every PR goes through the same pipeline any human PR would. Linting. Type checking. Tests. Format checks. If it doesn’t pass, it doesn’t merge. Agents don’t get special treatment.

Antagonistic Review. Before a major feature gets built, a separate AI agent reviews the plan. Its only job is to find flaws. It catches architectural mistakes and scope creep before implementation begins.

Trust Gates. The system stops and asks me to approve at the moments that matter: merging to main, approving a project plan, authorizing a new dependency. Trust is earned incrementally.

Model Hierarchy. Small tasks get the fast model. Standard features get the balanced one. Architectural decisions get the most capable. Features that fail twice automatically escalate. The system adapts.

The Products

Three real products have shipped through this system:

protoLabs itself. The tool builds itself. New features are defined on its own board, implemented by its own agents, merged through its own CI. 94 features shipped this way.

MythXEngine. An AI-powered tabletop RPG engine. Complex domain — narrative generation, game state management, character systems. Not a todo app.

SVGVal. An ai powered generative SVG toolkit and evaluation platform. Smaller scope, but a complete product shipped start to finish by AI agents.

These aren’t demos at a conference. They’re deployed software with git histories you can read.

What My Day Looks Like

I wake up. I check the board. I read through what shipped overnight. I review any PRs that hit a trust gate. I define new features or adjust priorities. I think about how components should interact, where the interfaces are, what the failure modes look like.

I spend maybe an hour a day on what used to take twelve. The rest of the time I’m thinking about the product, talking to users, or writing this.

The system works not because AI is magic, but because the engineering around the AI is sound. The guardrails are real. The failure recovery is tested. The trust is earned, not assumed.

Try It

protoLabs is source-available. The code is at github.com/proto-labs-ai. You can read the architecture, run it locally, and build on top of it.

If you want help setting up your own autonomous development pipeline, that’s what protolabs.studio is for. No subscriptions. No per-seat pricing. Just the methodology and the tools.

The question isn’t whether AI can write code. It obviously can. The question is whether you can design a system that makes that capability reliable, safe, and autonomous.

I did. And I stopped coding.