Presentation: APIs for Agents: Rethinking API Programs in the MCP Era

Jim Gough, Andreea Niculcea · rss · 2026-09-23 Reader 🖥️

practical · mixed — A practitioner conference talk arguing for a specific course of action (rethink your API program around Architecture-as-Code rather than around any single agent protocol), built mostly from five live demo narratives rather than abstract argument — expository framing around narrative/demonstrative evidence, with argumentative claims concentrated in the framing and summary sections.

Structure

Key terms

• MCP (Model Context Protocol) MCP (Model Context Protocol)
  An open protocol for connecting LLM-based applications to tools and data, built around a discover/invoke/validate cycle. Its distinguishing primitives beyond a plain API are tools (structured operations), prompts (reusable parameterized instructions guiding behavior), and resources (documents/data brought into agent context) — but the protocol itself is 'dumb pipes': simple client-server interaction with security/governance only 'tending towards' first-class.
• CALM Evolutionary Architecture & Fitness Functions
  FINOS's (financial open-source) 'Architecture as Code' project: a JSON-schema core model for expressing architecture as typed boxes and arrows, plus a CLI, a hosted registry/visual layer ('CALM Hub'), and AI integration (prompts/chat modes). It is the mechanism Morgan Stanley uses to make architecture, patterns, and controls machine-readable and enforceable.
• Patterns
  Reusable architecture templates that encode a platform team's opinions; a developer instantiates a pattern into a specific 'architecture' and can only configure what the pattern exposes, not deviate from it. Morgan Stanley runs 110+ production deployments off three or four patterns.
• Templates
  Handlebars-like generators that take an architecture (JSON) as input and emit deployable artifacts — Terraform, Helm charts, kube manifests, ConfigMaps.
• Decorators
  A more recent CALM construct that pulls metadata (and other 'everything you want to know about an architecture') out of the core architecture JSON so the architecture document doesn't become one unmanageable blob.
• Control requirement / configuration
  CALM's non-functional-requirements model: a 'control requirement' is an adjacent JSON schema specifying what must be true of a node or relationship (e.g., 'deny certain symbols'); a 'configuration' specifies how a specific architecture satisfies that requirement. Together they let controls be declared, attached to architecture elements, and automatically validated/enforced.
• Deployment gates
  Automated checks run at each stage of promotion (pattern-conformance/CALM Hub lookup, CALM CLI schema+spectral validation, later smoke tests, entitlement checks, security review, drift detection, synthetic monitoring) that reject non-conforming architectures with specific, PR-style feedback before/after each environment.
• Operational rollout
  Morgan Stanley's term for a platform-team-initiated, zero-downtime propagation of a new 'platform opinion' (e.g., a security patch, a resource-limit default) across all existing production deployments, driven off CALM Hub's record of what's actually deployed, without the owning teams having to act.
• A2A (Agent-to-Agent) Agent-to-Agent Protocols
  A protocol/paradigm where independent systems discover each other ('is anything capable of doing this particular task?'), then exchange messages that build on tasks — explicitly contrasted with MCP's model of one thing calling tools on another. Jim compares it informally to Akka-style actor coordination.
• Composite pattern
  A CALM pattern that references another pattern rather than duplicating it — e.g., the MCP architecture pattern references the Trades REST-service pattern as a system of its own, so the underlying API is described once and reused by every protocol adapter.

Propositions

• explicitMCP is fundamentally a simple protocol — plain client-server interaction ('dumb pipes') — and the real complexity of adopting it lives in how agents orchestrate across many tools, not in the protocol layer itself.conf: high
  extendsMCP Is Making API Sprawl Worse · p2 — Both agree MCP layers a new abstraction over APIs; this talk adds the practitioner claim that the protocol layer itself is trivial and the real cost is orchestration/abstraction management, not the protocol.
• explicitAs the number of tools exposed to an agent grows, overlapping and ambiguous natural-language tool descriptions raise disambiguation and token cost, which is what has driven the emergence of specialized gateways and control planes.conf: high
• explicitThe primary demand driving MCP adoption is business stakeholders wanting natural-language access to systems/data ('I want to talk to x'), not any specific technical merit of the protocol over existing API specifications.conf: high
• explicitGovernance and security controls for agent-facing interactions should be implemented in the API (or API gateway) layer, not in protocol-specific adapters like an MCP server, so that a single control protects every current and future protocol built on top.conf: high
  refinesAn Evolutionary Architecture Pattern for Managing AI's Pace of Change · p2 — The source article argues traditional API gateways don't fit agentic assumptions and motivates a dedicated AI gateway; this talk draws a finer boundary — protocol-orchestration concerns belong in a gateway/control-plane, but authorization/business-rule controls belong in the underlying API itself so they aren't re-implemented per adapter.
• explicitBecause architecture, patterns, and deployments are held as versioned, machine-readable data (CALM Hub as 'golden source'), a platform team can push a new 'platform opinion' across all existing production deployments as a zero-downtime 'operational rollout' without the owning teams initiating anything.conf: high
  extendsAn Evolutionary Architecture Pattern for Managing AI's Pace of Change · p8 — The source article names the emerging 'policy-as-config' pattern (guardrails/routing declared as version-controlled config, reviewed and deployed); this talk supplies a concrete production instantiation, including a documented mass-rollout mechanism the source article doesn't describe.
• explicitAutomated deployment gates (pattern-conformance lookup, CALM CLI JSON-schema + spectral validation, later smoke tests/security review/drift detection) give developers PR-style feedback before promotion and apply identically whether it's the 1st or the 100th deployment.conf: high
  supportsPresentation: Platform Engineering in the Age of AI · p3 — The roundtable predicts the outer loop (deployment, security scans, governance gates) becomes the new bottleneck as AI speeds up code generation; this talk's deployment-gates section is a concrete implementation absorbing exactly that pressure.
• explicitAgentic workloads break the transactional request/response capacity-planning model platforms were built around: a single business question can fan out into dozens of chained, retried tool calls with partial failures, and each call additionally needs schema validation, pagination, output shaping, and workflow management that a plain REST call didn't require.conf: high
• explicitcontestedTime-to-production for a new Morgan Stanley API dropped from roughly two years (the first API) to about six months, and now to one to two weeks, which Jim attributes to CALM's automated security approvals.conf: high
  contradictsMCP Is Making API Sprawl Worse · p10 — That proposition holds API governance can't easily be automated given how emergent MCP still is; this talk's account of compressing time-to-production from six months to one to two weeks via automated security approvals is a concrete counter-example within a single, controlled enterprise estate.
• explicitdevelopedMCP and A2A are different interaction paradigms, not two interchangeable transports for the same model: MCP is an agent making discrete tool calls, while A2A is autonomous peer systems discovering each other and coordinating around tasks and message exchanges.conf: high
  extendsBuilding API Products in the AI Era · p4 — That proposition argues one product should be accessible via multiple protocols with the consumer choosing; this talk both demonstrates it working (Trades API via REST/MCP/A2A) and adds the nuance that MCP and A2A are different interaction paradigms, not interchangeable transports.
  extends ←Agent Tools & Interoperability · p4 — Morgan Stanley observes MCP and A2A are different interaction paradigms (tool calls vs. agent collaboration); this whitepaper extends that into a load-bearing architectural principle — the bounded/unbounded distinction and 'GOTO problem' — for why collaborative agent work structurally cannot live in the tool-call layer.
• explicitcontestedBecause individual agent protocols (MCP today, A2A tomorrow, whatever comes after) are each uncertain to persist, APIs should remain the stable integration point an organization anchors its architecture and experimentation around.conf: high
  supportsKin Lane on AI and the Future of APIs · p11 — Independent corroboration, from an enterprise-architecture practitioner rather than a developer-tooling commentator, that APIs remain the durable anchor regardless of which agent-protocol hype cycle is current.
  contradicts ←Agent Tools & Interoperability · p1 — Morgan Stanley argues individual agent protocols (MCP today, A2A tomorrow) are each uncertain to persist and recommends keeping APIs as the stable integration point; this whitepaper instead frames the protocols themselves as the durable 'Industry Standards' worth architecting around — opposite emphases on where durability lives.
• implicitEncoding platform opinions as versioned, machine-readable architecture — rather than as documentation or discretionary policy — is what simultaneously enables both automated per-deployment gates and mass, centrally-triggered operational rollouts; both draw on the same underlying CALM data model.conf: medium
• explicitNew AI capability should be adopted at Thoughtworks-Radar 'trial/assess' maturity rather than waiting for 'adopt' maturity, because competitive and business pressure have compressed the traditional enterprise technology-adoption timeline.conf: high
• implicitEven a simple, well-scoped natural-language query against enterprise data can require several failed and retried tool calls before an agent resolves the correct identifier — reliability at the query-resolution layer is a first-order design concern, not an edge case.conf: medium
• explicitNetwork micro-segmentation (default-deny plus explicit allow) is treated as a foundational security control agent-era platforms need regardless of which protocol (MCP, A2A) sits above it.conf: high
• implicitA platform team's ability to unilaterally push a new opinion (a patch, a resource limit, a control) across 100+ teams' production deployments concentrates real operational and security authority in that team — a form of centralized power the talk frames only as a governance benefit, never examines as a risk in itself.conf: medium

Arguments

Narratives

• Scenario 1 (Hello MCP): Claude is asked for 'top 10 Vodafone trades' and fails several tool calls — trying 'VOD', 'VOD.L', 'Vodafone' — before discovering an LSE ticker prefix and succeeding.
  → Shows, without arguing it abstractly, that natural-language-to-tool resolution is unreliable and 'chatty' even in a simple, well-scoped domain — supporting the claim that MCP's real complexity lives in orchestration, not the protocol (proposition 1, 13).
• Scenario 2 (MCP Guardrails): after a denied-symbols control is added, Claude's repeated Vodafone query returns an error that the symbol is restricted and the user should contact compliance.
  → Dramatizes concrete, business-legible governance (a symbol you literally cannot query) in place of an abstract policy statement — supports proposition 4/6 and the API-vs-MCP-placement argument.
• Scenario 3 (Deployment Gates): Andreea deliberately submits a 'rogue architecture' (wrong pattern reference, missing image-version placeholder, missing relationship controls) and shows the deployer rejecting it with specific JSON-schema and spectral errors, then submits a conforming version that passes.
  → Shows deployment gates functioning as designed — direct evidence for argument 4, while also implicitly testing (without fully resolving) whether gates can be gamed.
• Scenario 4 (Platform Upgrades): a `kube describe` shows the MCP server pod has no resource limits; the platform team ships 'bundle v2'; re-running CALM template plus kubectl apply retrofits pod limits onto the already-running deployment without the owning team acting.
  → Concretely illustrates the 'operational rollout' mechanism (proposition 5, argument 2) — a small, low-stakes stand-in for the Log4Shell-class scenario described in prose just before it.
• The two-years-to-two-weeks origin story: Jim recounts the first Morgan Stanley API taking about two years to ship, later about six months, now one to two weeks with CALM's automated security approvals — plus his boss's early skepticism about betting the program on an open-source project.
  → A compressed origin narrative implicitly arguing that Architecture-as-Code's payoff is measured in cycle time and organizational risk-taking, not just governance quality (proposition 8).
• Scenario 5 (Future Proofing / A2A rebalancer): a Python script observes portfolio drift via a trades A2A 'agent card,' decides to rebalance, and books trades directly; Jim then critiques his own design choice in front of the audience ('if I was building it again this week, I'd probably design it architecturally a bit differently... have it be, this is what I've got, can you rebalance me?').
  → Shows the team learning, in public and inside their own reference implementation, that A2A's task-delegation paradigm differs from MCP's tool-call paradigm — supports proposition 9 while also functioning as an honest admission of incompleteness.

Questions addressed

• ✅ What does MCP give us above what OpenAPI specifications already gave us?
  Technically, not much — the protocol is 'dumb pipes' and OpenAPI already described what APIs can do. The actual difference is social/adoption: business stakeholders get excited about MCP specs in a way nobody gets excited about an OpenAPI spec.
• ✅ Where should governance/security controls for agent-facing interactions physically live — in the MCP server, or in the underlying API?
  In the API — demonstrated by deliberately placing the Vodafone-filtering guardrail in the MCP server first, then explaining it belongs in the API so it doesn't need re-adding for every future protocol adapter.
• ✅ How do you evolve or patch a large fleet of already-deployed services without breaking teams' owned configuration or requiring their involvement?
  Via CALM Hub's golden-source record of what's deployed plus the 'operational rollout' mechanism: a new platform opinion is expressed as an updated template and reapplied centrally through the same gates as a normal deployment.
• ⭕ How do agentic workloads change platform capacity planning and SLA modeling, which were built around request/response transactions?
  Named explicitly (new burdens: JSON-schema validation, pagination, output shaping, workflow management, retries, partial failures across chained tool calls) but no replacement capacity/SLA model is offered.
• ⭕ When should you use MCP versus A2A?
  Partially: MCP models discrete tool calls, A2A models peer task delegation/discovery. But the team's own demo shows they are still finding the boundary — Jim says he would architect the same example differently if building it again.
• ⭕ What happens when a deployment satisfies every automated gate (schema-valid, pattern-referenced) but is still architecturally wrong in a way the pattern didn't anticipate?
  Not addressed. The talk asserts later-stage 'security review' and 'drift detection' catch such cases but never shows or specifies the mechanism — an unacknowledged gap the speakers don't flag as open.

Gaps

• incompleteThe talk's only concrete security example (the denied-symbols guardrail) is a business-logic/authorization control, not a protocol-level threat. It never engages MCP-specific attack surfaces — tool-description poisoning, malicious manifest redefinition, prompt injection via tool metadata — that the corpus has already mapped in detail elsewhere.
  Read next: extract-kale-securing-mcp-production-defense-in-depth, which decomposes MCP security into four separate layers (execution, management infrastructure, outbound trust, semantic integrity) this talk never touches.
• incompleteThe claim that operational rollouts happen 'without touching the integrity of our user configurations' and scale to 400+ gateways patched within an hour is asserted with no discussion of failure modes: what happens when a platform-pushed change conflicts with a team's legitimate customization, or when the rollout itself introduces a regression simultaneously across 100+ services (the platform team's own push becoming the largest blast-radius event on the estate).
  Read next: Look for a follow-up talk or postmortem on a failed Morgan Stanley operational rollout, or compare against incident literature on centralized config-push failures (e.g., CrowdStrike-style single-push blast radius).
• incompleteNo concrete replacement capacity/SLA model is offered for agentic workloads, despite explicitly naming the problem (dozens of chained, retried tool calls with partial failures replacing simple request/latency planning).
  Read next: Read for a proposed metric or model — e.g., something analogous to request-per-second but for tool-call chains, retries, and partial-failure budgets.
• uninformedThe talk asserts deployment gates catch non-conformance but never addresses what happens when an architecture is gate-compliant yet still architecturally wrong in a way the pattern didn't anticipate — a limitation the corpus has already surfaced independently for agentic fitness functions (structural conformance checks prove an import exists or a schema parses, not that the change is architecturally sound).
  Read next: extract-agentic-fitness-functions-evolutionary-architecture, which explicitly separates deterministic structural gates from judgment-heavy architectural review.
• incompleteThe Q&A culture-change question ('how did developer/architect culture change?') is answered only anecdotally, contrasting a 'configure a managed platform' path against a 'bootstrap then implement change' path, with no data on adoption resistance, teams that pushed back against losing configuration flexibility, or failed pattern rollouts.
  Read next: A platform-adoption case study or survey data on developer sentiment toward CALM-style mandated patterns, as a check on the talk's uniformly positive framing.

Closes gaps elsewhere

• Architecture as Code to Teach Humans and Agents About Architecture · g1 — That essay names nine intersections where architecture can be expressed as code but elaborates none of them. This talk is the concrete, in-production elaboration — patterns, templates, decorators, control requirement/configuration schema, CALM Hub, and automated deployment gates — with a documented before/after (2 years to 1-2 weeks to ship a new API).
• Building API Products in the AI Era · g1 — That article asserts AI agents need redesigned APIs but gives no concrete example of one successfully redesigned for dual human/AI consumption. Morgan Stanley's Trades API — exposed simultaneously via REST, an MCP server, and an A2A adapter, all generated from the same CALM architecture and patterns, with working governance controls — is exactly this case study.
• Building API Products in the AI Era · g2 — That gap flags the multi-protocol recommendation (REST/gRPC/MCP/A2A/webhooks) as never addressing engineering cost or maintenance burden. This talk answers it concretely: CALM's composite patterns let the MCP/A2A architecture reference — not duplicate — the underlying REST service pattern, and CALM template/CALM Hub propagate changes to every protocol adapter from one place.
• Kin Lane on AI and the Future of APIs · g5 — MCP is named prominently in that interview's framing but Lane's own answers never substantively engage with MCP's tradeoffs, security model, or discovery mechanics. This talk supplies exactly that missing substance from a practitioner's production deployment: the tools/prompts/resources model, the discovery/invocation/validation cycle, the tool-disambiguation cost problem at scale, and a concrete governance example.

Related documents

• Presentation: Autonomous Data Products for the Autonomous Era: Rethinking Data Architecture for GenAI
  Agent Governance (Internal) API Products & Sprawl MCP (Model Context Protocol) Platform Engineering
• An Evolutionary Architecture Pattern for Managing AI's Pace of Change
  Agent Governance (Internal) Agent-to-Agent Protocols Evolutionary Architecture & Fitness Functions MCP (Model Context Protocol)
• AWS Releases Loom, an Open-Source Reference Platform for Governing AI Agents at Enterprise Scale
  Agent Governance (Internal) Agent-to-Agent Protocols MCP (Model Context Protocol) Platform Engineering
• Why AI agents need a Context Lake
  Agent Governance (Internal) MCP (Model Context Protocol) Platform Engineering
• Why Developer Portals Must Evolve in the AI Agent Age
  Agent Governance (Internal) API Products & Sprawl MCP (Model Context Protocol)
• Governing AI in the Cloud: A Practical Guide for Architects
  Agent Governance (Internal) Platform Engineering Policy-as-Code
• Google and Industry Partners Announce Agentic Resource Discovery Specification for AI Agents
  Agent Governance (Internal) API Products & Sprawl MCP (Model Context Protocol)
• Article: Securing MCP in Production: Defense-in-Depth Beyond the Gateway
  Agent Governance (Internal) MCP (Model Context Protocol) Platform Engineering
• MCP Is Making API Sprawl Worse
  Agent Governance (Internal) API Products & Sprawl MCP (Model Context Protocol)
• Article: Multi-Agent AI for Production Security Operations: An A2A and MCP Architecture in a 5G Core
  Agent-to-Agent Protocols MCP (Model Context Protocol) Policy-as-Code