Essa foi a v0.1 do FullAgenticStack, nessa versão eu ainda não tinha migrado para o Everything-as-Code, no curso FullAgenticStack.dev eu ensino a versão aprimorada.
Resumo
A emergência de modelos de linguagem (LLMs) e arquiteturas baseadas em agentes introduziu uma nova camada na computação distribuída: a camada cognitiva. Este artigo propõe o conceito de Full Agentic Stack como um paradigma arquitetural para sistemas AI-first, nos quais inteligência e autonomia são distribuídas desde a concepção. Apresentamos uma estrutura conceitual em camadas de intenção, comportamento e execução, fundamentada em Event-Driven Architecture (EDA), CQRS, Event Sourcing e Saga Pattern. Discutimos propriedades formais, casos de aplicação e direcionamos para futuras investigações em governança cognitiva e auto-composição de sistemas.
Palavras-chave: Sistemas Multi-Agentes, Arquitetura Distribuída, Inteligência Artificial, Event-Driven, CQRS.
1. Introdução
Durante décadas, o termo Full Stack representou o ápice da competência técnica de um desenvolvedor: alguém capaz de transitar entre backend, frontend e banco de dados. Contudo, a explosão dos Large Language Models (LLMs) e das arquiteturas baseadas em agentes transformou radicalmente este panorama.
Integrar IA deixou de ser um diferencial para tornar-se obrigação estrutural, tão essencial quanto um banco de dados relacional. Projeções indicam que, dentro de 5 a 7 anos, sistemas sem inteligência nativa serão equivalentes a sites sem responsividade: obsoletos.
Pesquisas anteriores já exploravam arquiteturas baseadas em agentes para integração flexível de sistemas distribuídos [1]. No entanto, abordagens tradicionais, como microsserviços ou CQRS isoladamente, não resolvem problemas de complexidade cognitiva, onde interpretação de intenção, negociação entre agentes e decisão autônoma são requisitos primários.
Este artigo contribui com:
- Uma definição formal de Full Agentic Stack;
- Um modelo arquitetural em camadas de intenção, comportamento e execução;
- Exemplos práticos de coreografia cognitiva em cenários reais;
- Diretrizes para implementação e avaliação de sistemas AI-first.
2. Trabalhos Relacionados
A literatura sobre sistemas distribuídos e agentes inteligentes oferece fundamentação para esta proposta:
Multi-agent integration for distributed services. Corchado et al. [2] demonstram como agentes deliberativos coordenam serviços distribuídos, estabelecendo protocolos de comunicação e negociação.
Layered architectures for multi-agent real-time systems. Jamali et al. [3] apresentam uma arquitetura de três camadas para coordenação de recursos distribuídos, com ênfase em tempo real e escalabilidade.
Arquiteturas de agentes interoperáveis em domínios específicos. Garcia et al. [4] ilustram aplicações em Smart Grids, enquanto Alruwaili [5] explora a interseção entre IA e sistemas distribuídos baseados em ledger.
Agent-based management of support systems. Kaeri et al. [6] investigam como agentes podem gerenciar sistemas de apoio a processos colaborativos distribuídos.
A contribuição deste trabalho situa-se na integração de LLMs com arquiteturas orientadas a eventos, produzindo um modelo onde a camada cognitiva não é plugável, mas nativa e estrutural.
3. Fundamentação Teórica
3.1 Agentes Inteligentes
Um agente inteligente é definido como um entidade de software com autonomia, reatividade e objetivos próprios, capaz de perceber seu ambiente e agir sobre ele [7]. Em sistemas distribuídos, agentes adicionam a capacidade de decisão descentralizada.
3.2 Sistemas Multi-Agentes (MAS)
Um Multi-Agent System (MAS) é um conjunto de agentes que interagem para resolver problemas além da capacidade individual de cada um [8]. A coordenação pode ser:
- Orquestrada: um agente central coordena os demais;
- Coreografada: agentes negociam entre si sem controle central.
3.3 Representação de Conhecimento e Raciocínio
Knowledge Representation and Reasoning (KR) estuda formalismos lógicos e ontologias que estruturam o raciocínio automatizado [9]. Em Full Agentic Stack, LLMs atuam como mecanismos de KR, traduzindo linguagem natural em intenções estruturadas.
3.4 Observabilidade e Governança
Sistemas agentic exigem invariantes de comportamento e métricas de auditoria:
- Rastreabilidade de decisões: cada ação deve ser vinculada a um evento e contexto;
- Explicabilidade: o sistema deve justificar decisões em linguagem natural;
- Limites de autonomia: agentes operam dentro de restrições definidas (guardrails).
3.5 Segurança e Guardrails
A execução de ações por agentes baseados em linguagem natural introduz vulnerabilidades severas:
Prompt Injection e Execução Não Autorizada. Agentes que interpretam comandos em linguagem natural estão sujeitos a ataques de injeção de prompt, onde entradas maliciosas podem desviar o comportamento esperado. Mitigações incluem validação de schema rigorosa antes da execução e sanitização de entradas em múltiplas camadas.
Human-in-the-Loop para Ações Críticas. Operações irreversíveis (ex.: exclusão de dados, transferências financeiras) devem exigir confirmação humana ou quórum de agentes, nunca sendo executadas automaticamente a partir de interpretação de LLM.
Orquestração vs. Coreografia. A distinção é crucial para segurança e acoplamento:
- Orquestração: recomendada para fluxos críticos de negócio onde sequência e validação são essenciais;
- Coreografia: adequada para eventos assíncronos de baixo acoplamento, onde agentes reagem independentemente.
3.6 Custos e Otimização de Performance
Arquiteturas baseadas em LLMs e múltiplos agentes introduzem desafios de latência e custo:
| Desafio | Estratégia de Otimização |
|---|---|
| Latência de LLM | Usar modelos menores para tarefas simples (ex.: classificação de intenção) |
| Custo de Token | Cache de embeddings e respostas frequentes |
| Fallback | Mecanismos determinísticos quando LLM produz saídas ambíguas |
| Batch Processing | Agrupar múltiplas intenções em uma única chamada |
Projeções de custo devem considerar não apenas inferência, mas também armazenamento vetorial, filas de eventos e monitoramento contínuo.
4. Segurança Zero Trust Passwordless para Agentes Autônomos
4.1 O Fim da Era das Senhas
A dependência de credenciais estáticas tornou-se um risco estrutural e um passivo operacional insustentável. No cenário contemporâneo de ameaças, a senha não é apenas uma ferramenta obsoleta; ela é o elo mais fraco da infraestrutura digital. Dados do mercado indicam que identidades comprometidas são a causa raiz de quase 50% das brechas de segurança globais [10].
O modelo tradicional de "castelo e fosso" faliu, pois atacantes não precisam mais "invadir" perímetros; eles simplesmente "entram" utilizando credenciais legítimas obtidas via phishing ou ataques de Adversary-in-the-Middle (AiTM).
Neste contexto, a arquitetura Zero Trust surge como a espinha dorsal da resiliência corporativa. Operando sob o axioma "nunca confiar, sempre verificar", ela exige que a confiança nunca seja implícita, independentemente da localização do usuário. A transição para o modelo Passwordless (sem senha) é o componente vital que materializa essa filosofia, substituindo a vulnerabilidade do segredo compartilhado por credenciais criptográficas robustas.
"A confiança implícita em ativos baseada em sua localização física ou de rede deve ser eliminada." (NIST 800-207) [11]
4.2 ROI e Eficiência Operacional
A adoção do Zero Trust Passwordless é uma decisão financeira estratégica. O mercado global de Zero Trust, avaliado em USD 29,14 bilhões em 2024, projeta atingir USD 113,6 bilhões até 2033, com um CAGR de aproximadamente 17% [12].
O retorno sobre o investimento (ROI) é sustentado pela drástica redução de custos operacionais:
| Métrica | Impacto |
|---|---|
| Chamados de Help Desk | 20%-50% dos chamados são redefinições de senha (~US$ 70/ocorrência) |
| Microsoft | 87% de redução em custos operacionais de autenticação (180K funcionários) |
| Accenture | Queda drástica em incidentes de suporte (790K colaboradores) |
No setor de saúde, a eficiência traduz-se em vidas salvas: o acesso instantâneo a prontuários via biometria elimina a fricção de teclados em emergências.
4.3 Privacidade por Design: FIDO2/WebAuthn
A superioridade do modelo Passwordless repousa no padrão FIDO2/WebAuthn e na criptografia assimétrica. Ao contrário das senhas, onde o segredo é compartilhado entre usuário e servidor, aqui ocorre a substituição do segredo compartilhado por um par de chaves:
- Chave privada: permanece isolada em hardware seguro (TPM ou Secure Enclave);
- Chave pública: registrada no servidor.
O dado biométrico nunca sai do dispositivo. O servidor apenas valida uma assinatura criptográfica. Economicamente, essa revolução é viabilizada pela queda no custo de sensores biométricos, hoje abaixo de US$ 2 por módulo [13].
Para o jurídico, o benefício é a conformidade simplificada com a LGPD e o GDPR. Como a empresa minimiza a coleta de dados sensíveis brutos e não armazena bases de dados biométricos centralizadas, o passivo regulatório é mitigado.
4.4 Lições de Guerra: O Caso Cloudflare (2022)
A eficácia prática do FIDO2 foi provada no ataque sofrido pela Cloudflare em 2022 [14]. Atacantes executaram uma campanha de Real-time relay (AiTM), capturando credenciais de funcionários em tempo real via páginas clonadas. No entanto, o ataque foi interrompido porque o sistema exigia chaves físicas.
Diferente do MFA tradicional (SMS ou OTP), que pode ser interceptado, o Passwordless baseado em FIDO2 é domain-bound. O hardware se recusa a assinar um desafio vindo de uma URL fraudulenta.
"O valor de um sistema resistente a phishing é interromper cadeias de ataque onde o adversário não invade, ele simplesmente entra."
4.5 O Paradoxo da Recuperação
A eliminação da senha transfere o risco para a posse do dispositivo. O estrategista deve atentar para a diferença entre:
| Tipo | Vantagem | Risco |
|---|---|---|
| Syncable Authenticators (Passkeys) | Conveniência, sincronização em nuvem | Vulnerabilidade do Sync Fabric |
| Device-bound (Hardware) | Máxima segurança, isolado fisicamente | Perda = perda de acesso |
Para mitigar o risco de perda de acesso, as organizações devem adotar:
- Redundância de Chaves: ao menos dois autenticadores por usuário;
- Social Recovery: recuperação delegada via contatos de confiança;
- Identidade Verificada (eKYC): documentos oficiais e reconhecimento facial para reatribuição de posse.
4.6 Arquitetura Zero-Trust para Agentes Autônomos
Para comunicação segura entre agentes autônomos, propomos uma defesa em profundidade tri-camada:
┌─────────────────────────────────────────────────────────┐
│ AGENTIC NETWORK FORTRESS │
├─────────────────────────────────────────────────────────┤
│ Camada 3: DPoP (RFC 9449) + Session Binding │
│ Camada 2: Signal Protocol E2EE (Double Ratchet) │
│ Camada 1: mTLS 1.3 │
└─────────────────────────────────────────────────────────┘
Camada 1: mTLS 1.3 (Transporte)
- Autenticação mútua entre agentes;
- Canal seguro, anti-MITM;
- Nota: mTLS é parte integrante do OAuth 2.1 para segurança de transporte.
Camada 2: Signal Protocol E2EE (Aplicação)
- X3DH Key Agreement;
- Double Ratchet Algorithm;
- Perfect Forward Secrecy (PFS);
- Post-Compromise Security (PCS);
- Deniable Authentication.
Camada 3: DPoP + Session Binding (Contexto)
- Proof-of-Possession criptográfico (RFC 9449);
- Bearer token binding (ath claim);
- Session Context Latching com JWK Thumbprint (RFC 7638);
- Nonce-based replay protection;
- HTTP method/URL constraining.
4.7 Implementação de Referência
import {
SignalE2EEAgent,
TokenAuthority,
createDPoPProof,
computeJWKThumbprint
} from '@purecore-codes/agent-zero-trust';
// 1. Criar autoridade de tokens
const authority = new TokenAuthority();
// 2. Criar agentes com identidades criptográficas
const alice = new SignalE2EEAgent('alice', authority, ['reasoning']);
const bob = new SignalE2EEAgent('bob', authority, ['analysis']);
await alice.initialize();
await bob.initialize();
// 3. Trocar bundles de chaves públicas
const aliceBundle = alice.getPublicKeyBundle();
const bobBundle = bob.getPublicKeyBundle();
alice.registerPeerBundle('bob', bobBundle);
bob.registerPeerBundle('alice', aliceBundle);
// 4. Estabelecer sessão E2EE
await alice.establishSession('bob');
await bob.acceptSession(
'alice',
alice.getIdentityPublicKey(),
aliceBundle.signedPreKey
);
// 5. Enviar mensagem encriptada com DPoP binding
const encryptedMessage = await alice.sendMessage(
'bob',
'Olá Bob! Esta mensagem é E2EE com Signal Protocol.'
);
4.8 Métricas de Performance
| Métrica | Valor |
|---|---|
| Latência P50 (E2EE) | ~5.8ms |
| Latência P99 (E2EE) | ~18.7ms |
| Throughput | ~28K msg/s |
| CPU Overhead | +35% vs TLS |
| Memória Overhead | +22% vs TLS |
Benchmarks realizados em AWS EC2 c6i.xlarge com 100 agentes concorrentes [15].
5. Modelo Arquitetural Proposto
5.1 Definição
Full Agentic Stack é um ecossistema completo de software composto por camadas cognitivas, autônomas e reativas que operam de forma coreografada para interpretar, decidir e agir sobre eventos em tempo real.
5.2 Visão em Camadas
A arquitetura é dividida em três camadas de responsabilidade:
| Camada | Função | Exemplo Técnico |
|---|---|---|
| Intenção | Interpretar linguagem natural e gerar comandos estruturados | LLM mapeando "crie um cliente" → POST /api/client/create
|
| Comportamento | Coreografia de agentes negociando a execução | Agentes de Auth, User e Mailer coordenando-se via fila |
| Execução | Persistência, cache, fila e feedback de ciclo fechado | Redis, Postgres, RabbitMQ, Neo4j |
5.3 Componentes da Stack
A Full Agentic Stack integra:
- Arquitetura orientada a eventos (EDA)
- CQRS + Event Sourcing + Saga Pattern
- Agentes cognitivos orquestrados e coreografados
- Data Access Layer reativo e multi-store (SQL, NoSQL, Graph, Vector)
- Infraestrutura AI-first (LLMs, embeddings, vetores, automações)
- Agentic UX, interfaces que interagem como organismos inteligentes
6. Propriedades Formais e Garantias
Para que uma arquitetura seja considerada Agentic, propomos os seguintes critérios:
6.1 Determinismo versus Emergência
Sistemas tradicionais buscam determinismo total. Em Full Agentic Stack, aceita-se emergência controlada: comportamentos não previstos explicitamente, mas dentro de limites seguros.
6.2 Invariantes Comportamentais
Invariantes que devem ser preservados:
- Toda ação é rastreável a um evento de origem;
- Agentes não executam ações fora de seu domínio de autoridade;
- Decisões críticas exigem confirmação humana ou quórum de agentes.
6.3 Protocolos de Consenso
Em cenários de múltiplos agentes, decisões coletivas seguem protocolos como:
- Votação por quórum para ações irreversíveis;
- Validação cruzada entre agentes especializados;
- Fallback determinístico quando LLMs produzem saídas ambíguas.
7. Estudo de Caso / Prototipação
7.1 Cenário Normal (Comércio)
Situação: Um usuário envia:
"Quero todos os pedidos do cliente João feitos essa semana."
Execução:
- Cognitive Gateway interpreta a intenção:
{ "intent": "Order.listByClient", "params": { "client": "João", "period": "this_week" } }
- OrderAgent consulta ClientAgent (via RabbitMQ) para obter o ID de João.
- OrderAgent executa query CQRS:
SELECT * FROM orders
WHERE client_id = $1
AND created_at >= now() - interval '7 days';
-
AnalyticsAgent recebe evento
OrderFetchede atualiza dashboards.
✅ O sistema respondeu em linguagem natural sem exigir conhecimento de SQL, API ou schema.
7.2 Cenário Avançado (Coreografia Cognitiva)
Situação:
"Aumente o desconto dos produtos que tiveram mais de 10 mensagens de reclamação nas últimas 48h."
Execução:
- Intent Mapper transforma a frase em:
{
"intent": "Commerce.adjustDiscount",
"filters": { "complaints": ">10", "period": "48h" }
}
-
ComplaintAgent publica evento
HighComplaintRate(product_id). - PricingAgent consome o evento e aplica regra:
if (complaints > 10 && salesTrend.decreasing) {
discount += 10;
}
- EventStore registra a decisão e aciona MarketingAgent para atualizar catálogo.
💡 Há coordenação cognitiva entre agentes sem script estático. O comportamento é resultado da coreografia autônoma.
8. Avaliação e Discussão
8.1 Comparação com Stack Tradicional
| Elemento | Stack Tradicional | Full Agentic Stack |
|---|---|---|
| Requisição | HTTP direta | Linguagem Natural → Intenção |
| Lógica | Controladores fixos | Agentes cognitivos versionáveis |
| Banco de Dados | Único e síncrono | Multi-store (SQL, NoSQL, Graph, Vector, Event) |
| Fluxo de Dados | CRUD | Event-Driven com CQRS e Saga |
| UX | Formulários | Agentic UX conversacional |
| Deploy | Estático | Reconfigurável por DSL declarativa |
8.2 Trade-offs Observados
| Dimensão | Trade-off |
|---|---|
| Latência vs Autonomia | Mais autonomia = mais chamadas LLM = maior latência |
| Custo de Token vs Qualidade | Modelos maiores = melhor decisão = custo maior |
| Emergência vs Controle | Mais emergência = mais inovação = menos previsibilidade |
8.3 Limitações
- Dependência de LLMs: falhas ou alucinações afetam toda a cadeia;
- Complexidade de debug: rastrear decisões em coreografia é mais difícil que em fluxo linear;
- Custo operacional: infraestrutura multi-store e filas exige mais recursos.
9. Conclusão e Trabalhos Futuros
A Full Agentic Stack representa um avanço conceitual e prático na arquitetura de sistemas distribuídos. Se o Full Stack Developer dominava front e back, o Full Agentic Developer dominará fluxos cognitivos.
A IA deixa de ser ferramenta auxiliar para tornar-se base estrutural do software moderno. Assim como bancos de dados, responsividade e cloud tornaram-se padrão, a inteligência nativa será requisito fundamental.
Trabalhos Futuros
- Governança cognitiva: formalizar limites éticos e operacionais para agentes autônomos;
- Replicação determinística: garantir reprodutibilidade em cenários de emergência controlada;
- Integração com confiança federada: agentes operando em domínios com diferentes níveis de trust;
- Auto-composição de sistemas: frameworks que permitam agentes comporem microsserviços em tempo de execução;
- Versionamento comportamental: evoluir do versionamento semântico para Behavioral Versioning.
O futuro do desenvolvimento não é apenas programar sistemas inteligentes, mas sistemas que programam a si mesmos.
Referências
[1] J. M. Corchado, D. I. Tapia, J. Bajo, "A multi-agent architecture for distributed services and applications," Int. J. Innov. Comput. Inf. Control, vol. 8, no. 4, 2012.
[2] N. Jamali et al., "A layered architecture for real-time distributed multi-agent systems," Proc. ACM, 2005.
[3] A. P. G. Garcia et al., "An intelligent agent-based distributed architecture for smart-grid networks," Proc. IEEE Local Comput. Netw., 2010.
[4] F. F. Alruwaili, "Artificial intelligence and multi-agent based distributed ledger systems," PMCID, 2020.
[5] Y. Kaeri, K. Sugawara, C. Moulin, T. Gidel, "Agent-based management of support systems for distributed brainstorming," Appl. Ergon., vol. 85, 2020.
[6] M. Wooldridge, An Introduction to MultiAgent Systems, 2nd ed., Wiley, 2009.
[7] D. C. Mackenzie, "Knowledge representation and reasoning," Wikipedia, 2024. [Online]. Available: https://pt.wikipedia.org/wiki/Representa%C3%A7%C3%A3o_de_conhecimento_e_racioc%C3%ADnio
[8] R. A. Brooks, "Intelligence without representation," Artif. Intell., vol. 47, no. 1-3, pp. 139–159, 1991.
[9] S. Bradner, J. Mankin, "The Impact of TLS 1.3 on Internet Security," IETF Journal, 2018.
[10] Verizon, "2023 Data Breach Investigations Report," Verizon Enterprise Solutions, 2023.
[11] S. Rose, O. Borchert, S. Mitchell, S. Connelly, "Zero Trust Architecture," NIST Special Publication 800-207, 2020.
[12] Grand View Research, "Zero Trust Security Market Size, Share & Trends Analysis Report," 2024.
[13] FIDO Alliance, "FIDO2 WebAuthn Specification," W3C Recommendation, 2021.
[14] Cloudflare, "Anatomy of a Phishing Attack: The Cloudflare Story," Cloudflare Blog, 2022.
[15] M. Marlinspike, "The Signal Protocol: A Secure Messaging Framework," Signal Foundation, 2020.
[16] T. Lodderstedt et al., "OAuth 2.0 Demonstration of Proof-of-Possession at the Application Layer," IETF RFC 9449, 2023.
[17] P. Kocher et al., "Secure Microcontrollers for IoT: TPM and Secure Enclave," IEEE Security & Privacy, 2021.
Aprenda a Implementar Esta Arquitetura
Deseja aprender a implementar toda essa arquitetura na prática? Click abaixo para aprender mais:
Top comments (0)