Not Everything Needs an Agent
The term "agentic AI" has been applied to enough things that it has started to lose meaning. A single LLM call with a structured output prompt is not an agent. A chatbot with tool use is not a multi-agent system. The word describes a specific architecture with specific tradeoffs, and those tradeoffs only make sense for a specific class of problem.
A multi-agent system is appropriate when the task involves sequential decision-making where later steps depend on earlier outputs that cannot be predicted in advance, where different subtasks require meaningfully different capabilities or contexts, and where the overall problem is too large or too variable to fit in a single prompt context.
If your problem does not have all three of those properties, you probably do not need agents. A well-designed pipeline with deterministic logic and selective LLM calls will be faster, cheaper, more reliable, and easier to debug.
The Problem Class That Justifies the Architecture
The workflows where multi-agent architectures genuinely deliver value share a common structure. There is an orchestrator that understands the goal and decomposes it into subtasks. There are specialist agents that execute those subtasks with focused context. There is a mechanism for passing results between agents and for the orchestrator to reason about whether the overall goal has been achieved.
In practice, this tends to look like:
- Research and synthesis workflows: gather information from multiple sources, evaluate it, produce a structured output, where the sources and evaluation criteria are not fully known in advance
- Multi-step qualification and routing: where each step refines the understanding of a case and the path forward is contingent on what earlier steps discovered
- Document processing pipelines: where different document types require different extraction logic and the orchestrator routes based on classification
- Autonomous task execution: where an agent must plan, attempt, evaluate results, and retry or escalate without human intervention at each step
The key is genuine task interdependency and variable execution paths. If the path is always the same, a pipeline is cleaner.
LangGraph Over LangChain for Most Production Cases
We build most agentic systems on LangGraph rather than plain LangChain. The graph-based execution model is the reason. Production agents need cycle detection, state persistence, explicit node transitions, and the ability to interrupt and resume mid-execution. LangGraph provides these primitives. LangChain chains do not.
The graph mental model also maps directly to how these systems are designed and debugged. Each node is a discrete unit with defined inputs and outputs. Edges are explicit transitions, including conditional edges that route based on state. This makes the system legible. You can read the graph and understand what the agent does, which is not true of deeply nested chain definitions.
State management is where most agentic system failures originate. An agent that loses context between steps, or that accumulates context indefinitely, or that cannot recover its state after an interruption: these are the production failure modes. LangGraph's state schema forces you to be explicit about what persists and what does not. That explicitness is a feature.
MCP Servers for Tool Integration
Model Context Protocol has become the standard we use for connecting agents to external systems. The reasons are practical. MCP defines a consistent interface for tools. The agent does not need to know whether it is calling a database, an API, or another service. New tools can be added without changing agent code. The protocol handles schema validation and error reporting in a way that the agent can reason about.
For businesses with existing internal systems, MCP servers allow agents to access those systems without requiring the systems to be rebuilt or replaced. The agent calls the tool; the MCP server handles the translation to whatever the internal system actually speaks.
This separation matters at scale. Agents change. The tools they call should not need to change every time the agent does.
What Scoped Complexity Actually Means
The phrase we use internally is "scope to actual complexity needed." It means: before choosing an agentic architecture, be specific about what problem you are solving and whether that problem actually requires the overhead of orchestration, state management, and inter-agent communication.
A document that arrives in a defined format and needs three fields extracted does not need an agent. A document intake system that handles twenty document types, classifies them, routes them to specialized extractors, validates outputs, and escalates ambiguous cases: that is a problem that justifies the architecture.
The overhead of a multi-agent system is real: more moving parts, more failure modes, harder to debug, slower iteration cycles. That overhead is worth paying when the problem genuinely demands it. When it does not, you have added complexity without value.
Getting this scoping right at the start of a project is usually the most important decision in the engagement.