> ## Documentation Index
> Fetch the complete documentation index at: https://docs.2501.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Dynamic Context Injection

> How 2501 chooses what to put in an agent's context — and what stays out

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

| Resource                        | Behavior                                                                                     |
| ------------------------------- | -------------------------------------------------------------------------------------------- |
| **Agent's host**                | Static — set at agent creation; an agent can't change host mid-task                          |
| **Specialty**                   | Static — set at agent creation; can't change mid-task                                        |
| **Which agent gets the ticket** | Dynamic — the gateway picks per-ticket based on host and intent                              |
| **Operational Rules**           | **Both** — tag-matched programmatically, plus dynamic top-ups from the gateway and the agent |
| **Host Knowledge facts**        | Always available when working on that host                                                   |
| **Blacklist**                   | Runtime 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.