The Work Was Always There

A few weeks ago I sat in a meeting room with the founder of a company that does a great many things well and one thing badly. The badly part was a report. Every Monday someone on the team pulled numbers out of four different systems, pasted them into a spreadsheet, formatted the whole thing, and turned it into a deck that three people then argued about. It took the best part of a day. For years it had taken the best part of a day, and everyone had made their peace with that.

We did not talk about it for long. I opened my laptop, started Claude Code, and over the next forty minutes the two of us built a small agent that read the four sources, did the joins, wrote the summary, and put it where the team already looked. The founder watched the terminal scroll. When it finished and the numbers were right, he did not say well done. He said, can it also do the thing we do with the supplier invoices. And the thing with onboarding. And the forecast we redo every Friday.

That last part, the list that comes right after, is what I keep seeing now, in company after company. The agent itself is not the interesting part. It does one small task and then it stops. The interesting part is what people see once they have watched it work.

For most of that founder’s working life, the Monday report was the cost of knowing where the business stood. Nobody questioned it because there was nothing to question. The work was the work. Watch a small agent do it in under an hour, though, and the report is not what changes. What changes is that you start to see the other forty things shaped exactly like it.

The familiar way to describe this moment is a tool arriving to replace a task. From the rooms I sit in, what actually happens is different, and larger. People discover that a whole category of work they had stopped noticing, because fixing it was never worth the effort, has become worth fixing. The backlog was always there. They could not see it as a backlog. It was under water, the way a beach is at high tide, there the whole time and impossible to see.

Why did the backlog get this deep? Walk into most companies, even very successful ones, and you find people working in a way that would be recognisable in 1985. Numbers keyed from one screen into another. Documents emailed back and forth with the version number in the filename. A dashboard nobody trusts sitting next to a spreadsheet everybody does. None of this is stupidity. It is the residue of an economic fact that held for forty years: most small problems were not worth solving.

Solving a problem with software used to be expensive. It needed a specification, a budget, a developer, a project, a queue. By the time anyone reached the small annoyance that cost one person two hours a week, the cost of fixing it was larger than the cost of living with it. So it did not get fixed. It got absorbed. Multiply that single decision across every team and every year, and you arrive at the modern company: a structure held together by thousands of small inefficiencies that were each, on their own, rational to ignore.

You know the kind of thing. The finance team reconciling two systems by hand every month because the integration was never anyone’s priority. The operations lead with a private spreadsheet that does the job the official software was meant to do and never quite did. The proposal rebuilt from nothing each time, because templating it properly was a project no one approved. Each of these survived for one reason: it was cheaper to tolerate than to fix.

I wrote a while back about how complexity itself became a product, how whole businesses were built on the fact that small problems were too expensive to solve. The same logic explains the inside of almost every organisation I walk into. The work people do all day is shaped less by what would help and more by what was once affordable to build.

That constraint has moved. The cost of solving a small problem has fallen far enough that the old arithmetic no longer holds. The two hour weekly annoyance is now worth an afternoon with a laptop. And once one of them is solved in front of you, the rest of them stop being invisible.

So here is what the work looks like now, at least the work I find myself doing. We do not turn up with a slide deck or a strategy document about what the company could one day do. We turn up with questions, because everyone is at a different point and you cannot help until you know where they are. Then, as fast as we can, we start building. Not a demo made earlier and replayed, but a small agent built there in the room, on their own data, against a problem they actually have. Claude Code or Codex open in a terminal, a data source connected through MCP, a small agent standing up, an API wired in. The point of building it quickly is to make it real, because a working agent settles an argument that a presentation only starts.

The more useful move is the next one. We get the people who run the business onto their own laptops, connected to the same tools, building the next thing themselves rather than watching us do it. That is when the capability stops being something we are showing them and becomes something they can do. It is also when they see, plainly, what is real and what is theatre, what works now and what is still jagged and breaks the moment you lean on it. Building it yourself is the quickest way to tell the difference, and the only way the excitement turns into something a company can carry on without us.

This changes who needs to be in the room. The old way to improve a company at any scale was a programme: a large team, every discipline represented, the strategist and the designer and the engineer and the analyst all coordinating toward one big change delivered some months later. What I keep watching instead is a small number of people, sometimes one or two, going in and fixing many small things in sequence, each fix a matter of hours or days rather than quarters. The whole improves, not because anyone ran the big programme, but because enough of the small things got fixed. You reach the same place by accumulation rather than by grand design.

It is all still experimental, and it changes constantly. What worked three weeks ago has often been replaced by something better, or turned out to be a bad idea once it met real data. Early on the instinct is to build one enormous agent with every tool and all the context loaded in, the equivalent of hiring someone who knows everything and asking them to do all of it at once. That is almost always the wrong move. The discipline, and you learn it by getting it wrong first, runs the other way: fewer agents, each with a narrow job, the smallest set of tools that does that job, and far less context than feels comfortable. A focused agent that does one thing reliably beats a clever one that does ten things you cannot trust.

And trust is the part almost nobody budgets for. Connecting an agent to the systems is the easy half now. The hard half is knowing whether what it hands back is true. An agent that confidently returns the wrong number is worse than no agent, because someone will act on it. So the work that takes the time is not the building. It is the evals: the checks you write to test the thing against cases where you already know the answer, run again every time you change a prompt or swap a model, so it tells you it has broken before your team finds out the hard way. I have watched more good agents fail here than on anything technical. The plumbing holds. The output drifts, and nobody is checking.

The ground under all of this moves week to week. This week Vercel shipped eve, a framework for building and running production agents, and it sits inside a larger pattern: the standards and rails agents need, from how they connect to data to how they will transact and prove who they are, are being built in a hurry by the companies you would expect. This is not a fringe experiment any more. It is where a great deal of serious engineering is now pointed.

It would be easy to read all of this as a story about people being removed. Fewer people solving more problems sounds like a smaller payroll. I understand why the mind goes there, and I do not think it is the honest reading of what is in front of me.

The reason is the backlog. If improving a company were a fixed amount of work, a more capable team would indeed look like needing fewer people. But the work was never fixed. It was suppressed, capped for forty years by what the company could afford to build. The line has dropped, and the work that always sat below it, worth doing and never done, has come back into view at once. The pile is not shrinking. It has become visible.

So in the rooms I sit in, the feeling is rarely we need fewer people. It is something closer to we finally have a way to get to the things we gave up on. The founder who asked whether the agent could also handle the invoices and the onboarding and the forecast was not picturing a smaller company. He was picturing all the things he had decided, years ago, were not worth the fight. The constraint that is lifting is not the cost of people. It is the cost of caring about the small things.

That does not mean nobody is affected, or that every role carries on unchanged. A task that took five people a week can now take one person an afternoon, and that is a real change to how that work gets done. But the people are not standing in front of a shrinking pile of work. They are standing in front of one that was invisible a year ago and is suddenly addressable. The question stops being who do we no longer need, and becomes what could we finally fix.

If I am right that companies are sitting on a backlog they can suddenly see, then the next few years are going to be full of companies wanting to change how they work. Not buy a tool. Change how they work. That is the shift I hear forming in almost every conversation now, with founders and executives and the people who run things day to day. They have seen what one small build can do, and they want that feeling applied to everything.

The open question, the one I do not have a clean answer to yet, is how the capability spreads. Do you teach a company’s own people to think and build this way, so the fixing happens from the inside. Do you bring in small teams who lean in alongside them for a season and leave the habit behind when they go. Probably both, in proportions that depend on the company. I am working it out in real time, the same as everyone else.

What I am increasingly sure of is the shape of the skill that matters. It is not knowing the latest framework, which will have changed by the time you have learned it. It is the ability to sit in front of a real business, see the small thing worth fixing, build it, check that it is true, and then do it again. That is not a tool you can buy. It is a way of working, and it is learned the way that founder started to learn it, by watching something small actually work and then wanting more.

The interesting part of my job now is not the building. It is the moment right after, when someone looks at their own company differently and starts listing everything that could be better. That list is the real beginning.

The next piece follows one of these builds further in, into the harder question underneath this one: what it actually takes to get a company’s own people seeing their work this way, and why most attempts to train it miss what is actually being learned.

Craig Hepburn is an AI strategist and Perplexity Fellow. Twenty years building at the frontier of digital, from Microsoft and Nokia to Art Basel and UEFA. Now building at the frontier of agentic intelligence.