As organisations move from single large language model (LLM) chatbots to full agentic systems, the discussion is shifting from “which model?” to “what kinds of agents, in what roles, orchestrated how?”
In practice, most real-world architectures are now composed of a small number of recurring agent patterns. Understanding these patterns is critical for designing reliable, scalable and governable AI systems, particularly in regulated sectors and complex operational environments.
This article outlines eight practical types of AI agents that are appearing most frequently in production designs, and how they fit together in modern architectures.
1. Hierarchical Agents
Hierarchical agents are organised in a multi-level structure, with higher-level agents handling strategy and decomposition, while lower-level agents execute concrete tasks. The hierarchy mirrors organisational structures: planners at the top, orchestrators in the middle, executors at the bottom.
Typical roles
Top-level “Planner” agent that:
- Interprets goals and constraints.
- Decomposes tasks into sub-goals.
- Allocates work to specialised sub-agents.
Mid-level “Orchestrator” agents that:
- Sequence subtasks.
- Monitor intermediate outputs and errors.
- Decide when to loop, branch or terminate.
Low-level “Executor” agents that:
- Call tools, APIs or robotic actuators.
- Perform retrieval, transformation or analysis steps.
Where this pattern is used
- Complex workflows such as end-to-end customer journeys, incident management, or document-driven processes.
- Multi-modal analysis pipelines where different data types (text, geospatial, sensor data, video) are handled by different specialist executors.
- Enterprise “AI operating system” designs where a single planning layer routes work across multiple domain agents.
The key design concern is explicit control: logging which agent made which decision, under what context, to support observability, optimisation and audit.
2. Coordinating Agents
A coordinating agent is responsible for synchronising work across multiple peer agents. Unlike hierarchical planners, coordinating agents primarily manage collaboration and state-sharing rather than performing detailed task decomposition themselves.
Typical responsibilities
- Maintain a shared task graph or state store for a group of agents.
- Route messages and artefacts between agents.
- Resolve conflicts (e.g. two agents proposing contradictory actions).
- Track progress, deadlines and service-level objectives.
Where this pattern is used
- Multi-agent RAG pipelines where one agent retrieves, another filters, another synthesises and another validates.
- Cross-domain scenarios (e.g. finance, operations, HR) where different domain agents contribute to a composite decision or report.
- Real-time collaboration environments where agents and humans co-edit plans, schedules or configurations.
From an engineering perspective, coordinating agents are typically coupled with an event bus, workflow engine, or state machine, and instrumented extensively to monitor latency, failures, and contention.
3. Distributed Agents
Distributed agents operate within a decentralised environment, often embedded close to the edge (devices, gateways, microservices) and collaborating through protocols rather than a single central controller.
Key characteristics
- Autonomy at the node: each agent can perceive local state and act without waiting for a global controller.
- Communication through messages, topics or distributed ledgers rather than direct function calls.
- Resilience to partial failure: the system continues to operate even when some agents or links are unavailable.
Where this pattern is used
- IoT and cyber-physical systems (energy grids, building management, transport fleets) where agents run on or near devices.
- Marketplaces and resource allocation systems where agents represent different participants with their own objectives.
- Federated environments where data locality, sovereignty or latency constraints prevent centralisation.
These designs raise non-trivial questions regarding consensus, conflict resolution and security boundaries, and usually require close integration with existing OT and network control layers.
4. Human-in-the-Loop Agents
Human-in-the-loop (HITL) agents operate semi-autonomously but pause at defined decision points for human confirmation, override or enrichment.
Control points typically include
- Approval of high-impact actions (e.g. financial commitments, configuration changes, public communication).
- Selection between multiple candidate plans or outputs.
- Labelling, feedback and escalation when the agent detects low confidence or novel situations.
Where this pattern is used
- Regulated decision-making (public policy enforcement, eligibility assessments, clinical or safety-related recommendations).
- Operational centres (command-and-control rooms, NOCs, traffic management centres) where operators must retain ultimate authority.
- Expert workflows (legal drafting, engineering design, risk analysis) where judgement and tacit knowledge remain critical.
Designing HITL agents is primarily a governance and UX problem: defining thresholds for intervention, making the agent’s reasoning inspectable, and ensuring that humans can efficiently correct or redirect behaviour without becoming a bottleneck.
5. Self-Learning and Adaptive Agents
Self-learning and adaptive agents modify their behaviour over time based on interactions, feedback signals and changes in the environment. The learning may range from simple rule updates to reinforcement learning or continual fine-tuning.
Sources of adaptation
- Explicit feedback (thumbs up/down, ratings, human annotations).
- Implicit signals (task success/failure, rework rates, escalation rates, SLA breaches).
- Environmental changes (new tools, updated policies, changed constraints).
Where this pattern is used
- Personalised assistants that adjust to individual preferences, domain vocabulary and working styles.
- Operational optimisation (routing, scheduling, resource allocation), where reward signals such as throughput, delay or energy usage can be measured.
- Continuous improvement loops in customer service, knowledge management and process automation.
Key architectural concerns include data provenance, drift monitoring, rollback mechanisms and safe exploration constraints to avoid degraded performance or unsafe behaviours.
6. RAG-Based Agents
Retrieval-Augmented Generation (RAG)-based agents treat external knowledge sources as first-class dependencies. They retrieve relevant documents, data or facts at run-time and ground their reasoning and responses in this context.
Core capabilities
- Dynamic retrieval from vector stores, search indices, knowledge graphs, data warehouses or APIs.
- Context construction: filtering, ranking and chunking retrieved artefacts to fit model context limits.
- Grounded generation: explicitly conditioning outputs on retrieved evidence to reduce hallucination and maintain traceability.
Where this pattern is used
- Enterprise knowledge assistants over policy documents, contracts, technical standards or operational manuals.
- Decision support where historical data, regulations or reference designs must be consulted for each query.
- Hybrid analytics, where agents combine structured queries (SQL, time-series queries) with unstructured semantic retrieval.
RAG-based agents frequently serve as building blocks within larger agents (e.g., a planning agent that uses one or more RAG agents as tools) and require tight alignment among data governance, embedding strategies, and retrieval policies.
7. Planning Agents
Planning agents focus on devising and managing multi-step plans to achieve complex objectives. They reason explicitly over sequences of actions, dependencies and constraints, rather than acting in a single step.
Typical responsibilities
- Interpreting high-level goals and constraints (time, cost, risk, compliance).
- Constructing action sequences, including conditional branches and loops.
- Selecting tools, APIs or subordinate agents required at each step.
- Monitoring execution, re-planning when steps fail or conditions change.
Where this pattern is used
- End-to-end process automation (e.g. onboarding, applications processing, incident response).
- Complex analysis tasks (multi-dataset analytics, scenario generation, what-if simulations).
- Multi-system orchestration, where the agent must coordinate across legacy applications, APIs and physical assets.
Planning agents are usually combined with workflow engines, state machines or task graphs to allow deterministic replay, monitoring and integration into existing IT operations and change management practices.
8. Context-Aware Agents
Context-aware agents adapt their behaviour based on a rich model of the current situation, including user, environment, history and system state.
Dimensions of context
- User context: identity, role, permissions, language, preferences, current task.
- Environmental context: location, time, operating conditions, demand patterns, sensor readings.
- System context: current incidents, maintenance windows, capacity constraints, policy flags.
Where this pattern is used
- Smart environments (buildings, campuses, cities) where actions depend heavily on time, occupancy, safety status and external conditions.
- Multi-tenant enterprise platforms where responses and actions must respect organisational boundaries, data access controls and jurisdictional rules.
- Adaptive UX and guidance, where the agent tailors explanations, escalation paths and recommended next actions to the user’s role and expertise.
Technically, context-aware agents require robust context modelling, feature engineering and context injection into prompts or decision policies, as well as clear isolation boundaries to avoid cross-tenant or cross-domain leakage.
Putting the Patterns Together in Real Architectures
In practice, production systems rarely deploy just one of these agent types. Instead, they combine them into layered, governable ecosystems. A representative pattern might look as follows:
- A Planning Agent at the top of a Hierarchical Agent structure, responsible for decomposing business goals into workflows.
- One or more Coordinating Agents to manage interactions between specialist agents across domains or regions.
- Multiple RAG-Based Agents providing grounded access to enterprise and operational knowledge.
- Context-Aware Agents embedded at the edge (e.g. in IoT gateways or digital twins) acting as Distributed Agents within local control loops.
- Human-in-the-Loop Agents at key decision points, with interfaces designed for oversight, override and feedback.
- Self-Learning and Adaptive Agents that iterate on policies and prompts, constrained by defined guardrails and monitored for drift.
For organisations designing AI operating models, the important question is not “which label fits a given product demo”, but rather: which of these agent patterns are necessary for a given use case, how they are composed, and how they are instrumented and governed.