Why Agentic Systems Need Distinct Roles
A reflection from the Harvard Data Science Review Agentic AI 2.5 Week Intensive
Working through the agent taxonomy this week reshaped how I think about intelligent workflows. In the previous article on the hidden architecture of work, I explored how friction builds from the unspoken structures that hold a process together. The taxonomy extends that idea because it shows that AI cannot simply be dropped into those structures as one unified capability. It breaks the illusion that a single model can absorb all the complexity. Real organisational intelligence emerges only when distinct types of agents work together, each carrying a different responsibility that reflects the division of labour already present in the workflow.
The five roles feel intuitive at first. Assistants gather and structure information. Analysts interpret it. Taskers carry out the clear, bounded actions. Orchestrators decide how work moves. Guardians make sure nothing drifts beyond what the organisation can trust. But the moment you look closer, you see that the separation is not cosmetic. It is structural. It gives the workflow the ability to reason, act, learn, and stay safe all at once without collapsing the whole system into one overburdened agent.
When we fold everything into a single model, we create brittleness. The agent might try to interpret when it should simply execute, or it might execute before its reasoning is stable. It might handle governance decisions without the context it needs, or it might make operational changes without any awareness of upstream or downstream impact. That blend of responsibilities is fine for a small script, but it cannot support a workflow that carries live business value. The separation of agents prevents accidental authority. Each agent knows what it is allowed to do, what it must not do, and what information is safe for it to act upon.
The course positioned these roles as a kind of organisational architecture expressed in machine form. Humans already behave this way because complex work requires different minds. The person who investigates context is not always the person who interprets the data, and the person who interprets it is often not the one who executes the action. The person who oversees safety and compliance is certainly not the one writing the production code. We divide these responsibilities because it creates stability. A system with boundaries is easier to govern and easier to trust. The same principle applies when we shift that work into agentic systems.
Once you view the agents as distinct intelligences rather than generic tools, the hand-offs between them become the heart of the workflow. The Assistant shapes the problem so the Analyst does not waste time searching for meaning in noise. The Analyst grounds the insight so the Tasker does not execute based on an ambiguous signal. The Orchestrator chooses when each role takes over, maintaining a coherent sense of intent across the whole journey. The Guardian stands slightly apart and sees what the others miss, catching silent drift, policy breaches, and misalignments before they undermine trust.
This architecture changes how a workflow behaves over time. A single model makes the system faster, but not wiser. A multi-agent design gives the system room to observe itself. It can track where reasoning happens, where decisions arise, where actions propagate, and where governance needs to tighten. Each anomaly becomes a chance to refine a boundary, update a contract, or adjust an assumption. The system learns in a way a monolithic agent cannot because the feedback is not lost inside one black box. It travels across roles that were designed to reflect and adapt.
There is also a practical business reason for separation. Organisations do not trust systems that blur authority. If an agent recommends a decision, executes the decision, and checks its own compliance, the governance body cannot trace the life of the action. Separation creates traceability. You know which agent thought, which agent acted, and which agent checked. You know where the responsibility lies. It gives leaders the confidence to let agents handle more of the workflow without fear that something will slip through unnoticed.
This is where the conversation becomes interesting for consulting and engineering work. If we want systems that scale and continue to adapt as the organisation grows, we need workflows that behave more like teams than like scripts. That means clarity of role, clarity of escalation, clarity of knowledge, and clarity of risk. It means designing architecture that mirrors how we expect good organisational intelligence to operate. Splitting the agents is not overhead. It is what allows the system to reason about its own behaviour.
As I move into the engineering phase of the course, this is the theme that will shape the build. The challenge is not to craft one powerful agent but to design a set of agents that amplify one another’s strengths while catching one another’s weaknesses. The goal is to create a workflow that does not simply move faster but moves with intention and learns from every exception it encounters.
The work ahead involves giving these roles concrete form. That means building the orchestration patterns, defining the contracts, shaping the escalation paths, and designing the learning loops. It is the craft that turns theory into something an organisation can rely upon. The next article will follow that early construction work as the ideas begin to take shape on the ground.