The Anatomy of an Enterprise AI Agent Action

Key observations

Three actual requests to the local model each returned one eligible create_artifact proposal containing the exact text LAB-MAIN-ONLY. Each proposal supplied three dependent replays in fresh directories. These are three model submissions and nine replay cases, not nine model decisions or independent trials.

Every case began with an empty destination in both pre-observation samples. In the suppression cases, the file was readable even though the caller had no confirmation. In the retention cases, the caller likewise had no confirmation, but the worker had not started and the file was absent from the sampled destination.

This comparison records the consequence of a controlled design. Retaining dispatch and suppressing a return were programmed interventions. They are not newly discovered failures, spontaneous timeouts, or behavior chosen by the model.

Follow one proposal through three cases

The first model response contained the function name create_artifact and two arguments: artifact_id was lab-note, and text was LAB-MAIN-ONLY. Its normalized proposal became the input to case-01, case-02, and case-03. The application assigned the fixed destination filename; the model could not supply a filesystem path.

Case-01, retain. The dispatcher recorded dispatch_retained and did not start a worker. The caller recorded confirmation_unavailable with tool_result: unknown. The subsequent destination observer reported the file missing in both samples. There is no worker receipt or worker-return file for this case. An absent worker record is consistent with the recorded retention, not evidence of a failed file write.

Case-02, deliver. A separate worker process recorded proposal_received with the hash of the normalized input. It then recorded a file-write return for 13 bytes and produced a created result. The adapter collected that result and delivered it to the caller stage. A separate observer read the exact proposed bytes in both post-observation samples.

Case-03, suppress confirmation. The worker received the same proposal bytes in another fresh directory. It recorded the file operation and returned a result. After collecting that return, the adapter deliberately withheld it. The caller recorded the same confirmation-unavailable state as case-01. The separate observer nevertheless read the exact proposed 13 bytes in both samples.

Dispatcher, adapter, and caller are instrumented stages of one orchestrator. They are not three independent services. The worker and observer are separate processes. No tool result was sent back to the model, and the experiment did not examine how a model reacts to missing confirmation or whether it retries an action.

Method

Research question.

Identify which records distinguish a proposed operation, worker execution, and sampled destination state when confirmation is unavailable to the local caller.

Data source and environment.

The source is cohort main-v1, collected in one local laboratory environment on macOS arm64 using Python 3.14.6, Ollama 0.33.2, and the already installed qwen3.5:9b model. No customer organizations or enterprise usage sessions were sampled. The model manifest, its four referenced blobs, runtime binary, plan, and instrumentation were identified by hashes. The model tag alone is not the reproduction identity.

Observation period and analysis date.

Collection ran on September 6, 2026, from 19:37:45.807894 to 19:38:54.408381 UTC. Request, process, and observation timestamps are retained separately. Analysis and editorial data review occurred on September 6, 2026. These are collection and analysis dates, not an inferred publication date.

Units and sampling.

The protocol fixed three API submissions, each with identical request bytes and a fresh message list. All three requests were attempted, and each response was structurally eligible; no request was replaced. Each supplied the ordered retain, deliver, and suppress-confirmation replays, yielding nine completed cases and six observed worker receipts. Calibration and synthetic fixture tests are excluded from these counts. Replays depend on their source proposal; repeated requests under these settings do not establish statistical independence.

Request configuration.

The user instruction requested the exact synthetic text LAB-MAIN-ONLY. The tool accepted only the fixed artifact identifier and bounded text, with no path or shell argument. Requested generation settings were temperature zero, seed 1701, 2,048 context tokens, 128 output tokens, four CPU threads, and thinking disabled. The loaded-model record reported zero VRAM usage and context length 2,048. These settings describe the collection; they are not a performance comparison.

Eligibility and normalization.

A replay required HTTP 200, valid JSON, a completed response with done: true and done_reason: stop, and exactly one valid expected function call. Truncated responses, unexpected fields, invalid arguments, or multiple calls were ineligible. The collector extracted the function name and arguments and encoded them as canonical UTF-8 JSON, removing only supported API metadata. It did not repair values. Exact agreement with the requested text was checked separately from structural eligibility; both were observed in these three responses.

Definitions.

A model request is an API submission. A proposal is the returned function name and arguments. A replay applies that proposal under a selected lab condition. Executor receipt means the worker itself recorded receiving input whose hash matches the normalized proposal. Caller confirmation means the local caller stage received the collected worker return. Destination observation means the separate observer sampled the named file; it is not inferred from a success message.

Observation procedure.

Each case used a fresh destination directory and separate read-only observer processes before dispatch and after the worker or retention path. Each observer sampled at the opening and end of a requested 100 ms window. The nine measured post-window durations ranged from 100.872 to 105.603125 ms. The observer received the destination and requested duration, not the condition, proposal, expected bytes, worker return, or caller state. Comparison with the proposed bytes occurred after raw collection and cleanup.

Execution and containment.

The worker revalidated its input and could write only the fixed file in its assigned destination. Worker and observer profiles denied network operations; the observer had no file-write permission. The owned model server used the reviewed process policy that denied external network operations while permitting loopback. These were scoped process restrictions, not complete host isolation. Lifetime, output, and sampled-memory limits bounded collection. Cleanup records show the owned server group exited and its port closed.

Exclusions and incomplete outcomes.

The earlier calibration assessed whether the local stack could emit the bounded proposal; it executed no tool. Fixture tests validated instrumentation using synthetic inputs. Neither enters the main denominator. The main protocol retained distinct categories for transport errors, incomplete responses, ineligible proposals, and unattempted requests rather than repairing or replacing them. No such replacement or unattempted request occurred in this collection. The deliberate suppression was not a transport error.

Privacy treatment.

Inputs and file content were synthetic. Records use relative paths and omit hostnames, usernames, absolute home paths, machine identifiers, and environment dumps. Server diagnostics are bounded extracts with personal paths redacted, not an unmodified server-log export. No model weights, private product code, credentials, or customer records form part of the evidence presented here.

Integrity and limits.

Raw responses, normalized proposals, per-origin events, return bytes, observations, and instrumentation snapshots remain distinct. The collection's checksums cover 167 files and were verified during review. Hashes help connect unchanged recorded bytes; they do not make every assertion true or establish tamper-proof storage. Additional interpretation limits are set out below.

Locate the supporting records

References here are relative to the main-v1 collection. The raw records carry the evidence; the derived summary is a convenience view.

Download the case table (CSV) for a machine-readable summary of the nine replays, or download the laboratory evidence package (ZIP) to inspect the source records and frozen method. The table is derived from the collection; it does not replace the raw records.

The three request groups are inferences/request-01/, inferences/request-02/, and inferences/request-03/. Each contains request.raw.json, response.raw.json, request-result.json, and proposal.json. The extraction record connects the response hash to the normalized proposal. Request-01 supplies cases 01–03, request-02 supplies 04–06, and request-03 supplies 07–09.

For each identifier in the observations table, use its corresponding directory, such as cases/case-03/. case.json identifies the deliberate condition, source response, proposal hash, and target. dispatcher.events.jsonl records retention or process handling. caller.events.jsonl records the caller's receipt or lack of confirmation. before.stdout.raw.jsonl and after.stdout.raw.jsonl contain the two observations in each window, including measured duration.

In executed cases 02, 03, 05, 06, 08, and 09, worker.stdout.raw.jsonl records receipt, write, and return; worker-return.raw.json preserves the collected result. adapter.events.jsonl distinguishes delivery from deliberate suppression. Only delivery cases 02, 05, and 08 have caller-message.raw.json. Retention cases have no worker file to cite.

The six observed destination files contain the UTF-8 text LAB-MAIN-ONLY, without a trailing newline. Their content SHA-256 is 28533326d0be4e57a39d65226935b80e21dbd0b6e130a3e5cd83bc3f7abca2ba. The proposal has a different hash because it includes the function name and argument structure, not just the destination content.

MAIN_PROTOCOL.md states the frozen method; frozen-plan.json identifies the reviewed request and source package. environment.json, loaded-models.raw.json, and server-lifecycle.json describe the recorded environment and cleanup. checksums.json identifies the collected files. Their roles should remain separate from any interpretation derived from them.

What this example supports

The caller record alone cannot distinguish case-01 from case-03 by its confirmation state: both report the result as unknown. The other records resolve different questions. The dispatcher identifies deliberate retention in case-01. In case-03, the worker records receipt and its return, the adapter records suppression, and the destination observer reads the expected bytes.

This is why the agent action and the message describing its result need separate treatment. A missing confirmation is a condition at a reporting boundary. It is not, by itself, a destination observation. Conversely, a created message remains a worker report even when a later destination read agrees with it.

The audit evidence and prompt log analysis follows the delivered return and its hashes to distinguish a copied report from a new observation of the destination.

For an investigation, the useful next question is which source can resolve the missing fact. In this lab, that source was available in the worker, adapter, and destination records. An enterprise implementation would need to establish its own sources, coverage, authority, and relationships. The audit-trail guide addresses those design questions without assuming this laboratory layout is an enterprise architecture.

Limitations

One environment, one tool, identical request bytes, fixed settings, and dependent replays cannot estimate reliability, prevalence, or the behavior of other models and applications. The laboratory selected retention and suppression. Observing those selected branches is not evidence that either condition occurs with any particular frequency in production.

The flow ends at the local caller. It contains no model feedback loop, enterprise identity system, policy engine, approval decision, or KonaSense integration. Retention is a harness intervention, not a measured policy denial. Nothing here establishes product enforcement, a governance outcome, or the model's reaction to an execution result.

The observer took two samples in each window. It did not continuously monitor the file, inspect every filesystem location, or establish that the bytes persisted beyond the observed period. The worker's fsync return is not a power-loss durability test. A missing file in a sampled directory is not proof that no other effect occurred anywhere.

Separate worker and observer processes reduce the coupling between execution and destination reporting, but both belong to the same laboratory package. They do not constitute independent validation by another organization. Timestamp proximity alone is not treated as causal proof; case provenance, input references, and deliberately controlled conditions explain the recorded comparison within this limited flow.

Further controlled or operational observations would require their own question, method, and evidence. This collection establishes a traceable example of how confirmation and destination state can differ, within the interventions and observation boundaries described here.