Timeline · 07 of 10 · Observability

Did the agent do the right thing, and how do we know?

One task_id is stamped on the intent, the tool calls, the commits, the pipeline runs and the deploy. The last event is not a green build: it is the service confirming the change did what it was meant to.

Did the agent do the right thing, and how do we know? Timeline of one agent task over ten minutes, from recorded intent through tool calls, a pull request, a failed and a passing gate, merge, sync, and a final SLO check, with one task_id carried by every record. TASK_ID = T-7F3A · CARRIED BY EVERY EVENT0m1m2m3m4m5m6m7m8m9m10mMINUTES SINCE TASK STARTIntent recordedgateway auditRead logs via MCPgateway auditPR openedgit · task_id labelGate fails: rule 4ci · structured failureGates passci · verify contractMerged (T1)git · policy decisionArgo syncargocd · annotationSLO check okslo · burn rateLEGENDEventOutcome checkSame task_id on every record

Requirement

Observability has to answer a new question. Not just "is the service healthy" but "did the agent do the right thing, and how do we know."

Design choices

  • task_id propagates through commits, PR labels, gateway audit rows, Argo annotations and traces.
  • Outcome metrics: first-attempt gate pass rate, retries per task, human override rate, rollback rate against a human baseline.
  • The closing event is a service-level check, not a pipeline status.

Evidence and gap

Built in Hangar: release-outcome-span tracing, the Tower Release Record with compare view, and a HolmesGPT triage prototype. Proposal only: task_id as a first-class field across the gateway and Argo.

Hangar · reference architecture