Skip to main content

OpenClaw for AEEF Agent Orchestration

This page explains how to use OpenClaw as an execution surface for AEEF-governed agent workflows.

It is an AEEF integration pattern, not an endorsement of uncontrolled agent swarms. The objective is to combine OpenClaw's multi-agent capabilities with AEEF requirements for contracts, skills governance, stage gates, and human approval.

Why This Page Exists (Market Signal to Standard)​

This AEEF page was added after a high-signal ecosystem post from Elvis (@elvissun) linking an X Article titled:

  • OpenClaw + Codex/ClaudeCode Agent Swarm: The One-Person Dev Team [Full Setup]

AEEF interpretation:

  • the market is moving from single-agent usage toward orchestrated multi-agent execution
  • "one-person dev team" framing increases adoption speed and gate-bypass risk
  • enterprises need a control layer (contracts, skills, approvals, telemetry) before scaling these patterns

Source signal (attributed):

  • X post: https://x.com/elvissun/status/2025920521871716562?s=46
  • AEEF review date: 2026-02-26 (tweet metadata and engagement verified via authenticated X API)

What OpenClaw Adds (Documented Capabilities)​

Based on OpenClaw official docs, OpenClaw provides a local-first gateway/runtime model for AI coding workflows and includes:

  • multi-agent routing capabilities
  • sandboxing and isolation guidance (including per-agent worktree/sandbox patterns)
  • command checkpoints/approvals
  • web surfaces (admin/control/workbench style interfaces)
  • remote access patterns (loopback-first, SSH/Tailscale Serve guidance)

These capabilities make OpenClaw a practical execution plane for AEEF Agent SDLC workflows when combined with AEEF policy overlays.

Field Pattern Extracted from the Elvis Workflow (AEEF Interpretation)​

The article you shared is useful because it documents a real operating pattern, not just agent demos. The core pattern is:

  • a high-context orchestrator agent (Zoe) holds business context and writes task-specific prompts
  • coding agents (Codex / Claude Code) execute in isolated worktrees and terminal sessions
  • a deterministic monitoring loop checks task state, PRs, CI, and retries
  • human review happens late, after automated gates and multi-model reviews

This is a meaningful AEEF signal because it separates:

  • business-context orchestration from
  • code-generation execution

That separation maps directly to AEEF's distinction between governance/orchestration roles and delivery agents.

Article-Derived 8-Step Workflow Mapped to AEEF Controls​

The article describes an 8-step flow. Below is the AEEF interpretation and required controls.

Step 1: Customer Request -> Scoping with Orchestrator (Zoe)​

Article pattern:

  • orchestrator reads meeting notes / business context
  • may access admin APIs and read-only production data
  • builds a detailed task prompt for a coding agent

AEEF controls:

  • classify Zoe as an orchestrator agent with a formal contract (PRD-STD-009)
  • separate data scopes:
    • business context vault access
    • read-only production data retrieval
    • no direct code merge authority
  • require explicit audit logging when customer/prod context is injected into prompts
  • redact or minimize customer data before agent handoff

Step 2: Spawn Agent in Isolated Worktree + Session​

Article pattern:

  • per-task worktree
  • per-agent tmux session
  • full terminal logging

AEEF controls:

  • treat worktree isolation as a positive control (recommended)
  • bind agent runtime to:
    • repo allowlist
    • branch restrictions
    • environment restrictions
  • capture run metadata:
    • agent-id
    • task-id
    • worktree
    • branch
    • model
    • skill-id / skill-version (if skills are used)

Step 3: Monitoring Loop (Cron + Deterministic Checks)​

Article pattern:

  • cron every 10 minutes
  • checks tmux sessions, PR status, CI, retries failed agents
  • avoids polling agents directly to reduce token cost

AEEF controls:

  • this is a strong enterprise pattern for observability and cost discipline
  • enforce retry limits and escalation thresholds
  • require retry reason classification (CI failure, review blocker, context miss, tool failure)
  • preserve retry prompt deltas for auditability

Step 4: Agent Creates PR (Not Yet “Done”)​

Article pattern:

  • agent commits, pushes, opens PR
  • no notification yet
  • PR alone is not completion

AEEF controls:

  • aligns well with PRD-STD-009: creation is not approval
  • require branch sync + conflict checks before candidate completion
  • require AI traceability fields in PR metadata

Step 5: Automated Multi-Model Code Review​

Article pattern:

  • Codex reviewer
  • Gemini reviewer
  • Claude reviewer
  • different reviewers catch different classes of issues

AEEF controls:

  • supports defense-in-depth review design
  • standardize reviewer roles as named review agents with explicit scopes
  • do not treat any AI reviewer as approval authority
  • require human reviewer to own final merge decision

Step 6: Automated Testing + UI Screenshot Rule​

Article pattern:

  • CI lint/types/unit/E2E/Playwright
  • UI changes require screenshot or CI fails

AEEF controls:

  • directly aligns with PRD-STD-003 and PRD-STD-007
  • screenshot requirement is a strong review acceleration control for UI-heavy workflows
  • require preview environments to be non-production and data-safe

Step 7: Human Review (Late, Evidence-Rich)​

Article pattern:

  • human notified only when PR is “ready for review”
  • review is fast because gates and evidence are pre-assembled

AEEF controls:

  • this is the correct AEEF target state for supervised autonomy
  • retain mandatory human approval for production-bound changes
  • define which changes require code-level review vs artifact-level review (screenshots/docs/evidence)

Step 8: Merge + Cleanup​

Article pattern:

  • merge after review
  • daily cleanup of orphaned worktrees/task registry

AEEF controls:

  • cleanup automation should be policy-scoped (no protected branch or shared workspace damage)
  • retain task registry and run records before cleanup
  • log cleanup actions for incident/debug traceability

Definition of Done (DoD) Pattern from the Article -> AEEF Standardization​

The article's “definition of done” is one of the strongest signals and should be standardized in AEEF orchestration profiles.

Recommended AEEF DoD profile for agent-generated PRs:

  • PR created
  • branch synced to target branch
  • CI passing (lint/types/unit/integration/E2E as applicable)
  • AI reviewer checks completed (advisory)
  • required security checks completed
  • screenshots/artifacts attached for UI-impacting changes
  • human reviewer approval recorded

This should be codified as a reusable gate bundle in the orchestrator and CI pipeline.

Critical Risk Pattern in the Article (AEEF Hardening Required)​

The article includes examples of runtime flags that bypass approvals/sandboxing (for example, direct approval bypass flags in CLI invocations). This is acceptable only as a description of a personal setup, not as an AEEF enterprise baseline.

AEEF Position (Non-Negotiable)​

  • Do not use approval/sandbox bypass flags in enterprise production-bound workflows
  • Do not grant coding agents production admin API access
  • Do not grant coding agents direct production database access
  • Keep production data access in a tightly-scoped orchestrator or service layer, with logging and minimization

Safer AEEF Replacement Pattern​

  • orchestrator performs privileged reads through audited service adapters
  • coding agents receive scoped, sanitized task context only
  • elevated commands trigger checkpoints + human approval
  • production deploy/merge actions remain blocked for coding agents

“Zoe” as an AEEF Role Pattern​

In AEEF terms, Zoe is not just another coding agent. It is a combined:

  • product/context orchestrator
  • task router
  • prompt constructor
  • retry supervisor
  • notification coordinator

For enterprise use, split this into explicit roles or services where possible:

  • product-agent / scrum-agent for request shaping
  • architect-agent for design/handoff constraints
  • orchestration service for routing/retry/checkpoint logic
  • ops-agent for notifications and operational monitoring

This reduces hidden power concentration in a single orchestrator agent.

Metrics and Capacity Planning (Directly Implied by the Article)​

The article surfaces two operational realities that should be formalized in AEEF:

1. Capacity Bottleneck Is Often RAM / Parallel Tooling Load​

Each parallel agent may spawn:

  • dependency installs
  • type checkers
  • test runners
  • build processes

AEEF recommendation:

  • track host resource saturation (RAM, CPU, disk IO) as orchestration SLO inputs
  • throttle agent concurrency by environment and task class
  • schedule heavy validation jobs to avoid synchronized resource spikes

The article uses business-facing metrics (for example, speed -> customer delivery -> revenue impact).

AEEF recommendation:

  • track both engineering and business outcomes:
    • PR cycle time
    • gate pass rate
    • retry rate
    • human review time
    • defect escape rate
    • feature request turnaround time

This is a stronger executive narrative than “agent activity” metrics alone.

AEEF Positioning: OpenClaw Is the Execution Plane, Not the Governance Plane​

Use this separation of concerns:

  • AEEF (governance plane):
    • agent roles/contracts (PRD-STD-009)
    • skills catalog governance (PRD-STD-017)
    • code review/testing/security gates
    • audit evidence and traceability
  • OpenClaw (execution plane):
    • agent invocation and routing
    • sandboxed execution contexts
    • local/remote operator interfaces
    • checkpointed command execution and tool access

This separation prevents a common failure mode: assuming orchestration tooling replaces enterprise governance.

Control Layers​

  1. Agent Contract Registry (AEEF)
  • role definitions and boundaries
  • allowed inputs/outputs
  • forbidden actions
  1. Skill Registry (AEEF)
  • approved/provisional/blocked skills
  • role and environment gate rules
  • attribution metadata for external skills
  1. OpenClaw Runtime
  • routes work to agents
  • runs skills/tools in constrained environments
  • enforces runtime checkpoints and sandboxing
  1. CI/CD Gate Layer
  • code review, test, security, and quality gates
  • deployment promotion controls
  1. Human Approval Layer
  • architecture approvals
  • security approvals
  • production deployment approvals

Reference Topology (AEEF + OpenClaw)​

Developer / Operator
    |
    v
OpenClaw UI / CLI / API (execution requests)
    |
    +--> AEEF policy pre-check
    |      - agent contract lookup
    |      - skill registry lookup
    |      - role/environment gate validation
    |
    +--> OpenClaw routed agents
    |      - product-agent
    |      - architect-agent
    |      - developer-agent
    |      - qa-agent
    |      - security-agent
    |
    +--> checkpoint approvals (risky commands / sensitive actions)
    |
    +--> repo changes + artifacts + handoff records
    |
    v
CI/CD gates (PRD-STD-002/003/004/007/008)
    |
    v
Human approvals (PRD-STD-009)

Choose Your AEEF OpenClaw Implementation Path​

OpenClaw can orchestrate your AEEF agents in two practical modes:

  1. Path A: 4-Agent Starter (fastest implementation)
  2. Path B: Full 11-Agent Orchestration (transformation-scale implementation)

The right choice depends on your rollout stage, team size, and governance maturity, not on model capability alone.

Use this path if you are:

  • implementing OpenClaw in the first repo
  • validating your governance controls
  • operating a startup/small team
  • optimizing for fast feedback with limited operational overhead

Use the AEEF starter model from:

AEEF 4-Agent Set (OpenClaw Runtime)​

AEEF AgentRole in OpenClaw FlowMain ResponsibilityNon-Negotiable Limit
product-agentrequest shaping / scopingstory hardening + acceptance criteriano code edits
developer-agentimplementation executorpatch generation + implementation notesno merge / no CI bypass
qa-agentvalidation agenttest matrix + regression validationno self-approval of code changes
security-agentsecurity review agentsecure review + hardening guidanceno scan bypass / no waivers
Operator -> OpenClaw orchestrator
  -> product-agent (scope + acceptance criteria)
  -> developer-agent (implementation in isolated worktree)
  -> qa-agent (tests + regression checks)
  -> security-agent (security review)
  -> human review + merge

When 4-Agent Path Is Enough​

Use this path for:

  • small/medium feature work
  • bug fixes
  • UI changes with screenshot evidence
  • fast client-request delivery with strict PR gates

Do not add more agents until you have stable metrics for:

  • handoff completeness
  • CI gate pass rate
  • retry rate
  • human review time

Path B: Full 11-Agent Orchestration (AEEF Canonical Model)​

Use this path if you are:

  • implementing the Transformation track
  • running multi-team or regulated workflows
  • needing explicit planning/compliance/platform/executive stages
  • scaling from feature delivery to organization-level operating model control

Use the AEEF canonical model from:

AEEF 11-Agent Set (OpenClaw Runtime + Gate Coordination)​

The OpenClaw execution surface can route or coordinate these AEEF roles:

  • product-agent
  • scrum-agent
  • architect-agent
  • developer-agent
  • qa-agent
  • security-agent
  • compliance-agent
  • platform-agent
  • devmgr-agent
  • ops-agent
  • executive-agent
Stage 1: product-agent + scrum-agent
Stage 2: architect-agent
Stage 3: developer-agent
Stage 4: qa-agent + devmgr-agent
Stage 5: security-agent + compliance-agent
Stage 6: platform-agent
Stage 7: ops-agent -> executive-agent (reporting)

OpenClaw should orchestrate execution and handoffs, while AEEF still owns:

  • stage gate criteria
  • approval authority
  • traceability schema
  • exceptions/waivers

Mapping “Zoe” to AEEF Agents (4-Agent vs 11-Agent)​

The article uses one orchestrator (Zoe) to perform several responsibilities. In AEEF, those responsibilities should be split by path.

In the 4-Agent Path​

A single OpenClaw orchestrator service may still coordinate the workflow, but it SHOULD delegate responsibilities as follows:

  • scope shaping -> product-agent
  • implementation -> developer-agent
  • validation -> qa-agent
  • security review -> security-agent
  • notifications/monitoring -> OpenClaw runtime + ops scripts (not a privileged coding agent)

This preserves speed while reducing hidden authority concentration.

In the 11-Agent Path​

Decompose Zoe responsibilities across the AEEF model:

  • business context + story framing -> product-agent
  • planning / capacity / prioritization -> scrum-agent
  • design and constraints -> architect-agent
  • coding execution -> developer-agent
  • test validation -> qa-agent
  • quality oversight -> devmgr-agent
  • security review -> security-agent
  • compliance evidence -> compliance-agent
  • deployment gating -> platform-agent
  • operations monitoring + notifications -> ops-agent
  • executive reporting -> executive-agent

This is the AEEF enterprise-safe way to preserve the article's productivity gains without centralizing too much privilege in one orchestrator.

OpenClaw Implementation Blueprints for Your AEEF Agents​

Blueprint A: 4-Agent Starter (First 2-4 Weeks)​

Objectives​

  • prove the OpenClaw orchestration pattern in one repo
  • enforce PRD-STD-009 contracts and PRD-STD-017 skill gates
  • keep the operator review workload low without bypassing approvals

Minimum Components​

  • OpenClaw runtime (local or secured remote)
  • AEEF agent registry for 4 agents
  • skills registry with 5-10 approved/provisional skills
  • isolated worktree execution
  • deterministic monitor loop (task registry + PR/CI checks)
  • CI gate bundle (lint/tests/security/AI metadata)

AEEF Gate Bundle (Starter)​

  • Gate A: scope approved (product-agent -> human owner)
  • Gate B: implementation checks passed (developer-agent + CI)
  • Gate C: QA validation complete (qa-agent)
  • Gate D: security review complete (security-agent)
  • Gate E: human merge approval

Example OpenClaw-Orchestrated Starter Request (AEEF Overlay)​

request:
  task_type: feature
  path: aeef-openclaw-starter-4-agent
  repo: product-service
  environment: dev

flow:
  - step: scope
    agent: product-agent
    outputs: [approved-user-story, acceptance-criteria]
    human_checkpoint: product-owner
  - step: implement
    agent: developer-agent
    runtime_controls: [isolated-worktree, sandbox, checkpoints]
    required_gates: [ci-lint, ci-tests]
  - step: validate
    agent: qa-agent
    required_gates: [test-evidence, regression-risk-note]
  - step: secure-review
    agent: security-agent
    required_gates: [sast, sca]
  - step: merge
    agent: human
    required_gates: [all-prior-gates-pass]

Blueprint B: 11-Agent Full AEEF Orchestration (Transformation Track)​

Objectives​

  • map OpenClaw execution to the full 7-stage AEEF orchestration model
  • separate planning, quality oversight, compliance, deployment, and reporting concerns
  • support enterprise auditability and controlled scaling

Minimum Components​

  • OpenClaw runtime + checkpointed execution
  • full 11-agent AEEF registry/contracts/handoffs
  • skills registry with role/environment gates
  • handoff schema validation
  • CI + approval gates mapped to AEEF stages
  • observability for task, gate, and resource metrics

Stage Ownership (11-Agent Path)​

AEEF StageOwner AgentsOpenClaw Role
Requirements & Planningproduct-agent, scrum-agentroute + coordinate handoff
Architecture & Designarchitect-agentenforce design checkpoint
Implementationdeveloper-agentexecute in sandbox/worktree
Testing & Qualityqa-agent, devmgr-agentgather evidence + quality decision support
Security & Compliancesecurity-agent, compliance-agentparallel review and evidence validation
Deploymentplatform-agentenforce production promotion checkpoints
Operations & Reportingops-agent, executive-agenttelemetry, reporting, next-cycle feedback

Example OpenClaw-Orchestrated 11-Agent Request (AEEF Overlay)​

request:
  task_type: feature
  path: aeef-openclaw-full-11-agent
  tier: transformation
  risk_tier: 2

prechecks:
  contracts_loaded: true
  handoff_templates_loaded: true
  skills_registry_loaded: true

stage_flow:
  - stage: requirements
    agents: [product-agent, scrum-agent]
    human_checkpoint: product-owner
  - stage: design
    agents: [architect-agent]
    human_checkpoint: architect-approval-required-if-tier-2-plus
  - stage: implementation
    agents: [developer-agent]
    runtime_controls: [sandbox, checkpoints, isolated-worktree]
  - stage: testing
    agents: [qa-agent, devmgr-agent]
  - stage: security-compliance
    agents: [security-agent, compliance-agent]
  - stage: deployment
    agents: [platform-agent]
    human_checkpoint: release-approver
  - stage: operations-reporting
    agents: [ops-agent, executive-agent]

Migration Path: 4 Agents -> 11 Agents (Recommended)​

Do not jump directly from ad hoc orchestration to the full 11-agent model.

Recommended progression:

  1. Start with 4 agents in one repo.
  2. Stabilize gates, retry logic, and traceability.
  3. Add architect-agent and devmgr-agent first (quality/design leverage).
  4. Add compliance-agent and platform-agent when deployment/compliance complexity rises.
  5. Add ops-agent and executive-agent when you need continuous telemetry/reporting loops.

This preserves the speed benefits demonstrated in the article while keeping operational complexity aligned to maturity.

AEEF OpenClaw Template Pack (Reference Implementation)​

Use the AEEF template pack for implementation-ready starting points:

The pack includes:

  • task registry schema (active-tasks.json)
  • deterministic monitor loop contract and checklist
  • 4-agent starter route policy
  • 11-agent full route policy

Multi-Agent Orchestration Pattern in AEEF​

1. Define Roles First (Before Routing)​

Before enabling any OpenClaw multi-agent routing, define:

  • agent-id
  • owner role
  • contract version
  • allowed tools
  • allowed environments
  • escalation path

This is mandatory under PRD-STD-009.

2. Bind Skills to Roles and Environments​

Do not expose a shared, unrestricted skills set to every agent.

Bind skills using the AEEF skills registry:

  • developer-agent -> implementation and test design skills
  • qa-agent -> test execution and debugging skills
  • security-agent -> security review skills (provisional/sensitive)
  • architect-agent -> review and conformance skills

See PRD-STD-017 and Skill Registry & Multi-Agent Gate Patterns.

3. Require Checkpoints for Elevated Actions​

OpenClaw checkpoints should be mapped to AEEF gate categories, for example:

  • command execution outside allowlist -> checkpoint + human approval
  • branch mutation / merge operations -> checkpoint + developer lead approval
  • infrastructure / deployment actions -> checkpoint + platform approval
  • security remediation with broad file changes -> checkpoint + security review

4. Preserve Traceability​

Every OpenClaw-mediated workflow SHOULD emit:

  • agent-id
  • skill-id (if used)
  • skill-version
  • task/request identifier
  • output artifact references
  • gate results
  • approver identity (when required)

This aligns OpenClaw usage with PRD-STD-009 and PRD-STD-017.

Skills Catalog Integration with OpenClaw​

OpenClaw docs include guidance around skills organization (including per-agent and shared skill layouts). AEEF recommends using that capability to enforce PRD-STD-017 rather than maximizing convenience.

AEEF Rule​

  • Shared skills: only low-risk, broadly approved skills
  • Per-agent skills: role-specific and elevated/sensitive skills
  • No direct external imports into runtime skill paths without intake + attribution + review

AEEF Intake -> Runtime Flow​

  1. External catalog discovered (for example, awesome-claude-skills)
  2. Clone into quarantine intake folder
  3. Create attribution manifest and triage record
  4. Map selected skills into internal AEEF catalog (approved / provisional)
  5. Publish only approved skills to OpenClaw runtime-accessible skill paths
  6. Keep provisional skills sandbox-only and role-restricted

See:

Security and Remote Operation (DigitalOcean / Public Server Considerations)​

If you run OpenClaw on a server (for example, a DigitalOcean VM with a static IP), treat the runtime UI/API as an administrative surface.

Recommended Controls (AEEF + OpenClaw-aligned)​

  • bind OpenClaw services to loopback where possible
  • use SSH tunnel or Tailscale Serve for operator access
  • require authentication for any web/admin surface
  • keep TLS termination and access control in front of the runtime
  • segment runtime from production credentials and deployment keys
  • log checkpoint approvals and privileged actions

AEEF Additional Controls​

  • do not permit production deployment actions from developer-oriented agents
  • isolate agent sandboxes/worktrees per task
  • route all code changes through PR-based CI/CD gates
  • block direct merge or protected-branch push from agent tool policies

AEEF Implementation Sequence for OpenClaw Adoption​

  1. Start with dev only and 2-3 supervised agents (developer, qa, architect).
  2. Implement AEEF agent contracts (PRD-STD-009) before enabling multi-agent routing.
  3. Enable a small approved skills catalog (PRD-STD-017) and keep elevated skills provisional.
  4. Configure OpenClaw checkpoints for elevated commands and sensitive actions.
  5. Enforce CI gates and human review on all production-bound changes.
  6. Add security-agent and compliance-agent after stable traceability and gate pass rates.
  7. Expand remote access only after auth, audit logging, and network controls are validated.
  8. Standardize a DoD gate bundle and monitoring loop before increasing agent concurrency.
  9. Add resource-based concurrency limits (RAM/CPU-aware scheduling) before “swarm” scaling.

Example AEEF Overlay (Pseudocode)​

The following is an AEEF policy overlay example, not an OpenClaw native config format:

workflow_request:
  requested_agent: developer-agent
  environment: dev
  requested_skill: aeef.impl.tdd-assist@0.1.0

prechecks:
  agent_contract:
    required: true
    status: pass
  skill_registry:
    required: true
    status: pass
    skill_status: approved
  gate_bindings:
    required:
      - code-review
      - testing

runtime_controls:
  sandbox_required: true
  isolated_worktree: true
  checkpoints:
    - trigger: command_outside_allowlist
      action: block_and_request_human_approval
    - trigger: protected_branch_operation
      action: deny

traceability:
  emit:
    - agent-id
    - skill-id
    - skill-version
    - task-id
    - gate-results

AEEF Pillar Impact​

Reinforced​

  • Agent SDLC Orchestration - clear fit for routed multi-agent execution
  • AI Security - sandboxing, checkpoints, isolated execution patterns
  • Vibe Coding Standards - structured skills + checkpoints instead of ad hoc prompting
  • Human-AI Collaboration - explicit human approvals remain in the loop

Needs Enhancement (AEEF Work)​

  • standard OpenClaw deployment hardening profile (server, auth, audit)
  • formal mapping template from OpenClaw checkpoint types to AEEF gate classes
  • operator runbook for incident response and emergency disablement

References (Attribution)​

Market Signal​

  • Elvis (@elvissun), X post linking X Article: OpenClaw + Codex/ClaudeCode Agent Swarm: The One-Person Dev Team [Full Setup]
  • https://x.com/elvissun/status/2025920521871716562?s=46

OpenClaw Official Docs​

  • Getting started / multi-agent overview: https://docs.openclaw.ai/getting-started
  • Security overview: https://docs.openclaw.ai/security
  • Secure remote access: https://docs.openclaw.ai/security/secure-remote-access
  • Web surfaces and authentication: https://docs.openclaw.ai/web-surfaces
Last updated on by BalrogEg