Give Skills the Right Context, Not All Context
A skill should load the information it needs to do its job. I do not want every capability carrying the entire conversation, knowledge base, customer history, policy manual, and tool catalogue on every run.
- Required versus optional context
- Retrieval at skill invocation time
- Context isolation between capabilities
- Freshness and source authority
- Passing summaries versus raw history
- Reducing context cost and distraction
The situation
General agents often accumulate context continuously. That feels convenient because every new task has access to everything that came before. Over time, the model receives large amounts of irrelevant history, stale facts, duplicate documentation, tool descriptions, and instructions from unrelated tasks.
The naive solution
Give the model as much context as possible. More information should mean better decisions.
The hidden constraint
Context has cost and cognitive consequences. Relevant information competes with irrelevant information, stale context can override current truth, larger prompts increase latency and spend, and sensitive information may be exposed to capabilities that never needed it. A skill boundary is useful partly because it gives me a natural place to control context.
The decision
Make context selection part of the skill definition. Each skill should declare what it requires, what it may retrieve, which sources are authoritative, and how freshness should be handled.
The implementation
For a renewal-summary skill I might load the account profile, contract dates, recent support history, product usage summary, and approved commercial terms. I would not automatically include unrelated internal chats or the entire CRM history. If historical conversation is useful, I may pass a structured summary rather than every raw message. When facts must be current, the skill should retrieve them at execution time rather than trust an old snapshot.
The tradeoff
Selective context means additional retrieval design and occasionally an extra tool call. The alternative is cheaper to build but much harder to govern and usually more expensive to run at scale.
The evidence I would look for
I would look for lower prompt sizes without quality loss, fewer errors caused by stale or conflicting information, and clearer data-access reasoning. It should be possible to explain why a skill had access to a particular customer record or document.
The reusable lesson
Context is a permissioned dependency, not an unlimited memory dump. Give a skill the information required for the responsibility it owns.
The consultant's questions
- What information does this skill actually need to succeed?
- Which context is loaded because it is useful and which is loaded simply because it is available?
- How does the skill distinguish current authoritative data from old conversational context?
- Could sensitive information be removed from this skill without reducing its usefulness?