enterprise-ai-agents-spec — Workflow

Main Development Workflow (Orchestrator Mode)

The Orchestrator mode in Roo Code implements the spec's coordination model:

1. Requirements & Product Strategy
   → switch_mode("product") → requirements definition
   → switch_mode("research") → market/technical feasibility
   → Quality Gate: Requirements Sign-off

2. Architecture & Security Design
   → switch_mode("architect") → enterprise architecture
   → switch_mode("security") → threat modeling
   → switch_mode("compliance") → regulatory validation
   → Quality Gate: Architecture Approval

3. Implementation & Quality
   → switch_mode("code") → implementation
   → switch_mode("debug") → testing and QA
   → switch_mode("performance") → performance testing
   → Quality Gate: Implementation Validation

4. Infrastructure & Deployment
   → switch_mode("devops") → CI/CD setup, deployment
   → switch_mode("data") → data pipelines
   → Quality Gate: Production Readiness

5. Documentation & Compliance
   → switch_mode("docs") → documentation generation
   → switch_mode("compliance") → final audit preparation

Quality Gate Pattern (4-Phase)

Each quality gate uses a standardized approval workflow:

Planning & Requirements Validation
Design & Architecture Approval
Implementation & Testing Validation
Deployment & Success Confirmation

Gate implementation uses Roo Code's ask_followup_question with suggested next steps:

• Primary action with mode switch
• Alternative action without mode switch
• Refinement option
• Stakeholder engagement option

Task Parallelization

The Delivery/Dependency Agent continuously monitors the FDG:

• When work item W_i completes, check FDG for newly unblocked items
• Assign newly available items to idle agents
• Budget constraint: Σ C(w) for active work ≤ B (configurable budget limit)

Cost factors tracked: compute resources, API calls, licensing/SaaS, human reviewer time, security overhead.

Escalation Workflow

Agent detects anomaly
  → Local resolution attempt (Delivery Agent)
      → Resolved: continue
      → Unresolved: SuspiciousActivity event → Orchestrator
          → Committee consensus (if multi-orchestrator)
          → PauseFlow issued to affected agents
          → OversightEscalation → Human Overseer
              → Overseer: Approve / Reject / Query
              → Decision immutably logged

Human Overseer oversight is both push (automatic alerts for SecurityAlert, budget overrun, OversightEscalation) and pull (dashboard queries on demand).

Spec Workflow (Vendor-Neutral)

Per the main spec document:

1. Orchestrator receives project goal
2. Decompose into Work Items (Initiative → Epic → Story → Ticket → Task)
3. Build Fluid Dependency Graph
4. Delivery Agent tracks FDG, unblocks tasks as dependencies resolve
5. Agents receive TaskCreated events from Message Queue
6. Agents execute, append results to immutable ledger
7. QA/Security/Compliance checks run continuously
8. OversightEscalation events route to Human Overseer
9. Human Overseer: pause/resume/approve at critical gates
10. Sprint/milestone checkpoint reviews compile governance reports

Conflict Resolution

Minor conflicts are resolved locally before escalating:

1. Delivery Agent or Requirement Clarification Agent negotiates
2. Two Developer Agents disagreeing → run benchmark, choose winner
3. Complementary solutions → Merger Agent synthesizes without human input
4. Only if local resolution fails or deadlines exceeded → escalate to Orchestrator
5. Only if Orchestrator cannot resolve → Human Overseer

Approval Gates

enterprise-ai-agents-spec — Memory & Context

Spec-Level Memory Model

The spec defines memory through two mechanisms: the immutable event ledger and the Fluid Dependency Graph.

Immutable Event Ledger

The central persistence mechanism. Defined formally as: L = { (t₁, A₁, action₁, result₁), (t₂, A₂, action₂, result₂), ... }

Properties:

• Append-only: No data is deleted; corrections are new entries
• Decision tracking: All critical decisions, especially human ones, logged with rationale
• Replicated: In committee mode, the ledger is replicated across Orchestrator nodes for fault tolerance

Every significant action is appended: task state changes, escalation events, human approvals, security alerts, compliance checks.

Fluid Dependency Graph (FDG)

Maintained by the Delivery/Dependency Agent. Dynamic state: as work items complete, edges are resolved and newly unblocked items become available. FDG changes are themselves logged to the immutable ledger.

The FDG is the system's "working memory" for project state — what's blocked, what's available, what's complete, and why.

Roo Code Implementation Layer

The Roo Code instruction templates do not define a specific in-session memory mechanism beyond what Roo Code provides natively. Context is passed between mode switches via the switch_mode(target, instruction) call where the instruction string provides handover context.

Context Preservation Protocol

The IMPLEMENTATION-GUIDE.md describes "context preservation" as a feature of the coordination system:

"Advanced Coordination System: Automatic workflow management with context preservation and seamless mode transitions"

In practice, this means the Orchestrator mode passes sufficient context in each switch_mode call to allow the target mode to continue without requiring the full conversation history. The Orchestrator instruction template explicitly handles "emergency response coordination" and "status updates" directly rather than delegating, preserving coordination context.

Research Mode Memory

The Research mode (v5.0) integrates MCP for persistent research capabilities. The MCP Integration Guide defines a decision matrix for when to use direct research (within current context) vs. delegating to Research Mode for deep investigation. Research findings are intended to be written to project files for persistence beyond the session.

Checkpoint Reviews as Memory

Section 5 of the spec defines Scheduled Review Gates at sprints or milestones. These compile compliance/governance reports from the ledger, effectively creating periodic memory snapshots of project state. Ad hoc oversight queries also serve as pull-based memory access against the ledger.

Context Across Scales

The spec's scalability design has implicit context management implications:

• Single-orchestrator: full project context in one node
• Committee: context is replicated across Orchestrator nodes; Delivery Agents maintain domain-local context; the global Orchestrator maintains cross-domain context

The separation of Delivery/Dependency Agent (domain context) from Orchestrator (global coordination context) is an explicit context partitioning strategy.

No Session-Level Memory Specification

The spec does not prescribe specific mechanisms for within-session context management (no explicit summarization strategy, context window management, or cross-agent state synchronization protocol). These are implementation details left to the runtime (Roo Code or other tools). The spec focuses on durable persistence (ledger, FDG) rather than ephemeral context window management.

enterprise-ai-agents-spec — Orchestration

Orchestration Models

Single-Orchestrator (Single-Cell)

For smaller or early-stage projects:

• One meta-agent manages task assignments, message routing, human interface
• Advantages: low overhead, easy configuration
• Drawbacks: single point of failure, limited scalability

Committee (Multi-Orchestrator)

For large, mission-critical environments:

• Multiple Orchestrator nodes using consensus protocol (Paxos, Raft, or PBFT)
• Shared state replication across nodes
• Committee leadership rotation if a node fails or becomes unreliable
• Higher complexity and resource usage; required for resilience against rogue agents

The spec explicitly targets scalability "to millions of agents" through committee-based orchestration.

Orchestrator + Delivery Agent Separation

A key architectural distinction: the Orchestrator and Delivery/Dependency Agent have separate domains.

Orchestrator responsibilities:

• Schedule tasks across agents
• Enforce gating rules
• Receive escalations from Delivery Agents
• In committee mode: replicate all updates across nodes
• Pause or isolate agents when thresholds/policy checks fail

Delivery/Dependency Agent responsibilities:

• Maintain the Fluid Dependency Graph
• Detect task completions and unblock downstream work items
• Own project analytics and AI-generated dashboards
• Detect anomalies (repeated errors, cost spikes, suspicious activity)
• Issue OversightEscalation when local resolution fails
• Serve as "source of truth" for domain-level metrics

In multi-domain projects, one Delivery Agent per domain feeds into the Orchestrator (or committee).

Agent Role Specialization

Agents communicate via the Message Queue (event-driven). The spec defines 8 core roles:

• Product/Market Analyst
• Designer (UX/UI)
• Developer
• QA/Tester
• Security Auditor
• Compliance/Regulatory Specialist
• FinOps/Cost Analyst
• Delivery/Dependency Manager

Custom roles (e.g., Observability Agent) can be added without structural changes: define role, add/reuse event types, specify agent tasks and integration points. No core components require modification.

Task Assignment Flow

Message Queue → Agent receives TaskCreated event
Agent executes → appends result to immutable ledger
Delivery Agent monitors FDG for unblocked work items
Orchestrator schedules newly available items

If an agent fails, tasks revert to Available status. Pausing is enforced by the Orchestrator via PauseFlow event.

Roo Code Orchestration (Implementation Layer)

In the Roo Code implementation, orchestration uses switch_mode() calls rather than a separate agent process:

Orchestrator mode → switch_mode("product", "Define requirements for...")
Product mode executes → returns to Orchestrator
Orchestrator mode → switch_mode("architect", "Create architecture based on...")
...

This is sequential mode-switching within a single VS Code conversation, not parallel agent execution. The spec's parallel swarm model is a methodology target; the Roo Code layer is a practical single-session implementation.

Governance Enforcement in Orchestration

The Orchestrator enforces governance at the meta-level:

• Automated checks run at both Delivery Agent (domain-level thresholds) and Orchestrator (global/cross-domain) levels
• OversightEscalation events are generated when: cost exceeds budget, security alerts are raised, tasks exceed expected duration, suspicious activity is detected
• Manual gating: certain flows (production releases) require explicit sign-off before proceeding

Peer Review & Meritocracy

Section 13 of the spec defines a peer review culture:

• Agents can review each other's work (automated + specialized review agents)
• Complementary solutions are merged by a "Merger Agent"
• Two conflicting implementations: run benchmark, choose winner by outcome
• Meritocracy: best solution wins regardless of which agent produced it

Rogue Agent Handling

The committee architecture provides defense against rogue agents:

1. Delivery Agent detects anomaly (contradictory commits, repeated error loops)
2. Local resolution attempted
3. SuspiciousActivity event → Orchestrator
4. Committee validates through consensus
5. Orchestrator issues PauseFlow, quarantines the agent
6. OversightEscalation → Human Overseer for final decision

enterprise-ai-agents-spec — UI & CLI Surface

Setup Script CLI

The primary CLI surface is enterprise_roo_setup.sh:

# Install all 12 modes (default)
./enterprise_roo_setup.sh ./my-project

# Install specific modes
./enterprise_roo_setup.sh --modes orchestrator,architect,code,security ./my-project

# Interactive mode selection
./enterprise_roo_setup.sh --interactive ./my-project

# Use local templates only (offline)
./enterprise_roo_setup.sh --local ./my-project

# List available modes
./enterprise_roo_setup.sh --list

Output: generates roomodes.yaml in the target project directory, compatible with Roo Code.

Roo Code VS Code Interface

After setup, the UI surface is entirely within VS Code via the Roo Code extension:

• Mode selection via Roo Code's mode switcher UI
• Conversation-driven interaction within VS Code panel
• switch_mode() calls are transparent to the user — mode transitions appear as context switches in the conversation
• No separate terminal or TUI

AI-Generated Dashboards

Section 9 of the spec defines a novel UI concept: the Delivery Manager Agent generates dynamic dashboards on demand rather than pre-defined reports.

"There is no need to pre-define reports or manage dashboards anymore, and natural language can be used to ask for project status."

The Delivery Agent decides which data to surface based on stakeholder role and current project state. Real-time alerts can be pushed via email or WhatsApp (configurable). Dashboard updates fire on every work item state change.

Types of dashboards:

• Security: vulnerabilities, patch status
• FinOps: cost usage, forecast, ROI
• Project status: task board (To Do → In Progress → Review → Done)
• Compliance reports: scheduled at sprints/milestones

Human Overseer Interface

The Human Overseer interacts through two channels defined in the spec:

• Pull: queries dashboards/logs on demand
• Push: automatic OversightEscalation alerts for critical issues

The pausing mechanism:

• Overseer decides to pause → Orchestrator issues PauseFlow event
• All tasks become "paused"
• No new tasks assigned until resume event
• Resume restores normal operation

No Web UI

The framework does not ship a web UI. The spec describes AI-generated dashboards conceptually; the Roo Code implementation layer relies on VS Code's built-in interface. No separate dashboard application is provided.

Spec as Documentation UI

The README.md (zoharbabin/enterprise-ai-agents-spec) and CHANGELOG.md serve as the human-facing documentation layer. GitHub Pages hosts the latest setup script for direct curl execution, which is the primary distribution mechanism for end users.

Mode Development Interface

The enterprise-mode-development-guide.md provides a template-based interface for creating custom modes:

• Purpose Statement Template (markdown)
• Scope Boundaries Framework (YAML)
• Mode Classification System
• Quality Gates Implementation Pattern
• Inter-Mode Collaboration Protocol

This is the "extensibility UI" — how practitioners add new agent roles to the system without modifying core components.