DEV Community

ORCHESTRATE
ORCHESTRATE

Posted on

Active Inference, The Learn Arc — Part 34: Session §6.3 — Run and Inspect, the Closing Workflow

#activeinference #ai #debugging #elixir

Session 6.3 — Run and inspect

Series: The Learn Arc — 50 posts teaching Active Inference through a live BEAM-native workbench. ← Part 33: Session 6.2. This is Part 34.

The session

Chapter 6, §3. Session title: Run and inspect. Route: /learn/session/6/s3_run_and_inspect.

You designed your three lists in Session 6.1 and filled the four matrices in Session 6.2. Session 6.3 is the payoff: the agent runs, you inspect it, you diagnose any weirdness, you iterate. This is the workflow every working Active Inference engineer lives in.

The debugging loop

Session 6.3 names the inspection loop explicitly:

  1. Boot the agent. Builder → Save+Instantiate → Studio attach.
  2. Step a few times. Watch the maze, the heatmap, the policy posterior.
  3. Form a hypothesis. "It should go left now." Does it?
  4. Read Glass. If the agent did something surprising, click the signal in /glass/agent/<id> and read the per-equation payload.
  5. Identify the cause. Which equation misfired? Which matrix produced the wrong number?
  6. Iterate. Fix the spec in Builder, re-instantiate, re-attach, re-run.

Six steps. Runs every time you build something new. The Workbench's architecture is designed to make this loop as short as possible.

What to check, in order

When your agent does something weird, check in this sequence:

1. Is the belief heatmap updating?

  • No → observations aren't reaching the agent, or A is broken.
  • Yes but slowly → A's off-diagonal mass is too high, or observation precision is too low.

2. Is the policy posterior reordering with belief changes?

  • No → G computation is broken; check the equation-trace in Glass.
  • Yes but always favors the same policy → γ (policy precision) too high, or C too sharp.

3. Is the agent's actual action matching the argmax of the posterior?

  • No → action sampling is broken or stochasticity parameter is off.
  • Yes but wrong → policy posterior is wrong; back to step 2.

4. Is the world responding correctly?

  • No → B (the agent's transition model) doesn't match the world's actual dynamics. Dirichlet-learn B to fix.

Four checks. Four narrow hypotheses. Each one either passes or fails in Glass.

The Glass trace format

Every tick emits 5–7 signals per agent. A typical trace:

tick 3  perceive         eq_4_13_state_belief_update   Q(s) updated, entropy 1.12 → 0.87
tick 3  plan_G_pi_0      eq_4_14_policy_posterior      G_0 = 0.42 (risk 0.38 + amb 0.04)
tick 3  plan_G_pi_1      eq_4_14_policy_posterior      G_1 = 0.55 (risk 0.50 + amb 0.05)
...
tick 3  softmax          eq_4_14_policy_posterior      Q(π) peak at policy 0 (0.67)
tick 3  act              eq_4_14_policy_posterior      emitted :east
tick 3  world_step       (engine)                     new position (1, 0)
Enter fullscreen mode Exit fullscreen mode

Every signal clickable → equation page → math. Tag filter by equation_id to isolate exactly one type. Download as CSV for analysis.

The four-modality example

Session 6.3's worked example is the multimodal frog from /cookbook/multimodal-two-channel-frog — a two-modality world (visual + acoustic). You boot the frog, feed it observations, and you watch:

  • Modality 1 (visual) → A_1 update → belief sharpens.
  • Modality 2 (acoustic) → A_2 update → belief sharpens further.
  • Joint update (sum of log-likelihoods) → belief converges.

The Glass trace shows one signal per modality per tick. You can tag-filter by modality to see which channel is doing most of the work at any moment. A debugging affordance most scientific software doesn't offer.

The closing payoff

By the end of Session 6.3 you have:

  • A spec you designed.
  • An agent running under that spec.
  • A Glass trace of every decision it made.
  • A debugging workflow that finds issues in seconds, not hours.

That is Chapter 6's deliverable. Everything after this (Chapter 7 POMDPs, Chapter 8 continuous time, Chapter 9 data fitting) builds on this workflow.

The concepts this session surfaces

  • Debugging loop — build, run, inspect, iterate.
  • Glass trace — per-equation-per-tick signal river.
  • Hypothesis-first inspection — form a specific claim before reading the trace.
  • Iteration velocity — why BEAM makes this fast.

The quiz

Q: Your agent's belief heatmap updates normally but it always picks the same action regardless of where the goal is. What's the likely cause?

  • ☐ A is mis-specified.
  • ☐ The agent's C (preferences) is uniform. ✓
  • ☐ The softmax temperature is 1.0.
  • ☐ The Dirichlet prior on B is too strong.

Why: If belief updates correctly, perception works. Always-same-action regardless of goal means risk doesn't differentiate between policies — which happens when C is flat (no preference). The agent has no reason to head for any particular state. Fix: concentrate C on the goal observation.

Run it yourself

The mental move

Chapter 6 is over. You can design, build, run, and debug Active Inference agents. Everything after this — Chapter 7's POMDPs, Chapter 8's continuous time, Chapter 9's data fitting, Chapter 10's unified theory — is variation on this core loop. Session 6.3 is where you earn the right to read any subsequent chapter with confidence.

Next

Part 35: Session §7.1 — Discrete-time refresher. Chapter 7 opens. The longest chapter in the book. Session 7.1 is the refresher — a fast rewind through Chapters 4 and 6 before we add depth, learning, and hierarchy. The on-ramp to the muscle chapter.

⭐ Repo: github.com/TMDLRG/TheORCHESTRATEActiveInferenceWorkbench · MIT license

📖 Active Inference, Parr, Pezzulo, Friston — MIT Press 2022, CC BY-NC-ND: mitpress.mit.edu/9780262045353/active-inference

← Part 33: Session 6.2 · Part 34: Session 6.3 (this post) · Part 35: Session 7.1 → coming soon

Top comments (0)