Context engineering

A note on what this page is: the product is the inbox work — the reading, the drafting, the remembering. This page is one level down, for the curious: how an agent is built to do that well. The model is fixed; we don't train it. The only thing we control — and therefore the entire craft — is what the agent perceives on each turn. That's context engineering, and it's how Dustav is made to work.

One agent, many runtimes

"Dustav" is really one agent definition composed into several runtimes, each assembled fresh per turn from a list of typed capabilities. The interactive Dustav you chat with carries the full toolset. The inbox reader that decodes each email runs a leaner assembly built for exactly that job — free to investigate (search the mailbox, read the thread) but shaped so its conclusions land as structured card fields, not prose. The reconciler reads your sent mail and closes loops. The morning run wakes once a day, checks each scheduled workflow against your real tables and calendar, and drafts what's due — with tools that can read and draft but structurally cannot send. And the narrow jobs — extracting workflow rows, reading an uploaded file into text, writing a reminder in voice, judging a claim — run as sealed one-shots that see only what their job needs.

That last discipline is load-bearing: the workflow extractor sees the email and your column rules, nothing else — because context that helps a conversational agent reason is exactly what tempts an extractor to fill a column from memory instead of from the email. Narrowness is the accuracy feature.

Generated vs stored

Everything in a context is one of two kinds, kept strictly separate:

• Stored content is the business's state, written down: the facts knowledge base, the tables, the documents, the mail it has read.
• Generated content is the platform's mechanics, composed fresh every turn: the operating frame, the tool catalog, the rules.

The reason is drift. If the rules were copied into every business at creation, improving them later would mean migrating stale copies forever. Generated at load time, every business always runs the current version. Mechanics get generated; state gets stored.

Lean by construction

A long-running agent can't grow its context forever. History loads as a bounded window; the facts stay tight rather than accreting a diary; there is no identity prose, no persona files, no relationship memory — an agent doing a job, not maintaining a self. And the stable parts of every context are arranged into cacheable spans, with the volatile tail placed where it can't blow the cache away — the economics of that are the whole next page, cost & caching.

Every hard bug is a context bug

The throughline: when the agent gets something wrong — misses a thing it was told, claims an action it didn't take, fills a field it had no source for — the fix is almost never "prompt it harder." It's "fix what the agent perceived." A required output with no available source will get filled; the cure is making sure the source is in view or the requirement is gone. Get the context right and the behavior follows.