No owner
One assistant answers everything. Nobody owns the PRD, the ADR or the release note, so nothing can be reviewed.
Case study · AI workforce
One person. A 25-role AI team.
I run my side projects like a small software company: 25 AI roles, seven functions, one human. Every role owns a single artifact. Every decision to ship stays with me.
This is the operating model behind the workforce floor on my homepage — what the roles do, what they are not allowed to do, and what has actually run.
- 25 agent roles
- 7 functions
- 4 human gates
- 1 human
Why it exists
A chat window is not an org chart.
Most agent setups fail at the same three points. The fix is not a better prompt. It is a smaller role, a named artifact and a gate.
No boundary
An agent with repo-wide write access is a production incident waiting for a trigger. Speed is not the constraint. Blast radius is.
No evidence
A demo shows the happy path. It never shows which roles have run a real ticket, or what happened when they failed.
The floor
Seven functions. 25 roles. One artifact each.
The chief-of-staff plans the week. Six functions do the work and hand off documents, not opinions. If a role cannot name its artifact, it does not get a desk.
Leadership
1 role- chief-of-staff weekly plan, OKRs, handoffs
Product & Eng
8 roles- pm PRD, acceptance criteria, backlog
- architect ADR, API/data contracts
- builder implementation + tests + PR
- reviewer code review
- qa test plan, e2e, regression
- release release note, deploy dispatch
- sre health, capacity, dependency risk
- librarian docs, runbooks, decision log
Prototype
3 roles- ux-designer flows, wireframes, states
- prototyper clickable HTML + preview link
- design-critic heuristic review, decision memo
Research
3 roles- market-researcher market/competitor/pricing, cited
- user-researcher interviews, usability, personas
- data-analyst event definitions, funnels, weekly metrics
Marketing
4 roles- marketing-lead positioning, channels, budget
- content-seo content drafts, SEO briefs
- growth experiments, CRO, activation
- brand-designer identity, creative assets
Support
3 roles- prod-support first response, triage, timeline
- incident-commander severity, decisions, comms cadence
- customer-comms status updates, support replies
Security
3 roles- sec-intel advisories, weekly bulletin
- patch-engineer dependency/vulnerability patches
- sec-reviewer auth/upload/crypto/dependency review
A 26th agent, notifier, is a subagent that only sends P1 alerts and
blocked-gate messages. It has no shell and cannot write to the repo, so it is not on the
floor.
The loop
One ticket, six steps, four human decisions.
A ticket is the only unit of work. It moves through the same path every time. A gate is a person, not a checklist.
-
Intake
The PRD, acceptance criteria and backlog. Nothing starts without a written problem.
-
Design
An ADR with API and data contracts, only for work longer than two days.
-
Build
Implementation, tests and a pull request. One ticket per branch.
-
Review
The diff is checked against the criteria, the test plan and CI.
-
Release
A release note, a green scan and a rollback SHA. Deploy waits for a person.
-
Operate
Health, capacity and dependency risk; triage and an incident timeline when something breaks.
The gates
What a human still decides.
Automation is allowed to prepare a decision. It is not allowed to make one. Content and spend carry their own gates.
| Gate | The question | Evidence required |
|---|---|---|
| Scope | Is this the right problem? | Problem statement + acceptance criteria |
| Design | Is this the right shape? (work > 2 days) | ADR + API and data impact |
| Merge | Is the diff safe to keep? | Green CI + no blocking review findings |
| Deploy | Is now the right time? | Green scan + rollback SHA |
The blast radius
What the agents cannot do.
Each role starts from a permission tier. A deny in the baseline cannot be relaxed by a role. The narrowest set that still does the job wins.
| Tier | Access | Roles |
|---|---|---|
read | No writes | reviewer · sec-reviewer · design-critic |
docs(path) | Write only under an assigned docs path | pm · architect · researchers · marketing |
code | Repository writes; push asks; force-push and main denied | builder · patch-engineer · prototyper |
ops-read | docker ps, logs and stats; no mutations | sre · prod-support |
security | docs/security only | sec-intel |
notify | No shell; alerts only | notifier |
Hard rules, for every role
-
Never read, print or commit
.env*, tokens or keys. -
Never run
sudo,systemctl, or anything that changes production. -
Never push to
main, force-push, merge or deploy without a human gate. - Never invent requirements, numbers, CVEs or test results.
The agent most likely to cause damage is the one with the broadest permission. Fix the tier before you fix the prompt.
Evidence, not intent
What has actually run.
I track the difference between a role that exists and a role that has shipped. The status table is deliberately unglamorous.
The first real review
reviewer read a merged origin-authentication change and returned six
findings: one high, one medium-high, two medium, two low. One was a real secret-path
disclosure; two were availability risks. It stayed read-only and named four residual
risks it could not verify.
Validation, not vibes
validate.sh fails when frontmatter is incomplete, a baseline deny is
missing, a command points at a role that does not exist, or the roster drifts from the
docs.
Scaffolded is a state
A role is marked in use only after one real ticket. The first phase — pm, builder and reviewer — is in use. The others have a file, permissions and a playbook, but not yet a written first run.
What I do not claim: every role is battle-tested. The design is complete. The evidence is still accumulating. I would rather publish the gap than imply that all 25 agents are shipping.
Questions
The parts people ask about.
Does 25 roles mean 25 employees?
No. 25 agent roles and one human. I approve scope, design, merge and deploy.
Do agents deploy to production?
No. release prepares the evidence and a rollback SHA. Deploy is a human
gate.
Which model runs the team?
The roles are model-agnostic. They run in OpenCode, and I choose the model per session instead of hardcoding one into a role.
Why not more roles?
Every role adds a handoff. I add one only when a real artifact has no owner.
Can I copy the model?
Yes. Start with one artifact per role and the smallest permission set that still does the job. If you want the checklist, email me.
What breaks most often?
Handoffs and permissions — a role that cannot see what it needs, or one that can see far too much. Both show up as review findings, not demos.
Next
Building an AI team of your own?
I write about the operating model, the failures and the gates. If you are wiring agents into real delivery, I am happy to compare notes.