The live view — the agent's attention zone, and what's in it

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. It opens the part we kept pointing at and never entered: the tail itself, and especially its last block — the live view (we call it the announce). The question here is simple. The agent receives one long input every round. Where does it know to look first for what's true right now?

The 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.

What 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. Here's one round of it, rendered, with each section labelled by the job it does:

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.

Everything in this list shares one property: it would be wrong if it were stale. So it's recomputed every round — which is exactly why it sits in the uncached tail.

The 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 (fi: refs) — each addressable by SID, loaded with react.read, and hidable with react.hide when large.

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.

Why 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 it in an uncached tail, both problems disappear. The prefix stays calm and reusable; the live view stays current for free. Being recomputed each round isn't a tax on the live view — it's the reason it can always be right. Freshness beats reuse, here and only here.

Lifecycle: refresh now → persist once → clear

A signal in the live view has a short, deliberate life:

• refresh now — 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.
• persist once — when a signal has been consumed or acted on, it's written into the timeline once as durable history. (A mid-turn follow-up the agent incorporated, a feedback reaction it addressed — these become part of the record.)
• clear — having persisted, the signal 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.

Why 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 structure. The five parts of the input and where each comes from.
• #2 — the caching. 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: journal/26/06/shorts/22/06/26-workspace-overview-in-react-announce/.

Documentation on GitHub

The live docs behind this entry:

• The live view / announce block — contents and lifecycle
• The sources pool — the adjacent tail block
• Where the tail sits in the input — the uncached tail pair
• Live turn events — follow-ups and steers in the tail
• Fresh feedback surfaced in the live view