Training · ComposerMoveemergingverified

Show the Working

also known as transparency-for-trust, expose agent reasoning, agent observability for trust, explain-then-act, audit trail teaching

A training module that teaches builders to surface agent reasoning and action traces to end users — via logs, step-by-step summaries, or the explain-then-act pattern. Users can then verify agent behaviour and trust the output enough to adopt it.

How the learner advances

flowchart TD A[Builder with a working agent] --> B[Explain trust gap + three log layers] B --> C[Demonstrate explain-then-act reasoning before action] C --> D[Instrument agent OpenTelemetry / Langfuse / LangSmith] D --> E[Non-technical user acceptance test] E --> F{User can confirm correct behaviour?} F -- No --> D F -- Yes --> G[More capable builder + instrumented readable agent]

Intent. Teach builders to instrument their agents with human-readable reasoning traces so end users can verify agent behaviour without reading code or logs.

When to apply. Use this move whenever an agent's output will be acted upon by a human who did not write the agent — which is almost every production use case. Apply it before the agent reaches end users; retrofitting observability after a trust incident is harder and often too late to prevent adoption failure.

Threshold — earns the next step. The builder's agent exposes a readable trace or step summary that a non-technical user can interpret without help, and that user can confirm whether the agent behaved correctly.

Masterpiece — the artifact that proves it. An instrumented agent that exposes a three-layer structured trace (context, reasoning, actions) to its end user — verified by a non-technical tester who can confirm correct behaviour without asking the builder to explain any part of it.

Example scenario

A product team at a legal-tech startup has built an AI contract review agent that flags missing clauses and drafts suggested additions. The agent works well in demos, but adoption by the firm's paralegal team has stalled. The paralegals do not know why the agent flags something as missing. They cannot defend the output to supervising attorneys. The team runs a Show the Working workshop. In the first step, the lead engineer shows the team three versions of a trace. The first is the raw LLM response chain — unreadable. The second is the framework debug log — developer-readable but cluttered with token counts and internal state. The third is a hand-crafted step summary she wrote for the demo — readable, but not produced systematically. She introduces the three-layer model: context (the contract clauses the agent read), reasoning (why it judged a clause to be missing), and actions (what it drafted). In the instrumentation step, two engineers add Langfuse tracing to the agent in 45 minutes. They structure the trace output as a human-readable checklist: 'Reviewed: NDA clause — present. Reviewed: limitation of liability — missing (standard threshold clause not found). Drafted: suggested limitation of liability text.' A paralegal from the firm who attended the workshop reads the trace cold and can identify which clause was missing and why. She tells the engineers: 'I can show this to the attorney and explain it. Before I couldn't.' The masterpiece is the instrumented agent with the three-layer trace. The real proof is the paralegal's ability to defend the output to a senior attorney without the engineers in the room.

Facets

Container — workshop
Mode — concepthands-on-build
Reach — team
Persona — builder
Craft (AI Fluency) — discernmentdescription
Guardrail — responsible-userisk

Inputs

Builders with a working agent — Participants who have a prototype or production agent and are about to expose it to end users or stakeholders who need to trust its output.
Tracing tool access — An observability tool the builders can instrument during the workshop — OpenTelemetry, Langfuse, or LangSmith are common choices. Access needs to be configured before the session.
End-user acceptance test criteria — A clear definition of what a non-technical end user needs to be able to read in a trace to confirm the agent behaved correctly. This prevents the workshop from producing traces that only the builder can interpret.

Outputs

A more capable learner — A builder who can instrument any agent with structured reasoning traces, write human-readable step summaries, and design an explain-then-act interaction pattern.
Masterpiece: an agent with a readable trace — The participant's agent updated to expose a human-readable trace or step summary to the end user — not just the final answer — verified by a non-technical tester who can confirm the agent behaved correctly without reading code.
Instrumented agent codebase — The agent's source code with tracing calls added, covering the three log layers: context (what the agent knew), reasoning (why it chose), and actions (what it did).

Steps (4)

Explain the trust gap and the three log layers
Open with the core problem: over 65% of organisations cite lack of explainability as the primary barrier to AI adoption. Introduce the three log layers — context (what the agent knew), reasoning (why it chose), and actions (what it did) — as the minimum readable trace structure. Show examples from real agents: one with no trace, one with a developer-only log, and one with a human-readable summary.
Demonstrate explain-then-act pattern
Show an agent built with the explain-then-act pattern: before taking any action, the agent outputs a brief reasoning statement that the user can read and optionally interrupt. Walk through the implementation. Show where in the agent loop the reasoning step is inserted and how it is formatted for non-technical readers. Show how to add a human-in-the-loop gate for high-stakes actions.
Instrument an existing agent
Builders add tracing calls to their own agent using the chosen tool. The goal is to cover all three log layers. The instrumentation must produce output that a non-technical person can read — not just raw JSON or framework debug logs. Builders test their traces by reading them aloud and checking whether a colleague who did not write the agent can follow what happened.
Non-technical user acceptance test
Each builder recruits a non-technical tester — a colleague, product manager, or workshop participant from another team — to read the trace and confirm whether the agent behaved correctly. The tester records any trace elements they could not understand. Builders revise until the tester can confirm correct behaviour without asking the builder to explain.

Principles

A trace that only the builder can read has not been written for the user.
Trust is earned by showing reasoning before the user has to ask — explain-then-act, not act-then-defend.
Three log layers are the minimum: context, reasoning, actions — missing any one leaves the user unable to verify the full decision.

Unlocks methodologies (2)

A learner who completes this pattern is equipped to execute these methodology families:

Agent Construction Evaluation

Known uses (4)

Known failure modes (2)

[developer-only-trace]
The anti-pattern of producing traces that are readable to the builder but not to the end user — raw JSON, framework debug output, or token-level logs. Traces written for developers do not close the trust gap for non-technical users and the adoption barrier remains.
[trace-as-afterthought]
The anti-pattern of adding observability instrumentation after a production incident rather than before first user exposure. Retrofitted traces are often incomplete because the original code structure did not preserve the reasoning state needed to populate the three log layers.

Related trainings (2)

Sources (3)

Provenance

Ecosystem: neutral
Added to catalog: 2026-05-27
Last updated: 2026-05-27
Verification status: verified

How the learner advances

Steps (4)

Explain the trust gap and the three log layers

Demonstrate explain-then-act pattern

Instrument an existing agent

Non-technical user acceptance test