Single agent with tools
One reasoning loop, a bounded tool set, and explicit stop conditions. The right default: most enterprise use cases are retrieval plus two or three actions, and a single agent keeps failure modes readable.
Agentic orchestration
Agentic orchestration for enterprise AI
Agentic orchestration is the layer that decides which agent runs, in what order, with which tools and context, under what limits — and how the whole run is observed. I work on this as Technical Product Manager of a multi-agent platform (PaaS) that lets internal developer teams build and run AI agents inside a closed corporate perimeter. This page describes the patterns and platform pieces that matter in practice.
Orchestration patterns
Supervisor / worker graphs
A supervisor decomposes a task and routes steps to specialised workers. Implemented as an explicit state graph (LangGraph) rather than free-form chat, so every transition is inspectable and replayable.
Sequential pipelines
Deterministic stages where each step's output is validated before the next begins. Preferred when the workflow is known and only individual steps need model reasoning.
Agent-to-agent (A2A) collaboration
Agents owned by different teams expose capabilities to each other over a shared protocol instead of being merged into one monolith. Useful when domain ownership and release cycles differ.
The practical rule: escalate to a more complex pattern only when a simpler one has measurably failed. Multi-agent topologies multiply failure surfaces, and most of the perceived need for them disappears once tools and retrieval are correct.
What the platform layer has to provide
- Tool and context layer (MCP)
- Model Context Protocol standardises how agents reach internal systems — data sources, search, ticketing, internal APIs. One integration is written once and reused by every agent, and access is granted per server rather than per prompt. In a closed perimeter this is also where authorisation and audit belong.
- Orchestration runtime
- Graph-based execution with explicit state, retries, timeouts, and human-in-the-loop checkpoints. Built with Python, LangChain, and LangGraph; Langflow gives non-platform teams a visual way to compose flows on top of the same primitives.
- Retrieval and memory
- A vector store (Qdrant) for document and knowledge retrieval, with collection-level isolation so each internal tenant only reasons over its own corpus.
- Observability and evaluation
- Traces of every step, tool call, token cost, and latency via Langfuse, with Grafana and Loki for platform-level metrics and logs. Without traces, agent behaviour is not debuggable — and not improvable.
- Runtime isolation
- Kubernetes as the execution substrate: agents run as isolated workloads with resource limits, network policy, and no egress outside the approved perimeter.
Why enterprises need the orchestration layer
Reusable capability, not one-off prototypes
Teams stop rebuilding the same connectors, evaluation, and guardrails. The platform ships them once, so a new internal agent is a configuration exercise rather than a project.
Accountability by construction
Explicit graphs plus full traces mean any answer or action can be reconstructed step by step — a hard requirement in regulated and closed-perimeter environments.
Bounded risk
Permissions live at the tool and MCP-server layer, not in prompt instructions, and human checkpoints sit on the steps that write to real systems.
Cost and latency visibility
Per-step token and latency data makes it possible to argue about model choice, caching, and decomposition with numbers instead of intuition.
MCP and A2A in one paragraph
MCP (Model Context Protocol) is vertical: it standardises how one agent reaches tools, data, and context. A2A (agent-to-agent) is horizontal: it standardises how agents discover and delegate to each other. Enterprises usually need MCP first — most value comes from clean, governed access to internal systems — and A2A later, once several teams own agents that must cooperate without being merged into a single codebase.