How Dim Gives AI Agents an Input Guide: Meta Prompts, State, and Timeline

By duskzhen

Just after midnight on November 3, at 00:00:22, a local Dim session appended the day's date state. By the next model call, both dates appeared in the request:

<dim-state source="dim/environment/date">2026-11-02</dim-state>
<dim-state source="dim/environment/date">2026-11-03</dim-state>

The requests on either side of midnight (main #1910 and #1930) used the same System Prompt. The new date arrived in the messages, while the old date remained in the history. How should the model know which one means today?

The answer is Dim's Meta Prompt: an input guide supplied with each request in the Rust implementation. Its System section has a direct title, How to read your input. One of its rules says that a later state from the same source supersedes the earlier current value.

Why send environment state separately?

If today's date were inserted directly into the System Prompt, crossing midnight would require a new System version. The date, runtime environment, and available skills change on different schedules. Binding those values to the rules for interpreting them would force the prefix to change whenever any value changed.

Dim separates the instructions for reading an input from the input itself:

• System tells the model how to interpret state.
• Messages carry current values with their sources; updates have their own source and order.

To investigate the environment of an earlier request, you can follow the Timeline back to the inputs used at that point. Input guide and state definitions

If both messages have the user role, who said what?

Consider another recorded sequence. A background command finished, Dim recorded exec/ended at #413, then wrote a notification containing <dim-notification> at #414. Once consumed, that notification appeared in the model request at #421 with the API role user.

The human operator's own words also use the user role. The role alone cannot distinguish them. Dim sends the notification as a separate message with a runtime marker, and the guide explains its origin and meaning. A background completion notice is a result of earlier work; the model should relate it to its current task and decide whether it needs to read the full output. Message projection implementation

Branches follow the same principle. In another recorded sequence, a child timeline inherited the main timeline's history through #97. Its first model request contained both the inherited messages and a newly written branch identity block. That block also arrived in a user message; the guide explained that it described the current timeline.

One agent can have several timelines. The model needs an input that tells it which one it is on.

The diagram divides the model's input into eight categories:

1. System prefix
2. Rules and state
3. Tool declarations
4. Runtime inputs
5. User inputs
6. Tool results
7. Compressed context
8. Input guide

State describes the current situation. Rules have their own scopes. Files, web pages, and command output returned by tools are material for the model to analyze. The guide explains how to read each kind of input. Runtime permission checks still happen in the runtime: a marker identifies a source; it does not grant authority.

Who writes the guide for a new plugin?

Take background execution as an example. The capability that produces a notification also registers the explanation for that notification. Prompt combines shared guidance with the entries applicable to the current branch. A plugin registers its explanation when loaded and withdraws it when unloaded. Once the configuration adopts the change, subsequent requests use the updated guide.

Three model calls on the main branch of one session. The blue sections show the guide delivered in System each time; the message excerpts show a date update, a branch message, a background notification, and compacted context.

This matches the way Dim assembles capabilities with rutis. When a new capability sends messages to the model, its developer can maintain the marker, meaning, and explanation in the same component. Core owns the shared reading rules; each capability owns the content it introduces. Guide registration and composition

What can the model understand with this guide?

The Meta Prompt does more than explain one message. It helps the model maintain an accurate picture of its environment. Follow the main Timeline in the diagram above:

• Configuration: Prompt combines the shared guidance and registered plugin entries into Guide A. At context/configured, that guide is adopted in System.
• Request 1: Messages include a project rule (<dim-rule>) and the current date (<dim-state>). The model can see both the rule it should follow and the date.
• Request 2: A date update (<dim-state>), branch message (<dim-branch-message>), and background notification (<dim-notification>) arrive in order. The model can tell that time has advanced, another timeline has sent a message, and a task has finished.
• Request 3, after compaction: A history summary (<dim-summary>) and tool digest (<dim-digest>) replace older detail, while currently effective rules and state are reaffirmed. The model can distinguish past events from conditions that still apply.

All three requests use Guide A in System. The Messages change. The reading rules stay stable while the environment moves through the input stream.

In concrete terms, the model can track:

• Time: which date is current, without mistaking an earlier date for today.
• Rules: which project rules still apply and what their scopes are.
• Position: which branch and timeline it is on.
• Events: whether a background command finished or another timeline sent a message.
• History: after compaction, what happened earlier and what still governs the present.

These are no longer stray lines mixed into a conversation. They form an account of the environment with a source, an order, and a reading guide.

How do rules change midway through a session?

So far, the examples have started from an already configured guide. In a real session, a plugin can be enabled or disabled midway, and rules can become active or expire. Two questions need separate answers: how should the model read a kind of content, and which specific content is currently effective? Dim handles those through different channels.

Reading rules: register with a plugin, withdraw with it

When a plugin is enabled:

1. It registers the markers it will emit, their meanings, and their explanations.
2. Prompt recombines the shared guidance with those entries into a new guide.
3. After configuration adoption (context/configured), subsequent requests use the new System.

Disabling it reverses the sequence: the plugin unloads, its explanation is withdrawn, Prompt recombines the guide, and later requests stop carrying that explanation.

This ordering puts the explanation in place before the content appears. It also prevents the model from continuing to interpret new input using withdrawn guidance. Earlier requests are not rewritten; the Timeline still records which guide version each one used.

Current content: append new rules, expire old ones within their scope

Rules and state do not rewrite history either. They are appended. The op on a <dim-rule> describes what happens to that rule:

• set or replace makes the rule in the block effective; replace identifies the currently adopted version.
• revoke or expired makes that rule ineffective within its scope. A rule with the same name in another scope is unaffected.

State is simpler: a later value from the same source supersedes an earlier one. A state block with cleared="true" says that state no longer applies.

Adding a rule during a session means appending an effective block. Removing one means appending a block that marks it ineffective. The old block remains in history; the model uses the latest block for the same source and scope. The two dates at the start of this article work the same way.

After compaction, expired rules stay expired

When compaction happens, subsequent state blocks reaffirm only the rules and state still effective at that moment. Each is restated in its most recently delivered form, such as a replace block for the adopted rule version. A revoked rule is absent, so the model does not treat it as current again. The guide also says these reaffirmations confirm the current situation: they are not new changes and do not grant permissions.

Which state survives compaction?

Return to the session that crossed midnight. Later, #2025 recorded a successful context compaction. The next model request, #2026, carried the summary and then reaffirmed five rules and state values still effective at that point. Of the two dates, only November 3 remained as current state.

The two parts have different jobs. The summary describes what happened before; the subsequent state blocks describe the conditions the model should keep working under. The input guide explains that these restatements mean the earlier rules and state are still effective.

To see exactly what a model received at a given moment, return to that request and compare its adopted guide, state, and retained history. Post-compaction message projection

Editorial note: AI tools assisted with the English adaptation and illustrations.