The Agents

13 agents, 4 models, 2 modes. Each agent is tuned to its model's strengths. The harness picks the right model for the right task.

The Full 13-Agent Hierarchy

The Jarvis ecosystem employs a specialized hierarchy of 13 distinct agents, moving beyond the simplified 4-agent view. Each agent has a specific role and operates within strict boundaries.

Orchestrators

  • Sisyphus (claude-opus-4-6) — Main orchestrator. Runs the boulder. Coordinates all agents.
  • Atlas (claude-sonnet-4-6) — Todo-list orchestrator. Manages work plans via task().
  • Sisyphus-Junior — Category-spawned executor. Spawned by Atlas for specific domain work.

Planners

  • Prometheus — Strategic planner. Decomposes goals into ordered task graphs.
  • Coeus — Recursive divide-and-conquer planner. Sub-Prometheus for domain sub-plans.
  • Sub-Prometheus — Domain sub-planner. Generates domain-specific plans.
  • Metis — Pre-planning consultant. Surfaces ambiguities before execution.

Workers

  • Hephaestus (gpt-5.3-codex) — Autonomous deep worker. "The Legitimate Craftsman." Executes complex implementation tasks.

Reviewers

  • Momus (gpt-5.4) — Plan validator. Evaluates work plans against clarity, verifiability, completeness.

Specialists

  • Oracle (strategic advisor, read-only) — High-IQ reasoning for hard problems. Never writes code.
  • Librarian (gemini-3-flash) — Multi-repo research. Retrieves official docs, searches remote codebases.
  • Explore (grok-code-fast-1) — Fast codebase grep. Answers "Where is X?", "Which file has Y?"
  • Multimodal-Looker — PDF/image analysis. Extracts information from visual documents.

Note: Earlier documentation referenced "Daedalus" as a placeholder name. The actual implementation is handled by Sisyphus and Hephaestus. Daedalus is deprecated and no longer part of the active hierarchy.

Multi-Model Orchestration

Jarvis leverages a multi-model strategy, routing tasks to the LLM best suited for the job:

  • Claude (Opus/Sonnet) → Orchestration, planning, and complex reasoning.
  • GPT (gpt-5.3-codex, gpt-5.4) → Execution and review.
  • Gemini (gemini-3-flash) → Research and multi-repo analysis.
  • Grok (grok-code-fast-1) → Fast codebase search.

Agent categories for delegation include: visual-engineering, deep, quick, ultrabrain, unspecified-low/high, and writing.

Two Modes of Operation

The ecosystem operates in two distinct modes, sharing the same knowledge layer but utilizing different interaction models.

flowchart TB
    subgraph INLOOP["IN-LOOP MODE (engineer present)"]
        direction TB
        ENG1["👨‍💻 Engineer"] --> CC["Claude Code"]
        CC --> OMO["OMO Hooks
41 hooks · 7 events"]
        OMO -->|"auto-inject"| KS_IN["ks_recall"]
        OMO -->|"auto-capture"| KS_IN2["ks_ingest"]
    end

    subgraph OUTLOOP["OUT-LOOP MODE (autonomous)"]
        direction TB
        ENG2["👨‍💻 Engineer"] -->|"1. write task"| AB["Autoboard / CLI"]
        AB -->|"2. trigger"| BE["Blueprint Engine"]
        BE -->|"3. agent nodes"| G["Goose HTTP SSE"]
        BE -->|"4. det. nodes"| DET["lint · test · git"]
        G --> TS["Toolshed (curated subset)"]
        BE -->|"5. memory"| KS_OUT["ks_recall / ks_ingest"]
        BE -->|"6. done"| PR["Pull Request"]
        PR -->|"7. review"| ENG2
    end

    KS[("Knowledge Service
Rust · gRPC
PostgreSQL + pgvector
✅ COMPLETE")]

    KS_IN --> KS
    KS_IN2 --> KS
    KS_OUT --> KS

In-Loop Mode Details

In-Loop mode keeps the engineer present, utilizing Claude Code as the primary interface.

  • OMO (oh-my-opencode) — A custom fork with 45 custom commits on upstream opencode.
  • Features 46 lifecycle hooks across 7 event types.
  • Auto-injects context via hooks (e.g., PreCompact → extract, UserPromptSubmit → recall).

Out-Loop Mode Details

Out-Loop mode is designed for autonomous execution, following a strict lifecycle: Task → Blueprint → Goose → PR → Review.

  • Nightshift — Enables overnight autonomous runs with a 50+ task taxonomy and a continuous plan-implement-review loop.
  • Mastra — Handles workflow sequencing.
  • Autoboard — Provides the review UI for engineers to evaluate completed work.

Blueprint Execution Sequence

A single blueprint run orchestrates both deterministic nodes and agent nodes to complete a task.

sequenceDiagram
    participant H as 👨‍💻 Human
    participant AB as Autoboard
    participant BE as Blueprint Engine
    participant KS as Knowledge Service
    participant G as Goose Agent
    participant GIT as Git / CI

    H->>AB: "Implement login endpoint"
    AB->>BE: POST /blueprints/implement-feature/run

     rect rgb(20,40,60)
         note over BE,KS: 🔵 deterministic node
         BE->>KS: ks_recall("login patterns")
         KS-->>BE: context (past learnings)
     end

     rect rgb(60,30,20)
         note over BE,G: 🔴 agent node
         BE->>G: gooseAgent(implement, context)
         G-->>BE: files written
     end

     rect rgb(20,40,60)
         note over BE,GIT: 🔵 deterministic nodes
         BE->>GIT: pnpm lint --fix
         BE->>GIT: pnpm test
     end

     alt tests fail
         rect rgb(60,30,20)
             note over BE,G: 🔴 conditional agent node
             BE->>G: gooseAgent(fix-failures)
             G-->>BE: files patched
         end
         BE->>GIT: pnpm test (retry)
     end

     rect rgb(20,40,60)
         note over BE,GIT: 🔵 deterministic nodes
         BE->>GIT: git add && git commit
         BE->>GIT: gh pr create
     end

    BE->>KS: ks_ingest(session learnings)
    AB-->>H: PR ready — diff + reasoning + tests
    H->>AB: Approve / Iterate / Discard

Blueprint Abstraction Internals

The Blueprint Abstraction provides a thin architectural layer over the Mastra workflow engine, defining the execution graph.

flowchart LR
    subgraph BP["implement-feature Blueprint"]
        direction LR
        N1["🔵 ksRecall()"] --> N2["🔴 gooseAgent(implement)"]
        N2 --> N3["🔵 shellStep(lint)"]
        N3 --> N4["🔵 shellStep(test)"]
        N4 --> COND{pass?}
        COND -->|no| N5["🔴 gooseAgent(fix)"]
        N5 --> N4
        COND -->|yes| N6["🔵 gitStep(commit)"]
        N6 --> N7["🔵 shellStep(gh pr)"]
    end

    subgraph DSL["Blueprint DSL (~500 LOC)"]
        CB["createBlueprint()"]
        SS["shellStep()"]
        GA["gooseAgent()"]
        GS["gitStep()"]
        KSF["ksRecall() / ksIngest()"]
    end

    subgraph MASTRA["Mastra Workflow Engine"]
        CW["createWorkflow()"]
        CS["createStep()"]
        DOW[".then() .branch() .parallel()"]
    end

    BP -.->|"uses"| DSL
    DSL -.->|"thin wrapper over"| MASTRA

Toolshed Profiles

Agents are granted access to curated subsets of tools via profiles, ensuring they only have the capabilities necessary for their specific role.

flowchart TD
    subgraph PROFILES["Tool Profiles"]
        P1["implementer
ALL categories"]
        P2["reviewer
knowledge + context
git read-only"]
        P3["planner
knowledge + project
+ context"]
        P4["oracle
knowledge + context
only"]
        P5["quality_gate
quality + git read-only"]
    end

    FILTER["getToolsForProfile()
Mastra MCPClient
aggregates + filters"]

    P1 & P2 & P3 & P4 & P5 --> FILTER

    subgraph SERVERS["MCP Servers (5 backends)"]
        S1["knowledge-service-mcp ✅
ks_recall · ks_query
ks_ingest · ks_search
ks_compact · ks_export"]
        S2["bd-mcp 🔧
bd_ready · bd_show
bd_update · bd_close
bd_sync"]
        S3["git-mcp 🔧
git_status · git_diff
git_commit · git_log
git_pr_create"]
        S4["quality-mcp 🔧
run_tests · run_lint
run_build"]
        S5["context-mcp 🔧
get_agents_md
get_project_context"]
    end

    FILTER --> S1 & S2 & S3 & S4 & S5

    subgraph CONSUMERS["Who Gets What"]
        C1["Blueprint implement node
→ implementer profile
= all 20+ tools"]
        C2["Blueprint review node
→ reviewer profile
= 8 tools (read-only)"]
        C3["OMO in-loop
→ implementer profile
= all 20+ tools"]
    end

    P1 -.-> C1
    P2 -.-> C2
    P1 -.-> C3

Sources

docs/WORKFLOW.md docs/architecture/diagrams.md