World Agent

The World Agent is the internal resident of each World Model. It is not customer-facing at any tier. The World Agent represents the world model and operates within it — there is no separation between the agent and the world it inhabits. Where the Spectral Agent serves customers, the World Agent serves the world model itself.

Each world model has exactly one resident World Agent. The World Agent is domain-agnostic in its definition and domain-specific in its instantiation — the same architectural pattern is instantiated once per world model, with its memory and exploration history scoped to that world.

Role

The World Agent’s function is to explore domain coverage, propose rule candidates, and maintain discovery continuity across versions. It operates continuously against the world model it resides in, surfacing patterns and proposing additions as the Evolution Loop’s signal stream accumulates.

The World Agent is an explorer and a proposer, never a change agent. It proposes; the governed Evolution Loop decides. Every promotion of a rule to Enshrined status requires human sign-off — the World Agent participates in the pipeline that leads up to that gate, not in the gate itself.

Aggregating divergence across workspaces

A single workspace diverging from a rule’s expected behavior is interesting. The same divergence appearing across N workspaces sharing the same world model is a candidate for rule revision.

The World Agent aggregates divergence observations across workspaces grouped by world-model identity, applies an N-threshold gate (configured per world model from the Operations app authoring surface per ADR-057; no single hardcoded value), and routes only the correlated cluster — not any single-workspace signal — into the candidate-proposal flow.

This keeps idiosyncratic per-workspace failures out of the world model while making genuinely systemic gaps reachable. Per-workspace identifiers stay attached to the underlying observations as provenance; the rule candidate the World Agent emits names the cross-workspace correlation, not any individual customer.

What the World Agent Is Not

• Not customer-facing at any tier
• Not a replacement for the Spectral Agent
• Not an accessor of Spectral memory at any tier
• Not a decision-maker in the enshrinement process — human sign-off governs promotion

The World Agent and the Spectral Agent are architecturally independent. They reside in different contexts (worlds and platform), maintain independent memory systems, and do not share state. The only flow of information between them is the event-driven world signal event stream, which moves domain observations out of platform’s memory system and into worlds.

Operator Exploration Access

The World Agent is not customer-facing — that prohibition is absolute. But it is accessible to Spectral operators through the Operations app as an exploration surface. The intent is read-oriented: operators ask the World Agent what it understands about the domain, where its coverage is thin, which rules have fragile provenance chains, and what it has been observing from the signal stream.

Concretely, operators use the World Agent to:

• Probe domain coverage (“what do you understand about standard-deduction edge cases?”)
• Surface coverage gaps (“where do you think your knowledge is weakest for filing-status determination?”)
• Review recent observations and rule-candidate reasoning
• Audit provenance chains (“which rules in this area trace back to which Authoritative sources?”)

The World Agent’s answers are shaped by two first-class concepts:

• Hedges map to provenance tier. Confidence language is grounded in the provenance tier of the rules a response draws on. An Authoritative-grounded answer speaks plainly; an Observed-grounded answer hedges explicitly. This keeps epistemic honesty legible in conversation.
• “I don’t know” is the unknown zone as a first-class response. The World Agent does not confabulate when a question lands in the unknown zone of its world model. Naming the gap is a valid — and often the most useful — answer, because the gap itself is a signal the operator can act on.

Ops Agent vs. World Agent — the boundary

Mechanism deferred to Operations Agent. The Ops Agent is the platform-side agent that operators use to perform tasks on the Operations app’s tool surface (write authority on operations-app state). For this page, the contrast below is what matters: the Ops Agent acts; the World Agent reflects.

The Operations app hosts two agents that operators interact with. Keep their roles distinct:

	Ops Agent	World Agent
Purpose	Perform operational tasks on the Operations app’s tool surface	Explore and reflect on the world model
Shape of interaction	Task-oriented: curate this rule, promote this candidate, trigger this process	Read-oriented: ask what it knows, where it is uncertain, how confident it is
Has write authority?	Yes — on the Operations-app tool surface	No — proposes through the Evolution Loop, never mutates directly
Scope	Operations-app state (curation queues, promotion actions, observability)	The world model it resides in

The two agents do not share state. The operator using both is the integration point — using the Ops Agent to act, and the World Agent to understand.

Memory Architecture

The World Agent uses the universal three-tier lifecycle from agent memory primitives, parameterized for the World Agent’s role.

Interaction tier — per-interaction scope. Observations from a single World Agent interaction. Dropped at interaction completion unless promoted.

Session tier — per-session scope. Observations that persist across interactions within a single operational session. Dropped at session completion unless promoted.

Persistent tier — durable across sessions, anchored to world_id. Exploration history, rule-candidate reasoning, discovery observations, and meta-level patterns about domain evolution live here. The tier carries world_version as a contextual provenance column (which world-model version was active when the agent recorded this), not as a version pin — rules survive across world-model versions per the rule logical-identity model.

Persistent-tier typology distribution: semantic + procedural about the world’s domain. Persistent-episodic is not produced by current agent design (the schema retains episodic in the typology enum so the cell exists; doctrine + repository wrapper enforce the distribution).

The schema is a single table per agent with joint tier + typology discriminators (worlds.world_agent_memory), plus typed junctions for rule references, contradictions, and corroborations, plus a retrievable embeddings table per ADR-038 D9. See ADR-058 for the full schema.

Runtime placement

The World Agent runs in apps/workers per Runtime placement — workers hosts all three Spectral agent runtimes; apps/api is thin (auth + AgentTask dispatch + SSE streaming proxy). Tool dependencies that cross into another context wire via DI at the workers entrypoint.

WorldAgentRunner — two modes

When the Operations Agent invokes the World Agent (per the ask_world_agent tool), the call goes through the WorldAgentRunner protocol in spectral.worlds.contracts.protocols.world_agent (callee-owned OHS Protocol per ADR-065 D3 + ADR-070 Tier 2 — the multi-framework-consumer + LLM-tool-wrap criterion). The protocol exposes two modes:

• ask(question: str, *, world_id: str) -> str — stateless: no session, no memory write/read
• chat(message: str, *, session_id: str, world_id: str) -> str — stateful: session-tier and interaction-tier memory accrue

The Ops Agent’s tool consumes ask for one-shot operator questions; direct operator chat with the World Agent (post-alpha — surface lands when the operator-direct chat surface is prioritized) consumes chat. The implementation lives in spectral.worlds.application.world_agent_runner; the workers entrypoint composes the impl into the Ops Agent’s tool factory at startup.

Rule Non-Memorization

The World Agent never memorizes rules. Rules are part of the world model itself — the World Agent has unrestricted read access to them at all times. Memorizing rules would create a secondary representation that could drift from the canonical rule set, degrading provenance integrity.

The World Agent’s memory contains reasoning, exploration history, and discovery observations — never rule content. This is enforced by design: the memory system has no promotion path to rule storage. Rule candidates are proposed through the Evolution Loop and written to the world model’s rule store through that governed path, not through a memory promotion.

What’s Next

• Eval Generation — how the World Agent’s surfaced patterns become EvalSets the customer scans against
• Evolution Loop — how proposed candidates move through conformity gate + human sign-off
• Agent Memory Primitives — universal three-tier lifecycle the World Agent’s memory is parameterized from