Context engineering

A note on what this page is: the product is the calendar — the thing that remembers your kids' schedule for you. This page is one level down, for the curious: how that agent is built well. The model is fixed. We don't train it, and most days we don't even change its settings. The only thing we control — and therefore the entire craft of building a good agent — is what the agent perceives on each turn. That's context engineering, and it's how Dustav is made to work.

Generated vs stored

Everything that goes into the agent's context is one of two kinds, and keeping them separate avoids a whole category of bugs:

• Stored content is owned by the household and written down per agent: the facts knowledge base, the calendar, the notes. This is the household's state — the stuff that should persist and change over time.
• Generated content is owned by the platform and composed fresh on every load: the Charter, the operating manual, the live tool catalog. It's never frozen into a per-agent copy.

The reason is drift. If the platform's rules or tool list were copied into every agent at creation, then improving them later would mean migrating thousands of stale copies. By generating them at load time, every agent always runs the current version, and there's no migration debt. The rule of thumb: mechanics get generated; state gets stored.

The constitution sits on top

Context is assembled in a deliberate order, and at the very top sits the constitution: a visible Charter (how to be a good agent) and a hidden safety floor. Putting them first means they frame everything the agent reads after. (The constitution covers what's in each and why only one is public.)

Built to stay cheap and bounded

A long-running household agent can't grow its context forever — that would make every message slower and more expensive without end. So the assembly is disciplined:

• History is loaded as a bounded window of recent turns (a sort-by-newest, limit query — the cost scales with what we keep, not with how long the household has used it).
• The durable facts don't grow without limit; the agent keeps them tight rather than accreting a diary.
• The stable parts of the context are arranged so they can be cached between turns, and the volatile parts (live calendar state, the latest facts) are placed where they don't blow that cache away.

These aren't premature optimizations. On a per-message-billed product running a frontier model, context size and the number of round-trips are the two biggest cost levers, and we treat them as first-class — the full accounting is on cost & caching. The honest version of "we care about cost" is a visible price in the product itself: a forcing function that dares the agent to be worth it.

Every hard bug is a context bug

The throughline: when the agent gets something wrong — forgets something, claims it did something it didn't, narrates instead of acting — the fix is almost never "prompt it harder." It's almost always "fix what the agent perceived." Get the context right and the behavior follows.