Morgan Stanley engineers used a QCon London presentation to show how the firm is rethinking its API program for an AI-driven, agentic world. In the talk, Jim Gough and Andreea Niculcea described how Architecture as Code with CALM, the Model Context Protocol (MCP), and emerging agent-to-agent communication can be combined with governance gates, deployment controls, and zero-downtime upgrades to scale enterprise AI safely.
Why APIs for agents are forcing a rethink
The central argument in APIs for Agents: Rethinking API Programs in the MCP Era is that traditional API programs are being pushed to evolve as agents become more common consumers of enterprise systems. Gough said Morgan Stanley has spent the last year “rethinking our API program in light of where the industry has gone,” pairing MCP with CALM to create a platform architecture that can move quickly without weakening control.
That matters because agentic systems do not behave like conventional request-response applications. Instead of a single, predictable call, they may invoke multiple tools, retry actions, disambiguate ambiguous prompts, and chain together workflows across several systems. In that environment, the speakers argued, APIs remain the stable foundation, but they need to be wrapped in patterns, policies, and automation that account for how agents actually operate.
What Morgan Stanley is using MCP for
MCP, short for Model Context Protocol, was described in the talk as an open protocol for connecting LLM-based applications to tools and data. Gough framed it as a client-server interaction model that supports discovery, invocation, and validation, with tools, prompts, and resources as the key pieces of the protocol.
The appeal is clear: teams can expose capabilities quickly, and in some cases even generate an MCP server from an OpenAPI spec. But that speed also creates risk. The talk emphasized that governance becomes essential because it is easy to publish a capability before considering access controls, policy, or the cost of repeated tool calls. Gough noted that the complexity lies less in the protocol itself and more in orchestration, tool selection, and scaling the surrounding control plane.
What drives the MCP hype
- Natural-language access to enterprise systems and data
- Fast exposure of tools to LLM-based applications
- Growing demand from business users who want agents to “talk to” internal systems
- Rapid adoption across the ecosystem, with OpenAI and GitHub among the examples cited in the talk
CALM as the control layer behind the platform
To keep the architecture consistent, the presenters leaned on CALM, an open-source FINOS project focused on Architecture as Code. Gough described it as more than a diagramming system, with a core model, CLI tooling, patterns, templates, and CALM Hub serving as a central place to manage architecture artifacts.
In the demo, Morgan Stanley’s API and MCP architectures were generated from patterns, while templates produced the deployment resources needed to connect services. The firm’s approach also used composite patterns, where one architecture references another, allowing the MCP layer to build on top of an existing REST service design rather than duplicating it.
Niculcea said CALM is used to represent the intended state of the system and to generate the deployments that make that state real. That includes services, ConfigMaps, and connectivity settings. The presentation also highlighted decorators, which the team uses to separate metadata and related details that would otherwise turn architecture definitions into large, hard-to-manage blocks of JSON.
Guardrails for MCP, not just demos
One of the most concrete examples in the presentation was an MCP guardrail. In the demo, the team introduced an active symbol restriction that denied certain symbols at the MCP server level. They did this by linking a control requirement to a configuration, then generating the resulting Kubernetes resources through CALM templates.
When Claude, the agent host used in the demo, was asked again for Vodafone trades, the server returned an error saying the symbol was restricted and could not be queried. The point was not the specific restriction, but the enforcement model: controls are defined in the architecture, turned into deployable artifacts, and checked at runtime.
The speakers also stressed that such controls are only part of the answer. They need to be consistently enforced across environments, which is where deployment gates come in.
Deployment gates and compliance by design
The second major thread in the talk was governance at deployment time. Gough and Niculcea argued that platforms should reduce the number of recurring decisions developers need to make, especially around standards, security, observability, and audit requirements.
In the presentation, deployment gates checked whether architectures matched approved patterns, whether required placeholders had been filled in, and whether relationship-level controls had been specified. Non-conforming examples failed early, while conforming ones passed validation. The team described this as a way to move governance out of manual review and into the deployment process itself.
That approach is designed to support self-service. Rather than blocking teams with ad hoc approvals, the platform encodes the organization’s requirements and checks them automatically. The result, according to the talk, is repeatable and auditable deployments that can scale beyond a handful of services.
Scaling platforms without downtime
The speakers also focused on platform evolution, especially the problem of rolling out new opinions or fixes across a large estate. Gough said Morgan Stanley runs hundreds of operational rollouts every month and has performed zero-downtime infrastructure upgrades across more than 100 API platforms in production.
One example in the talk involved adding new pod limits through a bundle update. After the updated bundle was applied, the MCP server showed the new resource limits in place. This was presented as a model for changing platform defaults without forcing every consuming team to redesign its service.
That same pattern becomes especially important when security or supply-chain issues emerge. The presenters said they can patch across a large number of gateways quickly, without downtime for consumers, by updating the platform opinion and redeploying architecture definitions through CALM.
Preparing for the next protocol
The final demo shifted from MCP to agent-to-agent, or A2A, communication. The speakers described A2A as more about collaboration between agents than tool invocation, with discovery and message exchange at the center of the model. Their example used an A2A interface over a trade-related workflow and a Python rebalancer script that observed portfolio changes and acted when conditions changed.
The takeaway was not that A2A replaces MCP, but that the platform needs enough structure to accommodate both. The same micro-segmented, secured Kubernetes environment could host the MCP server, the REST trade service, and the A2A layer, allowing the team to test new interaction models without rebuilding the underlying platform each time.
What the presentation says about APIs going forward
The talk repeatedly returned to one idea: APIs still matter, even as agents become a new class of consumer. Gough said APIs are the building blocks and the stable contract layer behind the changing world of tools, prompts, and agent workflows.
That framing helps explain why the session was less about a single protocol and more about operating model. Morgan Stanley’s message was that AI adoption will continue to move quickly, but the safe way to respond is to keep policy, governance, and architecture encoded in the platform rather than bolted on later.
The result is an API program that is no longer just about exposing endpoints. It is about building a governed foundation that can absorb MCP today, A2A tomorrow, and whatever comes next without losing control of production systems.
Source: Original report
Was this helpful?
Explore more: Software Development More Software Development Tech News
Last Modified: September 23, 2026 at 10:33 pm
0 views
