Agentic AI in Production: Lessons from Building a 68-Server MCP Platform

We built and operate a production agentic AI system with 68 MCP (Model Context Protocol) servers, 46 autonomous skills, and integrations spanning email, calendar, financial analytics, code repositories, project management, and security monitoring. Here is what we learned that the demos and whitepapers do not tell you.

What Agentic AI Actually Means in Production

The industry definition of "agentic AI" has become diluted to the point of uselessness. A chatbot with a system prompt is not agentic. A RAG pipeline that retrieves documents is not agentic. An AI that generates a Slack message is not agentic.

Agentic AI means autonomous multi-step execution. The AI receives a goal, decomposes it into subtasks, selects tools to accomplish each subtask, executes them in sequence or parallel, handles errors, and delivers results -- all without human intervention at each step.

In our system, a single user request might trigger the AI to: read emails from the past week, cross-reference meeting transcripts, check project management tickets, query financial data, synthesize findings, draft a briefing document, and deliver it through Microsoft Teams. That is agentic.

Lesson 1: Tool Design Is the Architecture

The most consequential decision in agentic AI is not which LLM you use. It is how you design your tools.

MCP servers are the interface between the AI's reasoning and the real world. Every tool definition -- its name, description, parameters, and return format -- teaches the model what it can do and how to do it. Poor tool design produces unreliable agents regardless of model quality.

What we learned:

Tool names must be unambiguous. search_emails and find_emails will confuse the model. Pick one.
Parameter descriptions are instructions to the model. "The search query" is useless. "A natural language search query, e.g., 'emails from David about the Q2 report'" is actionable.
Return formats should be consistent across tools. If one tool returns {status: "success", data: [...]} and another returns {result: [...], error: null}, the model wastes reasoning capacity on format normalization.
Error messages should be actionable. "403 Forbidden" tells the model nothing. "Access denied: this tool requires the 'calendar.read' scope, which is not available in the current session" tells it exactly what happened and implies a recovery path.

Lesson 2: Reliability Is a Systems Problem, Not a Model Problem

GPT-4, Claude, and other frontier models are remarkably capable at reasoning and tool use. They are also non-deterministic, occasionally hallucinate tool parameters, and sometimes decide to skip steps in a plan for no apparent reason.

You cannot solve this with a better model. You solve it with systems engineering.

Retry with context. When a tool call fails, include the error in the next prompt. The model is remarkably good at self-correcting when given specific failure information.

Idempotent tools. Design every tool so that calling it twice with the same parameters produces the same result without side effects. The model will occasionally duplicate calls. If your tools are idempotent, this is harmless.

Circuit breakers. Set hard limits on tool invocation counts per task. Without this, a confused agent can enter loops, calling the same failing tool hundreds of times and burning tokens.

Validation layers. Before executing any tool call that has side effects (sending an email, creating a ticket, posting a message), validate the parameters against business rules. The model is not your authorization layer.

Lesson 3: Cost Management Is Continuous, Not an Afterthought

Agentic AI costs scale non-linearly with task complexity. A simple question might require 1,000 input tokens and 200 output tokens. A complex multi-step workflow might consume 50,000+ tokens across a dozen tool invocations, each of which adds context to the conversation.

What we track:

Token cost per task type (not per session -- sessions are misleading)
Tool invocation frequency (which tools are used most? which are expensive?)
Context window utilization (are we hitting limits that force summarization?)
Model selection by task (not every task needs GPT-4; many work fine with smaller models)

What we optimize:

Task routing: simple questions go to smaller, cheaper models. Complex reasoning goes to frontier models.
Context pruning: aggressively trim conversation history to include only relevant context.
Caching: tool results that do not change frequently are cached and served without re-invocation.
Batch processing: where latency tolerance allows, we batch related tool calls to reduce round trips.

Lesson 4: Multi-Session State Is the Hard Problem

A single AI session managing a single task is relatively straightforward. Multiple concurrent sessions sharing state, resources, and context is where the real engineering challenge lives.

Our system runs multiple parallel AI sessions that need to coordinate:

Shared access to MCP servers (resource contention, connection pooling)
Cross-session awareness (what is session A doing that session B should know about?)
State persistence (session state must survive restarts and be recoverable)
Conflict resolution (two sessions trying to modify the same resource)

We solved this with a relay architecture: a shared message bus where sessions post notes about their activities. Each session reads the relay at the start of every interaction to understand what has changed. It is not perfect, but it is pragmatic.

Lesson 5: Security Is Not Optional, and It Is Harder Than You Think

An agentic AI system with access to email, financial data, and project management tools is a high-value target. The attack surface includes:

Prompt injection through data: An attacker embeds malicious instructions in an email that the AI processes. The AI follows the injected instructions.
Credential scope creep: As you add MCP servers, the aggregate permissions of the AI system grow. Nobody is tracking the combined access.
Output exfiltration: The AI generates responses that include sensitive data. Those responses may be logged, cached, or transmitted through channels with different security postures.

Our mitigation: zero trust at every layer. Every MCP tool call is authenticated. Permissions are task-scoped and time-bounded. All actions are logged with full context. Anomaly detection monitors for unusual access patterns. And we run 30+ security scanning tools continuously against the platform.

Lesson 6: Start Simple, Then Extract

The biggest mistake in agentic AI architecture is starting with a distributed, microservices-based system. Start with a monolith. Prove the workflows. Understand the failure modes. Then extract services as you identify clear boundaries and scaling requirements.

We call this "progressive extraction." Build the simplest thing that could possibly work. Run it in production. Observe where it fails. Extract the components that need independent scaling or isolation. Repeat.

This approach saved us months of premature architecture. Several MCP servers we planned to build as separate services turned out to be simple enough to remain as functions in a larger service. Others that we assumed would stay simple needed extraction much sooner than expected. You cannot predict this from a whiteboard.

Where This Is Going

Agentic AI in 2026 is where cloud computing was in 2010. The core technology works. The patterns are emerging. The tooling is immature. The operations knowledge is concentrated in a small number of teams who have actually built and run these systems.

The organizations that invest in production agentic AI now -- not proofs of concept, not demos, but actual production systems -- will have a compound advantage that grows with every month of operational experience.

David Boggess is Managing Partner and CEO of Boggess Advisory Group. The ORAC platform referenced in this article is a production AI system operated by Boggess AI (BAI).