Building a Shared Operational Substrate with MCP Servers

The shift in how we build digital products isn't just about better large language models. It is about the plumbing. AI has collapsed the cost of building software, but it has not yet collapsed the cost of coordination. When you run a digital product studio as a single operator, your biggest bottleneck isn't writing code—it is the overhead of managing the agents that write the code.

I learned the hard way that duplicating service clients and operational logic across a fleet of agents is a recipe for drift. If your research agent, your deployment agent, and your finance agent all have their own bespoke ways of checking a project’s status or verifying a budget, you aren't running a studio; you are managing a chaotic group of interns. To solve this, I built VERA. Originally a set of internal scripts, VERA has evolved into the operational heart of Total Ventures. By exposing VERA as an MCP server, I have created a shared operational substrate that allows every agent in the workspace to access studio vitals through a single, unified protocol.

The Fragmentation of Agentic Engineering

In the early days of building Total Ventures, I treated every agent as a silo. I would give a coding agent access to a specific repository and a research agent access to a search tool. This worked for simple tasks, but it failed the moment I needed the agents to understand the context of the business.

If a coding agent is tasked with refactoring a module, it needs to know if that module is part of a product we are actively scaling or one we are simply maintaining. If a content agent is drafting a newsletter, it needs to know the latest shipped artifacts from the monorepo. Without a shared source of truth, I was spending more time syncing context than I was making decisions.

This is where the Model Context Protocol (MCP) changes the game. Instead of building custom integrations for every new agent, I can build one server that exposes the entire studio’s state. This is the core of agentic engineering: building the systems that allow the machine to work without constant human intervention.

VERA: The Studio’s Operational Substrate

VERA stands as the bridge between my high-level intent and the machine’s execution. It is not just a database; it is a set of capabilities. When VERA is running as one of our mcp-servers, any agent I interact with—whether it is through Claude Code or a custom orchestration layer—can call upon it to understand the studio’s health.

This architecture moves the complexity out of the agent’s prompt and into the infrastructure. You no longer have to explain to an agent how to check Stripe for a customer’s subscription status or how to look up the current runway in the P&L. You simply give the agent the tool to ask VERA.

Why MCP Servers are the New Standard for Studio Ops

The Model Context Protocol provides a standardized way for AI models to interact with external data and tools. By using mcp-servers, we move away from the fragile world of "plugins" and toward a more durable, protocol-based architecture.

For a studio owner, this means portability. If I decide to switch from one model provider to another, I don't have to rewrite my integrations. As long as the new model supports MCP, it can plug directly into VERA. This is essential for a business that is built to keep. I am not building for the current hype cycle; I am building a system that will function for the next decade.

Exposing Financials and Approvals

The most high-leverage use of VERA as an MCP server is in the realm of financials and approvals. In a traditional agency, a project manager might check a budget before authorizing a developer to spend time on a feature. In my studio, VERA handles this.

I have exposed several key tools through the VERA MCP server:

1. Financial Health Check

Agents can query the current month’s burn, revenue per product, and available cash. This allows an agent to prioritize tasks based on the actual financial impact. If a product is seeing a dip in margin, the agents can surface that data before I even open the dashboard.

2. The Approval Gate

Every high-consequence action—like a production deploy or a significant API spend—requires an escalation. VERA acts as the gatekeeper. An agent can prepare a change, but it cannot execute until VERA receives a signed approval from me. This keeps the human face of the machine in control of the final decision while the agents handle the labor.

3. Ops Health and Monitoring

VERA monitors the heartbeat of our five brands. It aggregates logs, error rates, and traffic patterns. By exposing this via MCP, I can ask a general-purpose agent, "What is the most urgent technical debt across the portfolio?" and get an answer backed by real-time data from the server.

Building the Shared Context

The real power of using mcp-servers is the compounding effect of shared context. When every agent is looking at the same operational data, the studio begins to act as a single organism.

The research agent finds a market gap. The product agent drafts a spec. The coding agent builds the MVP. All of them are checking VERA to ensure they are staying within the studio’s architectural standards and budget constraints. This is how one operator runs a fleet of agents that do the work of a full team.

We are moving toward a world where the "team" is a collection of specialized agents and the "office" is a collection of mcp-servers. The role of the founder is to architect the protocol that connects them.

The Result: A System Built to Keep

Total Ventures is designed to be a durable asset. By centralizing our operations into VERA and using standardized protocols like MCP, I am reducing the technical debt that usually kills small studios. I don't have to worry about how a new agent will learn our systems; I just give it the VERA server address.

This approach allows me to stay small while my impact grows. I can spend my mornings with my son, Jupiter, or playing music, knowing that the machine is operating within the parameters I have set. The financials are being monitored, the approvals are being queued, and the products are being kept in good health.

If you are building a multi-agent system, the question isn't which model you are using. The question is: what is the shared substrate that allows those models to understand your business?

I am curious to see how other operators are structuring their internal tools. Are you building bespoke integrations for every agent, or are you moving toward a centralized server model?