Knowledge & Tenure

The Amnesia Problem

Every agent session starts cold. The model has no memory of what happened yesterday, what conventions your team follows, what mistakes were made last month, or what the client prefers. You’re re-onboarding the same worker every morning.

This is fine for stateless tasks (translate this text, format this data). It’s a fundamental problem for knowledge work. A contract reviewer who doesn’t remember what the client flagged in the last review isn’t a contract reviewer. They’re a stranger with legal training.

Tenure Changes Everything

DWS’s knowledge model gives workers tenure: the ability to accumulate institutional knowledge across sessions. At run 1, the worker knows what you told it. At run 1,000, it knows things it learned from experience, things no prompt could contain.

This is the same pattern that makes a senior employee more valuable than a new hire. The senior employee has context. They know which client is sensitive about certain clauses, which API is unreliable on Fridays, which team lead wants executive summaries instead of detail. That context was earned through experience, not provided in an onboarding document.

Three Knowledge Layers

Session context is ephemeral. It covers the current execution: the active intent, intermediate results, decisions made during this run. It does not persist beyond the session boundary unless explicitly promoted.

Institutional knowledge persists across sessions. It includes:

• Decisions made during past executions, with rationale.
• Patterns observed across multiple sessions (e.g., “this API returns rate-limited responses faster when using the Retry-After header”).
• Conventions the organisation follows (coding standards, brand voice, approval chains).
• Constraints the organisation enforces (compliance rules, security policies).
• Failure modes that have been documented when things went wrong.
• Lessons derived from verification findings.

Each entry has a confidence score, a decay model, and a scope (which workers, domains, and workflows it applies to). Entries that aren’t referenced lose confidence over time and are eventually retired.

Domain knowledge is external reference material: documentation, codebases, regulatory texts. Read-only and versioned.

How Knowledge Compounds

1. Worker executes an intent, producing events along the way.
2. Events generate candidate knowledge entries (e.g., a verification finding that identifies a recurring issue becomes a failure_mode entry).
3. Candidate entries are evaluated against promotion criteria (minimum occurrences, minimum confidence, minimum distinct sessions).
4. Entries that meet the criteria are promoted to institutional knowledge.
5. Promoted entries are loaded into future sessions, making those sessions more informed.
6. The dws reconcile tool proposes git commits incorporating promoted entries into the worker definition. A human reviews and merges.

This loop means that a worker deployed for six months has a knowledge base that a freshly created worker does not. That knowledge base is the worker’s employment record. It cannot be replicated without equivalent deployment history.

Knowledge and the Marketplace

When you publish a worker to the marketplace or transfer it between organisations, the knowledge travels with it (subject to data classification rules). A marketplace worker with accumulated institutional knowledge is fundamentally different from a template. It carries experience.

Knowledge entries are classified (public, internal, confidential, restricted) to govern what can be exported. Confidential and restricted entries stay with the originating organisation. Public and internal entries can be shared.