We started AdaL a year ago as a research lab with one obsession, which is autonomy. In this article I'll share where I think engineering autonomy actually stands, what is still blocking it, and why a lot of the field is building the next layer in the wrong place.
TL;DR
Today's agents are excellent tools for humans in the loop. But for many tasks, you don't want to babysit 12 hours a day. You want the work delivered end to end.
The field is trying to force that autonomy onto the agents of today, which were built for a different job. An agent is a model plus a harness: tools, files, browser, git, runtime, permissions. That harness is infrastructure designed to ask before it acts, with guardrails around anything that touches your codebase, which makes it close to perfect for a human in the loop and an awkward place to bolt autonomy onto.
The real answer may sit a layer above, in an agent modeled on what we already do with those agents. Whether it spins up a worker such as AdaL, Claude Code, or Codex, or a clone of itself to orchestrate a sub-task, what it builds is an agentic graph. The agentic loop is that graph in motion: instructions travel between the nodes, each agent does its piece, and the work iterates through the developer lifecycle until it's done.
Autonomy may be a complete layer above. AdaL Engineer, in preview, is our first cut at it: it drives AdaL today, with Claude Code support coming right away.
Autonomy is the bottleneck of the agents of today
Coding agents made developers more productive. They also made a lot of us more drained.
Sonar's 2026 State of Code report puts about 42% of committed code as AI-generated. That figure is the productivity half, and it is real. The drain sits on the other side of the same number, in the review, validation, understanding, and ownership that did not get cheaper at anything like the same rate.
Babysitting an agent for a week is fun, and for a month it still feels like leverage. Doing it for months, and then years, is draining. There is more output, and with it more demand on your attention and your judgment, because every cycle ends in a decision only you can make. What gets me is that plenty of these tasks have a clear goal from the start, and I still cannot hand one over completely. Our team has felt this all year. Agents can run overnight now, and we mostly choose not to let them, because it is expensive and what comes back is not good enough.
Before we discard the agents of today and chase autonomy everywhere, here is what I learned from using AdaL Engineer on everything. When the goal isn't clear, an autonomous agent is the wrong tool. Writing this article is the example, and so is building a deck: the writing is the thinking, and it only comes out of the iteration.
So the work splits in two.
Some work requires collaboration. The goal still needs defining, or you want to be in it, because you enjoy the process or because it has to sound like you. Here the agent is a tool that asks permission for every change, and today's agents are extraordinary at that. You are the outer loop, and the agent is leverage inside it.
Some work you just want delivered. The goal is clear, so you hand it over the way you would to the best engineer you can hire: give a high-level goal, and they carry the rest. What comes back is a scoped PR, a verified fix, a landing page that matches the brief.
Delivery is where babysitting begins. Cloning a landing page pixel-perfectly took us 50+ rounds of screenshot, compare, fix. One real bug meant reading 12 files, editing 3, running tests, checking nothing else broke. Every one of those cycles was goal, action, check, decide, repeat, and I was the one deciding, every time.
You ask it to fix A, and it fixes A and quietly rewrites B. Or it solves the problem in a way that fits nothing else in the codebase, which is what I call alien code. Or it gets halfway and needs you back. A better model does not remove any of these, and that is why I think autonomy, rather than capability, is our biggest bottleneck right now.
Creation got cheaper. Review, validation, and ownership did not.
From prompt to harness, and what comes next
The model reasons and the harness acts. The outer loop, understand, plan, build, test, review, iterate, is still a human workflow.
It is worth remembering how short this history is. The 2022 ReAct paper was an early harness: reasoning traces interleaved with tool calls, where the prompt itself largely decided what the system did. Then context windows grew, 20k to 50k to 100k and on to a million, and the harness had to grow with them. It stopped being a prompt and became tools and MCP, skills, file and image inputs, compaction, prompt structure and caching, and a runtime environment. The term context engineering only emerged in 2025, to name that layer once it was too big to ignore.
Which gives four layers, each one containing the last. Prompt engineering is the words you send. Context engineering is the full token state the model sees at inference. Harness engineering is the code that turns a model into an agent system in a real environment: tools, permissions, state, recovery. Loop and graph engineering is the structure that drives work to a verified outcome.
Each layer contains the one before it. The prompt is the smallest thing you control, and the harness is the largest.
Prompt sits inside context, context sits inside harness. Claude Code, Codex, and AdaL are all harnesses, and that stack is what made agents real. It is also where the autonomy we have today tops out. An agent plus a harness gives you L1: it can generate and act in a real environment, and the arms work. L2 is taking a well-defined goal to an outcome that fits the codebase and the developer's requirements, without a human driving each cycle, and nothing in these three layers gets you there on its own.
Addy Osmani puts the next move plainly:
Loop engineering is replacing yourself as the person who prompts the agent. You design the system that does it instead.
Peter Steinberger and Boris Cherny have each said a version of this: stop prompting every step, and design the structure that keeps the work moving.
So the diagnosis is not really in dispute. Everyone building here has hit the same wall, and we are all pointing at the same missing piece. What is still open is how to build it, and that is where the answers start to differ.
The solutions of today
The answer so far has been to push autonomy down into the agents of today. These patterns are worth naming because most of us already use them, and because they are good work by people I learn from.
On the single-agent side we have recurring workflows and scheduled goals, /goal and /loop in Claude Code, /cron in AdaL, plus permission modes like --yolo and dangerously-skip-permissions that let a run continue without interruption. One agent, more freedom to keep going. That helps, and it is also too simple, because you still have one trajectory and one context. A single long context fails in three ways I see constantly: agentic laziness, where it reviews thirty-five of fifty files and stops; self-preferential bias, where it grades its own work too kindly; and goal drift, where compaction quietly changes the mission.
Then multi-agent arrived in two shapes. Dynamic workflows compile a graph early in an episode and then execute it as a bound artifact, each run getting a clean context window. Agent teams let the main coding agent decide what to spawn next from what comes back, with peers that message each other rather than only report up. Both are aimed at parallelization and context rot, and both get expensive to coordinate while transparency drops fast.
Every one of these patterns is attached to the coding agent of today, so they all draw on the same scarce resource, which is the model's attention. Ask one agent to be the planner, the router, the memory, the evaluator, and the owner of the outer loop, and those roles compete for the same context window. The system goes opaque, because no single surface explains a decision made five roles ago, and the UX goes heavy, because every role needs settings.
Single-agent is too simple. Multi-agent tied into the same coding agent is too opaque. Both lean parallel, while real outer-loop engineering is mostly iterative, and that is the gap.
Agent teams show up as the Agent tool, dynamic workflows as the Workflow tool. Both live inside one coding-agent session.
Our answer: the agentic loop and graph
We took a different approach and pulled the whole autonomy layer out as an agent of its own, modeled after us, the humans who use these agents.
Put simply, the Claude Code, Codex, and AdaL of today are great for working by hand, and we want to keep them that way. So we built another agent whose job is to steer them and deliver a task end to end for you. Think of it as your clone. It does not need to be the strongest at coding, or at image generation, or at design, because the workers underneath already are and will keep getting better. What it needs is your taste and your memory.
The engineer takes a goal, spawns coding builders, a browser-use builder, an evaluator, or another engineer for a sub-task, and keeps the memory and work log until the goal is delivered.
We are all familiar with agentic search, where the agent runs a query, reads what came back, and picks the next query from what it actually found, so the path is written as it walks. Loop engineering and graph engineering are the names the field has landed on for that instinct one level up, and we built both into the agent itself, as the agentic graph and the agentic loop.
The engineer spins up a worker, or another engineer when a sub-task deserves its own orchestration, and assigns each one its piece. What builds up is a graph of agents: nodes that do the work, edges that carry tasks and context. Nobody draws that graph in advance, because the engineer composes it while the work is happening, adding a branch or a verifier when the task turns out to need one. The agentic loop is that graph in motion.
Builder and evaluator as separate workers. Verification written down. Humans can still see the workflow.
One last thing: when understanding falls behind
If more delivery becomes autonomous, humans do not disappear. Autonomy is how much work the loop and graph can carry, and agency is who remains answerable, so the output an agent can produce is capped by how well it hands that work back to the person in charge.
Addy Osmani names three dangers that show up when code gets written faster than anyone can understand it. All three end up on you.
Cognitive debt. The codebase grows faster than your picture of it. Builds pass, PRs merge, and slowly the team can no longer explain how the system works. Once you cannot explain it, you cannot maintain it either.
Cognitive surrender. Delegating means the agent does the work and then shows me enough that I can judge it myself. Surrender is saying yes before I have looked. Both look the same on screen, which is what makes it dangerous. A Wharton study found that when the AI was wrong, 73% of people went along with it anyway, and felt more sure than if they had worked alone.
Orchestration tax. Agents run in parallel. You do not. Every extra loop is more work to route, merge, check, and put back together, so running more agents never gives you more hours.
You are still the one who has to answer for the result, and only one of those two things can be handed over.
Which is why an autonomous agent has to be a good communicator, and the handover is part of the job: what it tried, what it threw away, what it checked, and a clear PR at the end. If it hands you perfect work you cannot explain, it has not saved you anything.
The job changes rather than disappears. Less time gluing tabs and agents together, and more time deciding what to build, how good it has to be, and whether the evidence is enough to ship.
Where we are on the autonomy curve
I have been trying to pin this down for a while, because "autonomous" on its own tells you nothing. It takes two axes. Model capability on one, engineering autonomy on the other, and the thing worth noticing is that they do not move together.
Model capability on one axis, engineering autonomy on the other. Claude Code sits at L1, the loops of today at L1.5, and AdaL Engineer is aiming at L2.
L1 is heavy supervision, a technician you prompt through every step. L1.5 is the loops of today, where the agent has more freedom to keep going and you are still in the seat, and that is where I think we actually are. L2 is single-task autonomy, a junior engineer who takes a goal and comes back with something finished, which is what AdaL Engineer is aiming at. L3 is multi-task, closer to a tech lead, and it needs memory that keeps learning across runs. L4 is team level, a company brain.
Model capability can keep climbing while the autonomy axis stays flat, and that is the babysitting regime. Nobody has shipped L2 yet, including us. AdaL Engineer is in preview and it still fails in places, so the far points on that curve are direction rather than arrival.
If the shape is right, the interesting work for the next year is not a better coding agent. It is memory that survives across runs, evaluation you can trust without reading every line, and handovers good enough that one person can answer for far more work than they could personally review.
AdaL is an AI research lab focused on autonomy, especially agents and memory. Named after Ada Lovelace. AdaL Engineer is our first experiment in the engineer seat, and it is in preview.
If you want to try it: adalagent.ai. I'd love to hear what worked, what broke, and what you think.