Different AI agents.
One team.
You lead.

The lead turns a brief into bounded worker jobs. Ajanda keeps a PR ledger, a fleet WIP gate that prevents automation from creating a blockage, and decisions waiting for an owner. Dispatch checks source freshness, project consent, host pressure and quota before starting work. Independent review follows the rule “author ≠ reviewer”; the reviewer can come from another provider. The correction path allows one fix round followed by a fresh review; unresolved work returns to the lead to split into smaller jobs.

• Count the checks, pin the revisionThe merge gate requires all counted checks to succeed and binds review to exact head and base SHAs; a changed revision stops the chain.
• Collect five recordsFor code delivery, the lead checks status, artifact, repository, remote delivery and remaining resources. A report alone does not close the job.

Claude Code and Codex are production paths; Antigravity / Gemini is beta. Kimi Code is production for local macOS sandboxed write work. Muse Code is preview and in local-dispatch acceptance. Its production dispatch fails closed unless quota admission is measurable. Each configured account maps to its provider identity; accounts and subscriptions stay separate. Budget and quota checks guide account selection, and rerouting checks consent again. Your self-hosted fleet maps a local project to its configured remote workspace.

• Remote cancellation with evidenceThe systemd scope path checks that the scope is inactive and its control group is empty or absent. Each host needs its own live acceptance.
• Local write, clear boundariesKimi Code write mode runs locally in the macOS Seatbelt sandbox with its own state-directory policy. Muse Code local dispatch is in acceptance. Its production dispatch fails closed unless quota admission is measurable. Remote Kimi Code and Muse Code targets are planned.

A grant binds an exact project root, provider, account and action set. Grant, revoke and receipts keep that decision traceable; consent is checked again before execution. We track four separate stages: source tested, change approved, installation and live acceptance. “Silence is not success” is the operating rule: unknown evidence stays visible.

• A visible permission boundaryAn unrelated project does not inherit permission. Revocation before execution blocks the start; it does not cancel a process already running.
• Watchdogs that explain the problemHealth checks and diagnosed alerts surface stale signals and failures so the operator knows where to look. A running service alone is not acceptance evidence.

One operator surface combines the dashboard and controls for account budgets, project consent, machine pause/resume, session and CSRF protection. Telegram carries owner questions, decisions and receipts when an operator decision is needed. The CLI exposes dispatch, job status and diagnostics. Live acceptance is tracked separately for each operator surface and provider.

• DashboardInspect jobs and account state; set budgets, grant or revoke project consent, pause or resume machines, and read redacted audit records.
• TelegramThe owner channel records selectable questions, approvals and receipts. Managed continuation evidence covers the Codex path; other provider modes and live message delivery still need separate acceptance.
• CLIUse the same team workflow from the terminal, with explicit job and health readback.

The roadmap starts with live acceptance of the orchestration workflow on each intended account and machine. Local inference needs a verified runtime, endpoint and isolation before hardware can count as usable capacity. Memory migration needs an agreed source, privacy boundary and repeatable import. Installation and live acceptance remain separate milestones.

• Team acceptanceExercise the complete dispatch, review and evidence chain on the intended fleet.
• Local runtime & memoryVerify inference and migration independently, with their own acceptance records.