Key Concepts
Workers, Not Agents
DWS defines workers, not agents. The distinction matters.
An agent is a runtime concept: a model instance with tools, executing in a session. When the session ends, the agent is gone. It has no identity that persists, no authority that is structurally enforced, no institutional memory that compounds.
A worker is a governed role. It has a name, a domain, an authority level, boundaries, skills, and an employment record. It accumulates knowledge across sessions. It is verified independently. It is auditable. When you deploy a worker from the marketplace, you get accumulated expertise, not just capability.
When DWS references an “agent,” it means a runtime agent (e.g., a Claude Managed Agent session or a CrewAI agent instance). DWS defines the worker specification that the agent runtime instantiates.
Authority Levels
DWS uses a four-level authority spectrum:
| Level | Label | What the worker can do |
|---|---|---|
| 0 | escalate-only | Gather information and prepare recommendations. Cannot act. |
| 1 | restricted | Act within a narrow, explicitly enumerated set of operations. |
| 2 | supervised | Act on most operations. High-impact operations require escalation. |
| 3 | autonomous | Act on all operations within declared capabilities. Must still log. |
Authority is a ceiling, not a floor. A runtime may constrain below the declared level but must not grant above it. A new worker typically starts at restricted and graduates to supervised through demonstrated reliability.
Knowledge Layers
DWS defines three layers of knowledge:
Session context is ephemeral. It lasts for one workflow execution: the current intent, intermediate results, decisions made during this run. It does not persist unless explicitly promoted.
Institutional knowledge persists across sessions. These are the patterns, conventions, failure modes, and lessons that accumulate as the worker executes work over time. This is what gives a worker “tenure.” At run 1,000, the worker knows things it didn’t know at run one.
Domain knowledge is external reference material: documentation, codebases, API specs, regulatory texts. Read-only within DWS; versioned for reproducibility.
Intent and Outcome
These are the two poles of a worker’s execution contract:
Intent is the work order coming in. It specifies what should be accomplished, what constraints apply, and how success is measured. Intents are authored by humans and evolve during execution as verification reveals gaps.
Outcome is the delivery receipt going out. It specifies what was produced, where it goes (email, CRM, downstream worker, event stream), and what quality criteria must be met before delivery.
Together, they make a worker independently verifiable. The verifier checks the output (Outcome) against the objective (Intent).
Verification
Verification in DWS has three properties that distinguish it from a guardrail or a unit test:
- Intent-referenced. The verifier evaluates against the intent artifact, not its own judgement. The intent defines what “good” means.
- Context-isolated. The verifier sees the output and the intent. It does not see how the worker arrived at the output. This prevents the verifier from rationalising the worker’s choices.
- Structured results. Verification produces typed findings with evidence and recommendations, not binary pass/fail.
Verification is distinct from guardrails (fast inline checks that prevent unsafe actions) and approval (human authority decisions). All three may exist in the same workflow.
The Determinism Model
The intelligence inside a worker is non-deterministic. That’s the source of value. But everything around it is deterministic:
- Authority boundaries are defined and enforced by the runtime. The model is not involved.
- Workflow phase transitions follow a defined graph with defined conditions.
- Escalation routing has defined targets and thresholds.
- Verification gates produce structured verdicts against defined criteria.
- Event emission follows a defined taxonomy. Every action produces a typed event.
- Cost tracking operates against defined budgets with defined alert thresholds.
The routing is deterministic. The workflow is deterministic. The tasks inside each step are non-deterministic. DWS governs everything except the intelligence.
Lifecycle
Workers have a lifecycle analogous to employment:
draft -> testing -> staging -> production -> deprecated -> retired
A worker in testing runs against test intents in a sandbox. A worker in production handles real work. A worker in deprecated still runs but new deployments should use the replacement. A worker in retired no longer executes; its knowledge and event history are preserved for audit.
Promotion between stages can require minimum test runs, minimum verification pass rates, and human approval.