A VOIR AI agent team does not exist in a vacuum: the AI CEO assembles it for one specific task — the way headquarters assigns a crew to a voyage. Some roles execute subtasks in parallel, another role checks the result without having done the work, and headquarters merges everything into a single report for the owner. Below: the team graph, the roles, the control points and the team's place in the AI CEO cycle.
Target architecture · nothing implemented
Demonstration · team graph
There are no standing teams in the target architecture. The task enters headquarters, headquarters builds the graph: which roles are needed, in which order, where the convergence point is. Roles work in parallel, the artefacts converge at independent acceptance, and the verdict goes into the report. Once the report is accepted, the graph is dissolved.
In the demonstration scenario: 4 executors in parallel, 8 departments donating roles, 5 steps in the management cycle.
Graph · task → HQ → roles → acceptance → report
Demonstration · pre-written scenarioINThe owner's task enters headquarters together with the acceptance criteria — fixed before any work starts.CEOHeadquarters (the AI CEO) breaks the task into subtasks and assigns roles from the department agents.RESThe researcher gathers data and tests hypotheses in parallel with the other roles.MKTThe marketer prepares positioning and copy — without waiting for the researcher, starting from the data already available.DEVThe developer assesses feasibility and drafts a prototype solution.OPSThe operator merges deadlines and dependencies into a single plan.QAIndependent acceptance checks every artefact against the criteria: VERIFIED, or REJECT with evidence.OUTHeadquarters merges the verified results into one report for the owner, with decisions that need a human listed separately.The demonstration runs a pre-written scenario and is not connected to a live AI service. The graph's nodes and edges describe the target architecture: in the product, none of these nodes is implemented yet.
Target architecture
A role is not a job title — it is a contract: which subtasks it takes, which artefact it returns, where its boundary lies. Headquarters builds the graph out of roles; the same role works on different inputs in different teams.
The only permanent role in any team. It takes the task from the owner, breaks it into subtasks, assigns executors, watches deadlines and dependencies, and merges the results into one report. It never executes subtasks itself.
Data, market, competitors, hypothesis testing. Returns a summary with sources and an explicit marker wherever data is missing — the role is contractually forbidden to invent facts.
Positioning, copy, campaign drafts for a specific audience. Works in parallel with the researcher: starts from the data on hand and refines the output when the summary lands.
Technical feasibility, prototypes, effort estimates. Returns an artefact rather than an opinion: a solution sketch with its constraints and implementation risks.
Deadlines, dependencies, process. Makes sure the parallel lanes converge at the acceptance point without gaps: who waits for whom, what blocks the next step.
The role that never did the work it checks. It compares every artefact against the criteria fixed before the start and issues a verdict: VERIFIED, or REJECT with a list of deviations and evidence.
Parallelism
A sequential chain — research first, then copy, then the plan — loses days. In the team graph, subtasks that do not depend on each other run in parallel: each role starts with its own inputs and refines its output as neighbouring lanes deliver artefacts. The diagram below is a static illustration of the same scenario as the graph above.
Synchronisation point · independent acceptance
Parallel does not mean "everyone on their own": every lane must converge at acceptance. An artefact that never reached QA does not exist for the report — headquarters will not count an unverified result, however finished it looks.
Control
Parallel work without control decays into a pile of inconsistent artefacts. The team architecture stands on four mandatory points — written into the role contract, not left to optional settings.
The task card fixes the acceptance criteria at the moment the task is set, before executors are even assigned. Acceptance compares the artefact against those criteria, not against what "looks right" after the fact. The team cannot move the criteria mid-flight.
Each role keeps a trace: what was done, on what data, which intermediate artefact came out. The task trace reads end to end — from setting to verdict — so any result can be reproduced and checked independently of who produced it.
The QA role never performs the work it checks: the author's bias is the main source of plausible-but-wrong results. A rejected artefact goes back for rework with a list of deviations, and the rejection itself stays in the trace and appears in the report.
Payments, publishing on behalf of the company, deleting data and any other irreversible external action are never performed by the team: headquarters prepares the materials and options and escalates the decision to the owner. This is an architectural constraint, not a default setting.
Link to the AI CEO
A team does not live apart from management: it exists inside the five steps of the AI CEO cycle — and is bounded by exactly those steps. Step 2 creates the team, step 3 is its work, step 4 is its check, step 5 is its dissolution. The list below shows what the team does at each step.
Management in detail lives on the AI CEO and AI CEO Cycle pages; a single executor is described on AI Agents; roles by department — on AI Employees.
Boundaries
These limits are built into the role contract, not into settings: no team assembled by headquarters can bypass them — whatever the task or the autonomy grade.
Payments, purchases and any financial obligation go through the owner's confirmation only. The team prepares the calculation and the options; a human decides.
External publications, client emails and posts leave the building only after confirmation. Inside the team drafts move freely — outside, never without a human.
The executor of a subtask never issues the verdict on its own artefact: acceptance is a separate role. Self-checks still happen, but only the QA verdict reaches the report.
No data means an explicit "no data" marker in the artefact, not a plausible-looking number. The researcher answers for the sources; acceptance verifies they exist.
A REJECT, a missed deadline and a blocker enter the final report as they are. A report with the inconvenient parts removed will not pass headquarters' own acceptance.
Choosing the format
A team is not an "improved agent" — it is a different way of working. It costs more compute and starts slower, so headquarters assembles a team only when the task is genuinely cross-domain.
| Parameter | Single agent | Team of agents |
|---|---|---|
| Task | One domain, clear criteria, linear flow of work | Cross-domain: data, copy, engineering and deadlines are interlinked |
| Execution | Sequential: step by step inside one pipeline | Parallel: independent subtasks run at the same time |
| Quality control | The agent's self-check plus acceptance inside its own pipeline | A separate QA role that never did the work |
| Report | One artefact and an acceptance verdict | A merged report: role artefacts, verdicts, trace, decisions for the owner |
| Cost of a mistake | Higher: the author's bias is not filtered by a separate role | Lower: an unverified artefact physically cannot reach the report |
| Cost and start-up | Cheaper and faster: one pipeline, minimal coordination | More expensive: headquarters, lane coordination, convergence point |
FAQ
Not as a product. This page describes the target architecture: team assembly, parallel execution and independent acceptance are not implemented in code. The graph demonstration runs a pre-written scenario and is not connected to a live AI service. The actual project status is published in the build log on the About the platform page.
A single agent handles a task inside one domain and checks its own work. A team adds three things: headquarters, which decomposes a cross-domain task and coordinates the lanes; parallel execution of independent subtasks; and a separate acceptance role that never did the work. See the table above for the full comparison.
No, there are no standing teams. Headquarters builds the graph for the specific task from agents of the eight departments and dissolves it once the report is accepted. A product launch calls for a researcher, a marketer, a developer and an operator; a cash-gap investigation calls for a financial analyst, an operator and a researcher.
Independent acceptance returns a REJECT verdict with a list of deviations from the criteria. The subtask goes back to the executor for rework, and the rejection stays in the task trace and appears in the final report — it cannot be hidden.
Yes, that is part of the architecture: decisions about payments, publishing on behalf of the company and any other irreversible external action are escalated to the owner. The team prepares the materials and the options, but a human makes the call.
The team is the middle layer of the system: the AI CEO manages it, and department agents make it up.
Who assembles the team, sets the tasks and answers for the final report to the owner.
Open → ProcessThe five steps inside which the team is created, works, gets checked and dissolved.
Open → ExecutorsThe pipeline of a single agent: what a team role looks like at the level of one executor.
Open →