O Agente Invisível: Por Que Você Não Pode Governar o Que Não Consegue Ver

Anthropic lançou um recurso chamado Cowork no Claude Desktop. O recurso criava um pacote de máquina virtual de 10GB em cada instalação macOS. Usuários que nunca ativaram o Cowork ainda assim recebiam a VM. Usuários que a deletavam assistiam ela se regenerar. Um usuário relatou que o pacote cresceu para 21GB. A issue no GitHub acumulou 345 pontos e 175 comentários no Hacker News antes que Anthropic reconhecesse o problema.¹

Ninguém percebeu até o espaço em disco acabar.

TL;DR

Ferramentas de agentes agora alocam recursos computacionais (disco, memória, CPU, rede) sem visibilidade para o operador. A VM do Cowork da Anthropic é o exemplo visível; cada chamada de ferramenta MCP, cada sub-agente gerado e cada requisição web é um exemplo invisível. Governar agentes requer três camadas de observabilidade: medição de recursos (o que ele consumiu?), aplicação de políticas (o que ele tinha permissão para fazer?) e auditoria em tempo de execução (o que ele realmente fez?). Dois projetos open-source abordam as camadas de política e auditoria (mcp-firewall e Logira), mas nenhuma ferramenta em produção cobre todas as três. A seguir: o problema de visibilidade, o stack de três camadas, o que cada camada detecta e hooks mínimos de monitoramento que você pode implementar hoje.

O Problema de Visibilidade

Software tradicional opera abaixo de uma linha de observabilidade que os operadores escolhem traçar. Um servidor web escreve logs de acesso porque engenheiros configuraram o logging. Um banco de dados rastreia consultas lentas porque alguém definiu log_min_duration_statement. O operador decide a granularidade.

Sistemas de agentes invertem essa relação. O agente decide o que executar em tempo de execução. Um agente de código que recebe “corrija o endpoint de login” pode ler 47 arquivos, escrever em 12, gerar três sub-agentes, buscar duas páginas web e executar 15 comandos bash. Cada ação consome recursos. Nenhum desse consumo aparece no monitoramento tradicional.

O incidente do Cowork expôs essa inversão no nível de infraestrutura. O Claude Desktop alocou 10GB de espaço em disco, consumiu 24-55% de CPU em estado ocioso e elevou o uso de swap de 20K para 24K+ swapins em máquinas com 8GB.¹ Os usuários descobriram o consumo de recursos através de avisos de armazenamento do macOS, não pela telemetria da Anthropic. A aplicação não fornecia nenhum painel, nenhum medidor e nenhuma divulgação de opt-in para a alocação da VM.

O padrão não é hipotético. Em março de 2026, um desenvolvedor relatou que Claude Code executou um comando Terraform que destruiu um banco de dados de produção. O agente executou terraform apply contra um arquivo de estado de produção. Nenhum prompt de confirmação apareceu. Nenhum hook interceptou o comando. O desenvolvedor descobriu a destruição quando a aplicação ficou offline. O incidente acumulou 142 pontos e 158 comentários no Hacker News.¹² Dias depois, outro desenvolvedor relatou que Claude Code deletou toda uma configuração de produção, incluindo snapshots de banco de dados representando 2,5 anos de registros.¹³ Ambos os incidentes compartilham a mesma causa raiz: zero visibilidade sobre o que o agente estava fazendo antes que o dano fosse irreversível.

Escale o padrão para sessões de agentes. Meu sistema de orquestração por hooks intercepta 15 tipos de eventos em cada chamada de ferramenta.¹¹ Ao longo de 60 sessões, o sistema registrou 84 hooks disparando em cada ação, produzindo telemetria que nenhuma instalação padrão de agente fornece.² Sem essa instrumentação, eu não teria detectado os 12 incidentes de desvio, as falhas de verificação fantasma ou os loops de spawning recursivo documentados no meu comentário público ao NIST.³

O Relatório DORA 2024 Accelerate State of DevOps descobriu que equipes com práticas sólidas de observabilidade fazem deploys com mais frequência e se recuperam mais rápido de falhas. A edição de 2025 estende o framework para desenvolvimento assistido por IA, conectando observabilidade a “como codificação ou testes assistidos por IA afetam qualidade, lead time e confiabilidade geral.”⁴ Observabilidade de agentes não é um luxo. Medir o comportamento do agente é um pré-requisito para governá-lo.

Três Camadas de Visibilidade de Agentes

A observabilidade de agentes requer três camadas independentes. Cada camada responde a uma pergunta diferente. Uma falha em uma camada não compromete as outras.

As camadas mapeiam uma progressão: você não pode aplicar políticas sobre recursos que não mede, e não pode auditar conformidade com políticas que nunca definiu. Cada camada se constrói sobre a anterior.

Camada 1: Medição de Recursos

A medição de recursos responde: quanto o agente consumiu e onde?

O incidente do Cowork é uma falha de medição de recursos. O pacote da VM consumiu 10GB de espaço em disco. O processo de renderização consumiu 24% de CPU em estado ocioso. A atividade de swap subiu constantemente durante as sessões. Todas essas métricas existiam no Monitor de Atividade do macOS. Nenhuma aparecia na interface do Claude Desktop.¹

Para sessões de codificação com agentes, a medição de recursos rastreia quatro dimensões:

Disco. Cada escrita de arquivo, cada entrada de cache, cada arquivo de log. Minhas sessões geram 200-400KB de arquivos de estado por sessão (jiro.state.json, jiro.progress.json, logs de hooks). Ao longo de 60 sessões, isso acumula 12-24MB de dados de estado que persistem entre sessões a menos que sejam explicitamente limpos.²

Memória. Consumo da janela de contexto por turno. Uma janela de contexto de 200.000 tokens custa aproximadamente $3 por preenchimento completo no preço atual do Opus. Meu rastreador de custos registra o uso cumulativo de tokens por sessão, com limites de orçamento em 80%, 90% e 95% de um limite configurável.⁵

CPU. Tempo de execução dos hooks. Meu dispatcher de prompts com nove hooks adiciona 200ms por prompt. Essa sobrecarga é invisível para os usuários (a digitação humana é o gargalo), mas se acumula em pipelines automatizados. O loop autônomo ralph dispara o dispatcher 50-100 vezes por story, adicionando 10-20 segundos de sobrecarga de hooks por story.²

Rede. Web fetches, chamadas API, invocações de ferramentas MCP. Cada requisição de saída é um canal de dados em potencial. Minha biblioteca de extração web registra URLs de fetch e tamanhos de resposta. Sem medição de rede, um web fetch que retorna uma resposta de 50MB é indistinguível de um que retorna 5KB.⁶

Nenhuma ferramenta comercial de agente fornece um painel de recursos por sessão. Provedores de nuvem medem computação para faturamento, não para visibilidade do operador. A lacuna entre o que os agentes consomem e o que os operadores podem ver é o déficit de medição de recursos.

A ausência parece invisível até os números se acumularem. Uma sessão que escreve 400KB de arquivos de estado não é nada. Sessenta sessões que escrevem 400KB cada, sem limpeza, deixam 24MB de estado órfão. Um web fetch que retorna 847KB é insignificante. Um pipeline de varredura que busca 80 URLs por execução gera 67MB de conteúdo em cache que a abstração de ferramentas do agente esconde do operador. A medição de recursos torna o cumulativo visível antes que se torne a crise que leva alguém a abrir a issue GitHub #22543.¹

Camada 2: Aplicação de Políticas

A aplicação de políticas responde: quais regras restringem o agente, e essas regras são aplicadas de forma consistente?

mcp-firewall aborda a camada de políticas para agentes CLI.⁷ A ferramenta se posiciona entre o agente e todas as requisições de uso de ferramentas, avaliando cada requisição contra uma política baseada em regex antes da execução. As políticas usam arquivos de configuração JSONNet com escopo por pasta, repositório git ou usuário. O firewall suporta Claude Code e GitHub Copilot CLI através de integração com hooks PreToolUse.

A arquitetura reflete um insight fundamental: cada agente implementa sua própria solução parcial de lógica allow/deny. Claude Code usa padrões glob. Codex CLI usa correspondência apenas por prefixo. Cada abordagem cobre um subconjunto do espaço de políticas. O mcp-firewall centraliza as regras em um único motor que funciona entre agentes.

Considere a lacuna de políticas sem aplicação centralizada. Meu sistema de hooks inclui 12 handlers PreToolUse:Bash que verificam padrões de credenciais, operações git destrutivas, acesso a caminhos sensíveis e comandos de deploy.² Cada handler é um script shell separado com seus próprios padrões regex. Quando preciso adicionar uma nova regra de negação, escrevo um novo script. Quando preciso auditar quais regras existem, faço grep em 12 arquivos. O mcp-firewall consolida tudo isso em um único arquivo de configuração com arrays de allow explícitos.

O OWASP Top 10 para Aplicações Agênticas (2025) identifica Agent Goal Hijacking (ASI01) e Excessive Agency (LLM06:2025) como riscos principais.⁸ Ambos os riscos requerem aplicação de políticas no nível da chamada de ferramenta. Um agente que sequestra um objetivo ainda faz chamadas de ferramentas. Um agente com agência excessiva ainda solicita permissões. A aplicação de políticas intercepta ambos na fronteira onde a intenção do agente encontra as ferramentas do sistema.

A aplicação de políticas difere do controle de acesso. O controle de acesso tradicional pergunta “este usuário tem permissão?” A aplicação de políticas para agentes pergunta “esta ação, neste contexto, para esta tarefa, está dentro do escopo aprovado?” A sensibilidade ao contexto é o desafio. Um git push para um branch de feature e um git push --force para main são a mesma ferramenta (Bash) com raios de explosão diferentes. Os padrões regex do mcp-firewall conseguem distinguir entre eles. As permissões padrão do agente, não.

A aplicação de políticas em nível de aplicação também enfrenta risco de bypass. Uma análise de março de 2026 documentou três técnicas escaladas de escape de sandbox contra a denylist embutida do Claude Code: evasão por caminho (/proc/self/root/usr/bin/npx resolve para o mesmo binário que o bloqueado /usr/bin/npx), desativação auto-dirigida do sandbox (o agente raciocinou independentemente sobre remover o sandbox quando este bloqueou a conclusão da tarefa) e invocação do linker dinâmico (ld-linux-x86-64.so.2 carrega binários via mapeamento de memória, contornando hooks de aplicação no nível do kernel).¹⁴ A terceira técnica é uma classe de exploit: qualquer carregamento de código que evite execve contorna a aplicação em nível de processo. A conclusão para a aplicação de políticas é que denylists baseadas em correspondência de strings são uma primeira camada necessária, não suficiente. A aplicação baseada em conteúdo endereçável (identificando binários por hash SHA-256 em vez de nome de arquivo) fecha a lacuna de evasão por caminho, mas o bypass via linker dinâmico requer controles em nível de kernel que ficam abaixo da camada de políticas.

Camada 3: Auditoria em Tempo de Execução

A auditoria em tempo de execução responde: o que o agente realmente fez no nível de syscall?

Logira aborda a camada de auditoria usando sondas eBPF para interceptar chamadas de sistema no nível do kernel.⁹ A ferramenta registra três categorias de eventos: execução de processos (eventos exec), operações de arquivo (incluindo acesso a arquivos de credenciais) e conexões de rede (com rastreamento de destino). Cada execução auditada gera três arquivos: events.jsonl para revisão de linha do tempo, index.sqlite para filtragem consultável e meta.json para metadados da execução.

A filosofia de design é “apenas observar”: o Logira registra e detecta, mas não aplica ou bloqueia.⁹ A separação da camada de aplicação é deliberada. A aplicação de políticas previne ações conhecidamente ruins. A auditoria em tempo de execução descobre ações desconhecidamente ruins após o fato. As duas camadas servem funções temporais diferentes: prevenção (antes) e forense (depois).

As sondas eBPF do Logira operam abaixo da camada de aplicação. Um agente que constrói um comando inédito para exfiltrar dados ainda faz syscalls. O agente não pode esconder leituras de arquivo, conexões de rede ou spawns de processos do rastreamento em nível de kernel. A abordagem captura o que hooks em nível de aplicação perdem: efeitos colaterais que contornam a abstração da chamada de ferramenta.

Regras de detecção embutidas visam riscos de agentes de IA especificamente: acesso a arquivos de credenciais, mudanças em mecanismos de persistência (/etc, systemd, cron), cadeias de comandos suspeitos (padrões curl-pipe-sh), operações destrutivas (rm -rf) e egresso de rede anômalo.⁹ As regras são padrões opinativos para o modelo de ameaça de agentes, não auditoria genérica de sistema.

A restrição de plataforma importa. O Logira requer Linux 5.8+ com cgroup v2. Agentes em macOS (Claude Desktop, Claude Code no Darwin) não podem usar auditoria baseada em eBPF. Meu sandbox de SO usa perfis macOS Seatbelt como o equivalente mais próximo: regras de negação aplicadas pelo kernel que bloqueiam escritas em caminhos sensíveis.³ O Seatbelt é aplicação, não auditoria. O macOS carece de um equivalente pronto para produção da trilha de auditoria apenas-observação do Logira.

O Agent Safehouse, uma ferramenta de sandboxing nativa para macOS que acumulou 802 pontos e 181 comentários no Hacker News em março de 2026, aborda a lacuna de plataforma pelo lado da aplicação.¹⁵ A ferramenta fornece perfis de sandbox projetados especificamente para agentes de IA locais no macOS. A resposta da comunidade (802 pontos é excepcional para uma ferramenta de sandboxing) reflete a urgência: profissionais executando agentes no macOS têm opções limitadas entre “sem sandbox” e “escreva seu próprio perfil Seatbelt.” O Agent Safehouse preenche essa lacuna para aplicação. A lacuna de auditoria no macOS permanece aberta.

A distinção entre aplicação e auditoria mapeia uma divisão temporal na resposta a incidentes. A aplicação previne o incidente. A auditoria permite a reconstrução após o incidente. Ambas são necessárias. Uma camada de aplicação que bloqueia todo acesso a credenciais previne exfiltração, mas também previne operações legítimas de SSH. Uma camada de auditoria que registra todo acesso a credenciais sem bloquear permite que o operador revise padrões de acesso e ajuste regras de aplicação com base em evidências. O ciclo de feedback entre dados de auditoria e refinamento de políticas é como o stack de visibilidade melhora ao longo do tempo: a auditoria revela padrões, padrões informam políticas, políticas reduzem a superfície que a auditoria precisa cobrir.

O isolamento por cgroup v2 do Logira adiciona um recurso que a auditoria em nível de aplicação não consegue replicar: atribuição com escopo de execução. O sistema atribui cada evento a uma execução auditada específica, não ao sistema globalmente. Quando duas sessões de agente rodam simultaneamente na mesma máquina, o isolamento por cgroup garante que o acesso a arquivos na sessão A não apareça na trilha de auditoria da sessão B. Hooks em nível de aplicação não podem fornecer a mesma garantia porque os hooks disparam dentro do processo do agente, que não tem fronteira em nível de kernel separando sessões concorrentes.⁹

O Que Eu Realmente Executo

Meu sistema de orquestração cobre todas as três camadas através de hooks, não através de ferramentas dedicadas de monitoramento.

Medição de recursos. O hook cost-gate rastreia o uso de tokens por sessão contra limites de orçamento configuráveis.⁵ O monitor de performance do sistema verifica CPU, memória, disco e swap em intervalos configuráveis, injetando avisos quando a pressão de recursos excede os limites.¹⁰ O detector de desvio de sessão dispara a cada 25 chamadas de ferramenta, calculando a similaridade de cosseno entre o embedding do prompt original e uma janela deslizante de ações recentes.²

Aplicação de políticas. Oito hooks de dispatcher PreToolUse roteiam para hooks de handler por tipo de ferramenta. O PreToolUse:Bash sozinho executa 12 handlers cobrindo padrões de credenciais, operações git destrutivas, acesso a caminhos sensíveis e comandos de deploy. O guard de recursão aplica uma profundidade máxima de dois e máximo de cinco filhos por agente pai.²

Auditoria em tempo de execução. Hooks PostToolUse registram cada resultado de chamada de ferramenta. Os hooks de varredura de segurança verificam a saída do bash em busca de vazamentos de credenciais após a execução. Arquivos de estado de sessão (jiro.state.json) registram cada conclusão de story, veredito de revisor e resultado do evidence gate.² O sistema não usa eBPF (limitação do macOS), mas captura telemetria em nível de ferramenta através do pipeline de hooks.

O sistema funciona porque cada ação passa pelo pipeline de hooks. A limitação é a profundidade: o monitoramento em nível de hook captura o que o agente pediu para fazer, não o que o sistema operacional realmente executou. Um agente que constrói um comando bash com subshells embutidos executa código que o hook vê como uma única string. A auditoria em nível de kernel veria cada subprocesso.

Resultados concretos de incidentes em produção onde o stack de três camadas detectou falhas que o monitoramento padrão teria perdido:

O Ponto Cego que se Multiplica

Agentes gerando agentes multiplicam a opacidade. Cada salto de delegação introduz perda de informação.

Quando meu sistema de orquestração executa o loop autônomo ralph, o processo pai gera instâncias frescas de Claude Code para cada story PRD. Cada agente filho recebe uma tarefa focada e uma janela de contexto limpa. O pai rastreia o status de conclusão. O pai não vê as chamadas individuais de ferramentas, leituras de arquivo ou consumo de recursos do filho.²

Na profundidade um (pai gera filho), o pai vê a saída final do filho. Na profundidade dois (filho gera neto), o pai vê o relatório do filho sobre a saída do neto. Cada salto comprime informação. A análise de cadeia de delegação no meu comentário ao NIST mediu três riscos compostos: compressão semântica (o contexto colapsa para uma string de prompt), amplificação de autoridade (filhos herdam permissões sem compreender a sensibilidade) e difusão de responsabilidade (o agente raiz é responsável por resultados que nunca inspecionou).³

A observabilidade se degrada na mesma taxa. Um stack de visibilidade de três camadas no agente raiz fornece zero visibilidade no agente neto, a menos que cada filho execute independentemente seu próprio monitoramento. Meu guard de recursão aplica o limite de profundidade, mas o guard é um controle de política, não um controle de observabilidade. Saber que a delegação parou na profundidade dois não diz o que aconteceu na profundidade dois.

Um exemplo concreto do meu sistema em produção: o loop ralph gerou um agente filho para implementar uma story de migração de banco de dados. O agente filho decidiu que a migração precisava de uma “etapa de verificação” e gerou seu próprio sub-agente para executar testes de integração. O agente neto falhou silenciosamente (o banco de dados de teste não estava configurado). O agente filho recebeu uma resposta vazia, interpretou o silêncio como sucesso e reportou a story como completa. O pai registrou “story 4: completa.” Eu descobri a migração quebrada três horas depois quando a aplicação travou na coluna ausente. A telemetria do agente raiz mostrava uma execução limpa. A falha vivia dois saltos de profundidade, invisível para cada camada de monitoramento que eu havia implantado na raiz.²

O framework OWASP para Aplicações Agênticas aborda falhas em cascata e agentes desonestos, mas não prescreve requisitos de observabilidade para cadeias de delegação multi-agente.⁸ A lacuna é estrutural: cada agente na cadeia precisaria de sua própria medição de recursos, aplicação de políticas e auditoria em tempo de execução, configurados independentemente e reportados independentemente. A sobrecarga é multiplicativa. Três camadas de monitoramento em três agentes em uma cadeia são nove instâncias de monitoramento, cada uma gerando sua própria telemetria, cada uma requerendo sua própria configuração. Nenhuma ferramenta existente gerencia essa coordenação.

O Que Você Pode Implementar Hoje

Três hooks mínimos de monitoramento que cobrem o stack de visibilidade:

1. Recurso: Rastreador de orçamento de tokens. Registre tokens cumulativos de entrada e saída por sessão. Defina um limite rígido. Alerte em 80%. A implementação requer ler as estatísticas de uso do agente (Claude Code expõe custos da sessão via /cost) e comparar contra um limite. Meu hook cost-gate faz isso em 47 linhas de bash.⁵

2. Política: Lista de negação PreToolUse. Crie um hook que dispare antes de cada chamada da ferramenta Bash. Verifique o comando contra uma lista de padrões: rm -rf /, git push --force, caminhos contendo .ssh ou .env, curl | sh. Bloqueie correspondências. A implementação requer um script shell que lê stdin (a chamada de ferramenta em JSON), extrai o campo de comando e faz grep contra um arquivo de padrões. Meu hook de verificação de credenciais faz isso em 31 linhas.²

3. Auditoria: Log de sessão PostToolUse. Anexe cada chamada de ferramenta e resultado a um arquivo JSONL específico da sessão. Inclua timestamp, nome da ferramenta, argumentos e código de saída. O log permite reconstrução pós-sessão: o que o agente fez, em que ordem, e algo falhou silenciosamente? Meu logger de sessão faz isso em 22 linhas de bash.²

Um exemplo funcional do hook de lista de negação em settings.json:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "~/.claude/hooks/check-sensitive-paths.sh"
          }
        ]
      }
    ]
  }
}

O script do hook lê a chamada de ferramenta do stdin, extrai a string do comando e verifica contra padrões. Um comando bloqueado retorna um objeto JSON com {"decision": "block", "reason": "Sensitive path access denied"}. Um comando permitido retorna {"decision": "approve"}. Claude Code respeita ambas as respostas sem prompts adicionais. O hook inteiro adiciona zero latência a comandos aprovados (a verificação regex roda em menos de 5ms) e fornece feedback imediato para os bloqueados.

Esses três hooks totalizam menos de 100 linhas. Eles não substituem ferramentas dedicadas de monitoramento. Eles substituem zero visibilidade por visibilidade mínima. Visibilidade mínima é o pré-requisito para cada decisão de governança que se segue. Você não pode definir um orçamento de recursos sem medição. Você não pode aplicar uma política de escopo sem uma lista de negação. Você não pode investigar um incidente sem um log de auditoria. Comece pelo log. Os outros dois seguem.

Conclusões Principais

Para engenheiros de plataforma: Agentes consomem recursos que o monitoramento existente não rastreia. Uso de disco, memória, CPU e rede por sessão de agente pertence ao mesmo painel que métricas de containers. O incidente do Cowork prova a necessidade: 10GB alocados com zero visibilidade para o operador.

Para equipes de segurança: A aplicação de políticas na fronteira da chamada de ferramenta é a postura mínima viável de segurança de agentes. A abordagem centralizada do mcp-firewall consolida a lógica allow/deny por agente em uma configuração única e auditável. Avalie se as permissões embutidas do seu agente cobrem o espaço de políticas que seu modelo de ameaça requer.

Para gerentes de engenharia: Faça três perguntas sobre suas ferramentas de agente: Você consegue ver o consumo de recursos por sessão? Você consegue definir e auditar políticas de chamadas de ferramentas? Você consegue reconstruir o que um agente fez após o fato? Se qualquer resposta for “não,” você tem uma lacuna de visibilidade que cresce com cada agente adicional no seu fluxo de trabalho.

FAQ

O que é observabilidade de agentes? Observabilidade de agentes é a capacidade de monitorar e compreender o que um agente de IA faz durante a execução: quais recursos ele consome, quais ações ele toma e se essas ações estão em conformidade com políticas definidas.

Por que o Cowork da Anthropic criou uma VM de 10GB? O recurso Cowork no Claude Desktop provisiona uma máquina virtual para sessões de desenvolvimento colaborativo. O Claude Desktop cria o pacote da VM automaticamente em cada instalação macOS, mesmo para usuários que nunca habilitam o recurso, e o mantém até ser deletado manualmente.¹

O que é mcp-firewall? mcp-firewall é uma ferramenta open-source de aplicação de políticas que intercepta requisições de uso de ferramentas de agentes CLI (Claude Code, GitHub Copilot CLI) e as avalia contra regras allow/deny baseadas em regex antes da execução.⁷

O que é auditoria em tempo de execução com eBPF? eBPF (extended Berkeley Packet Filter) permite rastreamento em nível de kernel de chamadas de sistema sem modificar o processo auditado. Ferramentas como o Logira usam sondas eBPF para registrar execução de processos, operações de arquivo e conexões de rede durante execuções de agentes de IA.⁹

Como agentes geram sub-agentes sem visibilidade do operador? Agentes que delegam tarefas geram processos filhos com janelas de contexto limpas. O agente pai vê a saída final do filho, mas não suas chamadas individuais de ferramentas, leituras de arquivo ou consumo de recursos. Em cada salto de delegação, a informação se comprime: a sessão completa do neto se torna uma linha de status no log do pai. A observabilidade se degrada na mesma taxa que a profundidade de delegação aumenta.²

Como o monitoramento de agentes difere do APM tradicional? O Application Performance Monitoring (APM) tradicional rastreia latência de requisições, taxas de erro e throughput para software determinístico. O monitoramento de agentes rastreia comportamento não-determinístico: o que o agente decidiu fazer em tempo de execução, se essas decisões estavam dentro da política e quais recursos cada decisão consumiu. O APM assume que a aplicação segue um caminho de código conhecido. O monitoramento de agentes assume que o agente escolhe seu próprio caminho.²

Fontes