From Chatbots to AI Agents: MCP, A2A and Multi-Agent Systems

A Chatbot Answers. An Agent Acts.

This distinction determines the value of AI in enterprises in 2026. A chatbot answers questions — “How many vacation days do I have left?” An agent executes processes. The difference is not incremental; it is fundamental.

A concrete example: An employee reports in sick. The HR agent receives the sick leave notification, checks the form for completeness, reconciles the absence period with the shift schedule, notifies the team lead, adjusts capacity planning, and documents the entire process in the personnel file. Four systems, one agent, zero manual inputs. Every step traceable, every step in the audit trail.

This is not a future scenario. This is the state of the art in 2026. And it is the reason why AI agent architecture is a strategic decision — not a task for the IT department alone.

This article describes the agent architecture for enterprise environments, explains the new MCP and A2A standards, presents five concrete business use cases with measurable savings potential, and defines the governance requirements without which no agent should go into production.

The Agent Architecture: Five Layers

An AI agent is not a monolithic system. The enterprise architecture consists of five layers, each with a clearly defined responsibility:

┌─────────────────────────────────────────┐
│           User Interface                │
│     (very-ai / Teams / Custom)          │
├─────────────────────────────────────────┤
│        Orchestration Layer              │
│    (Routing, Rule Engine, Escalation)   │
├─────────────────────────────────────────┤
│          AI Model Layer                 │
│  (Claude / GPT / Llama – per task)      │
├─────────────────────────────────────────┤
│       Tool Integration (MCP)            │
│  (ERP, CRM, DMS, Email, Calendar...)    │
├─────────────────────────────────────────┤
│      Governance & Audit Layer           │
│  (Logging, Policies, Human-in-the-Loop) │
└─────────────────────────────────────────┘

User Interface. The layer through which employees interact with the agent. This can be a dedicated AI portal (as described in Enterprise AI Portal: Four Open-Source Interfaces Compared), an integration into Microsoft Teams, or a custom interface for specific departments.

Orchestration Layer. This is where decisions are made about which agent handles a task, which model is used, and when to escalate. The orchestration layer knows the rule sets, the responsibilities, and the escalation paths. It is the control center.

AI Model Layer. The language model that performs the actual processing — understanding text, recognizing patterns, generating responses. In a model-agnostic architecture, this layer is interchangeable. A cost-efficient model for standard requests, a more powerful one for complex analyses. Routing happens automatically.

Tool Integration (MCP). The connection to your existing systems: ERP, CRM, document management, email, calendar, ticketing. Through the Model Context Protocol (MCP), agents access these systems in a standardized way.

Governance & Audit Layer. Every agent action is logged. Policies define what an agent may and may not do. Human-in-the-loop is enforced where required. This layer is not optional — it is the prerequisite for production deployment. The Decision Layer forms the architectural foundation of this governance.

MCP and A2A — the New Standards

Two protocols have changed the way AI agents communicate with the outside world and with each other in 2025/2026: MCP (Model Context Protocol) and A2A (Agent-to-Agent).

MCP: The USB Port for AI

MCP is an open standard that enables AI models to access external data sources and tools. The analogy is apt: just as USB created a universal interface for hardware, MCP creates a universal interface for AI integrations.

Before MCP, every combination of AI model and target system required a custom connector. Agent A accesses the ERP system — one connector. Agent B accesses the DMS — another connector. Agent C accesses the calendar — yet another connector. With ten systems and three models, that amounts to thirty individual integrations.

With MCP, each system defines its capabilities once in a standardized format: What data can it provide? What actions can it execute? What parameters are required? Any MCP-compatible model can use these capabilities — without system-specific code.

For enterprises, this means: New systems can be connected faster. Models can be swapped without rebuilding integrations. Dependency on individual model providers decreases.

A2A: Agents Talking to Each Other

A2A (Agent-to-Agent) is the counterpart to MCP for communication between agents. While MCP governs the connection between agent and system, A2A governs the connection between agent and agent.

Why does this matter? Because complex business processes are rarely covered by a single agent. A sick leave notification affects HR, capacity planning, payroll, and potentially project management. Each area has a specialized agent. A2A enables these agents to delegate tasks and exchange results — with defined permissions.

Critically: A2A does not mean shared data access. The HR agent passes the Finance agent the information “Employee X is absent from date Y” — not the complete personnel file. Each agent sees only what it needs for its task. Permission boundaries remain intact.

Five Business Use Cases with Measurable Savings

The question decision makers ask is not “What can an agent do?” but “What does an agent deliver?” Here are five use cases with quantifiable savings potential:

Area	Use Case	What the Agent Does	Savings Potential
HR	Onboarding	Create accounts, assign training, schedule introductions, send welcome email	4—6 hours per hire
Finance	Invoice verification	Read invoice, verify against purchase order, check account assignment, trigger approval workflow	70—80% reduction in processing time
Legal	Contract analysis	Extract clauses, compare against standard contracts, flag deviations	Hours instead of days
IT	Incident triage	Analyze error report, match against known issues, create prioritized ticket	Faster first response
Operations	Supplier monitoring	Track delivery dates, reconcile with production plan, proactive alert on delays	Early warning instead of rework

Each of these use cases follows the same pattern: the agent handles the structured, rule-based part of a process. The human handles exceptions, judgment calls, and approvals. The time savings come not from eliminating human work, but from eliminating manual routine tasks.

HR Onboarding in Detail. Today, an HR administrator manually coordinates each new hire: create IT accounts, configure access rights, assign mandatory training, prepare an onboarding plan, draft a welcome email, set up payroll. Every step a separate system, every step a manual entry. An onboarding agent orchestrates these steps automatically: it reads the employment contract, identifies position, location, and department, and executes the steps in the respective systems. The HR administrator approves the overall process — not every individual step.

Invoice Verification in Detail. An incoming invoice is read by the Document Agent. The agent extracts vendor, amount, line items, and purchase order number. It verifies automatically: Does a matching purchase order exist? Do line items and amounts match? Is the account assignment correct? Is the amount within approval thresholds? On a positive outcome, the booking is prepared. On deviations, the case is escalated to the responsible clerk — with the specific reason for the deviation, not a generic “please review” message.

Governance Requirements for Agents

An agent without governance is a liability. Four requirements must be met before production deployment:

1. Decision Layer. Every agent decision passes through the Decision Layer. For each micro-decision, it is defined: May the agent act autonomously, does a rule set apply, or must a human approve? These rules are versioned, traceable, and cannot be modified by the agent itself.

2. Human-in-the-Loop. For defined decision types, the architecture enforces human review. This is not a feature that can be activated — it is an architectural principle. The agent cannot bypass the human-in-the-loop requirement because it is technically enforced, not organizationally agreed upon.

3. Audit Trail. Every agent action generates an immutable log entry: What was the input? Which model was used? Which rule was applied? What was the outcome? When was the action executed? The audit trail is the foundation for financial audits, internal reviews, and works council (Betriebsrat) oversight.

4. Rollback. Every agent action must be reversible. If an agent generates an erroneous booking or sends an incorrect notification, the process must be correctable — technically, not just organizationally. Rollback capability is an architectural requirement, not an afterthought.

These four requirements are non-negotiable. Without them, no works council (Betriebsrat) will consent, no auditor will sign off, and no CIO will accept responsibility. More on governance architecture in the next article: Decision Layer & Shadow AI.

Multi-Agent Systems: Specialization Over Universal Agents

The next level beyond the individual agent: multiple specialized agents working together. Not one universal agent that does everything, but specialists who each master a single domain.

The sick leave example as a multi-agent system:

Sick leave notification received
              │
       Document Agent  →  Reads and classifies the sick leave notification
              │
         HR Agent      →  Checks rules: sick pay, return-to-work programs, deadlines
              │
       Workflow Agent  →  Notifies team lead, adjusts shift schedule
              │
       Finance Agent   →  Updates payroll

Each agent has its own permissions. The Document Agent can read documents but cannot create bookings. The Finance Agent can adjust payroll but cannot access personnel files. Permission boundaries are architecturally enforced — via the A2A protocol, agents communicate only the information the receiving agent needs for its task.

The Orchestrator Agent coordinates the overall flow. It knows which agent executes which step, in which sequence, and what happens when errors occur. The Orchestrator has oversight but no operational permissions. It delegates; it does not execute.

Multi-agent systems are powerful but complex. The number of interactions grows quadratically with the number of agents. Debugging becomes more involved. Governance requirements increase.

Practical Recommendation: Start Small

The temptation to begin with a multi-agent system is understandable. The recommendation is clear: start with a single agent for a clearly defined process.

Step 1: Identify a process that is structured, rule-based, and frequent enough to justify the effort. Invoice verification, onboarding, contract analysis — pick one.

Step 2: Deploy a single AI agent for that process. With a Decision Layer, with human-in-the-loop, with an audit trail. Not as a prototype, but as a production system.

Step 3: Measure. Throughput time before and after. Error rate. Cost per transaction. Satisfaction of the processing staff.

Step 4: Only when the first agent runs stably, plan the second. And only when multiple agents run stably, consider multi-agent orchestration.

This approach is not conservative. It is pragmatic. A functioning agent with proven value delivers more than an ambitious multi-agent concept stuck in the pilot phase.

The infrastructure — model hosting, vector databases, orchestration engine, API gateway — is built with the first agent and then available for every subsequent one. The investment in the first agent is simultaneously the investment in the platform.

Where these agents actually run — on which platform — is covered in Article 10: Agent Orchestration.

---

📘 Enterprise AI Infrastructure Blueprint 2026 – Article Series

← Previous	Overview	Next →
RAG & Document Intelligence: How AI Understands Your Documents	Overview	Decision Layer & Shadow AI: Control Instead of Chaos

All articles in this series: Enterprise AI Infrastructure Blueprint 2026

---

Ready to deploy the first AI agent for a concrete business process? Gosign partners with enterprise clients from process analysis to production agent — model-agnostic, with a Decision Layer and a complete audit trail.

Book a consultation — 30 minutes to identify the right first use case for your organization.