DS-EO: A Governance Framework for Multi-Agent AI Software Engineering
Deepsim AI Lab Research & Technical Reports — DAI-LAB-TR-2026-001
Dr. Shouke Wei (魏守科)
Founder, Deepsim Intelligence Technology Inc.
Deepsim AI Lab
ORCID: 0000-0002-4665-5366
DOI: 10.5281/zenodo.21744498
Version 1.0 — August 2026
Abstract
Large language models have transformed software development by enabling AI agents to perform increasingly sophisticated engineering activities, including requirements analysis, architectural design, code implementation, testing, documentation, and code review. As these capabilities improve, software development is moving from individual AI-assisted programming toward workflows in which multiple AI agents collaborate on the same engineering project.
However, capable agents do not automatically constitute an engineering organization. Multi-agent development introduces organizational problems familiar from human software teams: responsibility boundaries, task ownership, architectural authority, implementation handoff, independent review, approval, artifact management, version-control persistence, and release governance.
This technical note presents DS-EO (DeepSim Engineering Organization), an open-source framework for organizing multiple AI agents into a structured software engineering organization. DS-EO introduces explicit engineering roles, communication protocols, workflow gates, artifact ownership, review procedures, approval authority, and Git-based persistence. Its current organization consists of four official engineering roles: Chief Technology Officer (CTO), Project Manager (PM), Implementer, and Reviewer.
A central design principle is that software engineering completion is not equivalent to implementation completion. DS-EO therefore separates planning, implementation, review, approval, completion, and closure into explicit lifecycle stages. In its current five-gate model, the lifecycle progresses from planning through implementation, review, approval, technical completion, and final project closure.
The current DS-EO OpenClaw Edition v0.2.0 provides a concrete implementation of these principles. This release formalizes the PM role, introduces the G5 Complete-to-Closed transition, establishes a gate authority matrix as a governance source of truth, resolves protocol and artifact-ownership inconsistencies identified through a systematic governance audit, adds native Windows installation support, and establishes a controlled post-approval Git persistence workflow. The release includes 53 verification tests passing at release time.
The framework also distinguishes local repository persistence from remote publication. Approved engineering work can be committed to the local Git repository as part of the project lifecycle, while remote publication to GitHub remains subject to explicit user authorization. This provides a boundary between autonomous engineering activity and externally visible publication.
DS-EO is intentionally designed as an organizational layer above an AI-agent runtime. OpenClaw is the first platform-specific implementation, while the underlying organizational concepts are intended to be portable to other agent runtimes.
This technical note presents the motivation, design principles, organizational model, protocols, gated workflow, artifact governance, implementation architecture, development experience, current release, limitations, and future research agenda of DS-EO. It proposes empirical research to determine whether explicit organizational governance can improve the reliability, traceability, reproducibility, and efficiency of multi-agent AI software engineering.
Keywords: AI agents; multi-agent systems; agentic software engineering; AI-native software engineering; software engineering governance; AI coding agents; autonomous software development; human-AI collaboration; AI engineering organizations
1. Introduction
AI coding agents are rapidly changing the way software is developed.
Modern agents can read source repositories, reason about architecture, create implementation plans, modify source code, execute tests, inspect failures, revise implementations, write documentation, and review changes. With increasingly capable models and tool-use environments, an AI agent can perform work that previously required substantial human programming effort.
This development creates an important transition.
The first generation of AI-assisted development primarily focused on:
How can AI help a developer write software?
The next stage asks:
How can AI agents independently perform substantial software engineering tasks?
The emerging question is broader:
How should multiple AI agents work together as an engineering organization?
This question cannot be solved simply by increasing the intelligence of an individual model.
Software engineering is an organizational activity. Human engineering teams separate responsibilities because large software projects involve architectural decisions, planning, implementation, review, approval, documentation, version control, and release management. These responsibilities require different forms of authority and accountability.
When multiple AI agents participate in the same project, similar organizational requirements emerge.
An agent may be capable of writing code but should not necessarily control architecture.
A reviewer should be capable of identifying defects but should not necessarily modify the implementation being reviewed.
A project manager should track task completion but should not necessarily alter source code.
An architect may approve an implementation but should not necessarily be responsible for final project closure.
Without explicit boundaries, multiple capable agents can produce an engineering process that is difficult to understand, reproduce, verify, or govern.
DS-EO was developed to explore this problem.
2. From AI Agents to AI Engineering Organizations
A single AI coding agent can be extremely capable while still lacking organizational structure.
Consider a simple development process:
User request
↓
AI agent
↓
Code
↓
Tests
↓
"Done"
This workflow may work for small tasks.
For a larger engineering project, however, several questions immediately arise:
- Who determines the architecture?
- Who converts requirements into engineering tasks?
- Who decides whether a task is ready for implementation?
- Who is allowed to modify source code?
- Who independently verifies the implementation?
- Who resolves disagreement between implementation and review?
- Who authorizes completion?
- Who records the final engineering state?
- Who commits approved changes?
- Who is authorized to publish changes to an external repository?
These are organizational questions.
DS-EO therefore starts from a different premise:
The next step in AI software engineering is not simply better individual agents, but better organizations of agents.
The objective is to establish a layer between the underlying AI runtime and the software project:
┌───────────────────────────────────────────────┐
│ Software Engineering Project │
├───────────────────────────────────────────────┤
│ DS-EO │
│ │
│ Roles · Protocols · Gates · Authority │
│ Artifacts · Review · Approval · Governance │
├───────────────────────────────────────────────┤
│ AI Agent Runtime │
│ │
│ OpenClaw / Other Agent Platforms │
├───────────────────────────────────────────────┤
│ AI Models │
│ │
│ Local / Cloud / Specialized Models │
└───────────────────────────────────────────────┘
DS-EO is therefore not intended to replace an AI runtime.
It provides an engineering organization and governance layer above the runtime.
3. Design Goals
DS-EO was designed around several goals.
3.1 Explicit role separation
Each agent should have a clearly defined responsibility and authority boundary.
3.2 Controlled delegation
Engineering work should move through explicit task delegation rather than unrestricted agent-to-agent activity.
3.3 Independent verification
Implementation should be reviewed independently before final technical approval.
3.4 Explicit lifecycle management
A task should have a defined progression from planning through closure.
3.5 Artifact traceability
Important decisions and results should exist as persistent engineering artifacts rather than only inside conversational context.
3.6 Version-control persistence
Approved engineering changes should become persistent Git history.
3.7 Human control at important external boundaries
Autonomous development should not automatically imply unrestricted publication to external systems.
3.8 Runtime independence
The organizational model should not be permanently tied to a single AI-agent runtime.
3.9 Cross-platform accessibility
The framework should be usable across common development environments, including Linux, macOS, WSL2, and native Windows.
4. The DS-EO Engineering Organization
The current DS-EO organization contains four official roles:
CTO
│
Architecture /
Governance
│
▼
PM
│
Task Lifecycle
│
┌──────────┴──────────┐
▼ ▼
Implementer Reviewer
│ │
Coding Verification
│ │
└──────────┬──────────┘
▼
Approval
│
▼
PM Closure
The structure is deliberately not a simple hierarchy of “manager tells programmer what to do.”
Each role has a distinct engineering responsibility.
4.1 CTO / Architect
The CTO is responsible for technical direction and architectural governance.
Typical responsibilities include:
- architectural planning;
- technical strategy;
- task planning at the appropriate governance level;
- resolution of architectural conflicts;
- evaluation of major technical decisions;
- final technical approval.
The CTO should not become an unrestricted implementation agent.
This separation is important because architectural authority and implementation authority serve different purposes.
4.2 Project Manager
The PM is a first-class governance role in DS-EO.
The PM manages the engineering task lifecycle and, in the current implementation, owns the transition from technical completion to project closure.
Responsibilities include:
- task lifecycle management;
- coordination;
- artifact integrity verification;
- task status management;
- post-G4 completion;
- changelog and completion records;
- repository persistence;
- release-related engineering administration.
The PM role became particularly important during DS-EO development because a technically approved task is not necessarily a closed task.
After approval, engineering artifacts still need to be finalized, status must be updated, and approved work needs to become persistent repository history.
The PM therefore provides a bridge between technical completion and project closure.
4.3 Implementer
The Implementer is responsible for executing approved engineering work.
Typical responsibilities include:
- modifying source code;
- implementing approved designs;
- writing and updating tests;
- running validation;
- documenting implementation results;
- reporting completion.
The Implementer does not independently redefine the architecture when doing so would exceed the scope of the approved task.
4.4 Reviewer
The Reviewer provides independent technical verification.
Responsibilities include:
- inspecting implementation changes;
- examining test results;
- identifying defects;
- checking compliance with requirements;
- checking architectural consistency;
- producing review findings;
- recommending approval or further work.
The separation between Implementer and Reviewer is fundamental.
An agent should not be considered an independent reviewer of work that it has itself produced without an explicit mechanism for maintaining review independence.
5. Protocols Instead of Prompts
Simply assigning four agents the labels “CTO,” “PM,” “Implementer,” and “Reviewer” is insufficient.
For an organization to function, the roles must have a shared protocol.
DS-EO therefore defines explicit protocols for activities such as:
- communication;
- delegation;
- handoff;
- completion;
- review;
- approval;
- artifact ownership.
The distinction is important.
A prompt describes what an agent is expected to do.
A protocol describes how multiple AI agents are expected to interact.
This changes the engineering model from:
Agent A → Agent B
to:
Role A
↓
Defined protocol
↓
Required artifact
↓
Gate condition
↓
Role B
The protocol becomes part of the engineering infrastructure.
In the current release, the protocol system has been systematically audited against the actual workflow. Seven protocol inconsistencies, five artifact-ownership gaps, and eight actionable recommendations identified during governance review were addressed in the v0.2.0 stabilization work.
This experience revealed an important principle:
A governance protocol must be consistent not only internally, but also with the actual capabilities and authority of the agents expected to execute it.
6. Gated Workflow
DS-EO uses a five-gate engineering lifecycle.
G1
Planning → Implementation
↓
G2
Implementation → Review
↓
G3
Review → Approval
↓
G4
Approval → Complete
↓
G5
Complete → Closed
The gates define points at which responsibility and authority change.
6.1 G1 — Planning → Implementation
Authority: User approves the CTO plan.
The project must have an approved engineering plan before implementation begins.
The purpose is to prevent an Implementer from beginning substantial work based only on informal conversation.
6.2 G2 — Implementation → Review
Authority: Implementer completes implementation and CTO confirms the transition.
Implementation must produce sufficient artifacts and validation evidence for independent review.
The transition therefore represents:
“The implementation is ready for review.”
It does not mean:
“The organization has accepted the implementation.”
6.3 G3 — Review → Approval
Authority: Reviewer recommends; CTO confirms.
The Reviewer provides independent findings.
The CTO evaluates the review result and determines whether the work is technically acceptable.
6.4 G4 — Approval → Complete
Authority: CTO makes the final technical decision.
At G4, the technical work is considered approved and complete from the CTO’s perspective.
However, this is deliberately not the end of the lifecycle.
6.5 G5 — Complete → Closed
Authority: PM.
G5 is a key evolution in DS-EO v0.2.0.
The PM performs post-G4 administrative and repository operations, including appropriate status updates, artifact checks, completion records, and Git persistence.
This produces an important distinction:
Technical approval is not equivalent to project closure.
7. Governance as a Single Source of Truth
As DS-EO evolved, distributed descriptions of gate authority created a risk of contradiction.
The v0.2.0 implementation addresses this with a dedicated:
GATE_AUTHORITY_MATRIX.md
The matrix provides a single reference for gate ownership and transitions.
This illustrates a broader lesson:
When an AI organization has multiple protocols describing the same workflow, governance authority itself must be governed.
A protocol ecosystem therefore needs consistency checks just as software needs tests.
8. Artifact-Based Engineering
AI conversations are transient.
Software projects are not.
If an important architectural decision exists only in an agent’s context window, it is difficult to reproduce or audit.
DS-EO therefore emphasizes persistent artifacts.
Examples include:
- task specifications;
- architecture plans;
- implementation reports;
- review reports;
- approval records;
- completion records;
- project status;
- changelogs;
- gate authority definitions;
- Git history.
The engineering state should be reconstructable from persistent project artifacts rather than from an agent’s memory alone.
This principle can be summarized as:
Conversation is an interaction mechanism; artifacts are the engineering record.
9. Git as Engineering Memory
Version control is particularly important in AI-native software engineering.
An AI agent may perform many changes during a session, but a project needs durable history.
DS-EO therefore treats Git as part of the engineering lifecycle.
The intended progression is:
Implementation
↓
Review
↓
Approval
↓
PM finalization
↓
Git commit
↓
Persistent engineering history
The current implementation makes Git persistence part of the post-G4 lifecycle.
This creates a durable boundary between an agent’s temporary working state and the project’s persistent state.
10. Local Commit and Remote Publication
A particularly important governance distinction is between local persistence and remote publication.
A local Git commit records approved work in the development repository.
A remote GitHub push publishes that work to an external system.
These are not equivalent operations.
DS-EO therefore uses:
Approved work
↓
G4 technical approval
↓
PM post-G4 processing
↓
Local Git commit
↓
Persistent local repository
↓
Explicit user authorization
↓
Remote GitHub push
The current implementation automates local Git persistence after appropriate task closure while requiring explicit user confirmation before remote publication.
This provides a boundary between autonomous engineering activity and externally visible publication.
The goal is not to prevent autonomous engineering.
The goal is to prevent autonomy from silently becoming unrestricted external publication.
11. Secrets and Credential Governance
Autonomous repository operations introduce another engineering concern: credentials.
DS-EO v0.2.0 introduces explicit secrets-management conventions for Git and GitHub integration.
The project provides an environment template for configuration and credentials while preventing sensitive files from entering version control through .gitignore protections.
The design principle is:
Automation should not require credentials to become part of the source repository.
This is especially important when AI agents have access to development tools.
Credentials should remain outside the agent organization’s persistent source artifacts and should be exposed only through the required runtime environment.
12. DS-EO and OpenClaw
The first runtime implementation of DS-EO is the DS-EO OpenClaw Edition.
OpenClaw provides the agent execution environment.
DS-EO provides the organizational structure.
This distinction allows the two systems to evolve independently.
DS-EO
│
├── Roles
├── Protocols
├── Gates
├── Governance
├── Artifact rules
└── Lifecycle
│
▼
OpenClaw Edition
│
├── Agent runtime
├── Model execution
├── Tool access
└── Workspace interaction
The first implementation is therefore an integration rather than a definition of DS-EO itself.
The same organizational principles could potentially be implemented on other AI-agent platforms.
The project roadmap anticipates future platform variants and a platform abstraction layer. These are future directions rather than claims about the current implementation.
13. Cross-Platform Engineering
A practical engineering organization must also be accessible to developers using different operating systems.
DS-EO v0.2.0 adds native Windows support through a PowerShell installation suite while retaining the existing Bash-based Linux/macOS/WSL2 workflow.
The Windows implementation includes dedicated PowerShell support for:
- installation;
- installation verification;
- protocol deployment;
- agent deployment;
- configuration generation;
- conflict checking.
WSL2 remains a useful path where full Bash compatibility is desired.
This illustrates a broader design goal:
Governance should describe the engineering process, while platform-specific implementation details should remain replaceable.
14. Release v0.2.0: From Concept to Working Organization
The v0.2.0 release represents an important transition in DS-EO development.
The release includes:
14.1 Formal PM role
The PM is explicitly defined as one of the four official engineering roles and owns the G5 Complete-to-Closed transition.
14.2 Complete five-gate lifecycle
The addition of G5 closes the lifecycle gap between technical completion and project closure.
14.3 Governance consistency
A systematic governance audit addressed:
- seven protocol inconsistencies;
- five artifact-ownership gaps;
- eight actionable recommendations.
A gate authority matrix was established as a single source of truth.
14.4 Documentation consistency
A documentation sweep corrected stale role tables, protocol counts, tool-policy annotations, manifest registrations, and related documentation inconsistencies.
14.5 Verification
The v0.2.0 release notes report 53 verification tests passing at release time.
14.6 Windows support
Native PowerShell installation and verification support makes DS-EO accessible to native Windows development environments.
14.7 Repository persistence
Post-G4 Git persistence is incorporated into the PM’s lifecycle responsibilities.
14.8 Controlled remote publication
GitHub remote push is explicitly separated from local repository persistence and requires user confirmation.
Together, these changes demonstrate that DS-EO is no longer merely a proposed organizational model. The governance model has been implemented, exercised, audited, corrected, and incorporated into a working software framework.
However, this should not be interpreted as empirical proof that DS-EO improves software engineering outcomes. That question remains for future controlled evaluation.
15. What We Learned from Building DS-EO
The development of DS-EO revealed several practical lessons.
15.1 Capability does not equal organization
A highly capable agent can still fail in a multi-agent workflow if responsibilities are ambiguous.
15.2 More agents do not automatically produce better engineering
Adding agents without defining their authority can increase coordination complexity rather than reduce it.
15.3 Review independence matters
A reviewer needs an explicit role and authority boundary if its review is intended to provide meaningful independent verification.
15.4 Completion and closure are different
An implementation can be technically approved while still requiring project-level finalization.
15.5 Artifact ownership must be explicit
Every important artifact should have a clear owner and production mechanism.
Otherwise, workflows can specify outputs that no agent is actually authorized or capable of producing.
15.6 Governance must match agent capabilities
A protocol is not executable merely because it is documented.
If a role is prohibited from writing files but the protocol requires that role to create a file, the organization contains a capability contradiction.
This became an important design principle during DS-EO’s governance refinement:
Every protocol responsibility should be aligned with the actual capabilities and authority of the responsible role.
15.7 Governance itself requires verification
DS-EO’s governance audit revealed that protocols can become inconsistent in the same way that software components can become inconsistent.
This suggests a useful analogy:
AI-agent organizations need governance testing in much the same way software systems need software testing.
15.8 Autonomous engineering still needs boundaries
The objective is not maximum autonomy at every stage.
The objective is appropriate autonomy within explicit boundaries.
16. Current Implementation Status
At the v0.2.0 milestone, DS-EO OpenClaw Edition provides an operational foundation for:
- four defined engineering roles;
- eight engineering protocols;
- five workflow gates;
- gate authority governance;
- artifact ownership and integrity checks;
- independent review;
- approval workflows;
- post-G4 project closure;
- Git persistence;
- controlled GitHub publication;
- secrets-management conventions;
- native Windows installation;
- Linux/macOS/WSL2 installation;
- installation verification;
- cross-platform deployment tooling.
The release was accompanied by 53 passing verification tests.
DS-EO remains an evolving open-source engineering framework. The current implementation should therefore be regarded as a foundation for experimentation and further engineering rather than a final standard for AI software development.
17. Limitations
Several limitations should be recognized.
First, DS-EO has not yet been evaluated through a large controlled empirical study comparing governed and non-governed AI development.
Second, different AI models may respond differently to the same organizational protocols.
Third, role separation introduces coordination overhead. A governed process may require more interactions than an unconstrained single-agent workflow.
Fourth, the framework currently depends on the capabilities and constraints of its runtime integration.
Fifth, AI-generated review is not equivalent to human independent review in every context. The effectiveness of AI review remains an empirical question.
Sixth, the current evidence primarily demonstrates that the governance framework can be implemented and operated; it does not yet demonstrate causal improvement in software quality, productivity, or reliability.
Finally, governance itself can become a source of complexity. Excessive process can reduce productivity rather than improve it.
These limitations motivate future empirical research.
18. Research Agenda
The central research question arising from DS-EO is:
Can explicit organizational governance improve the reliability and reproducibility of multi-agent AI software engineering?
Several research questions follow.
RQ1 — Role Separation
Does explicit separation of architectural, management, implementation, and review responsibilities improve engineering outcomes?
RQ2 — Workflow Gates
Do explicit lifecycle gates reduce defects, rework, and architectural drift?
RQ3 — Independent Review
Does separating implementation from review improve defect detection?
RQ4 — Artifact Governance
Does persistent artifact-based coordination improve traceability and reproducibility?
RQ5 — Human Intervention
How does governed multi-agent development affect the frequency and type of human intervention required?
RQ6 — Engineering Efficiency
What is the trade-off between additional governance overhead and improvements in engineering quality?
RQ7 — Governance Reliability
Can automated governance checks detect inconsistencies between agent roles, protocols, authority boundaries, and actual tool capabilities?
The seventh question is especially important because it emerged directly from DS-EO’s own development process.
19. Toward Empirical Evaluation
A future empirical study could compare at least two conditions:
Condition A
Ungoverned multi-agent development
Condition B
DS-EO-governed multi-agent development
Possible dependent variables include:
- defect rate;
- requirement compliance;
- architectural drift;
- number of review findings;
- rework;
- number of workflow violations;
- human intervention count;
- task completion time;
- artifact completeness;
- test coverage;
- repository traceability;
- governance violations.
A simplified experimental design could be:
Same project tasks
│
┌──────────┴──────────┐
▼ ▼
Baseline DS-EO
Workflow Workflow
│ │
▼ ▼
Engineering Engineering
results results
│ │
└──────────┬──────────┘
▼
Comparative
analysis
The DS-EO development history can also provide a natural source of longitudinal evidence.
Rather than evaluating only final software quality, future studies can examine the development process itself:
Task
↓
Planning
↓
Implementation
↓
Review
↓
Approval
↓
Closure
↓
Git history
This could allow researchers to investigate how organizational governance changes the behavior and coordination of AI agents over time.
20. Toward AI-Native Software Engineering
Software engineering has historically evolved alongside increasing automation.
A simplified progression is:
Individual programmer
↓
Development team
↓
Software engineering organization
↓
CI/CD and DevOps
↓
Highly automated engineering systems
AI-assisted development introduces another possible transition:
AI-assisted programmer
↓
Individual AI coding agent
↓
Multi-agent development
↓
AI engineering organization
↓
Autonomous engineering system
DS-EO explores the organizational layer of this transition.
The central proposition is not that AI agents should simply replace software developers.
Instead, future software engineering may involve a combination of:
Human direction + AI agents + explicit engineering governance
Humans may establish objectives, constraints, architecture, and high-level decisions.
AI agents may perform increasingly large portions of implementation and verification.
The organizational layer coordinates these activities and establishes boundaries around autonomy.
21. Open Source and Reproducibility
DS-EO is developed as an open-source project under the Deepsim-AI organization.
The source code, protocols, engineering artifacts, and runtime integration are intended to provide a reproducible foundation for experimentation.
The canonical project repository is:
https://github.com/Deepsim-AI/DS-EO
The first runtime implementation is the DS-EO OpenClaw Edition.
As the project matures, releases, experimental configurations, datasets, and evaluation results can be archived alongside corresponding software versions.
This approach is intended to make it possible to connect:
Research claim
↓
Research paper
↓
Experimental configuration
↓
DS-EO version
↓
Source code
↓
Engineering artifacts
↓
Reproducible result
The separation between software releases and research publications also permits the software to evolve continuously while individual technical notes remain stable archival documents.
22. Conclusion
AI agents are becoming capable software engineers.
The next challenge is not merely to make individual agents more capable.
It is to make multiple agents capable of working together as an engineering organization.
DS-EO explores this problem by introducing explicit roles, protocols, workflow gates, artifact ownership, independent review, approval authority, Git persistence, and controlled external publication.
Its v0.2.0 implementation demonstrates a complete organizational lifecycle from planning through project closure, including a formal PM role, five governance gates, audited protocol consistency, artifact ownership alignment, cross-platform installation, verification, and repository persistence.
Its central principle is straightforward:
Intelligence alone does not create an engineering team. Engineering teams require organization, responsibility, process, verification, and governance.
DS-EO is an initial attempt to provide these structures for AI-native software development.
The current framework should be viewed not as a finished answer, but as an engineering foundation and research platform.
The most important next step is empirical evaluation.
If governed multi-agent development can be shown to reduce engineering errors, improve traceability, reduce architectural drift, or achieve better quality with an acceptable coordination cost, then organizational governance may become an important layer of future AI software engineering systems.
The broader question is therefore no longer simply:
Can AI write software?
It is becoming:
Can AI agents form reliable engineering organizations that can build software together?
DS-EO is an exploration of that question.
23. Publication and Availability
Project: DS-EO — DeepSim Engineering Organization
Organization: Deepsim-AI
Runtime implementation: DS-EO OpenClaw Edition
Publisher: Deepsim Press
Series: Deepsim AI Lab Research & Technical Reports
Report: DAI-LAB-TR-2026-001
Version: 1.0
DOI: 10.5281/zenodo.21744498
ORCID: 0000-0002-4665-5366
Current software release described: v0.2.0
Repository:
https://github.com/Deepsim-AI/DS-EO
The software repository is maintained by the Deepsim AI Lab at Deepsim Intelligence Technology Inc.
24. Author
Dr. Shouke Wei (魏守科)
Founder, Deepsim Intelligence Technology Inc.
Deepsim AI Lab
ORCID iD: 0000-0002-4665-5366
DS-EO is developed and maintained by the Deepsim AI Lab at Deepsim Intelligence Technology Inc.
Suggested Citation
Wei, S. (2026). DS-EO: A Governance Framework for Multi-Agent AI Software Engineering. Deepsim AI Lab Research & Technical Reports, DAI-LAB-TR-2026-001. Version 1.0. https://doi.org/10.5281/zenodo.21744498
Publication Note
This technical note describes the DS-EO OpenClaw Edition v0.2.0 and its development status at the time of publication. It is a technical publication of the Deepsim AI Lab Research & Technical Reports series, published by Deepsim Press, and is not presented as a peer-reviewed journal article.
Future empirical studies may build upon this technical note and evaluate the proposed governance model using controlled experiments and longitudinal engineering data.
License
The publication license should be specified separately from the DS-EO software license. The software repository and this technical publication may use different licenses where appropriate.
