The conversation around enterprise AI agents tends to gravitate toward one extreme or the other. Either everything becomes a chatbot, or every initiative requires a multi-agent system with a dozen specialized agents collaborating in real time. The reality is more nuanced. Agentic solutions exist on a spectrum of complexity, and choosing the right point on that spectrum is one of the most important design decisions you will make.
Deterministic meets agentic: you need both
The first thing to internalize is that agentic processing does not replace deterministic processing. It augments it.
Deterministic processing — the workflows, integrations, and business rules that enterprises have built over decades — is repeatable, predictable, and auditable. It is also rigid. It cannot adapt to novel inputs, reason about ambiguous situations, or improve itself over time.
Agentic processing is the opposite. It is dynamic, adaptable, and capable of handling situations that were not explicitly programmed for. It is also expensive, probabilistic, and operating in a domain where best practices for architecture and engineering are still being established.
Production systems need both. The question is how to combine them.
There are two fundamental integration directions. An agent can call processes — using deterministic workflows as tools, invoking existing integrations and business logic to accomplish tasks reliably. Or a process can call agents — delegating specific steps in a deterministic workflow to an agent, adding intelligence at decision points within an otherwise structured pipeline.
Most enterprise agentic solutions will use both directions. The agent calls a process to retrieve customer data, then the process calls an agent to interpret that data and generate a recommendation, then the process routes the recommendation through an approval workflow. Deterministic scaffolding with agentic intelligence at the points where it matters.
Agent tools are APIs with nuance
If you come from an API or microservices background, agent tools will feel familiar. You can think of them as APIs or microservices — with some important differences.
Granularity and metadata matter more. Agent tools need to be described at a level of detail that allows an LLM to select and invoke them correctly. The tool description, parameter names, and response schemas all serve as context for the model’s decision-making. Poor metadata means poor tool selection.
New protocols are in play. MCP, A2A, and other emerging standards define how agents discover and interact with tools. These complement but do not replace existing API standards like OpenAPI.
Authorization complexity increases. When a human uses an API through a UI, the authorization model is relatively straightforward. When an agent uses a tool on behalf of a human, you need to reason about delegated authority, scope constraints, and what the agent is permitted to do versus what the human is permitted to do.
Tools themselves fall into three categories. Knowledge tools are non-destructive — they retrieve information without modifying state. Action tools are destructive — they create, update, or delete records, process transactions, send messages. Composite tools combine multiple operations into coordinated sequences. The distinction between knowledge and action tools is critical for governance: action tools require stricter controls, approval workflows, and audit trails.
Four solution patterns
Agentic solutions fall into four patterns, arranged on a spectrum from simple to complex. Each pattern adds architectural elements, capability, and enterprise value — but also complexity and operational overhead.
Simple chatbots
The simplest pattern: a standalone agent that handles conversational Q&A with human users, backed by knowledge retrieval.
The elements are minimal — a user, an agent, and knowledge tools. The agent retrieves information from a knowledge base and generates natural language responses. No state is modified, no external actions are taken.
This pattern is easy to build and easy to demonstrate, which makes it attractive for proof-of-concept work. But the enterprise value is limited. A chatbot that can only retrieve and summarize information is a search interface with better UX — useful, but not transformative.
What it provides: Natural language access to information, reduced friction for knowledge retrieval, improved user experience for common queries.
What it doesn’t provide: Ability to act on behalf of users, integration with business processes, or any form of task automation.
Worker agents
The next step on the spectrum: functional agents that use tools to actually perform tasks, not just answer questions about them.
Worker agents add action tools to the mix. They can retrieve information and modify state — processing refunds, creating tickets, updating records, sending notifications. The agent operates as a functional assistant that executes tasks on behalf of the user.
This is where most enterprise customers are mentally when they think about agents. They picture an assistant that can take action, not just provide answers. It is also where the full platform value of enterprise integration becomes relevant — the agent needs reliable, governed access to the systems it operates on.
What it provides: Task execution, reduced manual work for repetitive processes, the ability to act across multiple systems through a single conversational interface.
What it doesn’t provide: End-to-end process automation, event-driven responsiveness, or coordination across multiple agents.
Agentic workflows
This is where the deterministic-meets-agentic integration becomes explicit. Agentic workflows are deterministic processes that incorporate agents as components — combining agents, workflow orchestrators, event streams, and traditional software into business process automation.
The key distinction from worker agents is the presence of a workflow orchestrator that defines the overall process structure. The agent handles the parts that require reasoning, adaptation, or natural language interaction. The orchestrator handles sequencing, branching, error handling, and compliance. Each component does what it is best at.
This pattern requires customers to reframe how they think about agentic processing. Agents are not standalone entities here — they are participants in a larger process. But the enterprise value is high. These are the patterns that automate real business processes end-to-end, with agents providing the intelligence that makes deterministic workflows adaptable to real-world complexity.
What it provides: End-to-end process automation, event-driven responsiveness, deterministic auditability with agentic intelligence, integration with existing enterprise systems.
What it doesn’t provide: Cross-domain collaboration between multiple specialized agents, dynamic task decomposition, or emergent behavior.
Multi-agent systems
The most complex pattern: multiple specialized agents collaborating in shared conversation spaces to handle tasks that exceed the capability of any single agent.
Multi-agent systems add agent-to-agent communication to the mix. A customer service request might be handled by a customer service representative agent, a repair technician agent, and a parts specialist agent, all collaborating in a shared conversation space to resolve the customer’s issue. Each agent brings specialized tools and knowledge. The conversation space provides the coordination layer.
The enterprise value potential is the highest of any pattern, but so is the complexity. Multi-agent systems require robust coordination mechanisms, clear delegation of authority between agents, and careful design of the conversation spaces where agents interact. Debugging a multi-agent interaction — where multiple LLMs are making decisions and passing information between each other — is significantly more challenging than debugging a single agent or a deterministic workflow.
What it provides: Cross-domain expertise collaboration, dynamic task decomposition, the ability to handle complex problems that no single agent can solve alone.
What it doesn’t provide: Simplicity. Multi-agent systems are the right answer for a relatively small set of problems. They should not be the default.
Choosing your pattern
The temptation is to jump to multi-agent systems because they feel more impressive. Resist it. Start at the simplest point on the spectrum that could solve your problem, and move up only when you have evidence that simpler patterns are insufficient.
Simple chatbots are the right answer when users need better access to existing knowledge. Worker agents are the right answer when users need to execute tasks across multiple systems. Agentic workflows are the right answer when you need end-to-end process automation with intelligent decision points. Multi-agent systems are the right answer when the problem genuinely requires multiple domains of expertise collaborating dynamically.
The most valuable enterprise agentic solutions — the agentic workflows — sit in the middle of the spectrum. They combine the reliability of deterministic processing with the adaptability of agentic intelligence, and they integrate directly with the enterprise systems and processes that organizations already depend on.
Start there.