Background enrichment

Why enrichment was needed

Early work with cheaper models exposed a recurring problem: their command responses were too sparse to make the systems feel real. Ask for a process list and the model would often return a handful of processes it seemed to think the scenario needed. The result conveyed the basic idea of a machine, but lacked the ordinary services, supporting processes, and accumulated detail of a system people actually used.

Repeated prompt changes asking for richer, more complete output did not reliably overcome that pattern. The goal was more than verbosity. A longer answer only helps if its details belong together and give the user something meaningful to discover on the next command.

Enrichment filled that gap by giving the same lightweight models a different job: develop the supporting detail around one part of the world. Freed from answering the immediate terminal command, they could produce convincing processes, files, relationships, and facts that the simulation could retain as anchors for later exploration. This is the development experience that motivated the design, rather than a controlled comparison of every model or prompting strategy.

Less context, more useful detail

One of the surprising lessons was that better results often came from giving the model less background. Asking it to manage the whole simulation could bring back the same sparse answers. Asking it to act as an expert in one field, with one concrete question and the relevant facts, let it concentrate on details it could supply well.

For example, a focused task might ask what supporting processes and operational records fit an established service on a particular kind of host. The Expert needs that technical context. It does not need the whole session history or instructions for managing DREAMLAND’s state. Keeping those responsibilities elsewhere lets a smaller model spend its effort on the subject itself.

This is the reasoning behind the Coordinator → Expert → Integrator split below. The Coordinator selects the question, the Expert develops the detail, and the Integrator checks how that detail fits the current world before proposing an update. A narrow brief still carries the facts and constraints needed to avoid contradicting what the user has already seen.

Finishing the world around the command

The command emulator constructs the hosts, services, and facts needed to answer the foreground command. Enrichment works around that interaction: it can add processes behind an established service, operational files surrounding a workflow, or everyday residue consistent with a host's purpose and history.

Its unit of work is one bounded cluster of net-new, host-local detail. Repeated jobs may deepen the world over time; a per-job limit is a latency and mutation boundary, not a fixed maximum depth for the entire simulation.

Events select when and where to work

The runtime publishes neutral events for session registration, completed commands, host changes, newly materialized state, idle time, and session closure. Deterministic policy turns suitable events into candidates and applies cooldown, rate, coalescing, and in-flight gates before dispatching model work.

A bounded interaction-focus record derived from command syntax and working-directory state can help target a concrete file or surface. These hints guide attention; they do not establish new fictional facts or grant mutation authority.

Closing the session cancels its timers and pending scheduling. A background job is always attached to a particular live session and target host.

Coordinator → Expert → Integrator

1. Coordinator. A scoped initial snapshot supports selection of one useful question and relevant references. The configured trigger policy chooses focused or ambient planning before this role runs.
2. Expert. A neutral domain brief asks for a concrete realization. The Expert supplies candidate details and explicit reference bases, rather than writing directly into DREAMLAND state. It does not receive the full workflow, world registry paths, or patch contract.
3. Integrator. A fresh snapshot and current reference bindings determine which eligible candidates still fit. The Integrator proposes a structured patch against that current state.
4. Runtime checks. Deterministic normalization, validation, and race-aware application decide whether the proposed additions may be committed.

A job can stop with a no-op at several boundaries. Producing no patch is a valid outcome when the references changed, the proposed detail conflicts, or nothing eligible remains. The graph proposes changes; the runtime service owns application.

Focused work and ambient presence

Focused mode

Build a compact cluster around a technical surface the user is approaching: a service, artifact, process, or operational workflow. The objective is a world that has useful connected depth beyond the immediate response.

Ambient presence

Think of arriving at someone’s desk while they are away. A maintenance note, a small script, or a message from a colleague can tell you who works there and what matters to them. Ambient presence adds these traces of life so the world feels inhabited.

Technically, the agent proposes related records and facts about a person, or an equivalent presence that fits the scenario. Those details must agree with the world’s history and make sense for the time they describe. This adds evidence of someone’s life and work; it does not create a character who acts independently or continues doing things as time passes.

The foreground remains authoritative

Candidate reference IDs are explicit dependencies. Before integration, the runtime checks whether each referenced value is still present and unchanged in the fresh projection. A stale reference blocks candidates that depend on it while allowing independent current candidates to continue.

Final apply checks also account for foreground authority and intervening updates. A carefully bounded Integrator refresh can address an eligible foreground-evidence conflict without repeating Coordinator and Expert work.

New details should respect what the user has already seen. If one command fails, enrichment should not turn that into a story that the entire machine is permanently out of memory or disk space. If a later command shows that the problem is fixed, new details should preserve that recovery.

The backend checks the structure of proposed updates and protects existing state. But those checks cannot fully judge the meaning of every sentence the model writes. The agent’s instructions also tell it to keep explanations consistent with the session’s history.

Modes for controlled experiments

Automatic enrichment is enabled in safe mode by default. It runs the proposal pipeline and applies only validated, bounded additions. shadow exercises the workflow without mutating the session, while disabling automatic scheduling provides a no-background-work comparison.

Shadow still incurs model work. Compare latency, tokens, candidate rejection, apply outcomes, and whether later foreground commands actually encounter the added detail. A completed background call alone is not evidence of a better simulation.

Retained enrichment events expose session/job correlation and lifecycle outcomes. API/MCP inspection can connect those jobs to command results and state deltas. Changes disappear with the session unless explicitly saved into a profile.

Its value changes as foreground models improve

As more powerful models have become affordable, the project has needed enrichment less to compensate for sparse command responses. More of that detail can now come from the model answering the command itself. The original motivation has become less pressing, even though enrichment remains part of DREAMLAND.

It remains an interesting solution: small models doing focused work can prepare details in advance or deepen a world between commands. Whether those benefits justify the extra calls and coordination depends on the model, scenario, and interaction. The project’s development experience motivates that question; the existing static world-build study and serving-tier series do not measure enrichment’s incremental benefit.

Compare enrichment off and on with the same foreground model, then examine the detail users actually encounter, consistency across commands, latency, and total session cost. The architecture is worth retaining as a research direction without assuming that every simulation benefits equally from it.

How changing model economics affect the enrichment tradeoff ↗

Beyond filling in detail

The trigger system offers possibilities beyond enrichment. A completed command, a move to another host, or a period of idle time can be a useful moment for another agent to examine the session. Future agents could use those events for different jobs:

• Introduce adversarial changes. A scenario could respond to exploration with a simulated intrusion, a changed service, or evidence of another actor’s activity. This would let an exercise evolve while someone investigates it.
• Guide and monitor users. An agent could notice repeated unsuccessful attempts, track milestones, or offer a timely hint. Guidance could reflect what the user has already explored while leaving room for discovery.
• Analyze intent and progress. An observer could examine command sequences to estimate what someone is trying to do, summarize their investigation, or identify where progress stalled. These would be interpretations to evaluate, not certain knowledge of the user’s intent.

These are future directions, not capabilities of the current enrichment agent. Today’s safe enrichment adds bounded supporting detail and preserves established state. An adversarial agent would need its own permission to change existing conditions; guidance and analysis agents could work without changing the world at all. Each role would need its own context, trigger policy, and evaluation criteria while sharing the event infrastructure.