Archetypes

Version 1.1. DWP recognizes three archetypes. The archetype determines how an agent onboards, how plans are scoped, and whether the machine-readable state layer is required.

Additive in v1.1. The agent workspace (§3) joins as a third archetype: the long-lived home of an autonomous agent. Git becomes RECOMMENDED rather than assumed. The two v1.0 archetypes are unchanged.

Individual repository

A self-contained codebase — an application, a library, or a service. Plans operate directly on the code.

Characteristics:

• Single coherent codebase.
• Plans modify files in this repository.
• .dwp/ workspace at the repository root.

Orchestrator hub

A coordination repository that manages multiple child repositories. Plans may spawn child plans in sub-repositories.

Characteristics:

• Coordinates multiple sub-repositories.
• Plans may delegate to child plans.
• Maintains a registry of managed repositories.
• .dwp/ workspace at the hub root tracks cross-repository state.

Agent workspace

An agent workspace is the long-lived working home of an autonomous agent — an OpenClaw workspace, a Hermes service directory, a personal-assistant daemon’s data directory, or a cloud agent’s persistent volume. It is a workspace, not necessarily a git repository, and its primary product is the agent’s ongoing work rather than one codebase.

The insight that makes this archetype possible: the harness is a workspace, not specifically a repository. Every harness element the methodology defines for a repository has a direct workspace equivalent:

An agent workspace MUST provide AGENTS.md, .agents/, and .dwp/ at the workspace root.

Git is RECOMMENDED, not REQUIRED. Where git is absent, every plan MUST carry the machine-readable state layer: state.json’s checkpoint, gate records, and per-task timestamps carry the recovery information the git log carries in a repository.

Plans in an agent workspace typically run unattended: a scheduled heartbeat or cron turn resumes the open plan via the DWP Resume Protocol, executes the next atomic task, updates the state layer, and yields. The plan — not the session — is the unit of continuity.

Classification heuristic

Repository

? Multiple nested repos or a hub registry?

No

Individual repository

• single codebase
• plans modify local files
• .dwp/ at repo root

Yes

Orchestrator hub

• coordinates sub-repos
• plans delegate to child plans
• cross-repo .dwp/ state

Classify as an agent workspace first, when the target is the working directory of an autonomous agent platform — signals: a platform identity file (such as OpenClaw’s SOUL.md or HEARTBEAT.md), no primary application stack, and content that is predominantly the agent’s own state. Any one strong platform signal suffices.

Otherwise, classify as an orchestrator hub when a clear majority of the following hold: multiple nested git repositories or submodules; a registry or manifest of managed repositories; configuration pointing to external repositories. Classify as an individual repository otherwise — it is the safe default.

When signals are ambiguous, the agent MUST present its assessment and evidence to the user and ask for confirmation before proceeding.

Onboarding differences