Blog: What if we’re building AI agents the same careless way we’ve been building jobs for sixty years?

Author: Ali Akkaya, Senior Digital Solutions Manager, CRF

A few weeks ago I was running an internal session on Microsoft Copilot. The point of it wasn’t really Copilot. The point was to move people away from the question that dominates every AI conversation right now “how do I write a better prompt?” and towards a more useful one: “how do I design a better workflow?”

To explain how a multi-agent system works, I reached for an analogy, the way I always do. I said: think of it like a team. You have a line manager who takes the brief, breaks it into pieces, and decides who does what. Then you have a few genuinely talented specialists, each handed the part of the job they’re best at, each trusted to get on with it. The manager doesn’t do the work. The manager composes it.

A colleague of mine, Prof. Rob Briner, who has spent his career on the evidence base behind how people actually work, listened to that and said something that has stuck with me ever since:

“That sounds like job design.”

He was right. And the more I sat with it, the more I realised it wasn’t a neat turn of phrase. It was the whole thing.

We’ve quietly stopped designing tools and started designing teams

Here’s the shift that I don’t think enough people have clocked. Prompt engineering is coaching an individual: you give one model better instructions, and you get better output from one model. Agent orchestration is something else entirely. You’re deciding what the specialists are, what each is allowed to touch, who hands off to whom, who checks the work, and who is answerable when it goes wrong.

That’s not a tooling upgrade. That’s the difference between writing someone a good brief and designing an operating model.

The moment you frame it that way, an uncomfortable thought arrives. We have been designing jobs for human beings for a very long time, and there is a deep, boring, unglamorous science about how to do it well: Hackman and Oldham on what makes work meaningful, Karasek on the brutal cost of high demand with low control, the sociotechnical systems people who figured all this out studying coal mines in 1951, Sharon Parker’s more recent work pulling it into something practitioners can actually use. Sixty-plus years. Hundreds of studies. A genuinely settled set of findings about what makes a role succeed or fail: a meaningful scope of tasks, enough autonomy to act, clear expectations, a manageable load, clean hand-offs, and honest feedback.

Hang on a minute. Doesn’t that list sound oddly familiar?

It should. We are now designing roles for non-human agents at enormous speed. And we are, for the most part, doing it without reading any of that.

So here is the question that became this article (and, I suspect, a few more after): what if the biggest risk in agentic AI isn’t the technology at all (I mean, it could be, but bear with me), but that we reproduce, at machine speed, every job-design mistake we’ve spent six decades documenting in humans?

The same mistakes, but just a little bit faster

I’m sure none of you have ever witnessed any of this but think about how badly designed human jobs can go wrong. Roles with no clear boundaries, so nobody knows where one person’s responsibility ends. People held accountable for outcomes they were never given the authority to control. Someone drowning under fifteen competing priorities because “they’re good, they’ll cope.” Work that’s been automated or restructured for people without anyone asking the people who do it.

Now look at how agentic systems fail in production, and tell me it’s a different list.

I’ll give you my favourite example, because it’s the one I find most beautiful and most revealing. The 10× generalist agent, one mega-agent armed with every tool, expected to do everything. This is the digital twin of the heroic individual contributor. You know the type in a human org: the person who’s across everything, the single point of dependency, the one whose departure quietly terrifies the leadership team. We all know that’s fragile and that’s why we say ‘we want teams, not heroes‘.

Turns out the machines agree. Microsoft’s own guidance on building agents is blunt about it: once you load a single agent with more than roughly thirty to forty possible actions, the quality of its decisions starts to degrade. It gets worse, not better, the more you pile on. The answer, in silicon exactly as in the org chart, is to stop building a hero and design a team. Narrow, well-scoped specialists, coordinated by something that orchestrates rather than does. Divide and conquer, I can see the computer scientists reading this article are nodding; they’ve been building systems this way for decades.

This is the part I find genuinely lovely, and I want to say it plainly because it sits underneath everything else: it is us, humans, who design and build these systems. So of course they strain in the ways we strain (at least for now). What better blueprint did we ever have than ourselves, and the way nature already solved coordination long before we did? Which brings me to the analogy I can’t let go of.

Cognitive load is now a design variable on both sides of the desk

Anyone who’s studied how the brain processes information knows about cognitive load, the simple, stubborn fact that working memory has a finite capacity, and when you push too much through it at once, performance collapses. I first met the idea in multimedia learning design at university: the whole discipline is built on presenting material without overwhelming the brain’s processing limit in the moment. Give a brilliant person too many things to hold in their head at once and they will fail at tasks they could easily have done with fewer.

It turns out LLMs do exactly the same thing, again at least for now. A 2025 study with the rather poetic title ‘United Minds or Isolated Agents?’ found that AI agents degrade under heavy in-context load in a way that maps almost eerily onto human working-memory limits. They start failing at problems they are perfectly capable of solving, simply because you’ve crammed too much into their attention at once.

Sit with that for a second. The thing we built to escape our own limitations has inherited them. Which means “don’t overload the agent” and “don’t overload the person” are no longer two different conversations. In a system where humans and agents work side by side, cognitive load is one design problem, not two. And the agentic workforce is not weightless, every time an agent escalates something to a human (the human-in-the-loop pattern, which I am planning to briefly cover in various articles), it’s spending that human’s attention. Build the system carelessly and you don’t remove the overload. You just move it.

One honest caveat

I want to be careful, because analogies are seductive and I love them too much to let this one mislead anyone.

Designing agents is like job design. It is not the same as employing people. Agents have no career, no motivation, no need/ambitions to grow, no wellbeing to protect. They have token budgets, context windows, and uptime. Push the metaphor too hard and you start anthropomorphising software, which is its own kind of mistake.

The analogy is valuable for exactly one reason: it imports design discipline. Purpose. Scope. Authority. Boundaries. Voice. Accountability. Feedback. The questions a good manager asks before handing someone a job are the questions we should be asking before we hand an agent one. Borrow the discipline. Don’t borrow the sentiment.

Where this leaves us

Here’s the thought I’ll leave you with, and it’s the one Rob’s offhand comment really planted.

Nvidia’s CEO Jensen Huang said a year ago or so that the IT department of every company is, in effect, becoming the HR department for AI agents. I think that’s close, but I’d put it more bluntly: the skill that’s about to matter most isn’t writing prompts or even building agents. It’s designing the work: deciding what should be done, by whom, with what authority, checked by whom, owned by whom. That’s not a new skill. We’ve just spent sixty years calling it something else.

I started where I always try to start, not with the technology, but with the why. And the why here is almost embarrassingly simple: these systems work better when we design them the way we’ve long known good human work should be designed. We built them in our own image. We might as well learn from the best of what we already know about ourselves.

More on that in the pieces to come. I’ve got at least a couple of these tensions I deliberately left on the table for next time, including one I find genuinely exciting: what happens to the science of work itself, now that we can stand up and tear down a “role” in minutes and watch exactly how it performs.