A maioria das demos de agentes parece ótima até sair do laptop do desenvolvedor. A UX despenca, os custos disparam e ninguém consegue explicar por que um agente empurrou uma mudança quebrada na sexta às 17h. Com a nova plataforma de IA para agentes da Cloudflare nos holofotes e o controle em nível de desktop ressurgindo com recursos ao estilo Codex, você está sendo cobrado com uma pergunta justa: qual é a nossa arquitetura de produção para agentes?
Esta é a resposta que entregamos: trate agentes como sistemas distribuídos e orientados a eventos na borda — não como chatbots monolíticos. Abaixo está uma arquitetura de referência pragmática que você pode apresentar à sua equipe hoje. É agnóstica a fornecedores, prioriza latência mensurável, políticas aplicáveis e previsibilidade de custo. Também escala de um único squad de produto para automação em toda a organização sem reescrever a plataforma.
Dos bots no laptop aos agentes nativos de borda
Duas coisas mudaram em 2026:
- Os runtimes de edge ficaram “cientes” de agentes. A Cloudflare anunciou uma camada de inferência projetada para agentes (pense em Workers + Queues + Durable Objects + Vectorize + inferência de IA), tornando realista manter estado e ferramentas próximos dos usuários. Vercel, Fly.io e os hyperscalers seguiram com suas variações.
- Os agentes de desktop estão de volta. Os recursos turbinados ao estilo Codex da OpenAI podem controlar seu computador em segundo plano. Isso é poderoso — e perigoso — sem política, auditoria e escopo adequados. Você precisa de guardrails no servidor mesmo que sua UI rode em um laptop.
Seu trabalho como CTO não é escolher a demo mais chamativa — é desenhar um sistema em que as decisões do agente sejam observáveis, reversíveis e baratas o suficiente para rodar em escala.
Requisitos de produção (a régua que você deve estabelecer)
- Latência: Latência percebida sub-1s para turnos comuns na América do Norte; compute na borda deve ficar <100 ms por função, recuperação <150 ms na região, raciocínio com modelos pequenos 300–800 ms, com modelos grandes 1,5–4 s. Deixe o usuário esperando apenas quando fizer sentido.
- Segurança: Política explícita sobre quais ferramentas o agente pode chamar, com escopo de recursos e aprovação humana para ações de alto risco.
- Observabilidade: Traços OpenTelemetry e eventos estruturados para toda ação, com replay. Se você não consegue reproduzir um incidente, você não construiu uma plataforma — construiu uma demo.
- Controle de custos: Orçamentos rígidos de tokens por turno/sessão, controle de admissão para prompts longos e backpressure para workloads com picos. Assuma escassez de compute de IA; projete para isso.
- Portabilidade: Troque modelos e hosts de ferramentas sem refatorar a lógica do agente. Evite “cola” que incorpore peculiaridades de um único fornecedor de LLM.
Uma arquitetura de referência nativa de borda
Mapeie estes conceitos para o stack de sua preferência. Vou usar termos da Cloudflare (entre parênteses) e apontar componentes equivalentes em AWS/GCP para manter os pés no chão.
1) Porta de entrada e identidade
- Edge API: Uma porta de entrada leve na borda (Workers, API Gateway + CloudFront ou Fastly Compute@Edge) termina TLS, autentica requisições (OIDC/JWT) e normaliza payloads.
- Metadados de sessão: Anexe IDs de usuário/organização, tier de risco e um orçamento de tokens por sessão. Armazene estado de sessão de curta duração em um key-value na borda ou objeto de sessão (Durable Objects; AWS: DynamoDB + Lambda@Edge).
2) Orquestrador e área de rascunho
- Event bus: Cada turno do usuário emite um evento para uma fila (Cloudflare Queues; AWS SQS; GCP Pub/Sub). Isso desacopla a latência da UI do trabalho a jusante.
- Orquestrador: Um worker sem estado consome eventos, executa o loop de controle (function calling, planning) e persiste um Grafo de Ações — um DAG de chamadas de ferramentas com entradas/saídas — em um objeto de sessão (Durable Objects; ou Redis/DynamoDB + Step Functions).
- Área de rascunho: Armazene dados do tipo chain-of-thought e planos como estado do agente privado não exposto aos usuários, e redija-os dos logs. O modelo recebe o plano; os logs recebem o resultado e um resumo da justificativa.
3) Motor de raciocínio (abstração de modelo)
- Roteador de modelos: Uma abstração fina que pode direcionar para modelos fechados (OpenAI/Anthropic), inferência hospedada na borda (Cloudflare AI) ou pesos abertos (por exemplo, Qwen 35B/A3B, Llama 3.x) em GPUs serverless (Fireworks, Modal) com base em política: sensibilidade dos dados, custo, velocidade e requisitos de acurácia.
- Interfaces somente JSON: Use saídas estruturadas (JSON Schema) para seleção de ferramentas, argumentos e resumos. Rejeite respostas malformadas no roteador e re-prompt com um orçamento menor em vez de deixar lixo fluir adiante.
4) Execução de ferramentas e sandboxing
- Sandbox WASM: Execute ferramentas rápidas e não confiáveis em WASI/WASM com limites de tempo e memória. Para ações mais longas, despache para funções serverless ou jobs de curta duração (Workers/Pages Functions; AWS Lambda/Fargate Jobs; GCP Cloud Run Jobs).
- Política de credenciais: Emita credenciais efêmeras e com escopo por invocação de ferramenta usando OIDC e um gerenciador de segredos (Vault, AWS STS + Secrets Manager). Nada de tokens de longa duração embutidos em prompts.
- Ações de desktop: Se você permitir que um agente “use um computador”, faça proxy por um broker que exponha uma superfície de ferramentas restrita (por exemplo, abrir URL em navegador sandboxed, ler texto da janela selecionada, simular clique dentro de uma bounding box) e registre cada ação com screenshots para auditoria. Nunca dê o sistema operacional completo.
5) Camadas de memória
- Curto prazo: Estado por sessão (Durable Objects; DynamoDB/Redis). TTL de minutos a horas.
- Longo prazo: Corpus de RAG em um repositório vetorial próximo ao agente (Cloudflare Vectorize; pgvector no Neon; Pinecone; Weaviate). Mantenha embeddings próximos de onde a inferência roda para evitar latência e custo de egress.
- Transacional: Um banco relacional (Postgres/PlanetScale) para direitos, aprovações e auditoria durável.
6) Política e aprovações
- Motor de políticas: Avalie cada chamada de ferramenta planejada contra a política (OPA/Rego ou Amazon Cedar). Entradas: papel do usuário, ambiente (prod/stage), sensibilidade do dataset, tier de risco da ferramenta, orçamento de tokens restante.
- Humano no loop: Para ações arriscadas (fazer merge no main, tocar em PII, gastar >$X), bloqueie e emita uma notificação no Slack/Email com um fluxo de aprovação em um clique. Registre quem aprovou e a justificativa.
7) Observabilidade e replay
- Traces: Emita spans OpenTelemetry para cada etapa: construção de prompt, chamada de modelo, recuperação, chamada de ferramenta, checagem de política. Correlacione com uma sessão e usuário.
- Log de eventos: Persista um fluxo de eventos compacto e redigido (Queue → armazenamento de objetos). Armazene entradas/saídas, versão do modelo, custo e latência. Esta é sua fonte da verdade para replay.
- Redação: Remoção de PII antes de qualquer coisa sair do runtime na borda. Mantenha um cofre não redigido e com controle de acesso apenas se for exigido por lei.
8) Controles de custo
- Orçamentos: Limites rígidos por turno e por sessão. Exemplo: 8K tokens de entrada + 2K de saída por turno, 40K de limite por sessão, com estratégia de backoff ao atingir 80% do limite.
- Controle de admissão: Rejeite prompts >N KB, sugira fragmentação (chunking) ou mude para um modelo mais barato/menor com consentimento explícito do usuário.
- Backpressure: Quando as filas acumularem, degrade graciosamente: modelos menores, menos ferramentas ou recuperações em lote.
Exemplo concreto: um agente de preparação de PR para seu monorepo
Objetivo: O agente redige um pull request que fecha um ticket do Jira ao estruturar mudanças de código, testes e um plano de migração — sem jamais fazer push no main sem aprovação.
- O usuário envia um link do ticket. A Edge API autentica, aloca um orçamento de 40K tokens para a sessão e grava um objeto de sessão.
- O orquestrador busca o ticket, roda RAG sobre caminhos de código relevantes usando um índice vetorial (região de edge mais próxima). Latência alvo: 80–150 ms para recuperação.
- O motor de raciocínio (modelo aberto de 14B ou fechado premium) planeja: ler os arquivos A/B, gerar o patch, rodar testes, propor a migração de BD, solicitar aprovação para abrir um PR.
- A camada de ferramentas executa na ordem: ler arquivos (WASM), redigir o patch (modelo), rodar testes (job serverless) e preparar um PR. Cada chamada de ferramenta carrega um token com escopo válido por 5 minutos.
- O motor de políticas bloqueia git push e emite um card de aprovação no Slack com um resumo do diff e custo/latência até aqui. O aprovador clica em “Permitir” ou “Revisar”.
- Com a aprovação, o agente abre o PR e publica um link para o trace. Todas as ações são capturadas em um log de eventos reproduzível.
Orçamento de latência (mediana):
- Requisição na borda + auth: 30–60 ms
- RAG: 80–150 ms
- LLM de planejamento (modelo pequeno): 300–600 ms
- Geração do patch (modelo): 700–2.000 ms dependendo do tamanho/modelo
- Testes (job serverless): em paralelo; o usuário vê atualizações em streaming
- Tempo total até algo útil: <1 s para prévia do plano; 2–5 s para o primeiro rascunho do patch
Esboço de custo (atualize com o preço do seu fornecedor):
- Defina o custo por 1M tokens para cada tier de modelo. Compute por turno: (tokens de entrada + de saída) / 1.000.000 × preço.
- Turnos com modelos de pesos abertos pequenos podem ser uma ordem de grandeza mais baratos do que modelos de fronteira. Use-os para planejamento e seleção de ferramentas; reserve os de fronteira para síntese de código ou raciocínio difícil.
- Egress ainda importa. O egress na nuvem pública costuma ficar em torno de US$0,05–US$0,09/GB. Se seu agente trafega artefatos grandes (logs, binários), co-localize compute e dados ou mova artefatos para armazenamento na borda.
Construir vs. comprar: o que terceirizar para a plataforma
Você não precisa construir tudo. Aqui vai uma divisão pragmática.
- Comprar/Aproveitar: runtime de borda, filas, armazenamento de objetos; hosting de modelos para pelo menos dois tiers (rápido/barato e preciso/caro); banco vetorial com posicionamento regional; logging compatível com OTel; gerenciamento de segredos.
- Construir: orquestrador (seu loop de controle), integração de políticas (seu risco), catálogo de ferramentas e política de sandbox, redação, UI de replay e controles de custo. Isso codifica suas regras de negócio e é a sua vantagem competitiva.
A stack integrada de agentes da Cloudflare reduz o trabalho de “cola”; AWS/GCP dão controle granular com mais montagem. De qualquer forma, mantenha o roteador de modelos e a camada de políticas sob seu controle para evitar lock-in de fornecedor.
Formato de time e cronograma (amigável a nearshore)
- Time core: 1 engenheiro de plataforma (edge/runtime/filas), 1 engenheiro de IA (prompting, roteador, evals), 1 engenheiro de aplicação (ferramentas, lógica de domínio), 0,5 SRE/observabilidade. Adicione um engenheiro de segurança para o escopo de agentes de desktop.
- Cronograma: Um piloto governado em 4 semanas é realista com um escopo focado:
- Semana 1: Porta de entrada, identidade, tracing e um orquestrador stubado. Escolha dois modelos e conecte um roteador.
- Semana 2: Implemente três ferramentas em WASM (somente leitura), adicione busca vetorial e o motor de políticas em modo “apenas relatório”.
- Semana 3: Ative política bloqueante para uma ação arriscada, adicione aprovação via Slack e redação. Inicie dashboards de custo.
- Semana 4: Entregue o agente de preparação de PR para um squad. Defina SLOs: resposta p95 do agente <2,5 s, custo por turno <US$X, zero bypasses de política.
Times nearshore brasileiros podem cobrir horas de build com 6–8 horas de sobreposição com os fusos dos EUA e manter a integração avançando enquanto seu time core foca em política e seleção de modelos.
Gestão de risco e trade-offs
- Acurácia vs. custo: Use modelos pequenos para planejamento e roteamento de ferramentas; escale seletivamente. Você reduzirá o gasto em 30–70% sem prejudicar resultados.
- Latência vs. portabilidade: Inferência hospedada na borda acelera a UX mas pode reduzir a escolha de modelos. Mantenha uma rota alternativa para um segundo provedor para failover e checagens de regressão.
- Segurança vs. autonomia: Mais aprovações reduzem incidentes, mas prejudicam throughput. Comece rígido e relaxe com métricas de confiança e auditorias pós-evento.
- Escopo do agente de desktop: É tentador deixar os agentes “simplesmente fazerem”. Não faça isso. Medie toda ação de desktop por uma superfície de ferramentas estreita e registre tudo.
Como decidir onde cada componente roda
Não empurre tudo cegamente para a borda. Use esta regra simples:
- Borda: Autenticação, modelagem de requisições, planejamento leve, recuperação quando o corpus já está em cache ou replicado. Regra prática: trabalho <100 ms e <256 KB de E/S.
- Regional: RAG pesado contra dados transacionais, janelas de contexto longas e qualquer coisa que incorreria em egress entre regiões se executada na borda.
- Background: Ferramentas que rodam >2 s ou precisam de isolamento (testes, compilações, indexação). Sempre faça checkpoint no log de eventos; transmita parciais para a UI.
Avaliação: prove que funciona antes de escalar
- Tarefas douradas: 20–50 tarefas reais representativas de produção. Acompanhe taxa de sucesso, média de turnos, custo por sucesso e tempo até a primeira saída útil.
- Testes de guardrail: Simule prompts arriscados e garanta que o motor de políticas os bloqueie. Inclua cenários de injeção de prompt e tentativas de exfiltração de dados.
- Carga: Faça soak test com concorrência realista. Observe profundidade da fila e comportamento de backpressure; verifique se as políticas de degradação graciosa entram em ação.
O que vem a seguir: prepare-se para a escassez
A demanda por agentes está superando a oferta. Espere escassez periódica de compute e throttling de modelos. Projete agora para roteamento multi-modelo, fallbacks cientes de orçamento e SLAs grosseiros (“rápido-e-bom-o-suficiente” vs. “lento-mas-preciso”). Quando a pressão vier, os times com alavancas de custo e observabilidade continuarão entregando enquanto o resto pausa os rollouts.
Principais conclusões
- Pare de tratar agentes como chatbots; trate-os como sistemas orientados a eventos, primeiro na borda.
- Construa seu próprio orquestrador, camada de políticas, roteador de modelos e replay; compre o encanamento.
- Atinga UX subsegundo mantendo planejamento e recuperação na borda; empurre trabalhos longos para jobs.
- Use modelos pequenos para planejamento e escale seletivamente para controlar o gasto.
- Imponha credenciais com escopo e efêmeras e aprovações humanas para ações arriscadas.
- Instrumente tudo com OpenTelemetry e mantenha um log de eventos redigido e reproduzível.
- Projete para multi-modelo e multi-provedor desde o dia um para sobreviver à escassez de compute de IA.