O que é arquitetura orientada a agentes de IA para sistemas legados?

Durante anos, a modernização de sistemas legados esteve associada principalmente à migração para cloud, decomposição de monolitos, adoção de microsserviços, APIs e arquiteturas orientadas a eventos. Essas estratégias continuam relevantes. O que muda com a evolução dos agentes de IA é a possibilidade de adicionar uma nova camada à arquitetura corporativa: componentes capazes de interpretar contexto, selecionar ferramentas, tomar decisões dentro de limites definidos e executar ações sobre sistemas existentes.

É nesse cenário que surge a arquitetura orientada a agentes de IA.

Em vez de tratar a Inteligência Artificial como um chatbot isolado ou uma funcionalidade adicionada na interface, essa abordagem posiciona os agentes como participantes da arquitetura operacional da empresa. Eles passam a interagir com APIs, bancos de dados, sistemas corporativos, eventos, documentos, mecanismos de busca, serviços externos e outros agentes.

Para organizações com décadas de sistemas acumulados, o ponto central é especialmente importante: adotar agentes de IA não exige substituir todo o legado.

A estratégia pode ser evolutiva.

Sistemas existentes continuam responsáveis por transações, regras determinísticas e dados críticos. Uma nova camada agêntica é construída sobre capacidades existentes, expondo-as de maneira controlada para que agentes possam consultar informações, raciocinar sobre contexto e executar determinadas operações.

Esse conceito está alinhado ao modelo de modernização da SeedTS, que combina decomposição de legado, microsserviços, agentes e MCP Servers dentro de uma arquitetura governável e progressivamente evolutiva.

O que é uma arquitetura orientada a agentes de IA?

Uma arquitetura orientada a agentes de IA é um modelo arquitetural no qual agentes autônomos ou semiautônomos participam da execução de processos de negócio e tecnológicos, utilizando modelos de IA, contexto, memória, ferramentas e regras de governança.

Um agente corporativo pode receber um objetivo como:

“Analise as transações recentes deste cliente, verifique os sinais de risco e prepare uma recomendação para o analista.”

Para cumprir essa tarefa, o agente pode precisar:

• identificar o cliente

• consultar diferentes sistemas

• recuperar informações relevantes

• interpretar regras e políticas

• correlacionar os dados encontrados

• utilizar modelos de IA

• decidir quais ferramentas precisa utilizar

• solicitar aprovação humana quando necessário

• executar uma ação autorizada

• registrar tudo que aconteceu.

Portanto, o agente não é simplesmente uma chamada para um LLM. Ele é um componente de software inserido dentro de uma arquitetura empresarial. Essa diferença é fundamental.

Um LLM responde.

Um agente percebe contexto, seleciona ações, utiliza ferramentas e participa de um fluxo operacional.

Em ambientes corporativos, essa autonomia precisa existir dentro de controles bem definidos.

Arquitetura agêntica não significa substituir microsserviços

Um erro comum é imaginar que agentes de IA irão substituir APIs, microsserviços, bancos de dados ou sistemas tradicionais. Essa não é a função deles. Cada modelo resolve um tipo diferente de problema.

Sistemas tradicionais

São eficientes quando o comportamento pode ser previamente definido:

• realizar uma transferência

• atualizar um cadastro

• calcular uma tarifa

• emitir uma nota

• validar um campo

• consultar um saldo.

Esses processos precisam continuar determinísticos.

Microsserviços

Organizam capacidades específicas da empresa em serviços independentes. Cada serviço possui responsabilidades e contratos claros.

Agentes de IA

Entram principalmente quando existe necessidade de:

• interpretar contexto

• lidar com informação não estruturada

• combinar informações de várias fontes

• selecionar entre diferentes ferramentas

• adaptar o fluxo conforme a situação

• analisar alternativas

• apoiar decisões

• coordenar várias etapas de um processo.

O resultado é uma arquitetura híbrida.

O legado continua existindo.

A diferença está na criação de uma camada de inteligência capaz de operar sobre ele.

O que muda na arquitetura de sistemas legados?

Considere uma empresa que possui:

• ERP

• CRM

• mainframe

• banco de dados Oracle

• aplicações Java antigas

• APIs REST

• serviços SOAP

• filas

• Kafka

• data lake

• documentos corporativos.

Em uma arquitetura tradicional, integrar esses elementos normalmente exige fluxos previamente programados.

Na arquitetura agêntica, surge uma camada adicional:

O fluxo pode variar conforme o contexto.

Essa característica cria flexibilidade, mas também introduz novos desafios relacionados a:

• autorização

• segurança

• previsibilidade

• auditoria

• custos

• observabilidade

• versionamento

• testes

• governança.

Por isso, colocar um agente diretamente sobre sistemas críticos raramente é uma boa arquitetura.

É necessário criar uma infraestrutura agêntica corporativa.

A arquitetura de referência utilizada pela SeedTS considera justamente elementos como integração via MCP, Agent Registry, estratégia de permissões, ambientes separados, observabilidade, avaliações contínuas e mecanismos como feature flags e kill switches.

Os principais componentes de uma arquitetura agêntica

Uma arquitetura empresarial orientada a agentes tende a ser organizada em várias camadas.

1. Camada de experiência e canais

É onde a interação começa.

Pode ser:

• aplicação web

• aplicativo mobile

• Microsoft Teams

• Slack

• WhatsApp

• portal corporativo

• sistema interno

• API

• evento

• outro agente.

Nem todo agente precisa possuir uma interface conversacional. Muitos agentes podem operar silenciosamente reagindo a eventos de negócio.

2. Camada de agentes

Aqui ficam os agentes responsáveis por executar diferentes tipos de trabalho.

Uma organização pode possuir agentes especializados como:

Agente financeiro

Analisa indicadores, documentos, movimentações ou projeções.

Agente de atendimento

Consulta informações do cliente e auxilia na resolução de solicitações.

Agente de risco

Correlaciona eventos e informações para apoiar análises.

Agente de engenharia

Analisa código, arquitetura, documentação e observabilidade.

Agente de operações

Investiga incidentes e executa playbooks autorizados.

Agente de compliance

Avalia documentos, regras internas e políticas.

Em vez de criar um “superagente” responsável por tudo, arquiteturas corporativas tendem a se beneficiar da especialização por domínio.

Essa separação facilita:

• governança

• controle de acesso

• avaliação

• manutenção

• auditoria

• reutilização.

3. Orquestração

À medida que o número de agentes cresce, surge outro problema:

• quem coordena o trabalho?

Um processo pode exigir diversos agentes.

A orquestração determina:

• qual agente deve atuar

• quando deve atuar

• qual contexto recebe

• qual resultado deve produzir

• quando outro agente deve ser chamado

• quando uma pessoa precisa aprovar uma ação.

Essa camada evita que agentes se transformem em componentes independentes sem coordenação.

4. Tools: como agentes realmente fazem alguma coisa

LLMs não acessam automaticamente os sistemas da empresa.

Para executar trabalho real, os agentes precisam de tools. Uma tool representa uma capacidade que o agente pode utilizar.

• consultar_cliente()

• consultar_saldo()

• buscar_pedido()

• abrir_chamado()

• consultar_estoque()

• calcular_risco()

• criar_proposta()

• enviar_notificacao()

Essas ferramentas podem apontar para:

• APIs REST

• serviços SOAP

• microsserviços

• bancos

• funções serverless

• sistemas SaaS

• mecanismos de busca

• plataformas de eventos.

Essa camada é uma das peças centrais da IA integrada ao legado.

5. MCP como camada de integração

O Model Context Protocol — MCP — cria uma maneira padronizada de disponibilizar contexto e ferramentas para agentes.

Uma empresa pode criar MCP Servers associados a diferentes domínios:

O agente deixa de conhecer detalhes internos de cada sistema.

Ele conhece capacidades.

• get_customer_profile

• get_transactions

• create_incident

• check_inventory

O MCP Server pode resolver posteriormente como essa ação será executada.

Tal modelo cria uma fronteira importante entre raciocínio probabilístico e execução empresarial.

A estratégia da SeedTS para infraestrutura agêntica utiliza justamente MCP Servers conectados a APIs legadas, bancos de dados e sistemas de arquivos, criando acesso governado aos recursos corporativos.

6. MCP Contract

Disponibilizar uma ferramenta não é suficiente.

Uma empresa precisa determinar claramente:

• o que a ferramenta faz

• quais parâmetros aceita

• o que retorna

• quem pode utilizá-la

• quais dados podem ser acessados

• quais operações são proibidas

• quais ações exigem aprovação

• como erros são tratados

• quais logs precisam ser registrados.

É onde entra o conceito de MCP Contract.

O contrato cria uma fronteira formal entre o agente e o sistema empresarial.

Considere uma operação:

• transfer_money()

Um agente jamais deveria ter acesso irrestrito a ela.

O contrato pode determinar:

A autonomia passa a ser explicitamente governada.

7. Dados e contexto

Agentes precisam receber contexto suficiente para realizar uma tarefa. Esse contexto pode incluir:

• perfil do usuário

• histórico da operação

• documentos

• regras

• políticas

• resultados de APIs

• eventos

• dados analíticos

• informações de outros agentes.

Entregar contexto insuficiente prejudica o resultado. Entregar contexto demais aumenta:

• custo

• ruído

• latência

• risco de exposição de dados.

Por isso, engenharia de contexto passa a fazer parte da arquitetura.

8. Knowledge e RAG

Grande parte do conhecimento empresarial não está estruturado em APIs.

Ele pode estar em:

• SharePoint

• PDFs

• documentos

• Confluence

• manuais

• políticas

• especificações

• tickets

• bases internas.

Arquiteturas agênticas normalmente criam uma camada de conhecimento para tornar essas informações pesquisáveis.

Uma estratégia comum utiliza RAG — Retrieval-Augmented Generation.

O fluxo passa a ser: O ponto crítico para ambientes corporativos é governar a origem do conhecimento.

O agente precisa saber:

• de onde a informação veio

• qual versão foi utilizada

• quem pode acessá-la

• quando foi atualizada.

9. Memória

Contexto e memória são conceitos relacionados, mas diferentes.

Contexto representa aquilo que o agente precisa saber agora.

Memória representa aquilo que pode ser útil posteriormente.

Uma arquitetura pode possuir:

Memória de sessão

Informações válidas durante uma interação.

Memória operacional

Estado necessário para continuar um processo.

Memória de domínio

Conhecimentos persistentes relacionados a uma área da organização.

Memória histórica

Decisões ou ações anteriores relevantes.

Em ambientes corporativos, memória precisa possuir:

• política de retenção

• controle de acesso

• origem

• versionamento

• validade

• possibilidade de exclusão.

Memória sem governança pode rapidamente transformar informação antiga ou incorreta em contexto operacional.

10. Event streaming e agentes orientados a eventos

Outra evolução importante acontece quando agentes deixam de responder apenas a solicitações humanas. Eles passam a reagir a eventos do negócio.

Uma plataforma como Kafka pode transportar esses eventos. O agente consome o evento e decide se alguma ação deve ocorrer.

Exemplo:

Esse modelo cria sistemas agênticos em tempo real.

A arquitetura deixa de ser simplesmente:

• pergunta → resposta

• e passa a operar como:

• detectar → interpretar → decidir → agir → observar.

Event streaming é uma das capacidades destacadas no portfólio de arquitetura agêntica da SeedTS, especialmente para casos como fraude, risco, logística, pricing e operações.

11. Agent Registry

Se cada equipe começar a criar seus próprios agentes, rapidamente surge um problema de governança.

A empresa passa a ter dezenas ou centenas de agentes sem saber:

• quem criou

• quem mantém

• qual modelo utiliza

• quais tools acessa

• quais dados utiliza

• quais custos gera

• qual sua versão

• qual risco representa.

O Agent Registry funciona como um catálogo corporativo.

Uma entrada pode conter:

O Agent Registry transforma agentes em ativos governáveis.

12. Governança e Human-in-the-loop

Quanto maior o impacto de uma decisão, menor deveria ser a autonomia irrestrita do agente.

Uma arquitetura madura estabelece diferentes níveis.

R0 — Informativo

Agente apenas consulta e responde.

R1 — Recomendação

Agente sugere uma ação.

R2 — Ação reversível

Agente executa operações de baixo impacto.

R3 — Ação sensível

Ação exige aprovação humana.

R4 — Ação crítica

Automação autônoma pode ser proibida ou submetida a controles adicionais.

A arquitetura de referência da SeedTS utiliza exatamente uma classificação de risco R0–R4 combinada com Human-in-the-loop, Agent Specs, MCP Contracts, Evaluation Suites, runbooks e kill switches.

Esse modelo permite autonomia gradual.

13. Observabilidade para agentes

Aplicações tradicionais já são monitoradas usando métricas como:

• CPU

• memória

• erros

• latência

• disponibilidade.

Agentes exigem uma segunda categoria de observabilidade.

É necessário descobrir:

• qual modelo respondeu

• qual contexto recebeu

• quais ferramentas utilizou

• qual decisão tomou

• quanto custou

• quanto tempo levou

• se a tarefa foi concluída

• qual versão do agente estava ativa.

Essa capacidade forma a base do AgentOps.

AgentOps: tratando agentes como software de produção

Agentes não deveriam ser tratados como prompts publicados.

Eles possuem um ciclo de vida:

Esse ciclo cria uma disciplina semelhante ao DevOps e ao LLMOps.

AgentOps adiciona preocupações específicas relacionadas ao comportamento dos agentes.

Entre as métricas possíveis estão:

• task success rate

• custo por execução

• latência

• utilização de tools

• taxa de intervenção humana

• erros

• respostas inadequadas

• falhas de políticas

• volume de tokens.

A própria arquitetura de referência da SeedTS prevê instrumentação, métricas de sucesso por tarefa, controle de orçamento por agente, gates de release, logs auditáveis e monitoramento contínuo.

Evaluation Suites: como testar algo não determinístico?

Uma API tradicional pode ser testada assim:

• Input = XExpected Output = Y

Com agentes, a resposta pode variar. Por isso, testes precisam avaliar comportamento e resultado.

Uma Evaluation Suite pode verificar: Evals passam a ser parte do pipeline de software.

Antes de promover uma nova versão: Esse processo reduz o risco de atualizações de prompts, modelos ou ferramentas alterarem silenciosamente o comportamento do agente.

Como modernizar um legado para uma arquitetura agêntica?

A modernização não precisa ocorrer em um único projeto.

Uma abordagem progressiva costuma ser mais segura.

Etapa 1 — Descobrir o legado

Primeiro, é necessário compreender:

• sistemas

• domínios

• processos

• dados

• APIs

• eventos

• dependências

• gargalos.

O objetivo não é começar perguntando:

“Onde podemos colocar IA?”

A pergunta mais útil é:

“Que capacidades do negócio poderiam ganhar inteligência, autonomia ou melhor tomada de decisão?”

Etapa 2 — Identificar os primeiros agentes

As oportunidades podem ser avaliadas considerando:

• valor

• frequência

• complexidade

• risco

• disponibilidade dos dados

• integração necessária

• autonomia possível.

O resultado é um portfólio priorizado.

Essa abordagem também é utilizada no modelo de Estratégia e Portfólio de Agentes da SeedTS, que parte do mapeamento de processos e jornadas e prioriza agentes por valor, risco, dependências e possibilidade de reutilização por domínio.

Etapa 3 — Expor capacidades do legado

O próximo passo é transformar capacidades existentes em interfaces controladas.

Em alguns casos será necessário criar APIs. Em outros, APIs existentes podem ser reutilizadas. Nem todo legado precisa ser reescrito.

Etapa 4 — Criar a foundation agêntica

Antes de multiplicar agentes, a organização precisa estabelecer sua base:

• Agent Registry

• MCP Servers e MCP Contracts

• identity, policies e secrets

• observabilidade e Evaluation Suite

• knowledge, memory e AgentOps

Essa foundation reduz o risco de cada projeto construir sua própria infraestrutura.

Etapa 5 — Construir um piloto controlado

O primeiro agente deve possuir:

• problema claramente definido

• dados disponíveis

• integração viável

• risco conhecido

• métricas de sucesso.

A arquitetura de referência utilizada pela SeedTS sugere justamente iniciar com diagnóstico, arquitetura e governança antes do piloto, reduzindo o risco de transformar uma prova de conceito isolada em dívida técnica.

Etapa 6 — Operar e medir

Após o deploy, é necessário acompanhar:

• qualidade

• custo

• latência

• falhas

• taxa de sucesso

• intervenções humanas

• resultados de negócio

A comparação com um baseline permite determinar se o agente realmente gera valor.

Etapa 7 — Escalar por domínio

Quando a foundation está consolidada, novos agentes podem reutilizar:

• MCP Servers

• tools

• contratos

• memória

• políticas

• observabilidade

• pipelines

• conhecimento.

É nesse momento que a economia de escala começa a aparecer.

Em vez de construir dezenas de agentes independentes, a empresa cria um ecossistema agêntico corporativo.

Do monolito à arquitetura agêntica

Uma possível evolução arquitetural pode ser representada assim:

Essa evolução demonstra por que modernização agêntica não deveria ser interpretada como uma nova onda de reescrita completa.

Grande parte do investimento já realizado pode permanecer.

• APIs continuam importantes.

• Microsserviços continuam importantes.

• Kafka continua importante.

• Bancos continuam importantes.

• Observabilidade continua importante.

A arquitetura agêntica passa a orquestrar essas capacidades com uma camada adicional de inteligência.

Um exemplo prático

Imagine uma instituição financeira que recebe um sinal indicando comportamento potencialmente suspeito.

Em uma arquitetura tradicional:

O analista precisa abrir diferentes sistemas e reunir informações manualmente.

Em uma arquitetura agêntica:

O agente não precisa possuir autoridade para bloquear a transação.

Ele pode preparar o contexto para o responsável humano. Se posteriormente a empresa comprovar que determinadas operações apresentam risco baixo e comportamento consistente, parte do processo pode ganhar maior autonomia.

É uma evolução controlada:

Governança e observabilidade determinam até onde essa autonomia pode avançar.

O papel da arquitetura orientada a eventos

Quando combinados, agentes e event streaming criam uma arquitetura especialmente relevante para operações complexas.

O sistema passa a reagir a acontecimentos do negócio.

Esse modelo cria um loop operacional.

O novo evento pode iniciar outra parte da operação.

Agentes passam a fazer parte de uma arquitetura distribuída e orientada a eventos, em vez de permanecer limitados a interfaces de chat.

Onde entra a Fábrica Agêntica de Software?

A arquitetura define como o sistema deve funcionar. O processo de engenharia define como construir e evoluir esse sistema. Por isso, arquiteturas agênticas exigem mudanças também no desenvolvimento de software.

Na metodologia Agentic Spec-Driven Development — ASDD — da SeedTS, agentes especializados participam de etapas como escopo, discovery, especificação, arquitetura, UX, QA, DevSecOps, implementação, UAT e operação, mantendo contexto e entregáveis padronizados ao longo do ciclo.

Isso cria dois níveis diferentes de aplicação de agentes:

Agentes dentro do produto

Executam processos de negócio.

Agentes dentro da engenharia

Ajudam a construir, testar, implantar e operar o próprio software.

Em uma estratégia madura, os dois modelos coexistem.

Principais benefícios para sistemas legados

Uma arquitetura orientada a agentes pode criar diversos benefícios quando utilizada de maneira adequada.

Aproveitamento do investimento existente

O legado pode ser incorporado à arquitetura em vez de simplesmente descartado.

Automação de processos complexos

Agentes conseguem coordenar múltiplas ferramentas e fontes de informação.

Maior capacidade de integração

MCP, APIs e ferramentas criam uma camada de abstração entre agentes e sistemas.

Reutilização

Uma tool criada para um domínio pode servir diferentes agentes.

Evolução gradual

A autonomia pode começar limitada e aumentar conforme o sistema amadurece.

Rastreabilidade

AgentOps permite acompanhar decisões, ferramentas, custos e resultados.

Governança

Agent Registry, MCP Contracts, políticas, avaliações e Human-in-the-loop criam controles explícitos.

Os principais riscos

Arquitetura agêntica não elimina complexidade.

Ela introduz uma nova categoria de complexidade.

Entre os principais riscos estão:

• agentes com permissões excessivas

• ferramentas mal definidas

• decisões sem rastreabilidade

• dados sensíveis enviados ao contexto

• conhecimento desatualizado

• custos imprevisíveis

• comportamento alterado após mudança de modelo

• dependência excessiva de um único LLM

• falta de testes

• inexistência de responsáveis pelos agentes.

Por isso, uma arquitetura corporativa não deveria começar pelo modelo de IA.

Deveria começar por:

• Negócio

• Domínio

• Risco

• Arquitetura

• Integração

• Governança

• Agente

• Modelo

O modelo é uma peça do sistema — não o sistema inteiro.

Quando uma empresa está realmente pronta para escalar agentes?

Criar um agente é relativamente simples.

Criar centenas de agentes confiáveis é um problema arquitetural.

Uma organização começa a estar preparada para escala quando consegue responder perguntas como:

• Quais agentes existem?

• Quem é responsável por cada agente?

• Quais sistemas cada agente pode acessar?

• Quais ferramentas estão disponíveis?

• Quais versões estão em produção?

• Quanto cada agente custa?

• Qual sua taxa de sucesso?

• Quais dados utiliza?

• Qual nível de risco possui?

• Quais ações exigem intervenção humana?

• Como uma execução pode ser reconstruída posteriormente?

• Como o agente é desligado rapidamente se algo der errado?

Se essas respostas dependem de conhecimento informal espalhado entre equipes, a empresa ainda está criando experimentos de IA.

Quando essas respostas fazem parte da arquitetura, dos contratos e da operação, começa a existir uma plataforma corporativa de agentes.

Na SeedTS, arquitetura orientada a agentes de IA é uma camada sobre o legado — com MCP, Agent Registry, governança R0–R4 e AgentOps — para evoluir sistemas existentes sem reescrever a empresa inteira.

Arquitetura agêntica é uma evolução do legado, não sua negação

O futuro das aplicações empresariais dificilmente será exclusivamente agêntico.

Sistemas críticos continuarão utilizando:

• APIs

• microsserviços

• bancos

• filas

• event streaming

• regras determinísticas

• cloud

• mainframes

• aplicações legadas.

A mudança acontece na forma como essas capacidades são combinadas.

Agentes adicionam uma camada capaz de interpretar contexto, coordenar ferramentas e participar de decisões que anteriormente exigiam lógica extremamente rígida ou intervenção humana permanente.

Por isso, a pergunta estratégica deixa de ser:

“Como substituímos nossos sistemas por IA?”

Uma pergunta mais útil é:

“Como transformamos as capacidades que já existem em ferramentas seguras que agentes possam compreender, combinar e utilizar?”

Essa diferença muda completamente a estratégia de modernização.

O objetivo deixa de ser simplesmente migrar tecnologia e passa a ser construir uma arquitetura na qual sistemas tradicionais, APIs, eventos, dados, conhecimento e agentes operam como partes de um mesmo ecossistema.

É essa fundação que permite avançar de pilotos isolados para agentes de IA para empresas capazes de operar processos reais, com IA integrada ao legado, arquitetura agêntica, governança, observabilidade e AgentOps.

No fim, a arquitetura orientada a agentes não representa o abandono da engenharia de software tradicional.

Representa sua próxima camada.

Quer evoluir o legado com uma arquitetura agêntica governada?

A SeedTS ajuda empresas a conectar sistemas existentes a MCP Servers, Agent Registry, AgentOps e governança R0–R4 — para colocar agentes de IA no centro da operação sem descartar o investimento já feito.

Descubra como estruturar essa camada sobre o seu legado.

Fale com um especialista