A Anatomia de uma Ação de Agente de IA no Ambiente Empresarial

Principais observações

Três solicitações reais ao modelo local retornaram, cada uma, uma proposta elegível de create_artifact com o texto exato LAB-MAIN-ONLY. Cada proposta alimentou três replays dependentes em diretórios novos. São três submissões ao modelo e nove casos de replay, não nove decisões do modelo ou ensaios independentes.

Todos os casos começaram com o destino vazio nas duas amostras anteriores à intervenção. Nos casos de supressão, o arquivo estava legível mesmo sem confirmação para o caller. Nos casos de retenção, o caller também não tinha confirmação, mas o worker não havia sido iniciado e o arquivo estava ausente do destino amostrado.

Essa comparação registra a consequência de um desenho controlado. Reter o envio e suprimir um retorno foram intervenções programadas. Não são falhas recém-descobertas, timeouts espontâneos ou comportamentos escolhidos pelo modelo.

Acompanhe uma proposta em três casos

A primeira resposta do modelo continha o nome de função create_artifact e dois argumentos: artifact_id era lab-note, e text era LAB-MAIN-ONLY. A proposta normalizada tornou-se a entrada de case-01, case-02 e case-03. A aplicação atribuiu o nome fixo do arquivo de destino; o modelo não podia fornecer um caminho no sistema de arquivos.

Case-01, reter. O dispatcher registrou dispatch_retained e não iniciou um worker. O caller registrou confirmation_unavailable com tool_result: unknown. O observador do destino informou, em seguida, que o arquivo estava ausente nas duas amostras. Não há registro de recebimento pelo worker nem arquivo de retorno do worker para esse caso. A ausência de registro do worker é coerente com a retenção documentada, não evidência de uma falha de gravação.

Case-02, entregar. Um processo worker separado registrou proposal_received com o hash da entrada normalizada. Depois, registrou o retorno da gravação de 13 bytes e produziu um resultado created. O adaptador coletou esse resultado e o entregou à etapa caller. Um observador separado leu os bytes exatos do conteúdo proposto nas duas amostras posteriores.

Case-03, suprimir confirmação. O worker recebeu os mesmos bytes da proposta em outro diretório novo. Registrou a operação de arquivo e retornou um resultado. Depois de coletar esse retorno, o adaptador o suprimiu deliberadamente. O caller registrou o mesmo estado de confirmação indisponível de case-01. Ainda assim, o observador separado leu os 13 bytes exatos do conteúdo proposto nas duas amostras.

Dispatcher, adaptador e caller são etapas instrumentadas de um único orquestrador. Não são três serviços independentes. O worker e o observador são processos separados. Nenhum resultado de ferramenta foi enviado de volta ao modelo, e o experimento não examinou como um modelo reage à falta de confirmação ou se repete uma ação.

Método

Pergunta de pesquisa.

Identificar quais registros distinguem uma operação proposta, a execução pelo worker e o estado amostrado no destino quando a confirmação não está disponível para o caller local.

Fonte de dados e ambiente.

A fonte é a coorte main-v1, coletada em um único ambiente local de laboratório com macOS arm64, Python 3.14.6, Ollama 0.33.2 e o modelo qwen3.5:9b já instalado. Nenhuma organização cliente ou sessão de uso empresarial foi amostrada. O manifesto do modelo, seus quatro blobs referenciados, o binário do runtime, o plano e a instrumentação foram identificados por hashes. A tag do modelo, sozinha, não identifica o ambiente necessário à reprodução.

Período de observação e data de análise.

A coleta ocorreu em 6 de setembro de 2026, das 19:37:45.807894 às 19:38:54.408381 UTC. Os timestamps de solicitações, processos e observações foram preservados separadamente. A análise e a revisão editorial dos dados ocorreram em 6 de setembro de 2026. Essas são datas de coleta e análise, não uma data de publicação inferida.

Unidades e amostragem.

O protocolo fixou três submissões à API, cada uma com bytes de solicitação idênticos e uma nova lista de mensagens. As três solicitações foram tentadas, e cada resposta foi estruturalmente elegível; nenhuma solicitação foi substituída. Cada uma alimentou, nessa ordem, os replays de retenção, entrega e supressão de confirmação, resultando em nove casos concluídos e seis registros de recebimento pelo worker. A calibração e os testes com fixtures sintéticas estão excluídos dessas contagens. Os replays dependem da proposta de origem; solicitações repetidas sob essas configurações não estabelecem independência estatística.

Configuração da solicitação.

A instrução do usuário pediu o texto sintético exato LAB-MAIN-ONLY. A ferramenta aceitava apenas o identificador fixo do artefato e texto de tamanho limitado, sem argumento de caminho ou shell. As configurações de geração solicitadas foram temperatura zero, seed 1701, 2.048 tokens de contexto, 128 tokens de saída, quatro threads de CPU e a opção thinking desativada. O registro do modelo carregado informou uso de VRAM igual a zero e contexto de 2.048 tokens. Essas configurações descrevem a coleta; não constituem uma comparação de desempenho.

Elegibilidade e normalização.

Um replay exigia HTTP 200, JSON válido, resposta concluída com done: true e done_reason: stop, e exatamente uma chamada válida da função esperada. Respostas truncadas, campos inesperados, argumentos inválidos ou múltiplas chamadas eram inelegíveis. O coletor extraiu o nome da função e os argumentos e os codificou em JSON canônico UTF-8, removendo apenas metadados da API previstos no contrato. Não corrigiu valores. A correspondência exata com o texto solicitado foi verificada separadamente da elegibilidade estrutural; ambas foram observadas nessas três respostas.

Definições.

Uma solicitação ao modelo é uma submissão à API. Uma proposta é o nome da função e os argumentos retornados. Um replay aplica essa proposta sob uma condição escolhida pelo laboratório. Recebimento pelo executor significa que o próprio worker registrou o recebimento de uma entrada cujo hash corresponde ao da proposta normalizada. Confirmação do caller significa que a etapa caller local recebeu o retorno coletado do worker. Observação do destino significa que o observador separado amostrou o arquivo nomeado; ela não é inferida de uma mensagem de sucesso.

Procedimento de observação.

Cada caso usou um diretório de destino novo e processos observadores separados, com acesso somente de leitura, antes do envio e depois da execução pelo worker ou do caminho de retenção. Cada observador coletou uma amostra na abertura e outra no fim de uma janela solicitada de 100 ms. As nove durações medidas das janelas posteriores variaram de 100,872 a 105,603125 ms. O observador recebeu o destino e a duração solicitada, não a condição, a proposta, os bytes esperados, o retorno do worker ou o estado do caller. A comparação com os bytes do conteúdo proposto ocorreu depois da coleta bruta e do encerramento dos processos.

Execução e contenção.

O worker revalidou a entrada e só podia gravar o arquivo fixo no destino atribuído a ele. Os perfis do worker e do observador negavam operações de rede; o observador não tinha permissão de gravação de arquivos. O servidor do modelo iniciado para a coleta usou a política de processo revisada, que negava operações de rede externa e permitia loopback. Eram restrições de processo com escopo definido, não isolamento completo do host. Limites de duração, saída e memória amostrada delimitaram a coleta. Os registros de encerramento mostram que o grupo de processos desse servidor terminou e sua porta foi fechada.

Exclusões e resultados incompletos.

A calibração anterior avaliou se a stack local conseguia emitir a proposta delimitada; não executou ferramenta alguma. Os testes com fixtures validaram a instrumentação usando entradas sintéticas. Nenhum dos dois entra no denominador principal. O protocolo principal preservou categorias distintas para erros de transporte, respostas incompletas, propostas inelegíveis e solicitações não tentadas, em vez de corrigi-las ou substituí-las. Não houve substituição desse tipo nem solicitação não tentada nesta coleta. A supressão deliberada não foi um erro de transporte.

Tratamento de privacidade.

As entradas e o conteúdo dos arquivos eram sintéticos. Os registros usam caminhos relativos e omitem nomes de host e de usuário, caminhos absolutos do diretório pessoal, identificadores da máquina e dumps do ambiente. Os diagnósticos do servidor são extratos delimitados, com caminhos pessoais ocultados, não uma exportação inalterada do log do servidor. Pesos do modelo, código privado de produto, credenciais e registros de clientes não fazem parte das evidências apresentadas aqui.

Integridade e limites.

Respostas brutas, propostas normalizadas, eventos por origem, bytes de retorno, observações e snapshots da instrumentação permanecem distintos. As somas de verificação da coleta abrangem 167 arquivos e foram verificadas durante a revisão. Hashes ajudam a relacionar bytes registrados que não foram alterados; não tornam toda afirmação verdadeira nem comprovam armazenamento inviolável. Os demais limites de interpretação estão descritos abaixo.

Localize os registros de apoio

As referências desta seção são relativas à coleta main-v1. Os registros brutos contêm as evidências; o resumo derivado é uma visualização de conveniência.

Baixe a tabela de casos (CSV) para obter um resumo dos nove replays em formato legível por máquina, ou baixe o pacote de evidências do laboratório (ZIP) para examinar os registros de origem e o método congelado. A tabela é derivada da coleta; não substitui os registros brutos.

Os três grupos de solicitações são inferences/request-01/, inferences/request-02/ e inferences/request-03/. Cada um contém request.raw.json, response.raw.json, request-result.json e proposal.json. O registro de extração conecta o hash da resposta à proposta normalizada. Request-01 alimenta os casos 01–03, request-02 alimenta 04–06 e request-03 alimenta 07–09.

Para cada identificador na tabela de observações, use o diretório correspondente, como cases/case-03/. case.json identifica a condição deliberada, a resposta de origem, o hash da proposta e o destino. dispatcher.events.jsonl registra a retenção ou o tratamento dos processos. caller.events.jsonl registra o recebimento pelo caller ou a falta de confirmação. before.stdout.raw.jsonl e after.stdout.raw.jsonl contêm as duas observações de cada janela, incluindo a duração medida.

Nos casos executados 02, 03, 05, 06, 08 e 09, worker.stdout.raw.jsonl registra recebimento, gravação e retorno; worker-return.raw.json preserva o resultado coletado. adapter.events.jsonl distingue entrega de supressão deliberada. Apenas os casos de entrega 02, 05 e 08 têm caller-message.raw.json. Os casos de retenção não têm arquivo de worker a citar.

Os seis arquivos de destino observados contêm o texto UTF-8 LAB-MAIN-ONLY, sem uma quebra de linha ao final. O SHA-256 de seu conteúdo é 28533326d0be4e57a39d65226935b80e21dbd0b6e130a3e5cd83bc3f7abca2ba. A proposta tem outro hash porque inclui o nome da função e a estrutura dos argumentos, não apenas o conteúdo do destino.

MAIN_PROTOCOL.md apresenta o método congelado; frozen-plan.json identifica a solicitação revisada e o pacote de fontes. environment.json, loaded-models.raw.json e server-lifecycle.json descrevem o ambiente registrado e o encerramento. checksums.json identifica os arquivos coletados. A função de cada um deve permanecer separada das interpretações derivadas desses registros.

O que este exemplo sustenta

O registro do caller, sozinho, não distingue case-01 de case-03 pelo estado de confirmação: ambos informam o resultado como desconhecido. Os demais registros resolvem perguntas diferentes. O dispatcher identifica a retenção deliberada em case-01. Em case-03, o worker registra o recebimento e seu retorno, o adaptador registra a supressão e o observador do destino lê os bytes esperados.

Por isso, a ação do agente e a mensagem que descreve seu resultado precisam ser tratadas separadamente. A falta de confirmação é uma condição em um ponto de comunicação do resultado. Não é, por si só, uma observação do destino. Da mesma forma, uma mensagem created continua sendo uma declaração do worker, mesmo quando uma leitura posterior do destino concorda com ela.

A análise sobre evidência de auditoria e log de prompt acompanha o retorno entregue e seus hashes para distinguir um relato copiado de uma nova observação do destino.

Para uma investigação, a próxima pergunta útil é qual fonte pode esclarecer o fato que falta. Neste laboratório, essa fonte estava disponível nos registros do worker, do adaptador e do destino. Uma implementação empresarial precisaria estabelecer suas próprias fontes, cobertura, autoridade e relações. O guia de trilha de auditoria trata dessas questões de desenho sem presumir que a organização deste laboratório seja uma arquitetura empresarial.

Limitações

Um ambiente, uma ferramenta, bytes de solicitação idênticos, configurações fixas e replays dependentes não permitem estimar confiabilidade, prevalência ou o comportamento de outros modelos e aplicações. O laboratório escolheu a retenção e a supressão. Observar esses ramos escolhidos não é evidência de que qualquer uma dessas condições ocorra com determinada frequência em produção.

O fluxo termina no caller local. Não contém ciclo de retorno ao modelo, sistema de identidade empresarial, mecanismo de políticas, decisão de aprovação ou integração KonaSense. A retenção é uma intervenção do programa de laboratório, não uma negação de política medida. Nada aqui comprova aplicação de controles de produto, resultado de governança ou reação do modelo a um resultado de execução.

O observador coletou duas amostras em cada janela. Não monitorou o arquivo continuamente, não examinou todos os locais do sistema de arquivos nem estabeleceu que os bytes persistiram além do período observado. O retorno de fsync do worker não é um teste de durabilidade após perda de energia. Um arquivo ausente em um diretório amostrado não prova que nenhum outro efeito ocorreu em qualquer lugar.

Processos separados para worker e observador reduzem o acoplamento entre execução e relato do destino, mas ambos pertencem ao mesmo pacote de laboratório. Não constituem validação independente por outra organização. Proximidade de timestamps, sozinha, não é tratada como prova causal; a proveniência dos casos, as referências de entrada e as condições deliberadamente controladas explicam a comparação registrada dentro desse fluxo limitado.

Outras observações controladas ou operacionais exigiriam pergunta, método e evidências próprios. Esta coleta estabelece um exemplo rastreável de como a confirmação e o estado no destino podem diferir, dentro das intervenções e dos limites de observação descritos aqui.