One repo, several very different concerns
This is a solo project, not a team, but a single change ("add a new blog field") can still touch a FastAPI model, an admin form, a public JS fetch, and the docs all at once. A flat context window blurs those concerns together, and scoped subagents keep each one focused.
Scoped context
Each subagent only sees the tools and instructions relevant to its lane. A docs pass doesn't carry DB-schema reasoning it doesn't need.
Least privilege
QA and security review-only agents have no write access. They report findings; they don't quietly patch auth code themselves.
Hard gates
Merges to main, production DB actions, and manual gcloud commands always stop for a human yes.
Eight agents, eight lanes
Defined in .claude/agents/ in the repo. The orchestrator picks one lane per sub-task; a change spanning several lanes gets broken up and integrated by the orchestrator, not handed wholesale to one agent.
Nothing ships without a stop
A worked (illustrative) example: someone asks for a schema change. Click a stage to see what happens at each step. The last one always waits for a real human reply, it never auto-continues.
See it running
This is a scripted, client-side recreation, not a live feed. It loops through a hardcoded sequence of realistic dispatch events to give a feel for the internal "Orchestrator Constellation" dashboard used to keep the roster above honest. The real one runs on a live database and isn't public.
Demo replay, not a live feed
Constellation
--:--:--
Each node is one of the eight scoped subagents in .claude/agents/.
Amber = actively dispatched, rose = flagged for review, slate = idle.
Recent activity
Roster
Walk the office
The private dashboard also has an Office view: the same eight agents as coworkers in a pixel-art office, acting out their live status. Busy agents type at their desks, idle ones drift to the sofa and coffee machine, and anyone waiting on a review stands up and waves. The owner walks in as an avatar, asks an agent what it's doing, or pins a task note on its desk. The orchestrator reads open notes at the start of its next session and asks before dispatching anyone.
This copy runs the same scripted replay as the demo above. Click the floor to walk, click a coworker to go talk to them.
Demo replay: canned answers, nothing is sent
In the real office, Claude answers free-form questions from the live dashboard data. This demo sticks to the quick questions.
Diagrams
How a request moves from chat to a merged, deployed change.
Sequence: a schema-touching request
The orchestrator fans out to the right lanes, then stops for approval before anything touches main or the database.
sequenceDiagram
actor Ikhwan
participant Orch as Orchestrator (Claude Code)
participant Backend as eonelabs-backend
participant Docs as eonelabs-docs
participant QA as eonelabs-qa
actor Human as Ikhwan (approval)
Ikhwan->>Orch: "Add a featured flag to Projects"
Orch->>Backend: model + schema + router change
Backend-->>Orch: diff (model.py, schemas.py, admin form)
Orch->>Docs: update README / CLAUDE.md if structure changed
Docs-->>Orch: diff
Orch->>QA: local verification (uvicorn --reload)
QA-->>Orch: pass/fail per area
Orch->>Human: Approval Gate: PR ready, DB migration needed
Human-->>Orch: approve migration + merge
Orch->>Orch: open PR, merge triggers Cloud Build
Roster at rest
Where each agent's read/write access stops.
flowchart LR
Orch["Orchestrator\n(top-level session)"]
Orch --> BE["eonelabs-backend\nread+write"]
Orch --> FE["eonelabs-frontend\nread+write"]
Orch --> CS["eonelabs-content-seo\nread+write"]
Orch --> QA["eonelabs-qa\nread-only"]
Orch --> DO["eonelabs-devops\nread+write"]
Orch --> SEC["eonelabs-security\nread-only"]
Orch --> DOC["eonelabs-docs\nread+write"]
Orch --> MOB["eonelabs-mobile\nread+write"]
BE --> Repo[("Local working tree")]
FE --> Repo
CS --> Repo
DO --> Repo
DOC --> Repo
MOB --> Repo
DO -. approval gate .-> Prod[("Cloud Run / Neon\n(production)")]