The Worker You Don't Yet Dare to Hire

There is an AI model that can win gold at an international mathematics olympiad. The same model reads an ordinary analog clock correctly 50.1 percent of the time.

A lone worker at a lit desk inside an orange boundary, surrounded by rows of empty desks in the dark.

That is the part worth sitting with.

Not because it is funny, and not because it is a gotcha. It matters because it tells us what kind of technology we are dealing with. This is not normal software. It is not a calculator that occasionally slips, and it is not a junior who simply needs more experience. It is a system with real capability and an unevenness our organizations are not built to reason about.

It can solve something extremely hard and then miss something embarrassingly simple. And it will not tell you which kind of moment you are in.

That is why I think this summer marks a real shift. AI is no longer only a tool you ask questions. It is becoming something you delegate work to.

An assistant helps you do the work. A worker does the work. Once you make that shift, the conversation changes. It stops being about prompts and productivity hacks. It becomes a question of delegation, permissions, verification, rollback, auditability and accountability. In other words, it becomes an engineering and organizational problem.

Inside the frontier labs, this is already visible. Engineers have moved most of their daily work into agents. Not one assistant in a chat window, but many agents planning, running, failing, correcting and trying again in parallel. The heaviest users report more than seventy hours of agent runtime in a single day. That is only possible because the work no longer happens at the pace of one person typing. It happens at the pace of a swarm.

But we should be honest about those numbers. They are the edge of the edge, and they are reported by the people who build and sell the tools. Step outside that world and adoption is still a rounding error. Around seventeen percent of organizations. Well under one percent of individuals. If you take the frontier number as a description of how work looks now, you are reading a sales sheet, not a map.

And faster code is not the same thing as more value.

Writing code was never the whole job. Understanding the problem, making the right trade-offs, handling legacy, knowing what must not break, testing the right thing and owning the result when it goes wrong. That is the job. AI is getting better at parts of it. It has not removed the need for ownership.

So the real picture is this. Capability is racing. Reliability is improving but still uneven. Adoption is behind both.

The bottleneck has moved. It no longer sits in what the model can do. It sits in what you dare to hand over.

That is the part I think most organizations get wrong. They look at an agent and ask: is the model good enough? That is the wrong first question. The better question is: what would have to be true in our systems and our organization for us to safely hand this work over?

Because you do not delegate serious work to something you cannot constrain, observe or hold accountable. A worker who is right two times out of three, and confidently wrong the third, is not a capability you buy. It is a responsibility you have to build around.

And yes, someone will object. A human can just review it.

Exactly. That human is the accountability. That human is the boundary. That human is where responsibility currently lands.

The problem is what happens next. As the model improves, the review starts to feel unnecessary. The errors become rare enough to be boring to guard against. So we quietly take the human out of the loop. But the rare errors that remain are usually the ones that matter. The ones that pass because everything looked reasonable. The ones that reach production. The ones that touch a customer. The ones that become expensive precisely because the agent acted fast, confidently and at scale.

So the objection does not survive. It proves the point. Human in the loop is not a strategy. It is a temporary control. Sometimes necessary, often useful, and never enough on its own.

So what do you actually do? You lean into it.

That sounds backwards, but it is not. The capability is coming, with or without your readiness. Whoever waits for the technology to become reliable before touching it will wait too long, and be outrun by whoever built while it still chafed. Build to delegate more, more boldly, earlier than feels comfortable.

Building for it does not mean making everything an agent. Clean interfaces, explicit permissions, traceable actions. That is simply good craft, whether the agent arrives or not. The agent only makes the bill come due.

But the boldness is not free. You get to spend it only once you have built the thing that lets you.

And here is where I think we mix up two kinds of guardrail that do opposite jobs.

The first kind is babysitting. You keep the task small, review every step, double-check everything, because the model cannot be trusted yet. That guardrail should shrink over time. As the systems get better, keeping a human on every tiny action becomes theatre. A slow process pretending to be control.

The second kind is not about the model's skill at all. It is there because the consequence is real. What the agent is allowed to touch. What data it can reach. What it can change. What it can undo. What you can see afterward. What must never happen without a human on it. Those guardrails do not shrink as the model gets smarter. They grow. Because a smarter agent acting on the wrong permission does more damage, faster, at greater scale.

This is the uncomfortable part. The better the model gets, the more you will want to hand over. And the more you hand over, the larger the blast radius when it is wrong. So control has to scale with capability. Not because we are afraid of AI, but because we are serious about using it.

None of this is new. In safety-critical systems you already know it. You never trust capability alone. You build responsibility around it. Boundaries, logs, approvals, separation of concerns, fallbacks, rollback, a human who answers. What is new is that this now applies to almost every process, because software is everywhere and AI is starting to act on behalf of people inside it.

So governance is not the brake on the opportunity. Done right, it is what makes the opportunity real.

The organization that builds the boundaries, the audit trails, the permission models and the rollback can delegate boldly without losing its grip on what happens in its name. The organization that does not will stay cautious. Not for lack of ambition, but because every step forward feels unsafe. That is the real competitive difference. Not who has access to the best model this month. Everyone will have strong models. The difference is who has built a place where those models can actually do useful work. Safely, repeatedly, at scale.

That is why I think agent readiness is one of the most important questions right now. Not can we build an agent. Almost anyone can build a demo. Can we let it work? Can we let it touch real systems? Can we let it run when no one is watching? Can we see what it did afterward? Can we undo it? Can we say who was responsible?

That is where the hard work is. And it is where the value is.

You do not build these controls to protect yourself from the future. You build them so you can run straight into it, without losing control of what happens in your name.

The capability is real. And the responsibility is still ours.