Skip to main content

​
ASURA & SENJU: The Execution Model

ASURA and SENJU are not tools. They are roles that any AI agent can take. 
SENJU (千手, thousand hands):  Parallel dispatch. Do N things at once.
ASURA (阿修羅, three faces):   Phase orchestration. Do things in order, synthesize.
Every multi-agent AI system, whether it knows it or not, uses some combination of these two patterns. connector.json makes them explicit and composable.

​
Why This Matters Now

AI agents are no longer single-threaded assistants. They spawn sub-agents. Sub-agents spawn more. The networks grow deeper and wider every month. There are two ways to relate to this: 
Use AI:       "Claude, build this feature." → wait → receive result.
              You don't need to understand the internal structure.
              This is driving a car.

Design AI:    "How should 15 agents across 4 levels coordinate?"
              You need to understand the fractal pattern.
              This is building the engine.
As AI systems grow in complexity, the people who understand the recursive orchestration pattern will design the systems. The people who don’t will use them. This is the new literacy: understanding how AI organizes AI.

​
The Two Roles

​
SENJU — The Hands

"Send N workers out. Collect results."

  SENJU
  ├── Worker A → result
  ├── Worker B → result
  ├── Worker C → result
  └── Worker D → result
       ↓
  [all results collected]
Fan-out, fan-in. Parallel execution. The simplest form of multi-agent work. In connector.json: 
{
  "phases": [{
    "name": "research",
    "parallel": true,
    "workers": 5
  }]
}

​
ASURA — The Faces

"Do this in phases. Each phase sees the previous phase's output."

  ASURA
  Phase 1: Research    → scratchpad
  Phase 2: Synthesize  → reads scratchpad → plan
  Phase 3: Implement   → reads plan → code
  Phase 4: Verify      → reads code → report
Sequential phases. Each phase can contain SENJU (parallel workers). The orchestrator synthesizes between phases. In connector.json: 
{
  "pipeline": {
    "phases": [
      { "name": "research",   "workers": 5 },
      { "name": "synthesize", "workers": 1 },
      { "name": "implement",  "workers": 1 },
      { "name": "verify",     "workers": 3 }
    ]
  }
}

​
The Recursive Insight

Here is what makes this a model, not just a pattern: Every SENJU can become an ASURA. 
You (Human)
  ↕
ASURA-0 (orchestrator)
  │
  ├── Phase 1: SENJU × 3 (research workers)
  │     │
  │     ├── Worker A ← looks like SENJU from above
  │     │     but inside, it becomes ASURA:
  │     │     ├── Phase 1a: read files
  │     │     ├── Phase 1b: analyze patterns
  │     │     └── Phase 1c: write summary
  │     │
  │     ├── Worker B ← also becomes ASURA internally
  │     │     ├── Phase 1a: search code
  │     │     ├── Phase 1b: trace call chain
  │     │     └── Phase 1c: SENJU × 2 (sub-workers)
  │     │           ├── Sub-worker B1
  │     │           └── Sub-worker B2
  │     │
  │     └── Worker C
  │
  ├── Phase 2: Synthesize
  └── Phase 3: Implement
From the outside, Worker B is a SENJU hand — one of three parallel workers. From the inside, Worker B is an ASURA face — running its own phased pipeline with its own SENJU sub-workers. The role depends on where you’re looking from.

​
This Is Dimensional Growth

Each time a SENJU becomes an ASURA, a new dimension opens: 
Dimension 1:  ASURA with N SENJU workers
              = flat multi-agent (what everyone does)

Dimension 2:  Each SENJU is itself an ASURA with M workers
              = N × M agents across 2 levels

Dimension 3:  Those M workers are also ASURAs with K workers
              = N × M × K agents across 3 levels

Dimension D:  Recursive to depth D
              = N^D agents (theoretical maximum)
The complexity grows exponentially with depth. But the pattern at each level is identical: ASURA orchestrates, SENJU executes, scratchpad connects. 
Level 0:  Human ↔ ASURA
Level 1:  ASURA ↔ SENJU (which are ASURAs inside)
Level 2:  ASURA ↔ SENJU (which are ASURAs inside)
Level N:  Same pattern. Same roles. Different depth.

​
The Human Interface

A human doesn’t manage the full tree. A human talks to one ASURA. 
Human: "Build the auth feature"
  ↕
ASURA-0: "I'll break this into research, implementation, and verification."
  ↓
  [ASURA-0 spawns SENJU workers]
  [Some workers become ASURAs internally]
  [Those spawn their own workers]
  [The tree grows to depth 3, 15 agents total]
  ↓
ASURA-0: "Auth feature implemented. 12 files changed. Tests passing. Here's the PR."
  ↕
Human: "Ship it."
The human said two things. 15 agents did the work. The human only talked to ASURA-0. This is why the model matters: as AI networks grow beyond human cognitive capacity (more than ~7 concurrent threads), the ASURA role becomes the cognitive bridge between human intent and AI execution. 
Without ASURA model:
  Human must manage 15 agents directly → cognitive overload → failure

With ASURA model:
  Human manages 1 ASURA → ASURA manages the tree → scales to any depth

​
Multiple ASURAs

A human can also talk to multiple top-level ASURAs: 
Human
  ├── ASURA-frontend: "Build the UI" → [own SENJU team]
  ├── ASURA-backend:  "Build the API" → [own SENJU team]
  └── ASURA-qa:       "Test everything" → [own SENJU team]

Each ASURA reports to the human independently.
Human synthesizes across ASURAs.
Or one ASURA is designated as meta-orchestrator.
This maps to connector.json’s meeting protocol — multiple ASURAs in dialogue, each managing their own SENJU teams underneath.

​
Origin

ASURA and SENJU started as Claude Code skills (/niia-asura, /niia-senju) — the first implementation of this model, running inside a single AI session using subagents. 
Evolution:
  Skill (prototype)     → ran inside Claude Code, Claude-only
  connector.json (spec) → declarative, any AI, any machine
  PTY-for-AI (runtime)  → headless daemon, cross-machine

The model stayed the same. The implementation grew.
The skill was the proof of concept. It validated that phased parallel orchestration produces better results than single-agent execution. connector.json is the generalization — the same ASURA/SENJU roles, expressed declaratively, executed on infrastructure that spans machines and LLM providers.

​
In connector.json

{
  "connector": "2.0",
  "name": "feature-build",

  "pipeline": {
    "phases": [
      {
        "name": "research",
        "workers": 5,
        "model": "haiku"
      },
      {
        "name": "synthesize",
        "workers": 1,
        "model": "opus"
      },
      {
        "name": "implement",
        "workers": 1,
        "model": "opus",
        "capabilities": { "can_spawn_teams": true }
      },
      {
        "name": "verify",
        "workers": 3,
        "model": "sonnet"
      }
    ],
    "scratchpad": true
  }
}
  • The pipeline is ASURA — sequential phases with synthesis between them
  • "workers": 5 is SENJU — parallel dispatch within a phase
  • "can_spawn_teams": true allows a SENJU to become ASURA — the recursive step
  • scratchpad is the connective tissue — how phases and levels share knowledge

​
The New Literacy

There was a time when understanding “files and folders” was a new skill. Then “client-server architecture.” Then “containers and orchestration.” Each era introduced a structural pattern that separated the people who could design systems from the people who could only use them. The AI era’s structural pattern is fractal orchestration. 
Era               Pattern                   Literacy
─────────────     ─────────────────────     ──────────────────
1980s             Files and directories     "Where is my data?"
1990s             Client-server             "What talks to what?"
2010s             Containers + K8s          "What runs where?"
2020s             AI agents                 "Who does what?"
2025+             Fractal orchestration     "Who orchestrates whom,
                                             and how deep does it go?"
Understanding the ASURA-SENJU pattern means understanding:
  • When to go parallel (SENJU) vs when to go sequential (ASURA)
  • When a worker should become an orchestrator (the recursive step)
  • How many dimensions to open (1D flat, 2D directional, 3D deep, 4D distributed)
  • Where to draw the boundary between human oversight and AI autonomy
  • How scratchpad and mailbox connect levels without coupling them
This is not about learning a specific tool. It’s about recognizing a pattern that will appear in every AI system — whether it uses connector.json or not. 
Without this literacy:
  "I have 5 AI agents running in parallel"
  = flat. 1-dimensional. Everyone does this.

With this literacy:
  "I have an ASURA with 5 SENJU workers,
   2 of which are ASURAs with their own 3-worker SENJUs,
   across 2 machines, with sandboxed worktrees per level"
  = designed. Multi-dimensional. Intentional depth.

​
Summary

SENJU: "Do N things at once"            → parallel workers
ASURA: "Do things in phases"            → sequential orchestration
Key:   Any SENJU can become ASURA       → recursive depth
Human: Understands the pattern           → designs the structure
Human: Doesn't need to understand inside → uses the structure

This is not a framework. This is a model.
connector.json expresses it. PTY-for-AI executes it.
The model scales to any depth, any width, any number of machines.

The pattern is the literacy.
The literacy is the power.