“O futuro da computação é distribuído por natureza. Empresas que não projetarem para o edge vão competir com uma mão amarrada.” — Werner Vogels, CTO da Amazon, re:Invent 2023
Escalar software tradicional é um problema de engenharia. Escalar agentes autônomos é um problema de arquitetura.
A diferença importa. Um sistema de software processa requisições. Um sistema de agentes toma decisões em paralelo, mantém estado entre execuções e coordena ações com efeitos reais no mundo. Latência de rede não é só inconveniente, é falha de coordenação. Lock distribuído não é só lento, é gargalo estrutural.
A maioria das arquiteturas que equipes de engenharia usam hoje foi projetada para o primeiro problema. Quando aplicadas ao segundo, elas escalam linearmente em custo e sublinearmente em throughput.
O Gargalo Que Ninguém Nomeia
Arquiteturas centralizadas têm um pressuposto implícito: o estado vive em um lugar, e a computação vai até ele.
Esse pressuposto funcionou por décadas porque o gargalo era processamento. Hoje, o gargalo é coordenação. Quando um agente precisa consultar estado, tomar uma decisão e disparar uma ação, cada round trip para um banco de dados centralizado ou um serviço de orquestração adiciona latência. Com dezenas de agentes operando em paralelo, essa latência se multiplica.
O resultado é previsível:
- Throughput cai à medida que o número de agentes cresce
- Custos de infra sobem porque cada agente precisa de conexão persistente com o backend central
- Falhas em cascata tornam-se mais prováveis, porque um ponto central de estado é um ponto central de falha
A solução não é escalar o backend central. É eliminar a necessidade de centralização para a maioria das operações.
Edge Computing: A Computação Vai Até o Dado
Segundo o Gartner, até 2025 mais de 75% dos dados corporativos serão criados e processados fora do data center tradicional [3]. Para sistemas de agentes autônomos, essa tendência é ainda mais pronunciada.
Edge computing inverte o pressuposto. O estado e a computação ficam juntos, próximos de onde a ação acontece.
Em vez de um agente em São Paulo consultando um banco de dados em us-east-1 para decidir se deve aprovar um deploy, a decisão é tomada no edge, com estado local, em milissegundos. O round trip desaparece porque não há round trip.
Para sistemas de agentes autônomos, isso tem implicações diretas:
Latência de decisão cai para sub-10ms
Agentes que operam em pipelines de CI/CD, code review ou deploy precisam de respostas rápidas para manter o throughput do pipeline. Latência de rede em arquiteturas centralizadas típicas fica entre 50ms e 200ms por operação. No edge, isso cai para menos de 10ms.
Resiliência aumenta por design
Quando cada nó de edge opera de forma autônoma para seu contexto local, uma falha em um ponto não propaga para os demais. O sistema degrada graciosamente em vez de colapsar.
Escala horizontal sem coordenação central
Adicionar capacidade significa adicionar nós de edge, não escalar um backend central. O custo de infra cresce linearmente com o número de operações, não com a complexidade de coordenação.
Durable Objects: Estado Consistente Sem Locks Distribuídos
Edge computing resolve latência. Mas cria um novo problema: como garantir consistência de estado quando a computação está distribuída?
A resposta clássica são locks distribuídos. O problema é que locks distribuídos são lentos, complexos de implementar corretamente e transformam falhas de rede em falhas de consistência.
Durable Objects resolvem isso com uma abordagem diferente: cada objeto tem uma única instância ativa em qualquer momento, com memória e armazenamento próprios, e todas as requisições para aquele objeto são roteadas para essa instância.
Não há lock porque não há concorrência. Há serialização por design.
O que isso significa na prática
| Cenário | Locks Distribuídos | Durable Objects |
|---|---|---|
| Dois agentes acessam o mesmo estado | Contenção, timeout, retry | Serialização automática, sem contenção |
| Falha de rede durante operação | Estado inconsistente | Operação completa ou não executa |
| Escala de 10 para 1.000 agentes | Complexidade de coordenação cresce | Cada objeto escala independentemente |
| Debug de condição de corrida | Extremamente difícil | Eliminada por design |
Para sistemas de agentes autônomos, isso é decisivo. Um agente que executa um deploy não pode ter seu estado corrompido por outro agente que lê o mesmo pipeline simultaneamente. Com Durable Objects, essa classe inteira de bugs deixa de existir.
Persistência entre execuções
Agentes autônomos precisam de memória. Um agente de code review precisa saber o histórico de um repositório. Um agente de CI/CD precisa saber o estado do último pipeline.
Durable Objects mantêm estado entre execuções sem necessidade de banco de dados externo para cada operação. O estado persiste no objeto, disponível na próxima execução em microssegundos.
Outcome-Based Pricing: O Modelo de Custo Que Fecha a Conta
Arquitetura de edge com Durable Objects muda o perfil de custo de infra. E isso tem uma consequência direta no modelo de negócio.
Em arquiteturas centralizadas, o custo é fixo: servidores, banco de dados, load balancers, todos rodando 24/7 independentemente do volume de operações. O custo de infra não acompanha o valor entregue.
No edge, o custo é proporcional ao uso. Cada execução de agente consome recursos exatamente pelo tempo que opera. Não há capacidade ociosa pagando por disponibilidade.
Isso cria a base para outcome-based pricing: cobrar por resultado entregue, não por capacidade reservada.
Por que isso importa para CTOs
A pergunta que toda liderança técnica faz ao avaliar agentes autônomos é: qual o ROI? Com pricing por licença ou por hora de compute, a resposta é difícil. O custo é certo; o valor é variável.
Com outcome-based pricing, o alinhamento é direto:
- Custo de infra sobe quando mais operações são executadas
- Valor entregue sobe na mesma proporção
- ROI é mensurável por operação, não por mês de contrato
Um agente que executa 500 code reviews por mês custa proporcionalmente ao que entrega. Se o volume cai, o custo cai. Se o volume dobra, o valor dobra junto.
Como a Witek Implementa Isso
A Witek projeta e opera sistemas de agentes autônomos sobre essa arquitetura. Os Full-Time Agents (FTAs) executam operações de engenharia de ponta a ponta: code review, debugging, migração de legado, CI/CD e deploys.
Cada FTA opera no edge, com estado gerenciado via Durable Objects. Não há servidor central de orquestração que se torna gargalo. Não há lock distribuído que se torna fonte de inconsistência.
O resultado, medido em produção:
- Throughput 10x maior comparado a workflows operados por times humanos
- Custo alinhado com outcome: cada operação tem custo rastreável e resultado verificável
- Human-in-the-loop preservado para decisões que exigem julgamento, não para operações que são puramente mecânicas
A arquitetura não é um detalhe de implementação. É o que torna o modelo de negócio possível.
Sistemas que cobram por resultado só funcionam quando o custo de infra é proporcional ao resultado. Edge computing e Durable Objects são a base técnica que fecha essa equação.
Para equipes avaliando adotar agentes autônomos em operações de engenharia, a pergunta certa não é “qual agente usar”. É “qual arquitetura garante que o agente escala sem criar novos gargalos”. A resposta começa no edge.
Comparação: Arquiteturas para Sistemas de Agentes
| Aspecto | Centralizada (Cloud) | Edge + Durable Objects |
|---|---|---|
| Latência de decisão | 50-200ms por operação | <10ms por operação |
| Consistência de estado | Locks distribuídos (frágil) | Serialização por design |
| Escala horizontal | Complexidade de coordenação | Linear, sem coordenação |
| Custo de infra | Fixo (24/7) | Proporcional ao uso |
| Resiliência | Ponto central de falha | Degradação graciosa |
| Debug de concorrência | Extremamente difícil | Eliminada por design |
| Throughput com agentes | Sublinear (gargalo central) | Linear (10x vs centralizado) |
Fontes
[3] Gartner, “Top Strategic Technology Trends: Edge Computing,” 2023.