For over a year I have been building AI agents that run for real inside companies: my own skills, a working harness, systems where one model plans, another executes and a third checks the result. The longer I do it, the more often I get a sense of déjà vu. The problems I solve look like they were taken straight out of a management textbook.
I am not talking about an agent that someone spins up on their own laptop for small tasks. I mean agentic systems that run in production and are available to the whole organization. Some of them work fully autonomously, some under human supervision (human in the loop). That is a completely different scale than a single tool for one person. Such an agent becomes a full-fledged worker that the company entrusts with real tasks, access to data and systems, and responsibility for the result.
I already covered a similar topic in the post The architecture of agentic AI was solved in 1949. Since then I have more experience and more thoughts, and “loops” have shown up too, so I want to describe it again.
In this post I will show that this is not a coincidence. Most concepts from agent engineering have an older counterpart in management theory, cybernetics and quality management. I will describe the strongest analogies, and at the end the things that are genuinely new in agents.
What is the main thesis?
Let me put it plainly:
Agent engineering is largely the management of an organization in which the worker is not a human, but a language model.
When a program was deterministic, code was enough. When the “program” plans on its own, picks tools, makes mistakes and needs supervision, we start to need the same things companies need to manage people: goals, roles, permissions, control, reporting, evaluation and an improvement loop.
The shortest way to write the whole thing is:
- the model is the worker,
- the prompt is the order,
- the context is the information,
- the tools are the resources and permissions,
- the harness is the management system,
- evals are quality control,
- a multi-agent system is an organization.
Where did the word “agent” come from?
This is my favorite part, because it shows that the AI field did not invent a new name. It reached for a concept that theory described 50 years ago.
Agency theory (Jensen and Meckling, 1976) describes the principal-agent relationship. I hand a task to someone who knows more about their work than I do (information asymmetry), who can optimize for themselves instead of for my goal (moral hazard), so I have to design incentives, monitoring and contracts. The AI field is discovering exactly the same agency costs today, it just calls them “alignment tax” and “oversight”.
There is one important difference here, which I will come back to at the end. A human can knowingly act in their own interest. An AI agent more often fails because of a badly described goal, missing information, a wrong interpretation of the instructions, or because the wrong model was picked for the task.
Two other roots are worth adding:
- reward hacking, meaning an agent that optimizes a benchmark instead of the real goal, is Goodhart’s law and a classic KPI pathology. An employee gaming the bonus system does exactly the same thing,
- orchestration and multi-agent systems are rooted in management cybernetics. Back in the 1970s Stafford Beer laid out an architecture with operational units, coordination, control and escalation signals. It is almost one to one today’s orchestrator diagrams with sub-agents.
How is running an agent like managing an employee?
Once you mentally swap the word “agent” for the word “employee”, most concepts suddenly become obvious. Below are the strongest pairs.
| AI concept | After swapping for a human | Known concept |
|---|---|---|
| System prompt | Permanent rules of the role | Job description, scope of duties, policy |
| User prompt / task | A specific assignment | Brief, work order |
| Context engineering | Choosing the information for the task | Briefing and information flow |
| RAG / knowledge base | Access to documentation while working | Knowledge base, procedures, instructions |
| Tool access | Access to systems and money | Allocation of resources and permissions |
| Fine-tuning | A permanent change of behavior | Training and skill development |
Notice one thing. A “better prompt” is rarely the equivalent of a more motivating speech. More often it is the equivalent of a better brief, a more precise instruction, easier access to knowledge and a clearer standard of the result. That is the work of a manager, not of a motivational speaker.
A separate example is skills. An agent skill is a ready package of instructions, tools and examples for a specific type of work. In a company we would call it a standard operating procedure, a playbook or a competence package.
What does supervision and control over an agent look like?
This is an area where IT is only now setting up rules that banking and audit have had written down for decades.
- human-in-the-loop is the four-eyes principle and a permissions matrix. Someone decided long ago which decisions require a countersignature and which do not. We are only now working out which tool calls require approval,
- escalating from the agent to a human is management by exception. A subordinate acts autonomously within norms and only reports deviations,
- guardrails are internal control, separation of duties and poka-yoke from lean, meaning building the workstation so that an error is impossible or immediately visible,
- observability and tracing are controlling, the audit trail and management reporting,
- levels of agent autonomy are the delegation continuum and situational leadership. The “tell, sell, consult, delegate” scale is ready: from “the agent proposes, the human approves” all the way to full autonomy, matched to the maturity of the worker.
An old idea from Deming comes back here too. Quality control at the end of the process is worse than quality built into the process itself. In the language of agents: a better prompt usually beats a validator on the output.
Why is a team of agents an organization design?
When you build a multi-agent system, you are not just writing code. You are making classic organizational decisions.
| AI concept | After swapping for a human | Known concept |
|---|---|---|
| Multi-agent system | A team of specialists | Organizational structure |
| Orchestrator / router | The person assigning tasks | Manager, dispatcher, coordinator |
| Handoff | Passing the task on | Handover between departments or stages |
| Planner-worker-reviewer | Separated roles | Separation of duties, maker-checker |
| Specialized agent | A specialist in one type of work | Division of labor (Adam Smith) |
| Agent swarm | A group splitting the work | A self-organizing team |
Building such a system, you answer the same questions as when designing a company:
- which roles to separate,
- who hands work over to whom,
- who is responsible for the result,
- who can make decisions,
- who checks quality,
- when a problem should go up,
- how many workers one coordinator can supervise (the classic span-of-control debate).
I see it in practice myself. A team of agents without a division of roles and responsibility behaves like a team of people in the same situation. It duplicates work, gets in its own way and loses the result. That is why Belbin roles, Tuckman’s stages and the RACI matrix suddenly become useful when designing agentic systems.
How do agents learn and improve?
The most interesting relationship here is with double-loop learning, which Chris Argyris described in 1977.
- single-loop: the agent did the task badly, so we fix the prompt,
- double-loop: maybe the task, the KPI or the rule itself was badly defined, so we change the assumptions of the whole system.
The AI field reaches this through “eval-driven harness improvement”, meaning fixing not only the instructions but the whole structure of work. A few other pairs from this area:
- agent reflection is an after-action review, a method of reviewing after the fact,
- evals built from production failures are lessons learned,
- a red-team agent is the devil’s advocate, internal audit and war-gaming,
- retry and error recovery are corrective actions and emergency procedures.
One important note about evals. An eval does not test the model alone. It tests the whole setup: the model, the instructions, the tools and the way of working. That is why it is closer to an audit of the whole process than to the review of a single employee.
What is genuinely new in agents?
I do not want to overstate the thesis that this is only reinventing the wheel. A few things are genuinely new:
- you can write the entire management structure in code,
- you can copy “employees” at almost no cost,
- you can run many copies in parallel,
- you can change roles and team structure in an instant,
- you can record almost every action, which is impossible with people,
- new problems appear from the probabilistic behavior of models, along with attacks through instructions such as prompt injection.
But the higher-level problems are old. How to define a good goal, how to delegate, how to measure the result, how to control risk, how to pass on knowledge, how to divide roles, how to detect errors and how to improve the process. Management theory wrote all of that down long ago.
There is one more observation that surprised even me. The AI field is not replaying random fragments of history, but the whole sequence. First Taylorist supervision of every step (approval on every tool call), then the discovery that this does not scale, and a shift to management by objectives and exceptions. Agents are going through a crash course in twentieth-century organization theory.
Summary
If you are building agentic systems today, it is worth looking at them more broadly than just through code and models. Older disciplines help with that:
- management theory and organization theory,
- cybernetics and control theory,
- quality management, lean and PDCA,
- principal-agent theory and corporate governance,
- process and project management,
- knowledge management and human factors.
In my opinion this is a practical hint, not a piece of trivia. Instead of inventing rules for escalation, permissions or role division from scratch, you can reach for solutions that have worked in organizations for decades. The model is the worker, the harness is the management system, and a multi-agent system is an organization. The rest is a set of known problems in a new disguise.
