Context Routers for Personalization: Sending the Right Motivation Data to the Right Model
Context routers should decide which motivational state reaches which model or agent, preserving relevance while preventing stale goals, excessive profiling, and unnecessary sensitive data from contaminating decisions.
A context router is the traffic controller for personalization
Anthropic defines context engineering as curating the information most likely to produce desired behavior at each inference step.[1] A router operationalizes that principle across models and agents. Instead of placing the user’s entire history in every prompt, it selects the current goal, relevant preferences, recent blockers, appropriate memory, and authorized external data for this particular decision. The router can send planning state to a planner, scheduling constraints to a calendar agent, and learning progress to a tutor without exposing unrelated personal context.
The smallest sufficient state is usually the safest state
Minimal routing improves focus and reduces the chance that an old preference or sensitive disclosure influences a task where it does not belong.
Routing belongs between application state and model context
OpenAI’s architecture separates application logic from the harness and environment, which gives products a natural place to own durable state and decide what the agent receives.[2] The application can store authoritative goal objects and privacy permissions, while the context router creates a task-specific view. This prevents the model from becoming the database and keeps personalization policies inspectable. The model can reason over the view without silently rewriting the source of truth.
Tool outputs should be filtered before they flood the next decision
Anthropic’s tool-design guidance recommends context-efficient responses using filtering, pagination, and truncation because overly large tool results degrade agent performance.[3] Motivational routing needs the same discipline. A health integration might return a summarized activity trend rather than years of raw data. A project tool might return the active milestone and blocked dependencies rather than every archived task. The router should transform raw information into the minimum evidence the model needs while preserving provenance for audit.
Route summaries with provenance
The model can see “practice completion declined for 2 weeks” while the system retains the underlying records and source identifiers outside the prompt.
Protocols help separate resources from actions
MCP explicitly distinguishes resources, prompts, and tools, providing a useful model for how contextual data and executable capabilities enter an agent system.[4] A router can attach a read-only goal summary as a resource while exposing an “update_goal” action only through a separate authorized tool. That prevents the model from treating whatever appears in context as permission to change it. Personalization becomes safer when information flow and action authority are designed independently.
Routing changes need trace-level evaluation
OpenAI’s agent-evaluation guidance encourages trace inspection and grading for routing logic, tool choice, handoffs, and policy adherence.[5] Context routers deserve their own graders: did the correct motivation state reach the correct specialist, was unnecessary sensitive information excluded, did stale memory influence a decision, and did a routing change improve user outcomes? Because context is invisible in the interface, evaluation is what prevents silent personalization regressions.
Context is part of the causal chain
A surprising recommendation may be a model problem, but it may equally be a routing problem: the model received the wrong slice of the user’s state.
Motivational state should have freshness and confidence metadata
A preference such as “likes competition” may have been true once and harmful later. A router should know when a field was observed, whether it was explicit or inferred, how confident the system is, and when it should ask again. Durable user declarations can outrank weak behavioral inference. This makes personalization adaptive without treating every past action as permanent identity.
Different models should receive different levels of intimacy
A simple classifier may only need task type. A planner may need goals and constraints. A sensitive coaching model may need a user-selected motivational style. A third-party specialist may need only the subtask and no personal history at all. The router should implement least-context privilege: give each component only what it needs.
Context access is a permission surface
Privacy design should govern not only what the company stores but which model or external agent is allowed to see each field.
Good context routing makes personalization feel precise rather than invasive
The best system remembers enough to reduce repetition and adapt help while resisting the temptation to make every decision from the entire user profile. It sends the right state to the right component at the right time, with freshness, provenance, and permission attached. That architecture produces a useful kind of personalization: specific to the current goal, easy to correct, and small enough that teams can explain why the system behaved as it did.
A useful router also needs negative routing rules: information that must not flow to particular models, vendors, or tasks even when it exists in the customer profile. Sensitive health context might be available to a wellbeing agent but excluded from a shopping recommender; workplace performance data might be relevant to a private coaching tool but prohibited from an employer-facing agent. These exclusions should be expressed as policy, not left to prompt wording. The router can enforce purpose limitation before the model sees the data. That creates a powerful architectural property: downstream agents can remain general-purpose without needing to reason perfectly about every privacy boundary. The system narrows the context first, then asks the model to reason inside the approved view.
Works Cited
- 01Anthropic — Effective Context Engineering for AI Agents anthropic.com
- 02OpenAI Developers — Agent Architecture: Harness, Environment, and Application Server developers.openai.com
- 03Anthropic — Writing Effective Tools for AI Agents anthropic.com
- 04Model Context Protocol — Server Primitives: Prompts, Resources, and Tools modelcontextprotocol.io
- 05OpenAI Developers — Evaluate Agent Workflows developers.openai.com
CodeHistory is a living archive. Citations document the evidence used for this edition; later evidence may refine the account.