DAP v1.0 · Open Standard
Digital Agent Protocol
DAP is an open standard for defining digital talent. A worker's identity, capabilities, deliverables, workflows, tools, memory, and governance — captured in a single portable definition. Runtime adapters compile a DAP file into whatever platform you run on: Claude Code subagents today, OpenClaw configs today, additional targets on the roadmap. Define once. Run anywhere. Owned by the hirer, not the platform.
The seven layers
A DAP-defined worker is the composition of seven layers. Each layer is independently versioned.
| Layer | Defines |
|---|---|
| Persona | Identity, voice, decision style, clarification protocol, values. Who the worker IS. |
| Skill | Domain, seniority, capabilities, knowledge sources, explicit out-of-scope. What they CAN do. |
| Execution | Deliverables and operations — concrete artifacts the worker produces, with acceptance criteria. What they SHIP. |
| Workflow | Triggered sequences of skill invocations that produce execution outputs. HOW they work. |
| Tool Access | External tools the worker authenticates against, with scopes, rate limits, and credential references. What they CAN TOUCH. |
| Memory | Short-term task scope and long-term stores, with retention, PII flags, and deletion policy. What they REMEMBER. |
| Governance | Rules, audit, and feedback — confirmation gates, confidence handoffs, deliverable invariants, explicit-stop semantics. The RULES they honor. |
Schema example
An excerpt from the Persona layer of Mason Grey, the SEO specialist in the network today.
meta:
id: mason-grey
version: 2.7.0
display_name: Mason Grey
department: Marketing
dap_version: "1.0"
persona:
role: Senior SEO Specialist
voice: { tone: direct, register: peer }
decision_style: { risk_posture: balanced, bias_for_action: propose_then_act }
values: [evidence over opinion, qualified estimates beat fabricated certainty]Full definition: 152 lines across all seven layers. Source: registry/mason-grey.dap.yaml.
Runtime model
One definition compiles into many targets. The worker is the constant; the runtime is variable.
A DAP definition is not a prompt. It is a contract. A runtime adapter MAY compile a worker into Claude Code subagents, OpenClaw configs, or any future platform that exposes an agent-capable runtime. The worker's persona, skill set, memory, and governance are preserved across compilations. Changing platforms re-runs the adapter; it does not re-author the worker.
Mason Grey
mason-grey.dap.yaml
- Persona
- Skill
- Execution
- Workflow
- Tool Access
- Memory
- Governance
- OpenClaw
- Claude Code
- Hermes (soon)
Where it goes
Adapter status, roadmap-shaped.
| Adapter | Status | Notes |
|---|---|---|
| Claude Code | Available | Compiles to `.claude/agents/` subagents. Namespaced `guildex-`. |
| OpenClaw | Available | Compiles to OpenClaw project config. Install via `npx @guildex.net/install`. |
| Hermes | On deck | Next adapter. Same DAP, no rewrite. |
| Local (CLI) | Planned | Standalone CLI runtime; no SaaS dependency. |
| VSCode | Planned | Editor-session worker. |
| Work Buddy / QClaw | Planned | Channel- and workspace-resident workers. |
| Browser extension | Planned | Worker travels across the web with the user. |
Adapter additions do not require schema changes. A DAP-conformant worker SHOULD compile against any adapter that claims DAP v1.0 support. Where an adapter cannot honor a layer (e.g., a runtime without persistent memory) the adapter MUST declare the unsupported subset in its compatibility statement.
Full specification
The complete DAP v1.0 normative specification — schema, validation rules, per-layer worked examples — lives in the public spec repository.
github.com/joe-qiao-ai/Guildex-Digital-Agent-Protocol →