Agentic AI Patterns

Course Content

Agentic AI Patterns

9 sections · 50 lessons

What are the core types of specialized agents commonly used in Agentic AI architectures?

The travel desk, before and after the splitOne agent, 14 tools• Mixed up flight and hotel tools• Context reached 60,000 tokens• Every request paid for the big model• One prompt carried every ruleRouter, supervisor, two workers• Each worker sees three or four tools• Worker transcripts stay out of the lead• 40 percent answered by the router• Policy critic checks before booking
Each split solved a measured problem; a memory agent was proposed too, and a plain function did its job.

What you need to know

The common roles

RoleJobTypical model
Orchestrator / supervisorOwns the goal, splits work, merges resultsStrong
PlannerTurns a goal into steps or a graphStrong or reasoning
RouterClassifies and dispatchesSmall, fast
Worker / executorOne bounded subtask, narrow toolsSmall to medium
ResearcherSearches, reads, citesMedium
Domain specialistWraps one system, like CRM or billingMedium
CoderWrites and runs code, checked by testsStrong
Critic / evaluatorScores output against a rubricMedium to strong
Memory managerExtracts facts, summarises, compactsSmall
GuardrailChecks inputs and outputs for policySmall or classifier

What a "specialised agent" really is

In code, a specialised agent is three things: a system prompt, a subset of tools, and a model setting. That is why splitting is cheap to build but not free to run. Each extra agent adds a handoff where information can be lost, extra tokens for its own context, and extra latency.

When splitting helps

  • Parallelism: four researchers read four sources at the same time.
  • Context isolation: a worker reads 50 pages and returns a 200-word summary, so the supervisor's context stays small.
  • Different permissions: the agent that reads vendor emails should not also hold the payment tool.
  • Different models: a small router saves money on easy requests.

Agents from other teams

When a specialised agent belongs to another team or company, it is called through a protocol rather than as a local function. A2A (Agent2Agent), an open protocol started by Google in 2025 and now under the Linux Foundation, lets agents advertise their skills in an "Agent Card" and exchange tasks, messages and results over HTTP. MCP connects an agent to tools; A2A connects agents to other agents.

A real-life example

A corporate travel-booking system started as one agent with 14 tools. It often mixed up flight and hotel tools, and the context grew to 60,000 tokens on complex trips.

The team split it into:

  • A router (small model) that handles "what is my booking reference?" directly, which is 40% of traffic.
  • A supervisor for real trips, which plans and delegates.
  • A flight worker and a hotel worker, each with 3 or 4 tools, running in parallel.
  • A policy critic that checks the combined itinerary against the travel policy before any booking.

Tool mistakes dropped because each worker saw only its own tools. Average tokens per trip fell by about a third because worker transcripts never entered the supervisor's context. The team did not add a separate "memory agent"; a plain function that saves traveller preferences did the job.

Follow-up questions to expect

  • "Is a critic agent always worth it?" — Only when there are clear criteria to check against. A critic with a vague rubric just adds cost and sometimes makes good answers worse.
  • "How do agents pass information?" — Through typed artefacts, like a JSON itinerary with a schema, not free chat. That makes handoffs testable.
  • "How do you decide between one agent and several?" — Start with one. Split when you see a specific problem: tool confusion, context overflow, or steps that could run in parallel.