Follow the source.
Claims retain links to the authorised material they came from, so a brief can be traced back to the information behind it.
Loading ATMAI
Dreamer
The next answer starts with the right context.
Dreamer constructs task-specific context for AI agents from information whose sources and revisions remain inspectable.
Plans are revised. Decisions are superseded. Sources disagree. Dreamer brings structure to that changing information and assembles context for the task at hand.
How a new decision changes the context
Illustrative example
Follow a decision as it changes.
Source history
Monday · Project brief
Launch the pilot on Friday.
Invite the existing pilot group.
Current context
- Pilot launch:
- Friday
- Scope:
- the existing pilot group
Trace it to the source
Source history
Monday · Project brief
Launch the pilot on
Friday.
Invite the existing pilot group.Launch date superseded
Tuesday · Updated decision
Move the pilot to Tuesday.
Keep the original scope.
Current context
- Pilot launch:
- Tuesday
- Scope:
- unchanged
Trace it to the source
Source history
Monday · Project brief
Launch the pilot on
Friday.
Invite the existing pilot group.Launch date superseded
Tuesday · Updated decision
Move the pilot to Tuesday.
Keep the original scope.
Context for the next task
Task brief
Prepare a launch update for the existing pilot group. Use Tuesday as the launch day.
Trace it to the source
Inside Dreamer
Information changes. Context should account for it.
A revised deadline changes a plan. A new condition changes when a decision applies. Dreamer works with versioned statements, their sources, and explicit rules for what reaches the next task.
Understand the change.
Revisions preserve a history of decisions. A new plan can take precedence while the earlier plan remains available to inspect.
Keep disagreement visible.
Conflicting claims carry an explicit state. Unresolved information stays visible for further evidence or human review.
Make room, keep a way back.
Reversible archival moves lower-priority claims out of the working context while preserving a route to restore them.
The construction process
From recorded claims to working context.
The core process starts with prepared claims linked to their sources. It applies explicit rules to those claims, then selects information for a particular task.
Source-linked claims
Prepared statements carry their source references and the information needed to inspect them.
Admission and revision
Rules govern which claims enter the record, which versions are current, and how conflicts are represented.
Task-specific selection
The current task and configuration shape which information enters the available context budget.
Context with references
The resulting context packet is accompanied by source references for inspection and downstream use.
Preparing claims from arbitrary text is a separate step. The core does not guarantee a lossless conversion of every document or conversation.
What deterministic means here
With the same prepared inputs, configuration, time, and software version, the core process is designed to reproduce the same construction. The model’s answer is a separate result, with its own evaluation.
The research question
How small can useful context become?
We study how to make context smaller while preserving the facts and relationships a task depends on. Who did something, when it happened, and under which conditions can matter as much as the statement itself.
The work combines mathematical study, deterministic software, and controlled and adversarial experiments. A useful result has to preserve what the task needs; in some cases, passing through the original context may be the appropriate choice.
- Memory
- Information retained over time, with a record of its sources and changes.
- Context construction
- The selection and arrangement of information for the task being performed now.
- Compression
- A measured reduction in size. The reduction may be zero; usefulness must be evaluated alongside it.
Evaluating the difference
The same task. A clear comparison.
Compare the same task, source material, and model with and without Dreamer’s context construction. This makes the question concrete: what changed in the answer, and what did that change cost?
Original context
Provide the baseline context to the model and record its answer and resource use.
Constructed context
Provide Dreamer’s context for the same task, then evaluate the answer using the same criteria.
- Task success
- Did the answer satisfy the task’s requirements?
- Source support
- Are the answer’s claims supported by the supplied information?
- Input and output tokens
- How much context went in, and how much output came back?
- Construction cost
- What did preparing and constructing the context consume?
- Added latency
- How much time did context construction add to the request?
- Request handling
- Which requests were transformed, and which passed through unchanged?
An evaluation should report these measures together. A smaller prompt is useful only in relation to the task outcome and the total work required to produce it.
Where we are
Built through research. Evaluated in context.
Dreamer is internally usable, with support bounded to tested tools and authorised sources. Current work evaluates the relationship between context size, answer quality, and the cost of constructing context.
A focused evaluation
Begin with a specific task, its source material, and a definition of success. The evaluation scope and supported integration need to be agreed before measuring the outcome.
Current access
There is no public self-service API today. A conversation with the team is the starting point for understanding fit and the scope of an evaluation.
What remains open
Structural checks and model-assisted grounding do not establish the truth of every claim. Quality and context savings depend on the task and need to be measured together.
What should your agents carry forward?
Tell us how your team uses agents, where context gets lost, and what a useful outcome would look like.
Discuss your use caseExplore the research