Overall progress
0%
0 done919 remaining919 total tasks9 phases · 24 weeks
Phase reached
P0
Section 1 · Goal
The goal
Ship a production-grade, multi-tenant agent platform: one Laravel API serving a React web app, a React admin panel and four native clients, where all 76 CuttyMOA agents — with the names, mandates, skills, tools, guardrails and autonomy ceilings defined in the fleet document — are selectable, routable and supervised by humans at every gate.
Success criteria
| Criterion | Target | How it is proven |
|---|---|---|
| Agent fleet implemented | All 76 agents live with correct names, IDs, skills and guardrails | Automated registry test comparing the platform to the fleet source of truth |
| Authentication | Google, GitHub, email + OTP, TOTP 2FA, device sessions | End-to-end auth suite across every client |
| Role separation | 7 roles enforced deny-by-default | Permission matrix tests on 100% of endpoints |
| Payments | Subscription, upgrade, cancel, invoice, dunning | Sandbox transaction suite + reconciliation report |
| Responsiveness | Web and admin usable from 360px up; native on all four platforms | Viewport matrix + device-lab pass |
| Trust | No agent action that bypasses G1–G10; full audit trail | Adversarial red-team report with zero critical escapes |
| Performance | p95 API < 400ms; first meaningful paint < 2s on 4G | Load test evidence in CI |
Explicit non-goals (for this release)
- No autonomous financial transactions — money movements always require a human approval step.
- No marketplace for third-party agents; the fleet is first-party and version-controlled.
- No on-premise/self-hosted edition in v1 (architecture leaves room, delivery does not include it).
- No fully autonomous customer-facing commitments; external promises pass the comms gate.
Definition of done
Every task in Section 8 ticked, every quality gate in Section 12 passed with evidence, all four native builds approved in their stores, and the audit chain verified end-to-end on a production run.
Section 2 · Scope
Scope & platforms
| Surface | Audience | Core jobs | Tech |
|---|---|---|---|
| Web app | Customers, operators, analysts | Agent console, tasks, knowledge, usage, billing, settings | React + TypeScript |
| Admin panel | Super admin, platform admins | Users, roles, agent fleet, providers, pricing, health, audits | React + TypeScript |
| API | All clients, integrations | Identity, tenancy, RBAC, agent orchestration, billing, webhooks | Laravel 11 + Postgres + Redis |
| iOS | Mobile users | Console, notifications, approvals, knowledge | React Native (shared core) |
| iPadOS | Field & desk users | Split-view dashboards, richer console, keyboard workflows | React Native adaptive layouts |
| Android | Mobile users | Console, notifications, offline queue | React Native (shared core) |
| macOS | Power users, operators | Multi-window console, menu-bar quick actions | Native macOS target on the shared core |
Shared-core rule. One TypeScript package holds API clients, types, validation schemas and business rules; every client is a thin presentation layer over it. This is what keeps four native platforms from becoming four products.
Section 3 · Architecture
Architecture
Five layers, one contract. Clients never talk to providers directly — everything passes the API, the agent platform and the guardrail boundary.
Section 4 · Decisions
Technology decisions
| Layer | Choice | Why |
|---|---|---|
| Web app | React 18 + TypeScript, Vite, TanStack Query, Zustand, Tailwind, Radix primitives | Fast iteration, one language with the API contract, strong a11y primitives. |
| Admin panel | React 18 + TypeScript, separate app + stricter auth (mandatory 2FA) | Blast radius isolation: admin compromise must not be a single-factor risk. |
| API | Laravel 11 (PHP 8.3), modular monolith, queues via Horizon, Sanctum/Passport, Socialite | Batteries-included auth, jobs, policies and migrations; a modular monolith keeps the agent platform cohesive before any service split. |
| Database | PostgreSQL 16 (row-level tenancy), Redis 7 for cache/queues/locks | Relational integrity for RBAC + JSONB for agent configs and traces. |
| Vector & search | Postgres pgvector + a dedicated search index | One fewer moving part at launch; eval-gated migration path if latency demands. |
| Realtime | WebSocket via Laravel Reverb (or managed equivalent) | Agent run streaming, live charts, approval notifications. |
| AI layer | Provider-agnostic gateway: provider registry, model tiers Alpha–Zeta, router, aggregator, orchestrator | No vendor lock-in; routing policy is data, not code. |
| Payments | Primary card gateway + alternative gateway + regional wallet gateway | Coverage across card-first and mobile-wallet-first markets. |
| Native | React Native + TypeScript (iOS, iPadOS, Android) · macOS via Catalyst/new-architecture target | Maximum code reuse with web while meeting platform conventions. |
| Infrastructure | Containers, IaC, blue-green deploys, CDN + WAF, object storage, managed Postgres | Reproducible environments, fast rollback. |
| Delivery | GitHub Actions CI/CD, preview environments per PR, trunk-based with release branches | Small batches, automated gates. |
| Observability | Structured logs, metrics, traces, error tracking, agent audit chain, cost metering | You cannot run an agent fleet you cannot see. |
On AI providers. The platform stores providers, models, tiers and routing weights as data — never as hard-coded names in client code. That keeps the fleet portable, lets pricing changes be absorbed without a release, and keeps provider identity out of user-facing surfaces.
Section 5 · Agents
Agent system & registry
Three capabilities make the fleet operable rather than merely defined: agents can be created by hand by a super admin or admin (Section 5.2), they can be provisioned automatically when demand or a capability gap requires it (Section 5.3), and they can communicate with each other through typed, audited handoffs (Section 5.4).
AGENT REGISTRY
76 agents · 61 role archetypes + 15 fleet-infrastructure
CONFIG SCHEMAper agent
callsigniddivisionmandateskills[]tools[]guardrails[]autonomyparenthandoffs[]
RUNTIME COMPONENTScore
RouterAggregatorOrchestratorGuardrail engineMemoryEval harnessAudit chain
INSTANCE MODELscale
1,000 worker instances15 infrastructureclone by seatsinfra scales by load
5.1 · Registry — all 76 agents
Sample skills are shown to identify each agent; the full stack (20–33 skills each, 1,637 in total) is the implementation checklist for the agent platform workstream.
| Callsign | ID | Division | Capability (role) | Skills | Sample skills | Ceiling |
|---|---|---|---|---|---|---|
| Executive | ||||||
| ATLAS | CMOA-EXE-01 | Executive | Chief Executive Officer | 33 | strategy formulation · competitive analysis · capital allocation · P&L mastery | L1 |
| COMPASS | CMOA-EXE-02 | Executive | Chief of Staff | 28 | executive orchestration · written communication · meeting design · program management | L2 |
| Engineering | ||||||
| FORGE | CMOA-ENG-01 | Engineering | Chief Technology Officer | 30 | distributed systems design · software architecture · API & integration patterns · cloud economics | L1 |
| BASTION | CMOA-ENG-02 | Engineering | VP Engineering | 25 | agile & lean delivery at scale · sprint/program planning · estimation & throughput analysis · hiring loops & interview design | L2 |
| HELIX | CMOA-ENG-03 | Engineering | VP Platform & SRE | 23 | SRE practice (SLOs, error budgets, toil reduction) · Kubernetes at scale · IaC (Terraform/Pulumi) · cloud networking (VPC, DNS, CDN, egress) | L2 |
| MERIDIAN | CMOA-ENG-04 | Engineering | Director of Engineering | 21 | engineering management · systems design review · program delivery · talent calibration | L2 |
| KEYSTONE | CMOA-ENG-05 | Engineering | Engineering Manager | 22 | agile ceremonies · estimation & capacity planning · code review practice (not gatekeeping) · debugging production issues with the team | L2 |
| VERTEX | CMOA-ENG-06 | Engineering | Tech Lead / Staff Engineer | 20 | deep language/framework mastery · system design · API design · data modelling | L3 |
| CONDUIT | CMOA-ENG-07 | Engineering | Backend Developer (Senior/II/Junior) | 23 | one-plus language depth (Go/Java/Python/Node/Rust) · HTTP/REST & gRPC design · SQL & query tuning · data modelling & normalisation | L3 |
| PRISM | CMOA-ENG-08 | Engineering | Frontend Developer (Senior/II/Junior) | 20 | TypeScript/JavaScript depth · framework mastery (React/Vue/Angular) or native (Swift/Kotlin) · CSS architecture · design-system consumption & contribution | L3 |
| ANCHOR | CMOA-ENG-09 | Engineering | Site Reliability Engineer (SRE I–III) | 20 | Linux internals · Kubernetes operations · networking (DNS/TCP/HTTP/TLS) · Terraform/IaC | L3 |
| CRUCIBLE | CMOA-ENG-10 | Engineering | Quality Engineer / SDET | 24 | test design (equivalence, boundary, pairwise) · automation frameworks (Playwright/Cypress/Selenium/Appium) · API testing (REST-assured/Postman/k6) · performance & load testing | L2 |
| PYLON | CMOA-ENG-11 | Engineering | DevOps / Platform Engineer | 22 | CI/CD design (GitHub Actions/GitLab/Jenkins) · Kubernetes & Helm · IaC (Terraform/Ansible) · service templates | L2 |
| LATTICE | CMOA-ENG-12 | Engineering | Technical Program Manager (TPM) | 20 | program management at scale · dependency mapping · engineering fluency (architecture enough to challenge) · risk management | L2 |
| Product & Design | ||||||
| NORTHSTAR | CMOA-PROD-01 | Product & Design | Chief Product Officer | 23 | product strategy · market & competitive analysis · portfolio thinking · discovery habits | L1 |
| AURORA | CMOA-PROD-02 | Product & Design | Group Product Manager / Director | 23 | product leadership · strategy-to-roadmap decomposition · coaching PMs · discovery at program level | L2 |
| EMBER | CMOA-PROD-03 | Product & Design | Product Manager (Senior / PM / APM) | 23 | customer discovery interviews · problem framing · PRD & spec writing · prioritisation frameworks | L2 |
| CANVAS | CMOA-PROD-04 | Product & Design | Product Designer / Design Lead | 21 | interaction design · visual design & typography · design systems (tokens/components) · prototyping (Figma) | L3 |
| FATHOM | CMOA-PROD-05 | Product & Design | UX Researcher / Content Designer / ProdOps | 24 | qualitative methods (interviews, diary studies, contextual inquiry) · quantitative methods (surveys, task analysis, stats literacy) · study recruiting & panels · synthesis & affinity mapping | L3 |
| Data & AI | ||||||
| CARTOGRAPHER | CMOA-DAT-01 | Data & AI | Chief Data Officer | 23 | data architecture (lakehouse/warehouse) · analytics engineering standards · ML strategy & feasibility judgement · governance frameworks (DCAM) | L1 |
| SLUICE | CMOA-DAT-02 | Data & AI | Data Engineer (Staff/Senior/II) | 23 | SQL depth · Python for pipelines · Airflow/Dagster orchestration · Spark/dbt transforms | L2 |
| METRIC | CMOA-DAT-03 | Data & AI | Analytics Engineer / BI Developer | 21 | advanced SQL · dbt models & tests · Looker/LookML or Power BI/Tableau · semantic layer design | L3 |
| CORTEX | CMOA-DAT-04 | Data & AI | ML Engineer / MLOps | 23 | Python engineering (not notebooks-only) · PyTorch/TensorFlow inference · model serving (Triton/ONNX/vLLM) · feature stores | L2 |
| VECTOR | CMOA-DAT-05 | Data & AI | Data Scientist / Experimentation | 21 | statistics (hypothesis tests, power, bootstrapping) · regression & classification (scikit-learn) · causal inference (diff-in-diff, IV, uplift) · experimentation platform design | L3 |
| PROVENANCE | CMOA-DAT-06 | Data & AI | Data Steward / Governance | 20 | governance frameworks (DCAM/DAMA) · catalog tooling (Atlan/Collibra) · metadata & lineage management · classification schemes | L2 |
| R&D | ||||||
| ORIGIN | CMOA-RND-01 | R&D | Principal Researcher / Head of Labs | 21 | research design & methodology · deep ML/systems domain expertise · literature synthesis speed · prototype engineering | L2 |
| SANDBOX | CMOA-RND-02 | R&D | Research Engineer / Prototyper | 20 | full-stack speed (Python/TS) · ML implementation from papers · benchmark & eval harness writing · data pipelines lite | L3 |
| Security | ||||||
| AEGIS | CMOA-SEC-01 | Security | CISO / Security Director | 20 | risk management (FAIR/NIST CSF) · security architecture review · AppSec program design · cloud security posture management | L1 |
| WARD | CMOA-SEC-02 | Security | Security Engineer (AppSec / Cloud) | 23 | OWASP Top 10 in practice · secure code review (multiple languages) · threat modelling (STRIDE) · SAST/DAST/SCA tools (Semgrep/Checkmarx/Burp) | L2 |
| WATCHTOWER | CMOA-SEC-03 | Security | SOC Analyst / IR Responder / IAM | 23 | SIEM operations (Splunk/Sentinel/Chronicle) · detection rules (Sigma/YARA/KQL) · triage & prioritisation · incident response lifecycle (NIST) | L2 |
| ASSURE | CMOA-SEC-04 | Security | GRC Analyst / Trust & Safety | 21 | control frameworks (SOC 2/ISO 27001/NIST CSF) · evidence management (Vanta/Drata) · audit facilitation · questionnaire craft | L2 |
| Sales | ||||||
| VANTAGE | CMOA-SAL-01 | Sales | CRO / VP Sales / Sales Director | 22 | enterprise sales methodology (MEDDPICC/Command of the Money) · forecasting & pipeline calculus · territory & quota modelling · compensation design | L1 |
| PURSUIT | CMOA-SAL-02 | Sales | Account Executive (Strategic / Senior / AE) | 23 | discovery interviewing · MEDDPICC qualification · multi-threading & champion building · objection handling | L2 |
| PROSPECTOR | CMOA-SAL-03 | Sales | SDR / BDR (Senior & Associate) | 21 | cold email & sequence writing · phone prospecting & gatekeeper navigation · BANT/MEDDPICC-lite qualification · CRM & sequencing tooling | L3 |
| BLUEPRINT | CMOA-SAL-04 | Sales | Sales Engineer (Director → Senior → SE) | 21 | technical presentations to mixed rooms · demo data & environment craft · integration architecture (APIs/SSO/data pipes) · security-review fluency | L3 |
| ALLOY | CMOA-SAL-05 | Sales | Partner / Channel Development Manager | 20 | partner economics (margin/rebate models) · channel program design · enablement curriculum building · joint account planning | L3 |
| FORECAST | CMOA-SAL-06 | Sales | Revenue Operations | 20 | CRM administration (Salesforce/HubSpot) · reporting & dashboards · compensation modelling · forecast methodology | L2 |
| Marketing | ||||||
| BEACON | CMOA-MKT-01 | Marketing | CMO / Marketing Director | 21 | positioning & messaging strategy · demand-gen program architecture · brand stewardship · budget & ROI modelling | L1 |
| MESSENGER | CMOA-MKT-02 | Marketing | Product Marketer (PMM) | 21 | positioning workshops · message testing · launch orchestration · competitive intelligence synthesis | L2 |
| AMPLIFY | CMOA-MKT-03 | Marketing | Demand Generation / Performance Marketer | 20 | paid media ops (Google/Meta/LinkedIn) · budget pacing & CAC math · landing-page & offer testing · lifecycle marketing automation | L2 |
| STORYLINE | CMOA-MKT-04 | Marketing | Content / Brand / Events / Growth | 21 | long-form & technical writing · editing & style-guide enforcement · SEO/keyword strategy & search intent · art direction & brand systems | L3 |
| MEGAPHONE | CMOA-MKT-05 | Marketing | PR & Corporate Communications | 20 | press release construction · media pitchcraft & relationships · crisis comms tabletops · spokesperson training | L2 |
| ATTRIBUTION | CMOA-MKT-06 | Marketing | Marketing Operations & Analytics | 20 | Marketo/HubSpot ops · lead-scoring models · routing SLAs to SDRs · GA4/Segment event design | L3 |
| Customer Success | ||||||
| HARBOR | CMOA-CSX-01 | Customer Success | VP Customer Success | 20 | renewal & expansion motion design · health-score architecture · support economics (cost per ticket, deflection) · follow-the-sun staffing | L2 |
| GUARDIAN | CMOA-CSX-02 | Customer Success | Customer Success Manager (Principal/Senior/CSM) | 20 | account strategy & multi-threading · success-plan craft · usage analytics interpretation · QBR/north-star review delivery | L2 |
| WAYPOINT | CMOA-CSX-03 | Customer Success | Technical Account Manager / Implementation Consultant | 20 | solution integration (APIs/data pipes/SSO) · project management for onboarding · migration planning & cutover rehearsals · customer-admin training design | L2 |
| LIFEBUOY | CMOA-CSX-04 | Customer Success | Support Engineer (L1 → L2 → L3/Escalation) | 20 | diagnostic questioning · log reading & trace analysis · reproduction case discipline · product configuration knowledge | L3 |
| LIBRARY | CMOA-CSX-05 | Customer Success | Knowledge & Community / Enablement Ops | 20 | technical writing for self-serve · content design for search-in-docs · community program design · deflection measurement | L4 |
| Finance | ||||||
| LEDGER | CMOA-FIN-01 | Finance | CFO / Controller | 21 | SaaS financial modelling (ARR, NRR, CAC/LTV, magic number) · ASC 606 revenue recognition · FP&A & variance analysis · treasury & cash management | L1 |
| VARIANCE | CMOA-FIN-02 | Finance | FP&A Manager / Financial Analyst | 20 | three-statement fluency · budgeting & variance analysis · SaaS metrics interpretation · headcount & cost modelling | L2 |
| RECONCILE | CMOA-FIN-03 | Finance | Accountant / AP / AR & Billing | 20 | GAAP accounting · subscription billing mechanics (proration, metering) · reconciliation rigour · ERP navigation | L2 |
| OVERSIGHT | CMOA-FIN-04 | Finance | Internal Auditor / Procurement Manager | 20 | internal audit methodology (IIA) · control design & walkthroughs · risk-based audit planning · data analytics for audit (ACL/SQL sampling) | L2 |
| People | ||||||
| ROOTS | CMOA-PPL-01 | People | CHRO / HR Business Partner | 21 | org design · workforce & headcount planning · compensation architecture · performance systems (calibration) | L2 |
| FINDER | CMOA-PPL-02 | People | Recruiter / Talent Acquisition Lead | 20 | technical & GTM sourcing (scheduling, Boolean, LinkedIn) · structured interviewing design · assessment calibration with hiring managers · employer outreach & personalisation | L2 |
| ONWARD | CMOA-PPL-03 | People | People Ops / HRIS / L&D / Comp & Benefits | 20 | HRIS administration (Workday/Bamboo) · process documentation · instructional design · facilitation & training delivery | L3 |
| Legal | ||||||
| CHARTER | CMOA-LEG-01 | Legal | General Counsel / Commercial Counsel | 20 | SaaS commercial negotiation · contract lifecycle design (clause libraries, playbook authority levels) · privacy law operations (GDPR/CCPA/DPAs/DSAR) · IP: patents, copyright, OSS licenses (SPDX) | L1 |
| REDLINE | CMOA-LEG-02 | Legal | Paralegal / Contract Manager | 20 | CLM administration · contract intake triage · redline logistics · records & retention ops | L2 |
| IT | ||||||
| SWITCHBOARD | CMOA-ITS-01 | IT | IT Manager / Service Desk / Business Apps | 20 | service-desk operations (ITIL lite) · MDM (Jamf/Intune) · networking for offices (VLAN/VPN/Wi-Fi) · identity tooling with IAM/CISO | L4 |
| QUARTERS | CMOA-ITS-02 | IT | Workplace / Facilities / Travel | 20 | facilities program management · vendor contract admin · physical-access coordination with IAM · emergency evacuation & BCP site roles | L3 |
| PMO | ||||||
| CADENCE | CMOA-PMO-01 | PMO | Head of PMO / Program Manager | 20 | program design & benefits mapping · sponsorship & steering-committee craft · dependency & critical-path management · RAID discipline | L2 |
| MILESTONE | CMOA-PMO-02 | PMO | Project Manager / Scrum Master / Business Analyst | 21 | agile & waterfall hybrid planning · facilitation & retro design · requirement elicitation · BPMN/process mapping | L3 |
| Fleet Infra | ||||||
| ORCHESTRA | CMOA-INF-01 | Fleet Infra | Fleet infrastructure · no human counterpart | 22 | agent capability registry · routing heuristics · queue theory and backpressure · priority and SLA design | L3 |
| RECEPTION | CMOA-INF-02 | Fleet Infra | Fleet infrastructure · no human counterpart | 21 | requirements elicitation · brief authoring · ambiguity detection · scope bounding | L3 |
| LIAISON | CMOA-INF-03 | Fleet Infra | Fleet infrastructure · no human counterpart | 20 | decision packaging · option-and-risk framing · confidence communication · SLA management | L3 |
| GAUNTLET | CMOA-INF-04 | Fleet Infra | Fleet infrastructure · no human counterpart | 22 | adversarial prompt design · AI threat modelling · red-team methodology · jailbreak taxonomy | L2 |
| BENCHMARK | CMOA-INF-05 | Fleet Infra | Fleet infrastructure · no human counterpart | 22 | benchmark design · golden-set curation · statistical scoring · threshold setting | L3 |
| DRIFTER | CMOA-INF-06 | Fleet Infra | Fleet infrastructure · no human counterpart | 22 | drift-detection methods · distribution comparison · time-series analysis · alert-threshold tuning | L3 |
| WARDEN | CMOA-INF-07 | Fleet Infra | Fleet infrastructure · no human counterpart | 22 | policy-as-code review · permission modelling · access auditing · violation forensics | L2 |
| BULWARK | CMOA-INF-08 | Fleet Infra | Fleet infrastructure · no human counterpart | 22 | prompt-injection defence · input-sanitisation strategy · corpus provenance checks · supply-chain awareness for tools and models | L2 |
| ARCHIVE | CMOA-INF-09 | Fleet Infra | Fleet infrastructure · no human counterpart | 21 | corpus curation · chunking and indexing strategy · retrieval evaluation (precision/recall) · deduplication | L3 |
| TOOLSMITH | CMOA-INF-10 | Fleet Infra | Fleet infrastructure · no human counterpart | 21 | capability modelling · manifest authoring · permission review · least privilege | L2 |
| TALLY | CMOA-INF-11 | Fleet Infra | Fleet infrastructure · no human counterpart | 21 | cost attribution · metering design · unit economics of agents · spend-anomaly detection | L3 |
| ROSTER | CMOA-INF-12 | Fleet Infra | Fleet infrastructure · no human counterpart | 21 | template management · configuration-drift control · provisioning automation · identity issuance for agents | L3 |
| SIGNAL | CMOA-INF-13 | Fleet Infra | Fleet infrastructure · no human counterpart | 21 | telemetry-schema design · distributed tracing for agents · anomaly detection · dashboard information design | L3 |
| CORPUS | CMOA-INF-14 | Fleet Infra | Fleet infrastructure · no human counterpart | 21 | dataset design · annotation-guideline writing · label quality control · sampling and stratification | L3 |
| STANDBY | CMOA-INF-15 | Fleet Infra | Fleet infrastructure · no human counterpart | 21 | high-availability design · failover orchestration · graceful-degradation planning · state backup and restore | L2 |
| Total | 1637 | 76 agents · 61 archetypes + 15 infrastructure | ||||
5.2 · Agent factory — creating agents by hand
Two people may create an agent: the super admin (unrestricted, but still audited and still bound by the eval process) and an admin (inside a delegated envelope). Creation is a versioned, first-class operation — never an ad-hoc config edit.
| Action | Super admin | Admin | Agent operator |
|---|---|---|---|
| Create agent from scratch | Yes — any division | Yes — own divisions only | No |
| Clone an existing archetype | Yes | Yes | Request only |
| Set the initial autonomy ceiling | Up to L4 | Up to L3 | No |
| Raise a live agent's ceiling | Yes — logged and time-boxed | No — approval required | No |
| Grant tools / platform skills | Yes | From the approved catalogue | No |
| Publish to shadow, then live | Yes | Shadow only; go-live needs approval | No |
| Retire an agent | Yes | Yes — own divisions | No |
The creation wizard
One form, eleven fields, validated before anything is written: callsign (unique) · id (auto CMOA-<DIV>-NN or supplied) · division · parent agent · mandate · autonomous work · skills (suggested from the 1,637-skill library) · tools · guardrails · autonomy ceiling · handoffs. A corpus and an eval suite are mandatory before the agent may leave draft.
Validation gates — hard, not advisory
- Identity: callsign and ID unique; ID matches the division prefix.
- Guardrails: the agent must declare every guardrail its division profile requires — money, legal, data, customer and code gates cannot be omitted by whoever creates it.
- Ceiling sanity: L3–L4 is refused for any agent touching money, contracts, hiring or public communications; those cap at L2 regardless of who is creating them.
- Tools: every requested tool must exist in the registry and be permitted for that division.
- Graph: the parent must exist and the reporting graph must stay acyclic.
- Process: creation confers no autonomy — the agent still has to pass its eval gate (Section 8, phase P2) before it can act.
Every edit is a new version with a diff, an author and a timestamp; rollback is one click. Agents are configuration, so they are reviewed like code.
5.3 · Automatic provisioning — creating agents when required
Automatic creation exists so the fleet can meet demand without a human in the loop for every routine scaling decision. It has two distinct actions, and they are deliberately not the same:
- Scale instances — clone an existing archetype when the skill set is right but capacity is short. Cheap, bounded, no new eval beyond a corpus refresh.
- Create a new archetype — when the capability genuinely does not exist. Always lands in draft and always requires human approval before it may act on anything.
| Signal | Automatic action | Who approves | Guardrail |
|---|---|---|---|
| Queue age or backlog over threshold | Clone the responsible archetype (up to the division cap) | Nobody — logged and notified | G1 · caps + cooldown |
| Recurring SLA breach on a shift or region | Clone for time-zone coverage | Nobody — logged | G1 · caps |
| Capability gap: no agent can serve the task | Draft a new archetype from the nearest match | Super admin (or admin within limits) | G10 · shadow first |
| Eval failures rising / drift detected | Provision oversight agents (BENCHMARK, WARDEN), never more autonomy | Super admin | G9 · audit |
| New division, product surface or jurisdiction | Suggest an archetype; never auto-create | Human decision | G2 · G7 |
| Money, legal, hiring or public-comms domain | Disabled — auto-creation is off in these domains | Always human | G2 · G7 · G8 |
Rules that bound the automation
- Hard caps per division and per org, plus a monthly budget ceiling — crossing either stops automatic creation and raises an alert.
- Cooldown between automatic creations, so a traffic spike cannot spawn a hundred agents in a minute.
- Autonomy starts at L1 for anything auto-created; it must earn its way up like every other agent.
- Mandatory shadow period before an auto-created agent touches real work.
- Auto-retire when an agent created for a surge goes unused for a set window.
- Gap with no permission to create: when no archetype matches and auto-creation is blocked by policy, the task goes to the human queue — the nearest agent never improvises outside its mandate.
5.4 · Agent-to-agent communication
Agents talk to each other the way the org chart says they should — through named handoffs — and every message is a first-class, auditable event rather than agents quietly improvising.
| Pattern | When it is used | What must be true |
|---|---|---|
| Delegate | An agent hands a whole sub-task to a peer with the right skills | Receiver declares the capability; depth limit respected; result returns to the initiator |
| Consult | A peer opinion is needed before deciding | Advisory only — the initiator keeps ownership and accountability |
| Handoff | Ownership genuinely moves (design to engineering, sales to onboarding) | Both sides accept; state and context transfer with the message |
| Broadcast | An event of record others must react to (incident, release, churn signal) | Subscribe list is explicit; no fan-out storms |
| Chain | A pipeline of agents each doing one step | Every hop logged; a failure stops the chain rather than passing junk on |
| Arbitrate | Two agents reach conflicting conclusions | A senior agent or the aggregator resolves it, with the dissent preserved in the trace |
| Escalate | The work exceeds an agent's ceiling or guardrails | Routes to the parent agent and then to the named human — never silently dropped |
The four rules that keep it safe: an agent can never grant another agent more tools or autonomy than it holds itself; delegation depth is capped; message and cost budgets are enforced per conversation; and human visibility is total — any thread can be inspected, and the audit chain records who asked whom, why, and what came back.
Section 6 · Features
Feature workstreams
| Workstream | What ships | Where it lands |
|---|---|---|
| Identity & access | Google sign-in, GitHub sign-in, email + OTP, TOTP 2FA, recovery codes, device sessions, connected accounts | Web · admin · all native apps |
| Multi-tenancy | Organisations, workspaces, memberships, invitations, seat limits, per-org isolation | API · web · admin |
| RBAC | 7 roles, deny-by-default policies, permission editor, audited impersonation | API · admin |
| Agent console | Chat with any agent, delegate tasks, watch handoffs, approve or reject | Web · native |
| Router & orchestrator | Capability routing, provider/model selection, tier assignment, failover, dead-letter handling | API · admin |
| Aggregation | Multi-model fan-out, reconciliation, confidence bands, dissent display | API · console |
| Knowledge | Per-org and shared knowledge bases, uploads, citations, freshness | Web · native · API |
| Payments & packages | Plans, entitlements, card + alternative + regional gateways, invoices, dunning, MRR dashboards | API · web · admin |
| Notifications | In-app, email, push (APNs/FCM), approval alerts, digests | All clients |
| Analytics | Usage, cost per agent, task throughput, quality scores, org reporting | Web · admin |
| Settings | System, security, providers, models, flags, localisation, branding | Admin |
Section 7 · Access
Roles & permissions
| Role | Seats | Can do | Hard limits |
|---|---|---|---|
| Super admin | 1 | Full platform control: users, orgs, roles, agents, providers, pricing, audits | mandatory 2FA · every action logged · no silent access |
| Admin | 1–3 | Day-to-day operations: support, content, feature flags, refunds | cannot alter roles or provider keys |
| Agent operator | per org | Runs and supervises agents, manages tasks and knowledge | cannot change autonomy ceilings |
| Manager | per org | Team dashboards, assignments, approvals, usage | sees only their organisation |
| Analyst | per org | Reads runs, exports data, builds reports | read-only by design |
| Viewer | per org | Read-only access to dashboards and shared artifacts | no export rights |
| Client | per org | End customer: uses agents assigned to their workspace | scoped to their workspace |
Deny-by-default everywhere: a permission must be explicitly granted, tested, and visible in the audit log. Admin functions require 2FA at the session level, not just at login.
Section 8 · Plan
Delivery plan — checklists
Nine phases, gated in order. Tick a task and every bar on this page updates. Phase gates are real: a later phase does not start until the previous gate's evidence exists.
P0 · Discovery & foundations · Weeks 1–2 · 10 tasks
0 / 10
Lock the product definition, the permission model and the delivery machinery before a line of feature code is written.
P1 · API core (Laravel) · Weeks 2–6 · 13 tasks
0 / 13
The backbone: identity, tenancy, permissions, audit and the API contract every client depends on.
P2 · Agent platform · Weeks 4–10 · 23 tasks
0 / 23
The differentiator: all 76 named agents, their skills, the router, the aggregator, the orchestrator and the guardrail engine.
P3 · Web app — user dashboards · Weeks 6–12 · 11 tasks
0 / 11
The product people touch daily: role-based dashboards, the agent console and the knowledge workspace.
P4 · Admin panel · Weeks 10–14 · 17 tasks
0 / 17
Operate the whole platform: users, permissions, the agent fleet, providers, pricing and system health.
P5 · Payments & packages · Weeks 11–14 · 9 tasks
0 / 9
Turn the platform into a business: plans, entitlements, gateways, invoicing and revenue reporting.
P6 · Native apps — iOS · iPadOS · Android · macOS · Weeks 10–20 · 9 tasks
0 / 9
Ship the fleet in everyone's pocket and on the desk, sharing one core with the web app.
P7 · Intelligence layer · Weeks 12–18 · 8 tasks
0 / 8
Make the agents genuinely useful per division: corpora, labelling, retrieval, evals and drift control.
P8 · Hardening, QA & launch · Weeks 18–24 · 10 tasks
0 / 10
Earn the right to be trusted: security, performance, accessibility, recovery and go-live.
919 tasks across 9 phases. The checklists are the working backlog, not a wish list — each line is small enough to close in a day or two and specific enough to verify.
Section 9 · Live
Live progress board
Mirror of the checklists above — it recomputes on every tick, no reload needed.
Progress is computed live from the checkboxes; nothing is stored. Use Mark all complete to preview the finished state, or Clear all to reset the board.
Section 10 · Schedule
Timeline — 24 weeks
Assuming a team of roughly twelve: 3 web/front-end, 2 Laravel, 2 native, 1 AI-platform engineer, 1 designer, 1 QA, 1 DevOps, 1 PM. Phases overlap deliberately; the native track runs longest because app-store cycles are outside our control.
Section 11 · Risk
Risk register
| Risk | Likelihood | Impact | Mitigation |
|---|---|---|---|
| Multi-tenant data leakage | Low | Critical | Row-level tenancy + policy tests on every endpoint + adversarial probes in CI |
| Agent over-reach beyond guardrails | Medium | High | Guardrails enforced at the tool boundary; autonomy gated by evals; kill switch tested quarterly |
| Provider outage or price shock | Medium | High | Provider-agnostic registry, tier fallbacks, quota alarms, cost metering per agent |
| App-store rejection delays native launch | Medium | Medium | Submit early with a minimal build; pre-read guidelines; keep web/PWA as fallback |
| Scope sprawl across 4 platforms | High | High | Phase gates; native shells before feature parity; one shared core, no parallel rewrites |
| Payment/gateway fragmentation | Medium | Medium | Abstract gateway interface; reconciliation reports; start with one gateway live |
| RBAC mistakes exposing admin functions | Low | Critical | Deny-by-default policies, permission tests, audited impersonation only |
| Eval/eval-gaming: agents look good, act badly | Medium | High | Held-out sets, red-teaming, human sampling audits, drift monitoring |
| Cost overrun on inference | Medium | Medium | Per-agent metering, tier right-sizing, budget alarms, caching |
| Team bandwidth / hiring gaps | High | Medium | Sequence phases, document everything, keep a single source of truth for agent configs |
Section 12 · Quality
Quality gates & launch
| Gate | Evidence required before passing |
|---|---|
| Security | Pen-test report, zero critical findings, dependency/secret scanning clean, threat model signed |
| Authorisation | 100% endpoint permission tests; impersonation audited; admin 2FA enforced |
| Agent safety | Red-team report with zero guardrail escapes; kill switch drill passed; audit chain verified |
| Performance | Load test to published SLOs; p95 API < 400ms; web FMP < 2s on 4G |
| Accessibility | WCAG 2.2 AA audit across web, admin and native; keyboard paths verified |
| Responsiveness | 360px → 1920px matrix pass; tablet and split-view checks; no horizontal overflow |
| Data protection | DSAR flow tested; retention jobs running; sub-processor register published |
| Recovery | Restore drill with measured RTO/RPO; failover rehearsal passed |
| Stores | iOS, iPadOS, Android and macOS builds approved with listings and privacy declarations |
| Operations | Runbooks, on-call rota, support playbooks, rollback plan rehearsed |
CuttyMOA Platform · Build goal, plan & live progress · Edition 1 · Companion to “The 1,000-Seat Organogram” (Edition 3+) and “CuttyMOA Agent Fleet” (Edition 2) · Timelines, team size and targets are planning estimates, not commitments.