The live view — the agent’s attention zone, and what’s in it
The tail of the model input is a pair: the sources pool — the evidence gathered this turn — and the live view, the runtime’s voice. Always last, never cached, rebuilt every round.
The agent receives one long input every round. Where does it know to look first for what’s true right now?
In #1 we mapped the shape of the model input: a stable per-agent front, a timeline that grows oldest → newest, and a volatile tail at the very end. In #2 we saw how almost all of that is cached and reused across calls — and why the tail, alone, is never cached. This is #3, the last of three: the tail itself, and especially its last block — the live view (we call it the announce).
01The agent needs one place it knows to look first
The timeline is history — a long, append-only record, perfect for “what happened,” wrong for “what’s true this instant.” If a fact must always be found in the same place, the agent shouldn’t have to scroll a growing transcript to find it. So the runtime keeps a fixed attention zone at the very tail: always last, always on top of the agent’s view, never cached.
The attention zone is a tail pair — two adjacent blocks with two different jobs: the sources pool, the citable evidence gathered this turn; and the live view, the volatile, immediate signals the agent must see now. They sit side by side at the bottom because both are things the agent reaches for constantly. But they are not the same thing.
02What lives in the live view
The live view is the runtime’s voice — the one place it tells the agent the current operating conditions, refreshed before every decision. It holds the fast-moving things, and only those.
What it deliberately does not hold: raw payloads, full tool results, whole plan artifacts, large source bodies. The live view is what the agent glances at first, not where the full record lives. Compact by design — and recomputed every round, which is exactly why it sits in the uncached tail.
03The sources pool is adjacent, not identical
People tend to lump the two tail blocks together because they’re neighbors. But they answer different questions.
The sources pool holds both web evidence and pulled or produced workspace artifacts (conv:fi: refs) — each addressable by SID, loaded with react.read, and hidable with react.hide when large.
| Tail block | Its job | Question it answers |
|---|---|---|
| sources pool | rolling registry of retrieved, citable sources | “what evidence can I cite?” |
| live view | live state and immediate runtime signals | “what’s true and current right now?” |
Same neighborhood at the bottom of the input, different jobs. One is evidence; the other is state. Keeping them as two blocks rather than one blob is the point — the agent learns which to reach for.
04Why being non-cached is the whole point
In #2 the rule was blunt: the tail is never cached. Here’s why that’s a feature, not a cost. Caching only reuses a prefix that’s byte-for-byte identical to last time. The live view changes on every round — a new round counter, a fresh steer, an updated workspace projection. If it lived inside the cached prefix, every tiny update would either churn that expensive prefix or force the agent to read stale state.
By keeping live state in an uncached tail, both problems disappear. The prefix stays calm and reusable; the live view stays current for free. Freshness beats reuse — here and only here.
05Lifecycle: refresh now → persist once → clear
A signal in the live view has a short, deliberate life. Each round, the runtime rebuilds the live view fresh and appends it at the tail — the agent sees the current budget, the current workspace, the live events as of this round. When a signal has been consumed or acted on, it’s written into the timeline once as durable history. Having persisted, it drops out of the live view so it isn’t shown again next round.
This is the same balance the announce strikes at end of turn: it’s hot and transient while the turn runs, and its final state is recorded once when the turn closes. The design isn’t “hide things from history.” It’s: give live state the right surface, then record the outcome once, so the same thing is never shown twice.
06Why this matters beyond ReAct
The live view is a ReAct mechanism, but the idea isn’t ReAct-specific. Once an agent is part of a real, distributed system, the runtime needs a voice of its own — and the agent needs a fixed place to hear it. Not everything important is a tool call; not everything current belongs in the cached transcript; not everything urgent can wait for the next cleanly-recorded turn.
Any agent benefits from a designated, always-on-top attention zone: one place, always last, always fresh, where the runtime says what’s true now. Collapse that job into the history and you get either a noisy prompt or a blind agent. The live view exists to avoid both.
That closes the arc. The input has a shape (#1), most of it is cached and kept fresh (#2), and its very last block — the live view — is the agent’s always-current attention zone (#3).
- #1 — The model input: the structure. The five parts of the input and where each comes from.
- #2 — How the model input is cached. Why the prefix is reused and the tail is never cached.
- The workspace-map Short — a concrete example of one thing the live view renders, every round.