Agents & Skills

AEGIS no longer ships a fixed roster of purpose-built agents. Domain capability is delivered by skills reached through skill routers, and domain logic lives in installable packs. Skills, routers, rules, prompts, and settings are tenant-configurable data served by the Agent Config Service (port 8010) — not code and not YAML checked into the repo.

The two seeded agents

New conversations choose between two seeded agents (rows in the agent_definitions table, no YAML file):

The Conversations page offers only general and creator. There is no per-domain agent to pick — General recruits whatever skill the conversation needs.

How routing works

A general-mode conversation does not carry domain skills up front. Instead:

1. Router manifest — the system prompt includes a manifest of active skill routers (the skill_routers table). Each router is an admin-curated recruitment taxonomy entry with a router_key and a recruitment_blurb.
2. pull_routers — the LLM calls this ordinary tool to read the full author descriptions of the skills a router routes to (its approved skill_router_map rows).
3. select_skill — the LLM then loads one skill by skill_key, which injects its Tier 2 specification into the conversation.

Routers are soft-deactivated only (never hard-deleted) so the manifest-delta watermark cannot miss a change. Seeded routers and the skills they route to:

The flaring router carries a watch/file pair: monitoring and status questions route to flaring_watch; preparing an exception application routes to rrc_rule32. The read-only flaring_watch skill also exposes flaring_volume_status and emissions_screening blocks, which reuse the rrc_rule32 code-block implementations under distinct tool names.

HITL travels with the skill

Human-in-the-loop checkpoints are not tied to agent identity. They fire from seeded skill require_hitl rules (an after_tool_call trigger attached to the skill) and from the before_tool_call mutating-tool gate. Because the rule travels with the skill, filing assembly stays gated no matter which agent recruited the skill. Seeded RRC rules:

For rrc_rule32, emissions is a model-supplied calculation, not a filing gate — so there is no emissions HITL rule. The approval_node is fail-closed: it pauses (awaiting_hitl) when a mandatory checkpoint cannot be recorded; only HITL_BREAK_GLASS restores fail-open for a logged emergency.

Skill injection tiers

Skills use a three-tier injection architecture, tracked by the injection ledger (a Redis Hash at skill:ledger:{conversation_id}) to prevent duplicate injection:

• Tier 1 — compact manifest (name, description, trigger keywords). Always available so the LLM knows what routers/skills exist.
• Tier 2 — full skill specification (steps, requirements, output format). Injected on-demand when the LLM calls select_skill.
• Tier 3 — rare artifact content (reference tables, form-field guides, regulatory text). Injected only when the specific skill requires it.

Packs — where domain logic lives

Each compliance domain is an installable pack at services/orchestration-engine/src/orchestration/packs/<name>/manifest.yaml (out-of-tree via PACKS_DIR), discovered at startup. A manifest declares the pack’s skills (descriptors), checklist template, and assessment recipe (a five-verb DSL plus pack-declared Cypher; thresholds resolve from rule_versions). Adding or removing a pack directory needs zero core edits.

RRC ships five packs — the first installed vertical:

The deterministic config-driven assessors (R41_CONFIG_ASSESSORS, ON by default since 2026-07-12) run from these recipes; the legacy imperative RRC assessors in compliance/engine.py remain only as a parity oracle / fallback.

Core tools vs. skill-scoped tools

Every conversation starts with a small set of core tools regardless of agent: entity_resolve (resolve a name to an entity), context_assemble (fetch a resolved entity’s details), and render_chart (present an AEGIS chart, R43). Oil-and-gas tools — spacing_calculation, offset_well_analysis, rule37_filing_assembly, good_cause_narrative, the Rule 32 filing/emissions blocks, and so on — are skill-scoped code blocks: they become available only once the relevant skill is loaded via select_skill.

Budgets and models

Token and cost budgets are two-tier (per-conversation cumulative and per-turn) and enforced by orchestration/budget.py; see the Budget glossary entry. The effective LLM model is tenant-configured via the Platform Settings admin page (resolution: request override → tenant setting → env floor); the box default is anthropic/claude-sonnet-5. There are no per-agent model or budget YAML files anymore.

Source Files