How Optevo Deployed 10 Production MCP Servers in 90 Days

The challenge

Optevo is a hybrid workspace platform built around WorkPods: shared spaces that keep a team's tasks, threaded conversations, files, and notes in one context, with an AI layer that assists on top of that context rather than guessing from generic text. That premise only holds up if the AI assistant can actually reach the work it is supposed to help with: the task someone is blocked on, the thread where a decision got made, the file that thread referenced, and who is allowed to see any of it.

That is a wide, sensitive surface, and it spans several distinct internal systems. Reaching it the direct way, wiring a model straight into each system one integration at a time, creates the same failure pattern every enterprise runs into once agents graduate from a demo to production: credentials scattered across scripts and services instead of held in one place, every integration built and secured differently, no consistent record of what an agent actually touched, and no clean way to say precisely what any given agent, or any given AI model, was allowed to reach. Swap the model, or add one new capability, and the wiring behind it has to be rebuilt.

For a platform whose entire value proposition is unifying a team's context in one place, that ungoverned approach does not scale, and it works directly against the trust the product depends on.

Why MCP

The Model Context Protocol exists to solve exactly this problem: a standard, model-agnostic way to expose a defined, permissioned catalog of tools to an AI agent, instead of handing it raw API access. Rather than design a governance layer from scratch for each new integration, MCP gave the team a single contract to build against, with four properties that mattered most for a context-heavy platform like Optevo:

• One protocol — every system exposes its tools the same way, so adding a new one does not mean inventing a new integration pattern.
• Scoped permissions per tool — an agent can only call what it has been explicitly granted, matched to the permissions a person in that role would already have.
• Full audit logging — every tool call is recorded, giving compliance and security teams one place to look rather than ten.
• Model agnostic — the tool layer does not care which model is calling it, so the governance work does not have to be redone every time the model changes.

This is the same governance discipline behind pairing MCP with a workflow execution layer for enterprise systems more broadly: MCP decides what an agent may call, and a governed server carries out the work.

The architecture

Rather than one large server trying to cover everything, the architecture splits into 10 production MCP servers, each owning one domain of WorkPod context: task tools, conversation and thread tools, file and document tools, notes tools, and decision-record tools among them, alongside servers covering permissions, search, and notifications. That domain-based split gives each server a clear owner, a bounded audit scope, and a permission model that maps to one system instead of a blended, harder-to-reason-about set of access rights.

Every server exposes named, typed tools, never raw query access. An agent calls a tool such as “summarize this thread” or “find files linked to this task”; it never composes its own query against the underlying data. Each call carries the caller's identity, is checked against that caller's actual permissions before it runs, honoring the same access a person would have, and is logged. Agents connect through the MCP protocol and can only reach the tools they have been explicitly scoped for, which means adding a new AI capability means adding a reviewed tool, not opening a new door into production data.

We go deeper on this decomposition approach, and why it holds up better than a single monolith, in what an MCP server actually is. For how we build and harden this class of server, see our MCP Server Development service.

The 90-day timeline

Shipping 10 governed servers without a rollout plan is how governance projects stall. The work broke into three 30-day phases, each with a concrete deliverable rather than an open-ended sprint:

• Phase 1 (Days 1–30): audit and foundation. Map every existing integration an AI agent touched, design the tool schemas around what the agent actually needed to do rather than around the underlying APIs, and deploy the first three servers covering the highest-value, highest-risk domains.
• Phase 2 (Days 31–60): scale and migrate. Deploy four more servers and begin moving agents off direct API calls onto the governed tool layer, running both paths in parallel where it mattered so behavior could be compared before anything was cut over for good.
• Phase 3 (Days 61–90): harden and launch. Ship the final three servers, run dedicated governance testing, deliberately probing permission boundaries and audit coverage, and move the full set into production once that testing passed.

The phases were sequenced by risk, not by ease: the domains with the most sensitive data or the most consequential actions were addressed early, so nothing high-stakes was left running on ungoverned access simply because it was scheduled last.

Results

• Credential sprawl eliminated. No agent or script holds a raw API key; every call runs through a scoped tool instead.
• Deployment time for new agent capabilities dropped from weeks to days. Shipping a new capability now means adding a reviewed tool to an existing server, not building and securing a new point-to-point integration.
• A full audit trail for compliance. Every tool call is logged in one place, giving security and compliance teams a single, consistent record instead of ten different logs in ten different formats.
• Any model can use any tool without rewiring. The governed tool layer does not change when the model behind it does, so evaluating or switching models no longer means rebuilding the integration underneath.

Lessons learned

Three things mattered more than anything else in this rollout:

• Start with the highest-risk integrations first. It is tempting to build momentum on whatever is easiest to wire up. That leaves the systems with the most sensitive data running on old, ungoverned access for longest, which is exactly backwards from a risk standpoint.
• Design tool schemas for the agent, not for the API. A tool named and shaped around what the agent is trying to accomplish is safer and easier to scope than a thin wrapper around an existing endpoint. It also makes least-privilege access far easier to reason about, because the tool only does one well-defined thing.
• Governance testing is non-negotiable before production. Treat it as a release gate, not a formality: deliberately test whether permission boundaries hold, whether audit logs capture what they should, and whether a scoped agent can be tricked into reaching outside its scope, before anything ships.

Frequently asked questions