How Harness Inspector Makes AI Agent Deliveries Observable, Inspectable, and Traceable

From Session to Complete Delivery Process

Harness Inspector expands from a session‑debugging tool to a read‑only workbench that correlates requirement (Intent), Agent session (Process), and Git commit (Output) into a traceable delivery chain.

How a software change flows from an intent, through an Agent, to a deliverable.

Intent → Process → Output

Intent : semantic start of a change (user story, issue, spec, architectural constraint).

Process : actions recorded in the Agent session (searches, reads, modifications, validations).

Output : final artifact entering the engineering system, currently a code commit.

Simple example: Story → Session → Commit

Running npx @qoder-ai/better-harness inspector in a project directory launches a local, read‑only Harness Inspector page that displays the project’s Agent session, file activity, and Git commits together. The public read‑only sample is available at https://qoderai.github.io/better-harness/inspector. The source repository is https://github.com/QoderAI/better-harness.

When Story, Session, and Commit are shown side‑by‑side, the Story explains why the change is needed, the Session shows how it happened, and the Commit records what was finally delivered.

Observation modes

Harness Inspector provides three modes centered on a complete delivery:

Workbench : visualizes relationships among requirement, session, and commit.

Trace : expands a selected session into a readable work trajectory organized by Turn (user input, intermediate replies, tool calls, file activities) and linked on a timeline.

Replay : steps through retained events in chronological order, showing user input, Agent replies, tool calls, file changes, and commits.

All modes are read‑only; they do not fabricate missing links, re‑run tools, or restore workspaces.

Workbench details

The left pane shows the triggering requirement, the middle pane lists searches, reads, tool calls, and Git actions, and the right pane lists observed commits and modified files. When evidence is missing, the link remains a candidate rather than an inferred connection.

Trace details

Trace groups events by Turn, collapses repeated actions, and allows clicking a segment to jump to the corresponding call, producing a readable workflow without inferring hidden reasoning.

Replay details

Replay presents the retained events in their original order, enabling reviewers to see the context of each decision, the timing of modifications, and the verification steps. No additional timestamps are added.

From delivery evidence to SKILL extraction

Identifying reusable SKILLs requires more than frequency of tool calls; stable work paths that appear across similar tasks and lead to successful outcomes are candidates. Examples include determining change scope from a requirement, establishing context, performing modifications, running verification, and recording the result. Mapping these behaviors back to their Story, Session, and Commit allows assessment of whether they are accidental or transferable.

SKILL automation therefore consists of:

Collecting stable patterns from multiple deliveries.

Enriching each pattern with applicable scenarios, context boundaries, execution steps, and validation methods.

Generating a SKILL.md file that documents the pattern rather than merely summarizing a single session.

Conclusion

Observing the full delivery chain—Intent, Process, Output—makes it possible to distinguish accidental actions from repeatable workflows that merit SKILL extraction, establishing the foundation for automated SKILL evolution.