Skip to content

Direction A scoping: per-intent system-prompt narrowing (#89 follow-up; composes with devagentic#237) #97

@PowerCreek

Description

@PowerCreek

Follow-up scoping issue for #89 Direction A. devagentic#240 (R1 classifier) has landed, so the upstream primitive is ready — this issue scopes the hermes-side narrowing work itself.

Background

#89 documented that the default hermes system prompt overwhelms tool-emission on mid-tier coding models (coding-groq, coding-gpt54). Direction A proposed per-intent narrowing — strip identity/SOUL/capabilities/behavior fragments from the system prompt when the classified intent is a tool-call-heavy case where the affected models hit saturation.

devagentic#240 ships a 6-key heuristic classifier ({code, confer, planning, exploration, refinement, generic}) — already merged + deployed. The classifier output is wired into devagentic's R5 dispatch hook but not surfaced to the hermes-side prompt builder. Direction A needs the same classification on the hermes side.

Composition options

Option A1 — port the classifier

Duplicate the heuristic into hermes_cli/intent_classifier.py mirroring devagentic's intent_classifier.py. Cheapest engineering; risks drift between the two copies.

Option A2 — devagentic-side surface

Expose classifyIntent(messages, role) as a devagentic GraphQL query; hermes calls it before assembling the system prompt. Single source of truth; adds a network round-trip per llm_call (latency on the hot path).

Option A3 — operator-supplied intent

Add HERMES_INTENT_OVERRIDE env var the operator sets per worker (e.g., HERMES_INTENT_OVERRIDE=code for a coding-only worker). No classifier on hermes side; narrowing decisions are static per deployment. Cheapest, least general; useful for the polynomial-explorer-style verticals where intent is known a priori.

Recommended order: ship A3 first (single env-knob, no classifier coupling, immediately unblocks deployment-specific narrowing). Defer A1/A2 until a use case shows up that needs dynamic per-turn classification on the hermes side.

Narrowing target — agent/system_prompt.py

The system prompt is assembled into 3 layers (see the module docstring at agent/system_prompt.py:10-20):

Layer Contents Narrowing applicability
stable identity, SOUL.md, tool guidance, skills prompt, environment hints, model-family operational guidance Primary target. Identity + tool guidance + skills prompt + model-family guidance are the bulk of the saturation envelope.
context caller-supplied system_message + AGENTS.md/.cursorrules Out of scope — caller controls these.
volatile memory snapshot, USER.md, timestamp Out of scope — small mass, per-turn anyway.

Specific candidates within stable to narrow when intent=code:

  • SOUL.md / DEFAULT_AGENT_IDENTITY block (largest single contributor)
  • HERMES_AGENT_HELP_GUIDANCE
  • SKILLS_GUIDANCE (large if many skills loaded)
  • KANBAN_GUIDANCE / SESSION_SEARCH_GUIDANCE (off-topic for code-only)
  • MEMORY_GUIDANCE (small; could keep)
  • Keep: TOOL_USE_ENFORCEMENT_GUIDANCE (critical for tool-emission)
  • Keep: per-model operational guidance (e.g., GOOGLE_MODEL_OPERATIONAL_GUIDANCE)

Concrete first-PR scope (Option A3)

  1. New env var HERMES_INTENT_OVERRIDE — operator-side, valid values per devagentic#240's enum: code / confer / planning / exploration / refinement / generic.
  2. build_system_prompt_parts(agent, system_message) opt-in narrowing: when env is set to a known intent, swap to a narrowed stable layer (drop SOUL.md + SKILLS_GUIDANCE + KANBAN + SESSION_SEARCH + MEMORY guidance; keep identity-as-fallback + TOOL_USE_ENFORCEMENT + per-model operational guidance).
  3. Doctor probe: surface the active intent override (silent when unset, check_ok when set+valid, check_warn when set+unknown — mirroring my doctor: validate HERMES_DEFAULT_PROVIDER + HERMES_INFERENCE_PROVIDER env vars #95/doctor: surface active HERMES_TOOLS_SUBSET at boot (#75/#87 follow-up) #96 doctor-probe pattern).
  4. Composition test: with HERMES_INTENT_OVERRIDE=code, the system prompt is < N tokens (set the bar based on baseline).

Acceptance

Out of scope

References

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions