K12 AI Agents
What K12 Agents Exist Today?
The K12 platform no longer uses a single generic editing agent plus a small QRG pipeline. It now exposes three K12 agent families:
- EOP annex and planning agents for district planning, facility planning, hazard annexes, functional annexes, and the legacy annex route.
- QRG agents for classification, role extraction/mapping, generation, and editing.
- Turn-based evaluation agents for scenario-quality testing of multi-turn conversations.
In total, the current K12 domain loads 13 agents:
- 7 annex/planning agents
- 5 QRG agents
- 1 turn-based conversation evaluator
Agent Families
| Family | Count | Purpose |
|---|---|---|
| EOP Annex and Planning | 7 | Edit or generate district plans, facility plans, hazard annexes, functional annexes, and role-suggestion variants |
| QRG Pipeline | 5 | Convert annex content into Quick Reference Guides and edit generated QRG content |
| Testing and Evaluation | 1 | Score multi-turn scenario runs and report quality failures |
EOP Annex And Planning Agents
These agents all belong to the same K12 annex workflow family, but they are no longer one shared external behavior surface. Each route now maps to a dedicated scenario/agent profile.
| Agent | Registry ID | Main Use |
|---|---|---|
| Legacy K12 Safety Agent | eop-k12-safety-agent | Backing agent for the legacy annex kickoff route |
| District Planning Agent | k12-district-planning-agent | District-level planning sections and district-wide EOP content |
| Facility Planning Agent | k12-facility-planning-agent | Facility-specific planning content and site-level adaptation |
| Functional Annex Agent | k12-functional-annex-agent | Standard functional annex editing |
| Hazard Annex Agent | k12-hazard-annex-agent | Standard hazard annex editing |
| Functional Annex Role Suggestion Agent | k12-functional-annex-suggest-roles-agent | Suggest roles and responsibilities for functional annexes |
| Hazard Annex Role Suggestion Agent | k12-hazard-annex-suggest-roles-agent | Suggest roles and responsibilities for hazard annexes |
What changed from the older model
The older model treated K12 annex editing as one main agent with downstream prompt variation. The current model keeps a shared implementation layer, but externally it behaves as dedicated agent profiles and routes for:
- district planning
- facility planning
- functional annex editing
- hazard annex editing
- functional annex role suggestion
- hazard annex role suggestion
That matters because each of these routes now has its own:
- agent profile ID
- registry ID
- default prompt variant
- route/tool mapping
How these agents differ
District and facility planning agents
These agents support broader planning content that may reference the accepted EOP role set, but they do not force the stricter role-scoped behavior used by the annex role-suggestion flows.
They are used for:
- district-level plan drafting
- facility-level customization
- general planning edits
- preserving the tone and structure of planning text while adapting it to the local context
Functional and hazard annex agents
These agents handle standard annex editing for the two main annex categories:
- functional annexes for operational procedures such as evacuation, reunification, or continuity
- hazard annexes for specific threats such as tornadoes, intruders, or hazardous materials
They support:
- normal section editing
- adding missing content
- restructuring weak content
- role-aware editing context when the request is role-related
Suggest-roles agents
The suggest-roles routes are separate agent variants, not just a UI label on top of the normal annex editors.
These agents are specifically tuned for:
"Suggest Responsibilities""Suggest Roles and Responsibilities"
They use:
- the current accepted EOP role list
- the accepted organization role universe
They are meant to generate or expand role-based responsibilities without switching back into a generic annex-editing mode.
QRG Agents
The QRG pipeline still uses five agents.
| Agent | Registry ID | Purpose |
|---|---|---|
| Category Classification Agent | qrg-category-classification-agent | Classifies annex content into the emergency or functional category used downstream |
| Group Extraction Agent | qrg-group-extraction-agent | Extracts audience groups from annex content |
| Role Mapping Agent | qrg-role-mapping-agent | Maps extracted groups to standardized K12 role tags |
| QRG Content Generation Agent | qrg-content-generation-agent | Generates BEFORE / DURING / AFTER content blocks for the mapped roles |
| QRG Editor Agent | qrg-editor | Edits generated QRG content while preserving structure |
QRG pipeline flow
The first four agents make up the generation pipeline. The editor agent is used when an existing generated QRG needs revision.
Turn-Based Evaluation Agent
The external K12 surface now also depends on a dedicated evaluator agent for scenario-quality testing.
| Agent | Registry ID | Purpose |
|---|---|---|
| K12 Turn-Based Conversation Evaluator | k12_turn-based-conversation-evaluator-agent | Evaluates multi-turn annex scenario runs, scores behavior, and reports hard failures |
What it does
This agent is not used to edit annexes directly. Instead, it scores conversation quality for the turn-based scenario workflows that test:
- instruction following
- continuity across turns
- grounding in the source content
- role-list preservation
- final output quality
It powers the evaluation layer behind the K12 turn-based testing workflows and the internal K12 test harness.
How Agents Relate To External Endpoints
From an external API perspective, the main K12 agent families map like this:
Important distinction:
- the dedicated kickoff endpoints route directly to the corresponding dedicated annex/planning agent variants
- the legacy annex route still exists, but it is now a compatibility surface over the workflow engine
- the turn-based scenario endpoints are testing workflows, and they use the evaluator agent in addition to the editing agents being exercised
Prompt And Configuration Model
These K12 agents use database-managed agent profiles with code-defined defaults.
That means each agent has:
- a stable profile ID and registry ID in code
- a default prompt shipped in the codebase
- a database-managed prompt/profile layer that can override the default at runtime
This is especially important for the annex/planning family, because the code now carries separate default prompt variants for:
- legacy annex editing
- district planning
- facility planning
- functional annex editing
- hazard annex editing
- functional annex suggest-roles
- hazard annex suggest-roles
So although some of these agents share underlying implementation helpers, they do not all share the exact same runtime prompt.
What To Expect From Agent Outputs
Annex and planning agents
These agents return structured editing responses containing:
- an explanation of what changed
- whether the result is an edit or a direct answer
- edited HTML content or a direct answer payload
Suggest-roles agents
These agents return structured role-oriented HTML content using the accepted role context available to the workflow.
QRG agents
These agents return intermediate or final pipeline artifacts such as:
- classifications
- extracted groups
- mapped roles
- generated BEFORE / DURING / AFTER guidance
- edited QRG sections
Turn-based evaluator agent
This agent returns evaluation JSON containing:
- pass/fail status
- scoring dimensions
- hard failures
- weaknesses
- evidence from the supplied turn trace
Summary
If you are integrating with the current K12 external surface, the main thing to understand is that the system is no longer documented accurately by the old “six agents” model.
The current external reality is:
- 7 dedicated annex/planning agents
- 5 QRG agents
- 1 turn-based evaluator agent
That split is what supports the newer endpoint families, the role-suggestion routes, and the scenario-quality testing stack.