Working state versus transcript

The meal agent's chat log is forty messages long. The household accepted Monday through Wednesday on message twelve. By message thirty-eight the plan still shows Monday as tentative, because nothing wrote acceptance into structured state. Local repair lost footing: the agent regenerated from ambiguous transcript instead of patching around accepted meals. Support hears "it forgot what we agreed" when the architecture never persisted agreement.

Chat history is easy to store and easy to mistake for architecture. Transcript answers what was said. Working state answers what currently matters for pursuing the goal: versioned, machine-readable, consumed by the loop each cycle.

Helpful context: Memory as architecture types working state among forms. The agent loop reads state each cycle. Conversation becomes state covers UX promotion from utterance to object. This page is agent architecture: the orchestration record, not designing copy alone.

Side-by-side in the household planner

Working state (orchestration)	Transcript (audit)
goal: accepted weekly plan	"Plan dinners for four.."
interpreted_week: busy Tue/Thu	"Tuesday is hectic this week"
plan_version: 3	assistant prose describing v3
accepted_meals[]: Mon, Wed	"Mon and Wed look good"
unresolved_gaps[]: Friday variety	follow-up chitchat
loop_budget: 2 remaining

Loops consume state. People read transcript. Evaluators score transitions on state fields when architecture is sound. That three-way separation is the foundation everything else on this page depends on.

Why conflation breaks loops

Accepted plan fragments, named open questions, and remaining budget must survive interruption, tool latency, and partial failures. If those live only as utterances, local repair cannot find accepted work to preserve (see persistence before regeneration), escalation lacks authority and gap context, run-level corrections may silently rewrite endorsed knowledge, and trajectory evaluation cannot prove patch versus replan events occurred.

Preference for this week only stays in context or working state, not durable knowledge without approval. Transcript may suggest updates. Working state and endorsement paths commit them.

Working state schemas are explicit about goal (what "done" means this run), interpretation (structured problem understanding, not raw user text alone), strategy (active approach, including retrieved expertise references), progress (plan version, accepted segments, rejected segments with reasons), gaps (named holes with type: information, authority, observation), authority (limits remaining, pending approvals), and budget (loop iterations, cost ceilings, time bounds). Checkpointing state after material transitions, acceptance, local patch, bridge request, and escalation, means idempotent replays recover from checkpoints rather than re-parsing transcript heuristics.

Checkpoints work best as first-class API events rather than debug logs. After acceptance, accepted_meals[] updates, plan_version bumps, and resolved gaps tied to accepted days clear. After a local patch, the weakness name, patch proposal source cognitive unit version, and preserved unrelated accepted meals are all recorded. After a bridge request, the gap type, required authority, and materiality flag persist so escalation UI can render without transcript parsing. After stop, a stop reason enum (success, authority exhausted, budget exhausted, unrecoverable conflict) persists for trajectory eval. Checkpoints enable replay: eval harnesses reload state at checkpoint N, inject fault, and assert recovery behaviour.

Evaluation and observability on state

Evaluators need versioned fields and transitions: did the agent patch locally, fetch for a named gap, escalate on authority? Dialogue order alone does not prove those events. Asserting on accepted_meals[], plan_version, and unresolved_gaps[] rather than substrings in message thirty-eight is what makes trajectory evaluation tractable. Pair with the agent loop stop conditions and minimum sufficient loop criteria so state reflects when pursuit ends.

Logging structured events alongside message pairs compounds that advantage. working_state_version at loop start and after each transition, accepted_meals_delta when acceptance changes, gap_opened and gap_closed with named gap IDs, cognitive_unit_call with slug, semantic versioning, and source-kind summary, and authority_pending flags when escalation is required give dashboards the fields needed to diagnose loop failures in minutes. Dashboards built on transcript keyword search diagnose in days, if at all.

Alerting when working state version stalls across multiple loop iterations while transcript grows often signals conflation before users report "forgetting." That pattern, where messages accumulate but structured progress does not advance, is the operational signature of an agent consuming transcript as state.

Designing for state over transcript

Working state is agent-owned pursuit material. cognitive units receive inputs and return bounded judgments. They do not silently own whole-goal progress unless mis-designed. See where the cognitive unit ends and the agent begins. cognitive units write into state only through declared contract effects that orchestration applies.

Designers often want chat because it feels natural. Architecture still requires state writes when conversation commits material facts. The pattern is: utterance becomes editable object in UI and structured field update in working state in the same transaction. See conversation becomes state. If UX shows "Mon accepted" in a bubble but state lacks accepted_meals[], the result is transcript theatre, not collaboration architecture. Preference store versus chat covers UX for standing choices versus ephemeral chat. This page stays on agent loop mechanics: the backend truth orchestration requires.

Existing chat-first agents can migrate incrementally. A minimal schema for goal, acceptance, gaps, and budget comes first. Extractor or structured tool calls write state on material utterances. The loop changes to read state first, transcript second for disambiguation only. Eval assertions on state fields run in parallel with transcript heuristics until eval proves parity. A big-bang rewrite is unnecessary unless safety requires it. Parallel-running state and transcript parsers until eval proves parity is the pragmatic path.

Escalation UI renders from working state: goal, accepted segments, named gaps, authority needed, and budget remaining. Support staff do not scroll forty messages to learn what the household already accepted. Transcript remains available as appendix, not primary operator surface. Chaos exercises that inject checkpoint corruption in staging verify loop recovery and eval detection before production depends on state.

Version working state schemas with migration notes the same way database schemas migrate. Breaking changes without migration break eval harnesses and replay tools. Document minimum fields required before an agent may call each cognitive unit in the chain, because missing state prerequisites cause cognitive units to fill holes from transcript by accident. In code review, rejecting loops that pass raw message history into cognitive unit prompts when structured fields exist catches the conflation smell worth blocking. Publish working state schema docs beside agent loop docs in the same directory so developers do not hunt wikis for fields the loop already requires implicitly. Treat working state migrations as breaking API changes, because consumers include eval harnesses, debug UIs, and escalation surfaces alongside the agent runtime. When debugging loops, diffing working state before and after each cognitive unit call is faster than re-reading transcript and more honest than asking the model what it thought happened. Store checkpoint snapshots for post-incident replay when production behaviour diverges from eval harness behaviour.

Common mistakes

The most common mistake is transcript summarisation as state, where an LLM compresses chat each turn and acceptance drifts. Implicit acceptance, where positive tone is interpreted without accepted_meals[] update, converts ambiguity into false progress. State without versioning means patches overwrite without history for audit or eval. A giant JSON blob mixing context, knowledge, and progress is an undifferentiated bag rather than typed working state. No budget fields means runaway loops with no structured stop signal.

Each of these mistakes produces the same downstream effect: the agent cannot explain what it currently believes matters, and eval cannot assert that transitions occurred in the right order. The fix is always structural. Name the fields. Version the transitions. Keep transcript for humans.

What to do next

Schema-reviewing agent working state before adding chat features establishes the architectural foundation that loops, eval, and escalation all depend on. Eval assertions on state fields rather than message substrings make trajectory evaluation tractable. Tracing one pursuit and marking each loop transition's state delta in logs reveals where conflation hides. Features that "read the thread" when a structured field exists are conflation in disguise, and blocking them in review prevents the drift from compounding. UX promotion paths pair with explicit state writes through conversation becomes state.

See the agent loop, where the cognitive unit ends and the agent begins, and the Thoughtware system for placement in the whole architecture.

Read next: Preference store versus chat.