The model input — what the agent receives, and where it comes from

Every time an agent thinks, it receives exactly one thing: an ordered block of input. Not a database, not a session object — one stretch of text and content, read top to bottom, assembled fresh for that call. Everything the agent knows on that turn is in there, and everything in there came from a specific place.

This is the first of three entries about that input. Here we map its structure — the parts, in order — and the provenance of each part: who chose it, and why it sits where it sits. We won't cover how the input is kept warm and updated across calls (that's #2), or how the volatile tail at the very end is built (#3). Just the shape, and where the shape comes from.

One fact frames the whole thing: the input is per agent. Our resident agent, ReAct, is not a single fixed prompt — an app can run several agents, and a different agent means a different instruction, a different tool set, a different skill set. So the front of the input changes depending on which agent is being asked. Keep that in mind; it's the through-line.

The five parts, in order

Read top to bottom, the input has a stable front, a growing middle, and a volatile tail:

the instruction envelope — who the agent is and how it must behave;
the tool catalog — what it can call;
the skill catalog — what it can run;
the timeline — the running record of events, oldest → newest;
the tail — sources and the live view, always last.

Parts 1–3 are the agent's identity and capabilities. They're stable and the same across many calls — which is exactly what makes them cacheable (more on that in #2). Part 4 grows as the conversation and the turn progress. Part 5 is recomputed every round and never cached. Let's take them one at a time.

1. The instruction envelope — the per-agent prefix

The envelope is the very front of the input, and it's a stack of instruction layers, composed in a fixed order:

a runtime instruction — the non-negotiable operating protocol the runtime itself depends on, shared by every compatible agent;
the selected agent's instruction — the body that defines this agent's role and behavior;
an integration / domain instruction — what this app and its domain add on top;
optional custom suffixes — per-deployment or per-user additions.

This is where "per agent" becomes concrete. The runtime layer is shared, but the agent layer is not: ask agent A and you get A's instruction; ask agent B and you get B's. A different agent is, quite literally, a different prompt prefix. The same is true of a subagent — it's not a cheap continuation of the main agent, it brings its own envelope and starts its own story.

The envelope is assembled, not authored in one piece. An app can take the broad default body, pick a lighter named profile, or compose a specific set of named blocks — but whatever it picks, the runtime protocol is always prepended and the catalogs (next) are always appended. The order is fixed; the contents are the app's choice.

2. The tool catalog — what this agent can call

Right after the instruction body, the input lists the tools this agent can call — each with its name and how to use it. Importantly, in the current decision path these tools are rendered as text inside the envelope, not as a separate machine-readable tool schema. To the agent, the catalog reads like part of its instructions: "here is what's available to you right now."

The catalog is configured per agent. One agent might see web search, code execution, and memory; another might see only a document renderer. Two agents with the same instruction body but different tool sets are two different inputs. And because users (or the runtime) can sometimes choose which tools an agent gets, the catalog can differ between two runs of the same agent, too.

3. The skill catalog — what this agent can run

Next, the skill catalog — the higher-level, composed capabilities the agent can invoke as a single unit. Same story as tools: rendered as text in the envelope, and configured per agent. The catalog tells the agent a skill exists; the agent loads the skill's detailed instructions only when it decides to use it.

Together, parts 1–3 are the stable, per-agent prefix: identity, then tools, then skills. Change any byte in here — a different agent, a custom suffix, a different tool selection — and you've changed the prefix. That's the seam that #2 cares about, because the prefix is the part worth caching.

4. The timeline — the running record of events

Below the envelope comes the timeline: the conversation and the current turn, rendered as a stream of blocks, oldest at the top, newest at the bottom. This is the part that grows. It has three regions, in order:

History blocks — prior turns (the user's message, the agent's work, its answer), plus any summaries of older stretches that have been compacted away, plus preserved beacons (internal anchors the agent left for itself). This is "what happened before now."
Current-turn user blocks — the request that started this turn, plus any attachments.
Turn-progress blocks — everything the agent has done so far this turn: tool calls and their results, short progress notes, and any live user follow-ups or steers that arrived mid-turn. This region keeps growing as the turn advances, round by round.

The timeline is where provenance is richest. History comes from stored turn logs and a summary index, loaded at turn start. The current user blocks come from the incoming request. The progress blocks are written by the agents themselves as they work — each tool result the agent sees is a block it (or a helper) appended a moment earlier. The timeline is, in effect, the agent's own running notebook, read back to it each round.

5. The tail — sources and the live view

Finally, always appended last, after the timeline:

an optional sources pool — the citable sources gathered this turn; and
the live view (we call it the announce) — the volatile, immediate signals the agent must not lose track of: current budget, live user interrupts, and a fresh projection of state that changes every round.

The tail is deliberately separate from everything above it. The front and the timeline are stable enough to cache; the tail is recomputed every round and is never cached. That's why fast-moving state lives here and not in the instruction envelope — putting volatile state up front would churn the stable prefix on every call. The live view is its own small structured world, and it's the subject of entry #3.

The whole shape

Put together, one model input looks like this — a stable per-agent prefix, a growing timeline, and a volatile tail:

One model input, read top → bottom — the per-agent prefix first, the live view always last.

The shape never changes — only which agent fills the front, how long the timeline has grown, and what the tail says this round.

A small per-agent example

Two agents in the same app, same conversation, same user request — same conversation underneath, but two different inputs, because the front is keyed to the agent:

The timeline they share; the envelope and catalogs they don't.

Same conversation underneath, but two different inputs — because the front is keyed to the agent. The timeline they share; the envelope and catalogs they don't.

Where this goes next

That's the structure and the provenance: a stable, per-agent prefix of instructions and catalogs; a timeline that grows oldest → newest from stored history and in-turn work; and a volatile tail that's rebuilt every round.

Two follow-ups build on this map:

#2 — how this input is cached and updated. The prefix is stable on purpose, so it can be reused across calls instead of re-sent every time; the timeline is kept warm with checkpoints and trimmed when it grows too large. The tail is never cached.
#3 — the live view. The tail's own structure: what the agent's attention zone holds, and why it's recomputed every round.

Documentation on GitHub

The live docs behind this entry: