Skip to main content
You shouldn’t have to tell an agent “don’t forget rule X, don’t forget rule Y”. 2501 figures out what’s relevant when a ticket arrives and injects only that. This is what makes specialties stay polyvalent and rules stay focused: the right rules show up at the right time, and irrelevant ones stay out.

​
What is dynamic vs static

ResourceBehavior
Agent’s hostStatic — set at agent creation; an agent can’t change host mid-task
SpecialtyStatic — set at agent creation; can’t change mid-task
Which agent gets the ticketDynamic — the gateway picks per-ticket based on host and intent
Operational RulesBoth — tag-matched programmatically, plus dynamic top-ups from the gateway and the agent
Host Knowledge factsAlways available when working on that host
BlacklistRuntime check, never injected. Each command is screened before execution.

​
How injection happens

Ticket arrives
   │
   ▼
Gateway batch-reads hosts & agents → picks the relevant ones
   │
   ▼
Tag-matched operational rules + host knowledge attached  ◄── programmatic
   │
   ▼
Gateway may inject additional rules it judges relevant   ◄── dynamic
   │
   ▼
Agent receives the task with all of the above
   │
   ├──▶ Agent may pull additional rules / facts mid-task ◄── dynamic
   │
   ▼
Tool calls go through the blacklist on each command       ◄── programmatic
Three injection points; three layers of safety:
  1. Tag matching at dispatch — fully deterministic. A rule with os:linux + procedure:restart lands on every Linux restart task.
  2. Gateway top-up — the gateway can attach non-obvious rules it noticed in the ticket text. This is the LLM-judgment layer that catches what tags can’t.
  3. In-task pull — if the agent encounters something it isn’t sure about, it can search for rules and facts mid-execution.

​
Why this matters

Without dynamic context injection, you’d be writing giant specialties that try to cover every edge case, or massive operational rules that fire on every task. Both bloat the agent’s context and degrade decisions. With dynamic injection, you keep each rule small and specific, and trust the matching layer to surface it when it matters.

​
How to think about it as an author

  • A specialty teaches the style — polyvalent.
  • An operational rule encodes truth about your env — small, specific, well-tagged.
  • The matching layer does the work of choosing which rules apply to a given ticket.
  • If a rule isn’t reaching the tasks you expect, the matching trace on each task’s detail page tells you which rules matched and which were skipped, and why.