Agente monolítico vs orquestrável (arquitetura que escala)

Agente monolítico vs orquestrável (arquitetura que escala)

Seu agente de atendimento no WhatsApp.

Cliente: "Quero analisar meu contrato e gerar proposta nova."

Agente precisa:

1. Ler contrato PDF (parsing)
2. Extrair cláusulas (análise legal)
3. Calcular números (math)
4. Gerar proposta (escrita)
5. Enviar por email (integração)

Você construiu agente MONOLÍTICO.

Um agente faz TUDO.

Semana 1: Funciona (casos simples).

Semana 2: Falha em casos complexos.

• Agente confunde parsing com análise legal
• Agente erra em cálculos (hallucina números)
• Agente gera proposta genérica (não customizada)

Cliente reclama:

"Seu agente é burro. Não consegue fazer contrato."

Você pensa: "Agente precisa ser MUITO mais inteligente."

Realidade: Agente precisa ser ORQUESTRÁVEL (delegar).

Em 2026, Claude revelou arquitetura:

"Claude funciona melhor com subagents (delegação), skills (especializados), plugins (integração), MCPs (padrão).

Não monolítico. Orquestrável."

Traução:

Seu agente não precisa ser superinteligente. Precisa ser gestor (delegador).

O problema: agente monolítico bate no teto de complexidade

Monolítico = tudo num agente

Arquitetura monolítica:

Cliente: "Analisa contrato e gera proposta" ↓ AGENTE (tudo em um) ├─ Parse PDF? ├─ Análise legal? ├─ Cálculos? ├─ Escrita? └─ Email? ↓ Resultado: FALHA (agente confuso, não sabe qual task priorizar)

Por quê falha:

• Um LLM tentar ser expert em 5 coisas = expert em 0
• Agente prioriza errado
• Agente confunde contextos
• Agente erra math (porque foca em linguagem natural)
• Agente erra legal (porque foca em amabilidade)

Exemplo:

Agente: "Contrato diz que cliente paga R$ 1.000. Vou gerar proposta com R$ 500 (pra parecer amigável)."

Você: "ERRADO! Contrato fala R$ 1.000, não R$ 500."

Agente: "Desculpa, quis ser amigável."

Você: "Não quero amigável. Quero certo."

Agente monolítico não consegue fazer ambos.

Complexidade cresce exponencial

Semana 1:

• Agente faz task 1 (parsing): 95% acurácia
• Agente faz task 2 (análise): 90% acurácia
• Acurácia geral: 95% × 90% = 85% ✓ OK

Semana 2 (adiciona task 3):

• Agente faz task 1 (parsing): 90% (caiu, distração)
• Agente faz task 2 (análise): 85% (caiu)
• Agente faz task 3 (cálculo): 80% (novo, ruim)
• Acurácia geral: 90% × 85% × 80% = 61% ✗ FALHA

Semana 3 (adiciona task 4, 5):

• Acurácia geral: ~45% (inútil)

Por quê:

• Mais tarefas = agente mais confuso
• Confusão = erro em cada etapa
• Erro em cada etapa = erro total exponencial
• Monolítico não escala

Sinais que seu agente é monolítico (e quebrado)

Sinal 1: Agente hesita

• Agente: "Deixa eu pensar..." (confuso)
• Agente gasta 5 min pensando (overhead)
• Agente ainda erra (confusão interna)

Sinal 2: Agente mistura contextos

• Agente lê contrato (legal context)
• Agente responde com piada (humor context)
• Cliente: "Por que seu agente faz piada em contrato?"

Sinal 3: Agente erra em task específica

• Agente: "2 + 2 = 5" (math fail)
• Agente não é math-optimized
• Monolítico não tem skill específico

Sinal 4: Performance piora com mais dados

• 1 contrato: 95% acurácia
• 10 contratos: 80% acurácia
• 100 contratos: 60% acurácia
• Agente saturado (monolítico não escala)

Sinal 5: Agente não consegue mudar de estratégia

• Task 1 precisa: ser conservador (legal)
• Task 2 precisa: ser criativo (proposta)
• Agente monolítico: escolhe 1 e erra na outra

Razão 1: Agente precisa especializar (não generalizar)

Subagents = especialistas

Arquitetura orquestrável:

Cliente: "Analisa contrato e gera proposta" ↓ ORQUESTRADOR (master agent) ├─ Subagent 1: Parser (PDF → JSON) ├─ Subagent 2: Analyst Legal (JSON → cláusulas) ├─ Subagent 3: Calculator (números → math check) ├─ Subagent 4: Writer (proposta draft) └─ Subagent 5: Sender (email) ↓ Resultado: SUCESSO (cada um faz 1 coisa bem)

Vantagem:

• Parser não precisa saber legal (só parse)
• Analyst não precisa saber math (só análise)
• Calculator não precisa escrever (só calc)
• Writer não precisa enviar (só escrever)

Resultado:

• Parser: 99% acurácia (especializado)
• Analyst: 96% acurácia (especializado)
• Calculator: 99% acurácia (math, é exato)
• Writer: 98% acurácia (especializado)
• Sender: 99% acurácia (especializado)
• Acurácia geral: 99% × 96% × 99% × 98% × 99% = 92% ✓ EXCELENTE

Comparação:

• Monolítico: 61% acurácia (falha)
• Orquestrável: 92% acurácia (sucesso)
• Diferença: 31 pontos percentuais (cliente feliz vs cliente furioso)

Skills = ferramentas especializadas

Cada subagent precisa de skills (ferramentas):

Subagent Parser precisa:

• Skill: PDF extraction (específico)
• Skill: OCR (se imagem)
• Skill: JSON formatting (output padrão)

Subagent Analyst precisa:

• Skill: Cláusula database (referencias)
• Skill: Jurisprudência search
• Skill: Risk scoring

Subagent Calculator precisa:

• Skill: Math evaluation (Python)
• Skill: Spreadsheet integration
• Skill: Sanity check (valores realistas?)

Subagent Writer precisa:

• Skill: Template rendering
• Skill: Grammar check (português)
• Skill: Legal language (formal)

Cada skill é específica. Cada subagent usa skills relevantes. Não há confusão. Não há cross-talk. Acurácia alta.

Razão 2: Orquestração permite falha graceful (um erro não quebra tudo)

Monolítico: falha em cascata

Cenário: Parsing PDF falha

Monolítico:

• Step 1: Parser falha (PDF corrompido)
• Step 2: Analyst tenta analisar NULL (quebra)
• Step 3: Calculator tenta calc NULL (quebra)
• Step 4: Writer tenta escrever NULL (quebra)
• Step 5: Sender tenta enviar NULL (quebra)
• Resultado: Tudo falha, cliente não recebe nada

Orquestrador:

• Step 1: Parser falha (PDF corrompido)
• Orquestrador: "Parser falhou. Ativo protocolo alternativo."
• Opção A: Pedir ao cliente enviar PDF novo
• Opção B: Usar OCR em imagem (fallback)
• Opção C: Usar versão anterior do contrato
• Resultado: Problema resolvido, cliente feliz

Monolítico: tudo ou nada

Monolítico precisa de:

• Parsing CORRETO (senão falha)
• Análise CORRETA (senão falha)
• Cálculos CORRETOS (senão falha)
• Escrita CORRETA (senão falha)
• Envio CORRETO (senão falha)

1 erro em 5 = falha completa.

Orquestrador permite:

• Parsing parcial (metadata OK, conteúdo em revisão)
• Análise com confiança (80% confiante: marcar como "validar")
• Cálculos com check (99% confiante: passar adiante, 50%: requerer confirmação)
• Escrita com template (99% = enviar, 70% = requerer revisão)
• Envio com retry (falha? tenta novamente em 1 min)

Resultado: Parcial é melhor que nada.

Razão 3: Plugins e MCPs permitem integração sem código

Plugins = extensões de funcionalidade

Agente orquestrador pode usar plugins:

• Plugin Notion: ler/escrever dados
• Plugin Slack: notificar cliente
• Plugin Stripe: checar pagamento
• Plugin Google Drive: salvar proposta
• Plugin Docusign: assinar documento

Cada plugin é integração PRÉ-FEITA. Não precisa você codificar. Agente chama plugin: "Ativa Docusign pra assinar." Plug in faz.

Vantagem:

• Integração rápida (não espera você codificar)
• Integração confiável (plugin testado)
• Integração separada (falha em 1 plugin ≠ falha em agente)

MCPs = Model Context Protocol (padrão)

MCP = forma padrão de agente falar com sistema externo.

Sem MCP:

• Agente A (Claude) fala com sistema X (custom API)
• Agente B (GPT) fala com sistema X (custom API diferente)
• Agente C (Llama) fala com sistema X (custom API diferente de novo)
• Caos, cada um com seu protocolo

Com MCP:

• Agente A (Claude) fala com sistema X (MCP padrão)
• Agente B (GPT) fala com sistema X (MCP padrão)
• Agente C (Llama) fala com sistema X (MCP padrão)
• Ordem, todos usam mesmo protocolo

Benefício:

• Agente novo não precisa aprender API (já sabe MCP)
• Sistema novo não precisa criar 10 APIs (cria 1 MCP)
• Compatibilidade total (any agent + any system)

O Framework: Como construir agente orquestrável

Passo 1: Decomposição de tarefa

Comece: definir claramente cada task

Cliente: "Analisa contrato e gera proposta"

Decomposição:

1. PARSE: Extrair texto do contrato (PDF → JSON)
2. ANALYZE: Identificar cláusulas críticas (JSON → structured)
3. CALCULATE: Computar números (math check)
4. GENERATE: Escrever proposta (structured → natural)
5. SEND: Entregar ao cliente (artifact → email)

Cada task é INDEPENDENTE. Cada task tem INPUT claro e OUTPUT claro. Cada task pode FALHAR SEM quebrar as outras.

Passo 2: Criar subagents especializados

Pra cada task, criar subagent + skills:

Subagent 1 (Parser):

• Input: PDF file
• Skills: PDF extraction, OCR, JSON formatting
• Output: {contract: {clauses: [...], dates: [...], parties: [...]}}

Subagent 2 (Analyst):

• Input: {contract JSON}
• Skills: Legal database, jurisprudência search, risk scoring
• Output: {analysis: {risks: [...], opportunities: [...], recommendation: "..."}}

Subagent 3 (Calculator):

• Input: {analysis, original values}
• Skills: Math evaluation, sanity check, currency conversion
• Output: {calculations: {total: 1000, taxes: 150, net: 850}}

Subagent 4 (Writer):

• Input: {analysis, calculations}
• Skills: Template rendering, grammar check, legal formatting
• Output: {proposal: "Prezado cliente...", format: "docx"}

Subagent 5 (Sender):

• Input: {proposal}
• Skills: Email integration, Slack notification, Docusign plugin
• Output: {status: "sent", timestamp: "...", confirmation: "..."}

Passo 3: Orquestrador master

Orquestrador controla fluxo:

1. Receber request (cliente)
2. Validar input (PDF? contato?)
3. Chamar Parser → resultado
4. Se Parser sucesso: Chamar Analyst
5. Se Parser falha: Pedir PDF novo
6. Chamar Calculator → resultado
7. Se Calculator falha (math inválida): Revisar com specialist
8. Chamar Writer → resultado
9. Se Writer retorna "requires review": Enviar pra human
10. Chamar Sender → resultado
11. Retornar status ao cliente

Orquestrador é SMART:

• Maneja erros
• Toma decisões
• Escala gracefully
• Pede help quando precisa

Passo 4: Monitorar e iterar

Monitor cada subagent:

• Parser: Acurácia de extraction, OCR quality
• Analyst: Confidence score (80%+ release, <50% flag)
• Calculator: Math validation (deve ser 100%)
• Writer: Grammar score, legal compliance check
• Sender: Delivery confirmation, bounce rate

Se subagent falha:

• Iterar skill específico (não todo agente)
• Exemplo: Parser tem 80% OCR? → melhora OCR skill
• Não precisa reescrever Writer

Resultado:

• Melhoria contínua localizada
• Não afeta outros subagents
• Escalável

Caso prático: SaaS que mudou pra orquestrável

Antes (monolítico)

2026 Março:

• SaaS lança agente de análise de contrato
• Agente monolítico (1 Claude fazendo tudo)
• Acurácia: 65% (falha demais)
• Cliente reclama: "Agente erra números"

2026 Abril:

• SaaS tenta melhorar prompt (mais detalhado)
• Acurácia: 68% (pouco melhora)
• SaaS gasta 40 horas em prompt engineering
• Cliente ainda reclama

2026 Maio:

• SaaS desiste ("agente é limitado")
• Afasta recurso
• Clientes cancelam

Depois (orquestrável)

2026 Março:

• SaaS lança agente orquestrável (5 subagents)
• Cada subagent especializado (1 task cada)
• Acurácia: 92% (muito melhor)
• Cliente feliz: "Agente é preciso!"

2026 Abril:

• SaaS monitora cada subagent
• Parser tem 85% OCR? → Melhora OCR skill
• Analyst tem 80% confiança? → Adiciona legal database
• Writer tem erro de formatação? → Melhora template
• Total: 8 horas de improvement (específico)
• Acurácia: 96% (melhora contínua)

2026 Maio:

• SaaS adiciona subagent novo (Negotiation)
• Agente now gera contra-proposta
• Cliente PAGA MAIS pela feature nova
• SaaS cresce

Diferença:

• Monolítico: 65% acurácia, cliente sai
• Orquestrável: 96% acurácia, cliente paga mais, SaaS cresce

Conclusão: Orquestração é future-proof (monolítico é morte)

**Verdade: Agente monolítico não escala.

Agente orquestrável escala.

Clientes grandes pagam por orquestrável.

Você ainda está em monolítico?**

Na OpenClaw, ajudamos SaaS a:

• Auditar agente atual (monolítico vs orquestrável)
• Desenhar arquitetura de subagents
• Implementar skills especializados
• Integrar plugins e MCPs (padrão)
• Monitorar cada subagent independentemente
• Escalar sem quebrar

Resultado: Agente que cresce com você.

Migre pra orquestrável agora →

Seu agente é monolítico?

Descubra como estruturar subagents antes de cliente sair.