Workflow: distinguish material agent progress from transport activity

[timigod]

What I am trying to do

I use Paseo to coordinate several long-running agents across more than one host. The coordinator needs to know whether the current continuation has produced useful work before deciding to wait, continue, recover, stop, or finish it.

Useful work can be a relevant read, file change, completed test, decision, or requested deliverable. A provider saying running, retrying, emitting commentary, or compacting context is activity, but it is not necessarily progress.

How I do it today

The coordinator reads agent status and then scans provider timelines/logs to infer:

• where the current real-user continuation began;
• whether useful output followed it;
• how many compactions happened after the last useful output; and
• whether the visible tail is trustworthy after a provider-history failure.

That logic is provider-sensitive and easy to get wrong. idle in particular is a transport state: it can mean completed, waiting for follow-up, failed before doing work, or compacted without making progress.

Where Paseo gets in the way

Paseo owns the durable agent timeline and lifecycle boundary, but currently exposes transport/lifecycle status without a provider-agnostic read of material progress. External orchestrators either duplicate timeline semantics or make stop/recovery decisions from incomplete state.

History recovery adds a second problem. If provider history is partial, fails, or races new live events, a client cannot safely know whether an apparently recent row is a trustworthy continuation boundary.

What the workflow would look like

agent inspect would include an observational materialProgress snapshot:

• none, progressing, warning, or stalled;
• completed compactions since the last material event;
• last material event time and kind when known; and
• a concise classification reason.

Paseo would calculate it from a bounded timeline read back to the current real-user continuation boundary and persist only the last trustworthy classification. A later real user message creates a new trustworthy boundary.

Paseo would not automatically stop, retry, archive, route, or gate anything. The coordinator remains responsible for policy.

This should remain provider-agnostic and contain no fleet topology, host naming, or Plexer-specific behavior.

Reference implementation

I opened draft PR #2689 for concrete review-shape feedback. It is built directly from latest stable v0.2.5 at exact commit 465efcf9d4704ffa515850caedda3b7fa9e5e608.

Because trustworthy inspection depends on timeline trust, the draft also serializes normal/forced provider-history hydration, buffered live events, per-agent durable replacement, and close. The exact branch has 188 focused passing tests, a passing full server build and typecheck, touched-file lint/format proof, and an independent exact-commit review with no unresolved high or medium finding.

I can split the protocol/classifier and history-lifecycle work into separate review units if that better matches the product direction.