🔄 O que muda com Managed — Você só envia tarefas
No modelo self-host, você provisiona servidor, gerencia Docker, monitora uptime, lida com crashes e configura secrets. Com Managed Agents, tudo isso desaparece. Você define o que o agente faz (skills, tools, CLAUDE.md) e envia tarefas via API. O resto é problema da Anthropic.
📊 Self-host vs Managed — o que muda
| Responsabilidade | Self-host | Managed |
|---|---|---|
| Infraestrutura | Você | Anthropic |
| Sandboxing | Você (Docker) | Anthropic |
| Persistência de estado | Você | Anthropic |
| Recuperação de erros | Você | Anthropic |
| Skills / CLAUDE.md | Você | Você |
| Controle de dados | Total | Parcial |
💡 Hosted + ops-as-a-service
O modelo de Managed Agents é análogo ao que AWS Lambda fez com servidores: você não pensa em VMs, só em funções. Com Managed, você não pensa em containers, só em tarefas. A abstração reduz overhead operacional de horas/semana para zero — mas exige abrir mão de parte do controle.
💵 Pricing — US$0,08/h (Modelo session-hour)
Em vez de cobrar por token (imprevisível), Managed Agents cobra por hora de sessão ativa. Para casos always-on — um agente que monitora chat ao vivo, ou um billing agent que roda 8h por dia — o custo é previsível e facilmente justificável.
🧮 Calculadora de custo real
Total para os 3 casos: ~US$5/mês em infra
Vs. custo de VPS self-host com 99.9% uptime: ~US$40-80/mês
📊 Session pricing + cost ceiling
O modelo session-hour tem um benefício oculto: você pode definir cost ceiling por agente. Se um agente ficar rodando em loop (bug), ele para ao atingir o teto. No modelo de tokens, um bug de loop pode gerar uma fatura surpresa de milhares de dólares.
🔒 Sandboxing Gerenciado — Isolamento embutido
Cada sessão de Managed Agent roda em um sandbox isolado por tenant. O agente do cliente A não pode ver arquivos, memória ou outputs do cliente B — sem você precisar configurar Docker, namespaces Linux ou políticas de IAM. O isolamento é garantia do serviço.
🏗️ O que o sandbox Managed garante
Nenhum dado vaza entre sessões de clientes diferentes. Ambiente completamente efêmero.
Cada sessão tem seu próprio espaço de arquivos temporários. Limpo ao final.
Agente só acessa URLs explicitamente autorizadas. Sem egress não declarado.
Sandbox destruído ao fim da sessão. Nenhum estado residual entre execuções.
💡 Sem você precisar configurar Docker
No self-host, manter sandboxing correto exige conhecimento de Docker security, seccomp profiles, e network policies. É fácil errar — e um sandbox mal configurado é perigoso. Managed delega essa responsabilidade para a Anthropic, que tem equipes dedicadas a isso. Para quem não é DevOps, é a escolha óbvia.
🧠 Persistência de Estado — Memória entre sessions
O problema clássico de agentes é a memória: cada sessão começa do zero, sem saber o que aconteceu antes. Managed Agents resolvem isso com state persistence gerenciada — a sessão nova continua de onde a anterior parou, com identidade de agente preservada.
💾 Como funciona a persistência
Agent Identity
Cada agente tem um ID permanente. Sessões são instâncias do mesmo agente.
State Store
Ao fim de cada sessão, estado é serializado e salvo. Na próxima sessão, é desserializado automaticamente.
Memory scoping
Você define o que persiste: preferências do usuário, histórico de decisões, contexto de projeto. O resto é efêmero.
📊 State persistence + agent identity
Para o Live Support Agent do Marco, persistência significa: o agente lembra dos whales que compraram na semana passada, das promoções ativas, e do tom da última live. Ele não começa cada live como se fosse a primeira. Isso é o que separa um "chatbot que reinicia" de um "assistente que aprende".
⚖️ Self-host × Managed — Quando escolher
Não existe resposta universal. A escolha entre self-host e Managed é estratégica, baseada em requisitos de privacidade, overhead operacional tolerável, e se os dados podem trafegar fora do seu perímetro. Aqui está o framework de decisão.
🎯 Framework de decisão
- →Não tem time de DevOps
- →Dados não são regulados (não PHI, não confidenciais)
- →Precisa de uptime >99% sem overhead
- →Agentes de uso geral (briefings, relatórios)
- →Dados PHI ou regulados (saúde, jurídico)
- →Contrato de data residency com cliente
- →Precisa de customização profunda de infra
- →Compliance corporativo exige on-premise
💡 Build × Buy — decisão estratégica, não técnica
Marco → Managed (dados de e-commerce, zero restrição regulatória, sem DevOps). Sally → Bedrock self-host (dados jurídicos, exigência de no-egress). Dra. Sana → self-host total (PHI, HIPAA). A lógica não é técnica — é sobre quem você serve e o que seus contratos exigem.
🗺️ Roadmap — Codex equivalente (OpenAI segue)
Managed Agents da Anthropic foi lançado em abril de 2026. O OpenAI Codex e o modelo de agentes gerenciados da OpenAI seguem direção similar. A tendência é clara: cada provedor terá sua plataforma de agentes gerenciados, e a escolha entre eles se tornará parte do stack decision das empresas.
📅 Landscape de Managed Agents em 2026
📊 Multi-vendor managed + lock-in risk
O risco principal de Managed Agents é lock-in: seu CLAUDE.md e skills são portáveis, mas a configuração de estado, networking e permissões é específica do provedor. A estratégia inteligente: mantenha o lógica de negócio (CLAUDE.md, skills) completamente separada da configuração de infra. Assim, migrar entre provedores é possível sem reescrever o sistema.
✅ Resumo do Módulo 6.4
Próximo módulo: Plano de 30 dias — o roteiro sequencial para implantar seu próprio Agentic OS, semana a semana, com entregáveis tangíveis em cada etapa.