Incomplete Action Logging

Issue: Only Some Agent Actions Are Logged, Creating Blind Spots

Frequency: Very Common

Symptoms

• Gaps in action sequences during investigation
• Some tool calls logged, others missing
• Read operations not tracked
• Internal reasoning steps invisible
• Partial picture of agent behavior

Root Cause Logging is typically added to obvious action points like API calls and database writes, but agents perform many other actions: reading files, querying context, making internal decisions, retrying operations. These “invisible” actions aren’t logged, creating gaps in the action timeline that make debugging and auditing incomplete.

Example

Agent task: "Update customer address and send confirmation"

What was logged:
  10:30:01 - API call: GET /customer/123
  10:30:05 - API call: PUT /customer/123 {address: "..."}
  10:30:06 - API call: POST /email/send

Investigation question: "Why did update take 4 seconds?"

What actually happened (not logged):
  10:30:01 - GET customer data
  10:30:01 - Read address validation rules (NOT LOGGED)
  10:30:02 - Query geocoding service (NOT LOGGED)
  10:30:02 - Geocoding failed, retry (NOT LOGGED)
  10:30:03 - Geocoding retry 2 (NOT LOGGED)
  10:30:04 - Check fraud rules (NOT LOGGED)
  10:30:04 - Fraud check passed (NOT LOGGED)
  10:30:05 - PUT customer update
  10:30:05 - Generate email content (NOT LOGGED)
  10:30:06 - POST send email

Blind spots:
  - Geocoding service issues (potential SLA violation)
  - Fraud check logic (compliance requirement)
  - Email content generation (customer communication audit)

Key Statistics From Observability Research (2026):

• Average agent logs 30% of actual operations
• Read operations logged 10% as often as writes
• Retry logic almost never logged
• Internal tool calls frequently missed
• “What happened between X and Y?” - common question

Logging Gaps

Contributing Factors

• Focus on “important” actions only
• Performance concerns limit logging
• Read operations seem unimportant
• Internal operations not instrumented
• Logging added reactively, not by design

Test Scenario & Reproduction

Scenario Setup

• Deploy an agent handling “update customer address and send confirmation” tasks, with logging added only at the obvious external API call points (GET, PUT, POST) and no instrumentation on internal reads, validation checks, or retries
• The agent’s actual workflow includes address-validation-rule lookups, a geocoding service call with retry-on-failure logic, and a fraud-rule check, none of which are logged
• No time-gap detection flags unexplained latency between logged actions

Trigger Mechanism

1. A task triggers the full internal workflow: GET customer, read validation rules, query geocoding (fails, retries twice), check fraud rules, PUT update, generate email content, POST send email
2. Only the GET, PUT, and POST calls are logged; the validation-rule read, geocoding query and its two retries, and fraud check are all invisible
3. An investigator notices the PUT update happened 4 seconds after the GET, with no logged explanation for the delay
4. The investigator cannot determine whether the 4-second gap represents a geocoding SLA violation, a fraud-check delay, or something else entirely

Example Reproduction Steps

1. Logged trace:
   10:30:01 - GET /customer/123
   10:30:05 - PUT /customer/123 {address: "..."}
   10:30:06 - POST /email/send
2. Actual (unlogged) sequence: read validation rules (10:30:01),
   query geocoding (10:30:01, fails), retry geocoding (10:30:02),
   retry geocoding again (10:30:03), check fraud rules (10:30:04,
   passed), then the logged PUT at 10:30:05
3. Investigator asks: "Why did the update take 4 seconds?"
4. Query the log for the gap between 10:30:01 and 10:30:05 -> no
   entries exist, gap is unexplained
5. Measure action_logging_coverage_rate for this task -> approximately
   30% of actual operations logged (3 of 10 steps)

Expected Failure State

The investigator cannot determine whether the 4-second delay was caused by a geocoding service SLA violation or a fraud-check bottleneck, because two full retry attempts and a compliance-relevant fraud check are completely invisible in the log, and both represent real operational and compliance concerns left undiagnosed. A correctly instrumented system logs every internal tool call, retry, and validation check through a common middleware layer, so the gap between GET and PUT is fully explained by geocoding-retry and fraud-check entries in the trace.

Mitigation Strategies

Prevention

1. Automatic instrumentation wrapping every tool/service call by default: Wrap all tool invocations — including reads, internal validation checks, and retries — with logging middleware at the framework level, rather than logging being added ad hoc to “obvious” points like the PUT and POST calls in the example while the geocoding query, retries, and fraud check go unrecorded. Trade-off: comprehensive default logging increases storage volume and can add latency if implemented synchronously.
2. Async, non-blocking logging to remove the performance objection: Since “performance concerns limit logging” is named as a contributing factor, implement logging as a non-blocking async write so completeness doesn’t have to be traded off against latency — removing the excuse for skipping retry or validation-check logging. Trade-off: async logging risks losing log entries on process crash between the action and the flush, requiring a durable buffer.
3. Debug-full / production-sampled logging tiers: Log every action type at full detail in non-production and staging environments, and use targeted (not blanket) sampling in production that still captures 100% of retries, validation failures, and internal tool calls even while sampling routine reads — since retries and validation checks are named as “High” importance despite being logged only 10-15% of the time today. Trade-off: differential sampling by action type adds configuration complexity versus a single global sampling rate.

Detection & Response

1. Time-gap detection in action sequences: Automatically flag when the elapsed time between two consecutive logged actions is large relative to what a fully-instrumented sequence would show (the example’s unexplained 4-second gap between GET and PUT), signaling missing intermediate actions even without knowing what they were.
2. Expected-log-entry-sequence validation: For known task types (e.g., “update address and send confirmation”), maintain an expected set of sub-actions (validation, geocoding, fraud check) and alert when a session’s logged trace is missing entries from that expected set, rather than only noticing gaps informally during an investigation.
3. Action-type logging-coverage audit: Periodically measure what fraction of each action type (reads, retries, validation checks, reasoning steps) is actually captured in logs versus performed, directly quantifying the gap between the “30% of actual operations” baseline and a target coverage level.

Architecture Patterns

1. Uniform action-logging middleware across all tool types: Build a single instrumentation layer that every tool call — read or write, internal or external, retry or first attempt — passes through, tagging each entry with action type for later filtering, rather than leaving reads and internal calls to be instrumented individually and inconsistently. Deployment consideration: requires retrofitting existing tools that weren’t built with a common calling convention, which can be substantial work in a mature codebase.
2. Structured action classification schema: Tag every logged action with a type (external-write, external-read, internal-tool-call, retry, validation-check, reasoning-step) so investigations can filter and reconstruct the full sequence (as the example’s hidden geocoding-retry-fraud-check chain would require) rather than parsing free-text logs. Deployment consideration: needs a shared taxonomy enforced across all agent components, including any third-party tools integrated into the pipeline.
3. Automated gap-detection alerting on incomplete sequences: Build a monitoring rule that compares actual logged sequences against the expected action-type distribution for a task type and fires when key categories (retries, validation, reasoning) are absent, rather than relying on a human investigator to notice the blind spot after the fact. Deployment consideration: requires maintaining per-task-type expected-sequence definitions, which need updating as agent workflows evolve.

Metrics

1. action_logging_coverage_rate: % of actual agent operations that are logged, broken out by action type (reads, writes, retries, validation, reasoning); target > 90% overall, > 80% even for lowest-priority categories; alert if overall coverage < 50% (current baseline is ~30%, the failure state to avoid).
2. retry_logging_rate: % of retry attempts that are logged; target > 90%; alert if < 30% (matches the example’s fully-unlogged geocoding retries).
3. unexplained_time_gap_rate: % of task executions with a time gap between logged actions exceeding an expected threshold with no corresponding log entry; target < 5%; alert if > 20%.
4. expected_sequence_completeness_rate: % of task executions where all expected sub-action types for that task category appear in the log; target > 90%; alert if < 60%.

Alerts

1. Logging Coverage Below Floor (P2): Condition — action_logging_coverage_rate for any high-importance category (retries, validation, reasoning) drops below 30%. Action: prioritize instrumentation work for that category; treat recent investigations relying on that category’s logs as potentially incomplete.
2. Unexplained Time Gap Spike (P2): Condition — unexplained_time_gap_rate exceeds 20% for a task type. Action: audit the task’s tool-call chain for unlogged internal operations (validation, geocoding, retries) and add instrumentation to close the gap.
3. Expected Sequence Incomplete (P3): Condition — expected_sequence_completeness_rate falls below 60% for a task category. Action: review and update the expected-sequence definition and the underlying instrumentation for that task type.

References

• Braintrust: Agent Observability Guide 2026 - Comprehensive logging
• LinkedIn: Silent Failures of Production AI - Logging gaps
• Arize: Why AI Agents Break - Observability requirements
• AWS: 3 Agent Failure Modes - Action tracking