Recibos de execução para agentes de IA: um esquema minimalista

A maioria das discussões sobre agentes ainda se resumem a prompts, modelos ou estruturas.

Esses aspectos são importantes, mas a coisa que eu continuo desejando após a execução de um agente é muito mais simples:

O que este agente realmente fez, qual área ele tocou e que evidências eu tenho se eu precisar revisar ou reproduzir isso?

Acredito que sistemas de agentes precisam de recibos em tempo de execução.

O que quero dizer com um recibo

Um recibo em tempo de execução não é um rastreamento completo, e não é uma transcrição de chat.

Um rastreamento diz onde a execução foi.

Uma transcrição diz o que o modelo viu e disse.

Um recibo diz qual responsabilidade o agente assumiu.

A forma mínima com a qual estou experimentando se parece com isso:

{
  "receipt_id": "rcpt_01",
  "run_id": "run_01",
  "parent_run_id": null,
  "agent": {
    "name": "local-coding-agent",
    "version": "0.1.19"
  },
  "task": {
    "summary": "Atualizar a configuração de um aplicativo local",
    "scope": "apenas arquivos locais do repositório"
  },
  "tools": [
    {
      "name": "filesystem.write",
      "server": "local-tools",
      "action_class": "write",
      "target": "config/app.json",
      "decision": "allowed"
    }
  ],
  "checks": [
    {
      "name": "validação de configuração",
      "status": "passou"
    }
  ],
  "state_changes": [
    {
      "type": "atualização de arquivo",
      "target": "config/app.json"
    }
  ],
  "outcome": {
    "status": "completo",
    "recovery": null
  }
}

A parte importante não é este JSON exato. É a ideia de que cada execução deixa para trás um artefato operacional compacto.

Por que isso importa

Uma vez que os agentes usam ferramentas, servidores MCP, navegadores, terminais, filas e trabalhos em segundo plano, a resposta final não é suficiente.

Para produção ou mesmo fluxos de trabalho locais sérios, eu quero saber:

Quais chamadas de ferramenta foram somente leitura versus aquelas que mudaram o estado?
Quais verificações foram executadas e quais foram puladas?
Uma ação foi aprovada, bloqueada, reexecutada ou escalada?
O agente tocou arquivos locais, rede, estado do navegador ou uma API remota?
Posso comparar esta execução com a última execução bem-sucedida?
Um avaliador pode pontuar o comportamento operacional, não apenas a mensagem final?

Isso se torna especialmente útil quando você tem múltiplos agentes. O agente pai pode dizer "feito", mas o gráfico de recibos deve mostrar quais agentes filhos foram executados, o que cada um mudou e onde o sistema teve que se recuperar.

Onde isso se encaixa com rastreamentos

Eu não vejo recibos como um substituto para OpenTelemetry ou rastreamentos de framework.

Eles ficam ao lado deles.

Use rastreamentos para tempo, spans, reexecuções e forma de execução.

Use recibos para superfície de capacidade, decisões, mudanças de estado, aprovações e evidências de revisão.

A ponte útil são os IDs:

run_id
trace_id
span_id
tool_call_id
policy_decision_id
artifact_id

Isso permite que um painel transite entre "o que aconteceu tecnicamente?" e "o que o agente assumiu a responsabilidade?".

Por que estou construindo em torno disso

Estou trabalhando no Armorer como uma camada de operações local para agentes de IA, e no Armorer Guard como a camada de fronteira que pode raciocinar sobre ações e decisões de ferramentas.

A direção atual é:

Armorer rastreia execuções, trabalhos, estado de configuração e recuperação.
Guard produz decisões estruturadas em torno de limites de ação.
Recibos se tornam o artefato comum que conecta execuções de agentes, avaliações, aprovações e depuração.

A discussão no GitHub sobre a forma em evolução do recibo está aqui:

https://github.com/ArmorerLabs/Armorer/discussions/43

E o repositório está aqui:

https://github.com/ArmorerLabs/Armorer