Executive Summary: The Frankenstein Risk
We are standing on the precipice of the “Agentic Web,” and everyone is scrambling to build the bridge. But if we aren’t careful, we’re going to build a bridge that collapses under the weight of its own good intentions.
The current discourse around the Model Context Protocol (MCP) often drifts into a dangerous territory: the desire to make the server-side implementation (the data source) the “brain,” the “police,” and the “executioner” all at once. This is a fundamental architectural mistake.
Server-side MCP implementations—specifically Coda’s—must remain the Supply. They are the System of Record, the logic engine, the deterministic truth. They cannot, and should not, attempt to be the Orchestra.
The Orchestra—the governance, the context management, and yes, the morality (should you care much about this)—must live on the agent side (the client). We call this architecture the Agentic Bridge. It is the only way to scale Coda as the backend for the AI era without creating a bloated, token-heavy, legally paralyzed Frankenstein’s monster.
As I recently noted in a Coda Community discussion regarding morality constraints in MCP:
“If you burden Coda’s MCP server with morality clauses, you’re going to create a problem in at least 179 other countries that don’t share any given definition of your morality, and certainly not your own. So, that’s the wrong place to apply such protective rules.”
This paper articulates why separating Agentic Operations (with frameworks like mcpOS™) from MCP Servers (like Coda MCP) isn’t just a technical preference—it is an existential imperative for broad adoption and sustainability of Coda.
1. The Context Gap: Beyond the “Pack” Mentality
Let’s address the elephant in the room: The Coda Packs Agent SDK.
It is a capable, necessary evolution. It allows developers to define “tools” that LLMs can invoke. It’s good. But relying solely on server-side SDK definitions to manage agent behavior is like trying to conduct a symphony by shouting instructions from inside the cello case.
Even with the Coda Packs Agent SDK, if we treat the agent merely as a remote user of an API, we hit a ceiling.
-
The Universal Mandate: Agents don’t just live in Coda. An enterprise agent must navigate a complex topography: Coda for data, Slack for communication, GitHub for code, and Salesforce for CRM. The list is endless.
-
The “Orchestrator” Void: If your “morality” or “business logic” is locked inside the Coda Pack definition, what happens when the agent needs to cross-reference that data with a sensitive email in Gmail? The Coda Pack has no jurisdiction there. But it could (you might argue). If you think that’s a good strategy, it requires a lot more code. Last I checked, the entire tsunami of the agentic surge is to write less code and fewer API integrations.
These are two primary reasons I argue for Agent-Side Sovereignty. The intelligence—the “laws” of interaction—must reside with the agent, independent of the server it is querying. It is precisely why mcpOS™ was developed.
2. The Morality Trap: Who Polices the Ghost in the Machine?
This is where the architecture typically drives into a ditch.
In a recent Coda Community thread, a user named @Sarah_Zwier posed a very reasonable request: “ensure that the MCP is programmed morally as well.”
It sounds nice. It’s noble. As users, we commonly assume that important ideas such as morality fall to the SaaS provider’s side of the responsibility ledger. My fear is that Coda product managers will quickly implement what users are telling them. That’s their job, after all. It is the customer’s duty to communicate their needs. However, it is also technically catastrophic if implemented at the server level in Coda MCP.
The “179 Countries” Problem
If Coda, as a platform, attempts to hard-code morality into its MCP server, it immediately becomes the arbiter of truth for the entire world.
- Is gambling content “immoral”? In Utah, yes. In Nevada, just a few miles away, it’s the economy.
- Is discussion of certain political topics “unsafe”? In San Francisco, maybe. In Texas, maybe not.
The Solution: Agent-Side Governance (mcpOS)
This is why I created mcpOS. As detailed in my book Agentic Coda, mcpOS is not just a toolset; it is an extensible Constitutional Framework for agents.
Governance belongs on the Agentic Side (The Orchestra). Why?
- Context-Awareness: The agent knows who is asking. An agent working for a medical researcher should have access to sensitive anatomical data that an agent working for a kindergarten teacher should not. The server (Coda) just sees a request for data; the Agent (mcpOS) sees the intent.
- Flexibility: You can extend mcpOS with your own “Constitution.” If your enterprise forbids swearing, you add a rule to the agent. You don’t ask Coda to patch their API to ban the F-word.
- Multi-App Defense: Agents don’t just talk to Coda. They talk to Slack, Gmail, and GitHub. If you rely on Coda to be the “morality police,” who polices Slack? mcpOS sits in front of the agent, sanitizing inputs and outputs regardless of the source.
“The laws in mcpOS are designed to work with all MCP services because they apply to all interactions… It will magically defend the inputs into Coda as well as the outputs in accordance with your rules.” — Bill French
3. The Architecture of Balance: Supply vs. Orchestra
To fix the broken model and avoid the “Morality Trap,” we must bifurcate the system. That’s a lot of big words to say:
Let’s write a few Markdown documents and stick them into our agent so that we can control and guide this hallucinating LLM as we choose.
The Supply: Coda (Server-Side)
Coda is the External Brain. It is the “System of Record.” Its job is to be:
- Deterministic: When I ask for
Sales.Sum(), I don’t want an LLM to hallucinate a number. I want Coda’s formula engine to return the exact math. - Structured: It provides the schema. It says, “This is a Task, it has a Due Date.”
- Passive: It waits for a request. It does not think; it serves.
The Orchestra: mcpOS (Agent-Side)
mcpOS (and frameworks like it) is the Local Operating System. It is akin to firmware in your Apple Watch or the kernal in Mac OS. Its job is to be:
- The Sculptor: It’s not just about “endpoints.” It is about a topography of agent-side tooling designed to shape and sculpt business solutions. It adapts the raw clay of Coda’s data into the fine porcelain of enterprise workflow.
- The Guardrail: It intercepts the prompt before it leaves the user’s machine. It checks for PII, it checks for “morality” violations (defined by the user), and it checks for dangerous code execution.
- The Verifier: As I mentioned in the community post, “when you ask an AI agent to write something into a system, you should verify that the agent has indeed performed that write precisely as you intended.” mcpOS handles this “read-after-write” verification loop locally.
Visualizing the Guardrails
To understand why the “Orchestra” must be separate from the “Supply,” look at the flow of data. The agent-side OS (mcpOS) wraps the LLM, sanitizing both the intent (Input) and the action (Output).
4. Evidence: The Community Agent & The “Support Engineer”
We aren’t just theorizing here. The Coda Community is a vibrant hub where makers push the boundaries of what docs can do. Today, using the latest Community Email Digest, I put the Coda MCP to the test.
I deployed an Antigravity AI agent, equipped with direct access to Coda’s primitives via MCP, to tackle complex community questions. The results were not just “chat completions”—they were architectural consulting. The agent shifted from “Chatbot” to “Support Engineer.”
The “Impossible” Stop Button
The Challenge: A maker needed to programmatically “Force Stop” a Pack sync—a feature Coda natively does not support.
The Agentic Insight: The agent didn’t just hallucinate a fake API endpoint. It understood the system architecture.
The Resolution: It proposed an “Agentic Sync” pattern. By moving the sync logic out of Coda’s internal engine and into an MCP-connected Agent (controlled via mcpOS laws), the user gains a “Control Table” to pause/resume data fetching. It turned a platform limitation into an architectural opportunity.
Optimizing Performance: Filters vs. Relations
The Challenge: A user struggled with a complex Filter() formula across tables, hitting performance walls and blank results.
The Agentic Insight: The agent verified the syntax was correct but identified the root cause: Data Type Mismatch.
The Resolution: It taught the “Coda Way.” Instead of an O(N) Filter() operation (slow), it recommended switching to Relation Columns (O(1) lookups). It didn’t just fix the formula; it optimized the compute cost.
Security by Architecture: Hiding Columns
The Challenge: Syncing a table to another doc while keeping “Salary” columns private.
The Agentic Insight: The user was building complex manual workarounds. The Agent grounded them in primitives.
The Resolution: It clarified that Views are the security boundary for Cross-doc syncs. By syncing a specific View (with hidden columns) rather than the raw table, the data never leaves the source. Secure, maintenance-free, and architecturally sound.
Flattening Complexity: The SwitchIf() Solution
The Challenge: A D&D spell calculator with messy “If/Else” helper columns. Classic spreadsheet spaghetti.
The Agentic Insight: Recognizing the “Excel thinking” pattern.
The Resolution: It refactored the logic into a single SwitchIf() function. To ensure clarity, the Agent created a live demonstration document and implemented the solution to verify it worked locally before presenting it.
5. The Maker’s Mandate: Building with Agents
This brings us to a critical pivot point for the Coda ecosystem. The definition of a “Coda Maker” is changing. Historically, a Maker was someone skilled in formulas and layout.
Tomorrow, a Maker is an Agent Architect.
Future makers will predominantly work with and through agents to build Coda solutions. Do not confuse this with a “nice to have” novel capability; it is a mandate.
- The Contract: Developers and Makers must establish a contract where the Agent handles the high-frequency orchestration (via mcpOS or similar tooling) and Coda provides the high-integrity supply.
- The Separation: To build sustainable, deep value, Makers must rely on the clear separation of agent-side tooling and server-side MCP. If you mix them, you build brittle systems. If you separate them, you build scalable systems.
To Coda Product Managers and Leadership:
- Don’t Build the Policeman: Resist the pressure to bake “morality” into the API. It’s a trap. Build the most robust, fastest, most deterministic Supply possible.
- Empower the Topography: “Open up the endpoints” is just step one. We need a topography that supports independent agentic behavior—rich metadata, shadow contexts, and high-speed retrieval—allowing tools like mcpOS to sculpt outputs with precision and safety.
- Trust the Makers: We, the developers and makers, are building the governance layers. We are writing the Constitutions in mcpOS. Give us the raw materials, and we will build the civilization.
The symbiotic relationship is clear: Coda provides the Truth. Makers provide the Wisdom.
➤𝖒𝖆𝖝
I enjoy the speed that using agents on the desktop afford, but mostly, it’s the level of automation and competence they exhibit. I work slower now, with greater purpose and thoughtfulness in every step I make. But the output is vastly better and somewhat greater in scope.
