The agent missed the one fact that mattered
The migration plan looked complete. The product brief said “approved,” the worker agent found it, and the cutover sequence read like competent engineering. In another record, a backfill cohort still had an unresolved reconciliation exception. If the agent never sees that condition, a persuasive plan is still the wrong plan.
That is the fictional case I use to design context systems. It exposes a problem that is easy to hide under “better RAG,” “larger context,” or “add a supervisor agent.” Each can help. None earns authority merely by being present. The system has to put the current governing fact in front of the worker at the moment a consequential action becomes possible, verify its source and version, and refuse to report completion until the target state agrees.
This field note is about active context injection: a specialist role with durable, narrow memory watches for decisions in its domain and sends a cited, case-specific packet. It is also about the ways that design fails. A specialist can remember the wrong version, miss a trigger, fabricate a source link, or become one more fluent participant in a chain of summaries. The case and experiments below are synthetic design fixtures, not incidents from Eric's production systems.
The three places the fact can disappear
First, retrieval can miss the record. A query about “migration approval” might rank the product brief ahead of an exception entered under an operational cohort ID. Contextual Retrieval shows one way a vendor improved top-20 retrieval on its studied corpus by enriching chunks and combining search methods. That is useful engineering, with a bounded published evaluation. It does not make an unreturned exception visible to the worker. GraphRAG research addresses different corpus-wide questions with graph and community summaries. The sensible response is to improve retrieval and identify which decision prerequisites must be checked, especially when their language differs from the user's request.
Second, the fact can be present but poorly used. The Lost in the Middle experiments found position sensitivity on their long-context question-answering and key-value tasks. That result should not be turned into a universal claim about every model in 2026. It is enough to motivate a local test: move the decisive exception through a realistic prompt and see whether this actual model and workflow still stop cutover. A million-token window is capacity, not a guarantee of attention.
Third, a remembered fact can be stale. LongMemEval tests long-term memory across extended interactions, including updates and temporal reasoning. Its tasks are not this migration case, but they show why “we persist memory” is an incomplete specification. An unresolved cohort can be reconciled tomorrow. A new one can appear next week. A role agent needs an update and invalidation contract, not a larger pile of notes.
A specialist role holds a responsibility, not a transcript
I would give a data-integrity steward a narrow durable state: the customer migration, affected cohort, governing reconciliation record, current owner, effective version, and unresolved conditions. The steward is prompted or triggered when a worker proposes cutover, changes the migration plan, resumes after a pause, or when the source record changes. It sends a compact packet at that boundary. The worker does not need every past meeting transcript to make this decision.
The distinction between local application state and model-visible context matters. The OpenAI Agents SDK handoff documentation says a receiving agent normally sees prior conversation history unless an input filter changes it; its context guide distinguishes application data from what is sent to the model. A “specialist agent” label alone will not reduce flooding. The host must decide what history is filtered, what source is fetched, and what narrow packet is sent. The same principle applies across products even though the specific handoff controls differ.
There is a concrete implementation trap here. In the current Agents SDK, input_type gives a handoff structured arguments; it does not replace the receiving agent's conversation history. Use an input_filter or explicit history mapping when you need a narrow specialist context, and keep durable source pointers in application state rather than assuming they enter or leave the prompt automatically. The handoff documentation also says server-managed conversations cannot use these handoff input filters; that route needs a separate run with deliberately selected input if isolation matters. Test the actual bytes each role sees, especially after a second or third handoff. A passing single-hop demo does not establish the later context boundary.
A packet for the fictional migration might look like this:
{
"case_id": "migration-214",
"task_id": "cutover-migration-214",
"claim": "hold_cutover",
"cohort_id": "cohort-7",
"source_uri": "protected://reconciliation/migration-214/cohort-7",
"source_digest": "sha256:<digest of protected record>",
"effective_version": 12,
"observed_at": "<timestamp>",
"expires_at": "<timestamp>",
"owner": "data-oncall",
"expected_readback": "no cutover event"
}
This is a claim, not a permit. A host validator resolves the source from a protected store, recomputes its digest, checks case and cohort identity, verifies that version 12 is still current, and checks whether the exception is still open. It rejects a perfectly shaped packet that names another customer, an expired record, or a source that the worker can edit. A schema catches missing fields; it does not make their values true.
The example packet also leaves out sender authentication. A production host must bind the packet to the authenticated steward principal and the specific task run; an owner string inside model-written JSON is not identity. Then check that this principal may raise a data-integrity hold for this case. The local companion verifies source and scope fields, not a real identity provider or agent transport. That missing integration stays on the real-test list.
At the cutover service, a second check asks whether a current reconciliation receipt exists for every required cohort. That check uses the service's own narrow authority, even if a supervisor message is suppressed or a provider's inner tool loop never emits the host event. A target readback then establishes whether cutover actually occurred. The worker's final sentence is not that readback.
Memory needs invalidation and a failure mode
Suppose the steward learned “hold” on Monday, the data owner signed off on Tuesday, and the worker asks on Wednesday. If the steward keeps repeating Monday's note, it prevents legitimate work. If it silently drops the hold while the source is still open, it permits the wrong action. Both errors belong in its acceptance tests.
For each durable item, I would retain source identity, scope, effective time, expiry or revalidation interval, supersession link and owner. Source-change events should update the steward, but the host should also fetch the current protected record at use. Delivery can fail and events can arrive out of order. In that case, the correct output is UNKNOWN with a named escalation, not a confidence-shaped guess. The memory is a fast hint to investigate; the authoritative record is what the action gate uses.
The supervisor also needs a trigger contract. It may watch proposals, pre-tool calls, post-tool outcomes, resumption after a paused task, and changes to governing records. Trigger coverage must be tested route by route. A system that only injects when the worker voluntarily asks “is there an exception?” has made the worker responsible for knowing the very thing it might miss.
Agents can disagree without becoming a voting committee
Now add a product steward that says launch is approved and a security steward that says the new region is allowed. The data steward says cohort 7 is not reconciled. Counting two green messages against one red message would quietly replace source authority with model consensus.
The host should bind each claim to its source and scope. Product approval can authorize a release window; it cannot certify data integrity. Security approval can allow a region; it cannot erase a backfill exception. A human owner decides an unresolved policy conflict. An agent-to-agent transport specification can carry task IDs, states, messages and artifacts, but interoperability does not decide which source governs. The authority matrix and service check remain application work.
This is where role agents are genuinely helpful: they can maintain different domains and raise the right contradiction in time. They should not pretend to be independent courts simply because they have different personas or models.
Compare architectures on accepted decisions
I would run four candidates on the same protected synthetic cases: ordinary top-k retrieval, a long-context packet, improved retrieval with source-aware indexing, and a specialist steward that injects a narrow packet. The cases include approval-only, unresolved cohort, superseded exception, contradictory record, missing source, delayed event and suppressed supervisor. Each candidate sees the same action service and the same independently labeled outcome oracle. Do not grade a model with another model's summary of the case.
Measure at least five things: whether the critical fact reached dispatch, false-green cutovers, false holds, reviewer minutes, and cost per accepted case including retries and recovery. Record latency and maintenance effort too. The result may favor a simpler rule and an improved index over another agent. That would be a good result. If the steward wins on consequential misses, keep its memory-update burden and false interventions on the scorecard rather than congratulating the architecture for having more roles.
Ten experiments before treating it as a control
These are proposed disposable experiments. They do not claim a live customer migration or measured vendor-model ranking.
- Put the migration approval and unresolved exception in different source classes. Run the literal user query and a prerequisite-aware query; record whether both source IDs arrive before action.
- Add distractor approvals for other customers and cohorts. Verify the system binds evidence to the exact case, not a semantically similar one.
- Place the decisive condition at the beginning, middle and end of a realistic long context for the target model; score the action, not only whether it quotes the condition.
- Give the steward a stale
holdentry, then a current signed reconciliation receipt. Verify it retracts the hold or returnsUNKNOWNuntil the current source is resolved. - Deliver update events out of order and drop one. At dispatch, require a protected current-version lookup rather than trusting event arrival.
- Forge a plausible source ID or substitute a different cohort's digest in an otherwise valid packet. The validator must reject it.
- Suppress the supervisor message. The cutover service must still deny an unresolved cohort and leave a visible pending task.
- Send conflicting product, data and security packets in different orders. The authoritative decision and escalation owner must remain the same.
- Call cutover through every reachable tool or delegated route in a disposable target. Verify a denied operation leaves no cutover event, even when a host hook does not fire.
- Compare the four architectures on protected cases, counting false-green, false-hold, reviewer time and recovery cost. Then remove the steward: if simpler retrieval plus a service rule meets the contract, keep the simpler design.
The public Week 12 companion fixture contains a synthetic packet verifier and a service gate. In the local source run, 11/11 unit tests passed; deliberately disabling the final service check made two negative-control tests fail as expected. That evidence establishes only behavior of this small Python fixture. The live target integration, real retrieval corpus and actual model/handoff coverage remain separate experiments.
The rule
Let retrieval find candidates. Give a specialist durable responsibility for the few facts that can change a decision. Inject a source-linked, versioned packet when the worker reaches the relevant boundary. Have the host check the packet against current records, let the service enforce authority, and read back the real effect.
Give the right agent the current, sourced condition when the action becomes possible; check it where the action happens and verify what changed. Do that because neither a relevant search hit nor a fluent second agent can make a missing or stale fact safe by itself.
The approved daily written reads are available in this journal. The public overview film, timed transcript and Week 12 companion accompany this article. Social and daily video links are added only after public readback.
The field kit
The companion folder for this week holds runnable examples, decision records, evidence and limits. The repository release log is updated after each article's live readback.