Introduction
The Problem
You wouldn’t hire someone without a job description. But that’s exactly what we do with AI agents.
Today, when you want an AI agent to do work, you write a prompt. Maybe a good one. But that prompt is:
- Disposable. It works once, then it’s gone. No versioning, no sharing, no building on it.
- Incomplete. It describes what to do right now, not who the worker is, what it’s allowed to do, how to verify its work, or what it should have learned from last time.
- Unverifiable. There’s no structured way to evaluate whether the output meets the objective. You eyeball it.
- Context-free. Your organisation’s conventions, constraints, and past decisions don’t carry forward. Every session is day one.
The result: you can’t actually delegate to AI. You can prompt it and babysit it. But you can’t hand it a role with clear authority, defined skills, quality standards, and institutional context, then trust it to deliver.
What DWS Is
DWS is an open specification for defining digital worker roles. It gives AI workers the same structural foundation that humans have operated within for centuries: job descriptions, standard operating procedures, training materials, and performance reviews.
A job spec is a portable, declarative definition of a digital worker’s role. Written in JSON, readable by humans, executable by any compliant runtime.
What a DWS Defines
| Concept | What it does |
|---|---|
| Worker Identity | Who the worker is: name, domain, role, authority level, boundaries |
| Skills | What it can do: composable, versioned units of capability |
| Intent | What it’s working on: structured objectives with success criteria |
| Outcome | What it produces: delivery contracts with routing and verification |
| Workflow | How it works: phased execution with verification and approval gates |
| Knowledge | What it knows: session context, institutional memory, domain references |
| Verification | How work gets checked: independent evaluation against codified intent |
| Coordination | How workers collaborate: task delegation, dependency management |
| Interaction | How it works with humans: check-ins, questions, feedback channels |
| Approval | Where humans decide: authority gates at critical decision points |
| Events | What gets recorded: structured telemetry for observability and learning |
| Compliance | How governance maps to regulation: EU AI Act, NIST, ISO 42001 |
The Job Description Analogy
Everything a hiring manager puts in a job spec has a direct equivalent in DWS:
- “Your role is code reviewer” = Worker identity
- “Don’t touch production” = Boundaries and guardrails
- “Follow this review process” = Workflow
- “Here’s how we do things here” = Knowledge
- “Your work gets peer-reviewed” = Verification
- “Get sign-off before merging” = Approval gates
A job spec can be simple (a single worker with one workflow) or sophisticated, with multiple specialist workers coordinating through structured handoffs. From the outside, it’s one role with a clear mandate.
Design Principles
- Specify structure, not intelligence. DWS defines how intent is represented and how artifacts flow. It does not define how workers think. The structural layer is the spec. The intelligence layer is where implementations compete.
- Minimal viable primitives. Each primitive justifies its existence by being referenced by at least two other parts of the spec. If it stands alone, it’s a feature, not a primitive.
- Domain-agnostic by construction. Every schema works for engineering, marketing, finance, legal, or any other domain without modification.
- Human-readable, machine-executable. Worker descriptors read like job descriptions. Intent artifacts read like work orders. Verification results read like performance reviews.
Getting Started
- Quick Start — Create and validate your first job spec
- Key Concepts — Understand the core ideas
- Project Structure — Read the foundation spec