The instruction your agent gets is computed from what it has

We switched the code-execution tool off for an agent and asked it what it can do. It answered, among other things: “Execute code (Python, shell, etc.) to process data.” It had no such tool. The rendered instruction showed why it believed otherwise: the reply protocol still taught the code channel in every section, a catalog section listed helpers callable only from generated code, and the read tool's own documentation said “inspect binary files with code and exec tool.”

The lesson generalizes past exec. The concepts in an instruction exist for the model only through that instruction — it has no prior about our channels, our tools, our contracts. Whatever the text teaches, the agent has; whatever it teaches about a tool that is absent, the agent hallucinates. So the instruction cannot be a fixed document that mentions capabilities. It must be computed from what the agent actually has.

One authority

What an agent has is its effective tool roster: the tools its app config declares for it, intersected with what the user selected for the conversation. At turn start the roster binds into adapters — one record per tool — and the set of adapter ids is the single input every conditioning decision reads. There is one mapping from ids to consequences, so the body, the protocol, and the catalogs can never disagree about whether a capability exists.

Six mechanisms, three kinds

Conditional rendering — teaching that appears exactly when its tool is wired:

• Capability blocks. The exec, rendering, and web teaching blocks render only with their tool present — even when a named profile lists them. A profile is an administrator's convenience, never authority to advertise a tool the user disabled.
• The reply protocol's code channel. The protocol teaches the base channels — thinking, action, an optional final summary — and says that a connected tool may extend the protocol with a channel of its own. The code channel is such an extension: with exec present the protocol says “4 channel types” and shows rounds with code; without it, “3 channel types”, and the worked examples use the workspace write tool. The parser accepts both shapes.
• The extended body's exec sections. The full default body drops its code-generation sections through the same gate — derived from the same id set, so the tiers cannot drift apart.
• The code-snippet catalog section. Tools callable only from generated code are advertised only when there is a way to generate code. Listing them without exec is exactly the misread that opened this entry.

Roster-proof text — the inverse mechanism:

• Generic surfaces speak in capability classes. The always-present text — the loop's own tool docs, the protocol's visibility rule, the paths and workspace guidance — names no opt-outable tool. It says file-processing tools (operate on local physical files), computation tools (create smaller derived artifacts), the producing tool's external visibility, every tool output is capped. A present tool matches its class through its own catalog entry; an absent tool is simply never named. A regression test fails the build if any exec signal appears in an exec-less composition.

Composition from the roster —

• The named-services block. The namespace teaching renders only when named-service connections are configured, and closes with the roster of exactly the connected namespaces. No connections, no vocabulary.

The catalog's own rule: never cut a contract

The tool catalog — the rendered inventory of the roster — has a companion rule. It renders in a full or a compact form, and the difference is purely format: dense lines and no prose examples versus banner layout. Each tool's contract — purpose, every parameter description, the return description, the constraints — renders in full in both.

The meter

Because the projection in the agent configuration forge composes through these same functions, every lever shows its real price while you configure: toggle the exec tool off in a draft and the projected instruction shrinks in the body and the catalog at once — exactly what the live agent would receive. On one measured roster, the catalog alone moved from 10.7k tokens (full form) to 3.1k (compact); removing a tool moves both numbers and the teaching with them.

The full picture

This entry owns conditioning: how the roster decides what the instruction teaches. Its companions: the input's anatomy (what the model input is made of), the choice (profiles, custom sets, and the per-conversation pick), and signal parity (how three instruction sizes keep the same rules).

Documentation on GitHub

The live docs behind this entry:

• The tool catalog — sections, forms, and the six mechanisms in full
• Instruction blocks and signals
• React system instruction — composition and caching