Two Roads to the Agent: Why StrataPort Is Building MCP and Native APIs in Parallel
← Content
Published
Published 01 May 2026, 00:00
Archive
Title
Body (Markdown)
:::hero variant: standard eyebrow: Technology title: "Two Roads to the Agent: Why StrataPort Is Building MCP and Native APIs in Parallel" subtitle: "Two of the most influential AI labs are betting on opposite architectures for how agents will reach business software. Anthropic is wiring everything to a structured protocol called MCP. OpenAI is teaching Codex to drive the same screens humans drive. The strata platforms that survive the next two years will refuse to pick a side." image: /assets/images/insights/two-roads-to-the-agent-hero.svg image_alt: "Two Roads to the Agent: MCP and Computer Use architectures" ::: :::text The conversation about agentic AI has moved on from _should we use it_ to _how will it actually reach our software?_ In the last six months, two of the most influential labs in the field have committed to opposing answers, and the divergence is no longer academic. Anthropic's bet is the **Model Context Protocol**, or MCP. Every application worth talking to publishes a structured server. The agent connects to that server, sees the tools and data the application has explicitly exposed, and operates within those boundaries. Clean, fast, audit-ready. The premise is that the software industry will build these servers fast enough to matter. OpenAI's bet is **computer use**. The agent drives the same graphical interface a human drives. It opens applications, clicks buttons, types into fields, reads what's on the screen. No structured integration required. The premise, in their own framing, is that _your apps don't need an API anymore_. These are not subtle differences in implementation. They are different theories about the future of business software. ::: :::text heading: What Each Camp Is Actually Betting On ::: :::data_table heading: "Two Architectures, Two Theories of the Future" variant: accent rows: - { label: "MCP", tone: go, value: "Anthropic. Model Context Protocol.", support: "Vendors publish structured servers. Agents discover capabilities, call typed tools, receive deterministic responses. Authority boundaries, audit trails, and scoping are baked into the protocol.", result: "Bull case: reliable, fast, audit-ready, if vendors cooperate. Bear case: requires years of enterprise adoption." } - { label: "COMPUTER USE", tone: caution, value: "OpenAI. Codex desktop agent.", support: "Agent drives the GUI directly: mouse, keyboard, screen pixels. No vendor cooperation required. Works with anything that has a screen, including 30-year-old council compliance portals and supplier sites that will never expose an API.", result: "Bull case: works with legacy systems today, covers the long tail. Bear case: less efficient, more brittle, fewer guarantees." } ::: :::text The MCP bet is conditional on enterprise software vendors moving fast. If they do, Claude-style agents inherit a clean, structured lane to every system that matters. Trust accounting platforms publish a trust-accounting MCP server with explicit authority boundaries. Compliance registries publish a registry MCP server. Supplier portals publish a procurement MCP server. The agent never has to guess what anything means; the protocol tells it. The computer-use bet is conditional on something more pessimistic. The bet is that enterprise vendors _won't_ move fast enough, especially in long-tail categories like government registries, regional suppliers, and three-decade-old council compliance portals. If most of the software an agent needs to touch will never expose an integration, the only path that scales is to teach the agent to use the screens themselves. ::: :::text heading: The April 2026 Inflection, and What It Actually Reveals body: | In April 2026, OpenAI shipped a major Codex update with more than 90 new plugins. Buried in the announcement was a detail that changed the strategic picture: those plugins are bundles of skills, app integrations, and **MCP servers**. OpenAI didn't abandon computer use. It added MCP as a parallel pathway. Codex, Claude Code, Cursor, Microsoft's Agent Framework, and Gemini CLI have all converged on MCP as the standard contract for structured tool access, while keeping computer-use capabilities for the long tail. The lesson is not that one bet won. The lesson is that the smart architecture supports both. ::: :::pullquote quote: "MCP is becoming the universal interface between agents and the tools they trust. Computer use is becoming the universal fallback for the tools that don't fit the protocol yet. Production architectures need both." ::: :::text heading: Why This Matters for Strata body: | Strata managers might be tempted to read this as a debate that doesn't reach them. It does, and faster than most operators expect. In our April Insight [From Chatbot to Colleague](/insights/chatbot-to-colleague.html), we pointed to the Macquarie data showing 24% of Australian strata businesses already deploying autonomous agents. Less discussed: every committee, owner, and supplier interacting with a strata firm is increasingly bringing their _own_ AI agents to the relationship. An owner asking Claude or ChatGPT to "lodge a maintenance request for unit 408," "summarise the last three years of levies for my apartment," or "find out when the next AGM is and add it to my calendar" is no longer a hypothetical interaction. It is a routine one. When that owner-side agent reaches your platform, it has two options: - **The clean lane:** a structured server (MCP) that explicitly tells the agent what it's allowed to do, with authority boundaries, audit trails, and deterministic responses. - **The fragile lane:** scraping public web pages, screenshotting, guessing field names, and submitting forms with no audit context. Every platform without a structured agent surface will be operated through the fragile lane by default, because owners and committees will not wait for vendor roadmaps to catch up with what their AI tools already do today. ::: :::text heading: StrataPort's Dual-Track Architecture body: "StrataPort has made the deliberate bet to do both, and to do them in a specific order." ::: :::data_table heading: "Three Tracks, Three Time Horizons" variant: accent rows: - { label: "TRACK 1", tone: go, value: "StrataPort MCP Server, in development", support: "A first-class MCP surface that exposes the read and action operations an agent legitimately needs (owner records, levy histories, work-order status, AGM calendars, document retrieval, compliance registers) within the same explicit authority boundaries that govern human users. Every action structured, logged, and scoped. The clean lane for the agents that arrive structured." } - { label: "TRACK 2", tone: go, value: "Native REST APIs, already live and expanding", support: "StrataPort's foundational REST APIs are in production today, powering partner integrations across the ecosystem. Banks, council registries, owner apps, supplier marketplaces, and customer-built workflow automations all live in this lane. The roadmap covers continued expansion of coverage, surface area, and partner reach. Consistent contract, versioned endpoints, predictable behaviour." } - { label: "TRACK 3", tone: go, value: "Computer-Use Compatibility, already true", support: "Because StrataPort is built on a clean web architecture with stable selectors, accessible markup, and predictable navigation patterns, computer-use agents that fall back to the GUI can still operate it. Useful for the long tail of integrations where neither MCP nor REST counterparts will ever exist." } ::: :::text The three tracks are not redundant. They serve different time horizons and different agent populations. Track 1 is the cleanest path for first-party agentic workflows the firm operates inside StrataPort. Track 2 is the substrate for the broader integration ecosystem we wrote about in [The Integration Imperative](/insights/integration-imperative.html). Track 3 is the graceful-degradation path for everything else. ::: :::text heading: Why Hedging Is the Conservative Call, Not the Aggressive One body: | It is tempting to read "build both" as expensive optionality. We read it as the lower-risk position. - **Picking only MCP** assumes vendor-side adoption catches up before owner-side agents become commonplace. In the long tail of regulators, councils, and regional suppliers, it will not. - **Picking only computer use** assumes the protocol layer never matures into the standard. It already has. Every major lab now ships MCP support. - **Picking neither** assumes the agentic shift will pause to wait. It will not. The firms whose technology partners are hedged across both pathways inherit two things: a clean, audit-ready surface for the agents that arrive structured, and graceful degradation for the agents that don't. That is the same logic that runs through everything we've written about agentic operations. The platform's job is to enforce the boundaries between deterministic and probabilistic, structured and unstructured, governed and ungoverned. Connectivity is not a feature. It is a survival posture. ::: :::text heading: The Boundaries Stay the Same body: | One thing the dual-track architecture does _not_ change: the deterministic guardrails we wrote about in [Deterministic vs Probabilistic](/insights/deterministic-vs-probabilistic.html). Trust account reconciliation, levy calculation, capital works fund movements, and AGM voting tabulation remain firmly inside the rules-based engine, whether the request arrives via MCP, REST, computer use, or a logged-in human at a keyboard. The protocol only ever determines _how the request was made_. It does not determine _what the system is allowed to do in response_. That distinction is non-negotiable. An MCP server is not a relaxation of governance. It is a more rigorous enforcement of it. Authority boundaries become explicit, audit trails become structured, and the agent's scope is documented in the protocol itself rather than implied by the UI it happened to land on. ::: :::text heading: The Bottom Line body: | The agent access question is not _MCP or computer use_. It is _do you have a deliberate posture, or are you about to be operated through whatever pathway happens to win the next news cycle?_ StrataPort's posture is straightforward: build the structured lane first, document the public lane next, stay compatible with the long-tail lane always. That is the position we believe will look obvious in 2027, and prudent in 2026. ::: :::pullquote quote: "When agents arrive, they will use the path of least resistance. The platforms that designed the path get to decide what the agents are allowed to do. The platforms that didn't get whatever the agents work out for themselves." ::: :::references items: - text: "YouTube. Your Apps Don't Need an API Anymore. Codex Just Proved It. (April 2026). Strategic analysis of OpenAI's computer-use desktop agent versus Anthropic's MCP-first approach." - text: "TechCrunch. OpenAI takes aim at Anthropic with beefed-up Codex that gives it more power over your desktop (16 April 2026). Capabilities of the new Codex desktop agent and the parallel-task execution model." - text: "Anthropic. Model Context Protocol specification and SDK documentation. Tool definitions, authority scoping, transport bindings, and the structured-server contract." - text: "Zuplo. OpenAI Codex Ships 90+ Plugins with MCP Servers Inside (April 2026). Convergence of major AI labs on MCP as the standard agent-tooling contract." - text: "OpenAI Developers. Agent Skills and Codex plugin packaging documentation. Plugin bundling of skills, app integrations, and MCP servers." :::
Change note
Preview
Save
Metadata
Slug
Meta Title
Meta Description
Anthropic is wiring everything to a structured protocol called MCP. OpenAI is teaching Codex to drive the same screens humans drive. The strata platforms that survive the next two years will refuse to pick a side.
Assigned to
Due date
Save metadata
Version History
1
v1
View
Baseline snapshot for staged publishing (B1.5)
system · 02 July 2026, 05:15