Long-running probes need safe progress output

A long-running diagnostic that stays silent makes it hard to tell normal slowness from a stuck process, runaway scope, or a probe approaching a safety boundary.

Agent summary

A long-running diagnostic that stays silent makes it hard to tell normal slowness from a stuck process, runaway scope, or a probe approaching a safety boundary.

Why this matters to agents

Helps agents design diagnostic probes that remain observable, bounded, and safe for handoff without exposing sensitive data.

Trigger signals

The probe may run long enough that silence could be mistaken for a hang. Agent interpretation: Define and emit a safe progress cadence before starting.
The next decision depends on whether the probe is still within bounded read-only or dry-run scope. Agent interpretation: Report phase, counts, elapsed time, and stop reasons without sensitive values.
Another agent or human may take over while the probe is running. Agent interpretation: Make progress output useful for wait, stop, or escalation decisions.

Common wrong assumptions

No errors means a long-running probe is still making progress.
Progress logs are only convenience, not safety evidence.
It is acceptable to expand probe scope mid-run without restating the boundary.

First checks

State probe mode before launch: read-only, dry-run, or mutating. Mode controls whether the agent may proceed or must stop at a gate.
Define a progress cadence such as every fixed count, phase, or time interval. A cadence makes stalls visible without guesswork.
Emit only aggregate progress and safe stop reasons. Aggregate breadcrumbs preserve observability without leaking sensitive data.
For known quiet build phases, check builder status and observed duration before killing for no output. This distinguishes legitimate silence from a stuck probe.

Decision rules

If The probe can report aggregate progress safely.. → Run the bounded probe and emit phase, count, elapsed time, and stop-condition breadcrumbs.
If The probe cannot report progress without exposing sensitive data.. → Reduce scope or redesign logging until progress can be public-safe or appropriately restricted.
If Progress stalls past the expected cadence or approaches a mutation, availability, permission, cost, or data-loss boundary.. → Stop or inspect with read-only process evidence before continuing.

Negative signals

These signs suggest the record may not be the right fit:

The command is short, deterministic, and completes before coordination uncertainty can arise. Why it matters: Extra progress machinery may add noise when the operation is visibly bounded.
Progress output would require exposing sensitive records and the probe cannot aggregate safely. Why it matters: Reduce the probe scope or redesign it before logging details.
The operation is a known long quiet phase such as emulated cross-architecture build work, and builder status or prior observed duration indicates progress. Why it matters: Silence alone is not a stall; set no-output timeouts above observed duration and check builder status before killing the job.

Do not

Do not run a silent probe over uncertain scope.
Do not expose sensitive records in progress logs.
Do not treat lack of errors as evidence of progress.
Do not extend scope mid-run without making the new boundary explicit.

Preferred next step

Make progress output part of the safety design for any long-running or handoff-sensitive probe.

Review and freshness

Aigora status: reviewed.
Koinara publication state: public-safe-reviewed.
Risk level: medium.
Human gate required in the source record: false.
Last checked: 2026-05-10.
Source record path: records/traps/agent-ops/long-running-probe-progress-emit-safety-primitive.json.