O Morgan Stanley modernizou seu programa de APIs combinando Architecture as Code com o projeto open-source CALM — Architecture as Code da FINOS (github.com), o protocolo MCP e comunicação agent-to-agent, chegando a mais de 110 APIs em produção e reduzindo o tempo de lançamento de novos serviços de seis meses para uma a duas semanas. A estratégia foi apresentada por Jim Gough, Distinguished Engineer da empresa, e Andreea Niculcea, vice-presidente, em sessão da QCon London sobre APIs para agentes.
A dupla mostrou como o banco passou de um programa tradicional de APIs para uma arquitetura de plataforma capaz de suportar agentes de IA em escala, com governança codificada, gates de deployment automatizados e atualizações de infraestrutura sem indisponibilidade.
O que é MCP e por que o morgan stanley o adotou
O Model Context Protocol é um protocolo aberto para conectar aplicações baseadas em LLMs a ferramentas e dados, segundo a definição apresentada por Jim Gough na sessão. Ele opera com um ciclo de descoberta, invocação e validação, e organiza as capacidades em tools, prompts e resources.
Anunciado em novembro de 2024, o MCP ganhou tração em 2025 quando a OpenAI começou a adotá-lo, seguida pelo GitHub, o que levou desenvolvedores a encontrá-lo no dia a dia. Gough afirmou que, embora o protocolo em si seja simples, na prática um modelo cliente-servidor de comunicação, a complexidade cresce rápido com a orquestração de agentes.
O sinal de demanda vem do negócio: usuários querem consultar em linguagem natural informações de trades, bancos de dados e outros ativos técnicos, com o agente interpretando a intenção. Por que isso muda a arquitetura de APIs? Porque o tráfego de agentes não é transacional: consultas simples viram cadeias de dezenas de chamadas de ferramentas, com retentativas e respostas grandes que elevam o custo em tokens.
# publicidade
CALM é um projeto open-source de Architecture as Code mantido pela FINOS, a comunidade open-source do setor financeiro, que permite modelar arquiteturas em JSON schema com padrões tipados, CLI, templates e um repositório central chamado CALM Hub. No Morgan Stanley, ele funciona como a camada de controle das implantações de APIs e MCP.
Como calm organiza padrões, templates e controles
O núcleo do CALM é um modelo JSON schema para representar caixas e setas, enriquecido com informações tipadas. Sobre ele, o Morgan Stanley criou três ou quatro padrões, templates de arquitetura aprovados, que sustentam as mais de 110 implantações em produção, segundo Gough.
Os padrões carregam as opiniões da plataforma: o desenvolvedor cria uma architecture a partir de um pattern e só consegue configurar o que foi permitido. Templates geram saídas como manifestos Kubernetes, Helm charts ou Terraform, enquanto bundles agrupam versões de opiniões de plataforma. O recurso mais recente, decorators, permite separar metadados da arquitetura para evitar um único JSON excessivamente grande.
Mas como isso aparece na prática? No primeiro cenário de demonstração, Andreea Niculcea implantou dois artefatos em um cluster minikube via kubectl apply: o serviço Trades API e um MCP server gerado a partir de um padrão composto que referência o serviço REST.
O Claude, como agente host, conectou ao MCP server por um conector customizado e respondeu a pedidos como "meus 10 principais trades da Vodafone", descobrindo sozinho a ferramenta GetTrades e o prefixo LSE após várias tentativas.
Info: O Morgan Stanley passou de zero para mais de 110 APIs em produção em um ano usando Architecture as Code, segundo Jim Gough. A primeira API do banco levou cerca de dois anos para chegar ao "hello world"; hoje, o ciclo caiu para uma a duas semanas.
Governança codificada: guardrails e gates de deployment
A equipe passou a modelar requisitos não funcionais, como observabilidade, performance e controles de MCP, dentro do próprio CALM. O mecanismo usa pares de control requirement e configuration: o requisito define o esperado, por exemplo uma lista de símbolos negados, e a configuração especifica como atendê-lo naquele ambiente.
No segundo cenário, a equipe aplicou um guardrail de restrição de símbolos no MCP server. O CALM gerou um ConfigMap com a lista de denied-symbols, e o código Java do servidor passou a lê-lo em runtime ao reiniciar. Quando o Claude tentou novamente consultar trades da Vodafone, o Trades Connector retornou erro informando símbolo restrito e direcionando o usuário ao time de compliance.
Guardrail em serviço é útil, mas insuficiente. Como garantir consistência entre desenvolvimento, staging e produção? A resposta do Morgan Stanley são os deployment gates: validações aplicadas em cada implantação, independentemente de ser a primeira ou a centésima.
Calm hub e validação de arquiteturas
O CALM Hub funciona como repositório versionado de padrões, arquiteturas e controles, com visualização gráfica, organização por namespaces, fluxos de negócio e vínculo de decision records. Niculcea destacou que apenas especialistas gostam de olhar JSON schema; a interface visual resolve o problema para o restante dos times.
No terceiro cenário, um deployer de arquitetura aplicou gates sequenciais. O primeiro verificou se a implantação seguia um padrão aprovado: uma arquitetura "rogue" referenciando o padrão errado foi rejeitada na hora, como aconteceria em um pipeline de PR.
O segundo gate executou calm-validate com a CLI do CALM. Na arquitetura não conforme, a validação de JSON schema apontou ausência de controles em relacionamentos (conexão MCP client para MCP server não autorizada explicitamente) e uma validação baseada em Spectral detectou placeholders não preenchidos, como a versão da imagem do Trades API. A arquitetura conforme passou nos dois gates.
Atenção: Niculcea ressaltou que permitir que cada time decida sozinho padrões de API, segurança e observabilidade gera dois problemas: aumento de carga cognitiva nos desenvolvedores e degradação da consistência arquitetural ao longo do tempo.
Gates por ambiente e revisões de segurança
Antes de ambientes de não produção, o Morgan Stanley aplica gates como smoke tests, padrões de API e checagens de entitlement. Para produção, entram revalidações de arquitetura com placeholders distintos, checagens contra a infraestrutura e revisões de segurança automatizadas, incluindo drift detection construído em colaboração com os departamentos de segurança.
A filosofia, segundo Niculcea, é que a governança não existe em torno do deployment: ela está dentro do processo de implantação, com controles codificados e reaproveitados em cada execução.
Escala, custo de tokens e mudança operacional
Agentes não se comportam como clientes REST tradicionais. Um pedido realista em ambiente empresarial, como "traga os trades de ontem e identifique os que violam minhas políticas de risco", exige acesso à ferramenta de trades, exposição de portfólio, análise de trading, políticas de risco e checagens de compliance. O que seriam poucas chamadas vira uma cadeia de dezenas de tools, com tentativas repetidas e falhas parciais.
Gough apontou que com apenas uma a cinco ferramentas a seleção é trivial; ao expandir o catálogo, surgem definições sobrepostas em linguagem natural, aumentando ambiguidade e custo, já que descrições e respostas consomem tokens. Essa pressão levou à emergência de gateways especializados e control planes para MCP.
Uma chamada de tool MCP carrega mais responsabilidade que uma requisição REST: validação de JSON schema, paginação, output shaping e gestão de workflow. A equipe concluiu que sistemas agentic só são operáveis com padrões bem definidos e controles automáticos embutidos na plataforma.
Operational rollouts e upgrades com zero downtime
O CALM Hub guarda a fonte única de arquiteturas versionadas, o que permite saber exatamente o que está implantado na plataforma a cada momento. Com essa base, o time de plataforma publica uma nova opinião, na forma de um template CALM, e redistribui as arquiteturas existentes sem depender de programas de higiene conduzidos pelas mais de cem equipes.
Niculcea lidera um exercício de upgrades de infraestrutura sem indisponibilidade nas mais de cem plataformas de API em produção. A técnica remove um cluster da rotação como configuração de rotina, reaplica todos os controles, redistribui o tráfego entre os três clusters restantes e depois reintegra o quarto. O time executa centenas de operational rollouts por mês.
No quarto cenário da demo, o time emitiu um bundle v2 com limites de recursos para pods, algo ausente no trades-mcp-server. Após regerar os manifestos com CALM template e aplicar via kubectl, o describe do Kubernetes confirmou os resource limits aplicados. Na avaliação do Mercado de TI, o ponto crítico é que a opinião da plataforma evolui sem burocracia adicional e sem exigir ação de cada time usuário.
Dica: Um dos controles mais citados pela dupla foi a microssegmentação de rede com default-deny, que isola componentes em nível de pod. Uma vez ativa, cada conectividade precisa ser permitida explicitamente, o que limita o impacto de comprometimentos e de vulnerabilidades da cadeia de suprimentos open-source.
De MCP a agent-to-agent: futuro dos protocolos
No quinto cenário, a equipe demonstrou o protocolo A2A sobre a mesma base. Um agente de trades expôs um agent card com skills, book a trade, get trade by ID, amend trades, e um script Python de rebalanceamento de portfólio observou mudanças, como NVDA saltando para 5,2% do portfólio, e agiu reservando novos trades automaticamente.
Gough diferenciou os protocolos: MCP organiza chamadas de ferramentas de forma padronizada, enquanto A2A aproxima-se de sistemas autônomos que descobrem outros agentes e colaboram por tarefas, com trocas de mensagens encadeadas. Ele comparou o modelo ao Akka, pelos paralelos conceituais, e reconheceu que, se redesenhasse a demo, organizaria as interações por tarefas em vez de expor funções atômicas da API no agent card.
APIs continuam sendo os blocos fundamentais, na visão de Gough: contratos estáveis que permanecem atrás de MCP, A2A ou do que surgir em seguida. Adaptadores mudam com rapidez; a camada de integração estável é a aposta segura. Curiosamente, o guardrail de Vodafone foi demonstrado no MCP server, mas a decisão arquitetural da empresa é mantê-lo na API, evitando reimplementação a cada novo protocolo.
Adoção acelerada e mudança cultural
Gough descreveu a IA como forçadora de adoção em estágio inicial: tecnologias que na Thoughtworks Radar estariam em fases de assess ou trial agora entram como padrão de experimentação, o que exige ciclos curtos de feedback primeiro em não produção e depois em produção. Modelos tradicionais de arquitetura, baseados em comitês de governança em salas de reunião, cedem espaço a controles embutidos no fluxo.
Perguntado sobre mudança cultural, Gough explicou que os padrões da equipe configuram elementos totalmente gerenciados pela plataforma, clusters Kubernetes, service mesh, API managers, e que desenvolvedores os usam para declarar como querem consumir a plataforma. Alguns times ainda utilizam CALM template para dar bootstrap em projetos, com scripts que chamam geradores como Spring Initializer ou Quarkus Start e entregam algo pronto para produção.
O resumo operacional apresentado na sessão inclui números diretos: patch aplicado em mais de 400 gateways em cerca de uma hora, sem downtime para consumidores; mais de 110 APIs em produção; centenas de rollouts operacionais mensais. Niculcea resumiu o propósito: uma plataforma em que os times se movem rápido, trazem feedback e operam de forma segura e consistente.
Principais pontos
- O Morgan Stanley implantou mais de 110 APIs em produção em um ano usando Architecture as Code com CALM, projeto open-source da FINOS.
- O tempo de entrega de novas APIs caiu de cerca de seis meses para uma a duas semanas, com aprovações de segurança automatizadas.
- Guardrails de MCP, como listas de símbolos negados, são modelados como controles no CALM e aplicados via ConfigMaps em runtime.
- Deployment gates rejeitam arquiteturas fora de padrões aprovados e validam placeholders e controles com cal-validate e regras Spectral.
- A equipe faz centenas de rollouts operacionais por mês e patches em mais de 400 gateways em cerca de uma hora, sem indisponibilidade.
O caso do Morgan Stanley indica que plataformas preparadas para APIs tradicionais podem absorver MCP e A2A sem redesenho profundo, desde que controles, padrões e versionsamento já estejam codificados. Para equipes de plataforma no Brasil, o recado da sessão é direto: governar agentes de IA em produção é problema de arquitetura e de deployment, não apenas de prompt.
Leia também:
Fonte: Infoq
