The big idea in one sentence
One agent that tries to do everything will do everything badly. A team of small, specialized agents — each with one clear job — does the work better, cheaper, and in a way you can actually debug.
Why does a single agent struggle? Because a complex task forces it to plan, fetch data, call tools, do the work, check the quality, and write the final answer — all in one breath, inside one crowded context window. Each extra responsibility makes every other responsibility worse. Mistakes pile up and nobody catches them, because the same model that made the mistake is the one "checking" it.
Human team analogy
You would never hire one person to be the architect, the developer, the tester, the researcher, the project manager, and the presenter on the same project. You create roles, give each person a clear scope, and let them hand work to each other.
The engineering name for this
This is simply separation of concerns, applied to AI. Each agent gets a narrow responsibility, a bounded context, and a measurable output. Smaller scope → fewer confusions → easier testing → easier debugging.
The seven roles on the team
The video describes a typical roster. You don't need all seven on day one — but it helps to know the full cast before you decide who to "hire."
In simple words: The planner reads the user's request and breaks it into a numbered list of steps before any work starts. "Build me a market report" becomes: identify the market → fetch data → compare competitors → analyze risks → make charts → write report → send for review.
The planner's output should be a plan (a task list or task graph), never the work itself. If your planner starts writing the report, you've built it wrong. Give it a strong reasoning model — bad plans poison everything downstream.
In simple words: The doer takes one step from the plan and executes it — writes the code, drafts the text, transforms the data. It's the worker on the assembly line. It's good at its small task, but it can't see the whole project, so its output may be locally right and globally inconsistent.
Treat the doer like a worker node: hand it a precise task, its inputs, its constraints, and the exact output format you expect. Never let the doer own the workflow — that's how you get an agent quietly redefining the goal mid-task.
In simple words: Language models don't actually know what's in your database right now. The tool operator is the agent that touches the real world: it calls APIs, queries databases, runs scripts, reads files, and brings back facts.
This is your highest-risk role. Govern it with permissions, audit logs, read/write boundaries, and approval gates for anything destructive. And keep it dumb on purpose: it fetches structured evidence and returns it — it should not "reason freely" about what the evidence means, especially in safety-critical domains.
In simple words: The learner goes and finds outside information the team doesn't have — recent data, documents, announcements. In most real systems this is the RAG (retrieval-augmented generation) role: search a knowledge base, pull the relevant pieces, hand them over.
The skill here is not retrieval — it's filtered retrieval. A good learner decides what is relevant, fresh, and trustworthy, and it labels where each fact came from. If you can, tag evidence by reliability (e.g. deterministic extraction > declared documentation > LLM inference) so downstream agents know what they can lean on.
In simple words: The critic reviews what the others produced and hunts for problems: hallucinations, missing requirements, logical contradictions, weak evidence, unsafe assumptions, bad formatting. This is the feedback loop that makes the team better than a single agent.
A critic that just says "looks good" is useless. Force structured, actionable feedback: the issue, its severity, the evidence, and a recommended fix. Example: "The output references signal X, but X is not in the extracted interface. Severity: High. Fix: replace with confirmed signal Y or mark unresolved." In high-stakes systems, the critic is not optional — it is the safety layer.
In simple words: The supervisor watches the workflow while it runs. Are agents stuck in a loop? Did a tool call fail three times in a row? Is the budget blown? Should we retry, escalate to a human, or stop? The planner made the plan; the supervisor manages the execution.
Watch for the classics: infinite loops, repeated failed tool calls, conflicting outputs, over-budget runs, low-confidence conclusions, and unsafe write actions. Give the supervisor hard STOP conditions. In production, this role becomes your runtime governance layer — the thing that keeps an autonomous system from quietly going off the rails.
In simple words: Internal agent chatter is messy. The presenter takes the validated results and assembles them into the thing the user actually sees — a clean report, an email, a dashboard, a document.
One iron rule: the presenter formats, it never invents. If a fact didn't survive the critic, it doesn't appear in the final output. Pick a strong writing model here — this role decides whether your sophisticated pipeline looks sophisticated to the user.
How the team works together
A clean minimal workflow looks like an assembly line with one decision point. The supervisor sits at the gate: it accepts the work, sends it back for another pass, or escalates to a human.
Start small, grow only when needed
You almost never need all seven roles on day one. A sensible growth path:
- Minimal production pattern: Planner + Tool Operator + Critic + Presenter. This already covers planning, grounding, quality, and output.
- Add later, when complexity demands it: Learner (when you need serious retrieval), Supervisor (when workflows get long enough to get stuck), then Domain Expert, Safety Reviewer, or Memory Manager roles.
Do not let your main "reasoning agent" also be the retriever, the verifier, the planner, and the final writer. That single decision creates exactly the failure modes multi-agent design exists to prevent: hallucination, circular reasoning ("I checked my own work and I agree with myself"), hidden assumptions, and zero traceability.
Making each agent good at its job
Defining the roles is half the work. The video names four levers for making each role actually perform — and each one has a clean HR analogy.
4.1Prompting
= writing the job description
The system prompt defines the agent's role, its boundaries, its expected output format, and what to do when it fails. Vague prompts produce vague employees.
4.2Model selection
= hiring the right person
Not every role needs the same (expensive) model. Planner and critic want strong reasoning; the tool operator wants reliable function-calling; the presenter wants strong writing; the learner wants retrieval performance. Match the model to the job and you cut cost without cutting quality.
4.3Tuning & examples
= on-the-job training
Fine-tuning or just good few-shot examples make behavior consistent. A requirements critic, for example, learns fastest from examples of good requirements, unsupported claims, ambiguous references, and missing test procedures.
4.4Context
= the access policy
Each agent should receive only the context its job requires. Too much context confuses the model, raises cost, and increases hallucination risk. Context is need-to-know, not all-you-can-eat.
Prompting: the difference in practice
Mapping this to a real engineering system
The pattern becomes concrete when you map it onto a real domain — say, a knowledge engine for model-based automotive software (Simulink/TargetLink models, ARXML, A2L, requirement databases). The roles translate almost one-to-one:
| Generic role | Concrete agent in an engineering knowledge system |
|---|---|
| Planner | Decides the workflow per request: documentation generation, root-cause analysis, requirement tracing, or interface/ring analysis. |
| Tool Operator | Deterministic extractors and query services — not LLMs. They parse MDL/SLX, ARXML, and A2L files, query the signal/ring/requirement databases and the vector store, and return structured evidence only. |
| Learner | The retrieval agent: pulls supporting documents and context, and labels every fact by evidence level — DETERMINISTIC > DECLARATIVE > LLM_INFERRED. |
| Doer | The domain-reasoning agent (e.g. motor-control reasoning). It reasons only after evidence has been retrieved — never from memory alone. |
| Critic | The verifier: checks every generated requirement or conclusion against the evidence levels, flags unsupported signal references, and returns PASS / FAIL / NEEDS_REVIEW with citations. |
| Supervisor | Controls retries, escalation to humans, missing-evidence handling, and hard STOP conditions for low-confidence or unsafe outcomes. |
| Presenter | The formatting layer that writes the final deliverable — documentation blocks, system or unit requirements, or a root-cause report — using only verified facts. |
Two design rules matter most in safety-relevant domains: extraction must be deterministic (parsers, not LLM guesses, decide what signals exist in a model), and the verifier is the safety layer — every LLM-generated claim passes through it before it reaches a human or a document.
Five things to remember
- One agent, one job. Narrow responsibility, bounded context, measurable output. That's the whole trick.
- Plans and execution are different jobs. The planner makes the plan; the supervisor manages reality when the plan meets it.
- Critics must be specific. Issue, severity, evidence, recommended fix — or the feedback loop is theater.
- Match models and context to roles. Expensive reasoning models for planning and critique; need-to-know context for everyone.
- Start with four roles (Planner, Tool Operator, Critic, Presenter) and add the rest only when the system's complexity earns it.
References & further reading
- IBM Technology. Building a Team of AI Agents: Roles, Feedback, & Teamwork Explained. YouTube, ≈10 min. youtube.com/watch?v=kqj22mWIdjU The primary source for this page: the seven roles and the four levers (prompting, model selection, tuning, context).
- IBM Think. What Are AI Agents? ibm.com/think/topics/ai-agents IBM's foundational definition of agents as systems that autonomously design workflows and use tools.
- Anthropic. Building Effective Agents. anthropic.com/research/building-effective-agents Strongly aligned advice: prefer simple, composable patterns; add agentic complexity only when the task demands it.
- LangChain / LangGraph documentation. Multi-Agent Systems. langchain-ai.github.io/langgraph/concepts/multi_agent Concrete implementation patterns for supervisor and hierarchical agent teams.