02 · Centre of the system Target architecture
We researched twenty platforms. Every one of them offers either technical agent orchestration or a single specialised worker. None offers a company manager as a product: something that takes a goal in business language, distributes it across departments, holds the deadlines and answers the owner with a report rather than a log.
Where this actually stands. The AI CEO is not implemented: at the time of publication this is a target architecture and none of the ten functions works. The sample report on this page is labelled as a demonstration and was written by hand — it was not produced by a live AI service. The project has no customers, testimonials or deployment metrics, so none are shown. The competitor references come from our own research of public materials and are cited with their sources.
01 · Responsibilities
This is the complete list of the AI CEO’s responsibilities in the target architecture. Every card is labelled with the system layer the function lives in, and none of them is claimed to be working.
F·01
The input is a plain statement of the outcome: “find the cause of the cash gap”, “launch the product”, “fill the sales role”. The owner writes no prompt, picks no model and does not say which department should own what.
F·02
The task is checked against the goals of the business: if it contradicts them or duplicates work already in flight, the AI CEO says so before execution starts, not after.
F·03
Decomposition with a definition of done for every part and with explicit dependencies: what can run in parallel and what only after the previous step has returned a result.
F·04
Every subtask goes to the department that owns it — marketing, sales, operations, finance, HR, research, development or support — together with its inputs and a deadline.
F·05
Tasks that span days or weeks stay open between stages. A delay, a stuck stage or a missing input is visible to the owner immediately, not at the end.
F·06
A department’s answer is compared against the definition of done. A conclusion the data does not support is rejected and sent back — instead of ending up in the owner’s report.
F·07
The outcome is consolidated into one answer per task: which department did what, which decision was taken, what remains on the owner’s side. The format is a business narrative, not a system log.
F·08
Recurring failures and systemic causes are separated from the one-off task: if five customer requests trace back to a single flaw in the process, that goes into the report as a process problem.
F·09
Every problem found comes with two or three options and the consequence of each. The choice stays with the owner: the system makes no decisions about money, people or customers on its own.
F·10
A large task can be split among several executors inside one department and across departments at the same time, with shared progress control and one consolidated result instead of several disconnected answers.
All ten functions are target architecture. Implemented: none of them. The list follows the project specification (section 4.1) and has not been extended with capabilities that are not in the plan.
02 · Mechanics
Automation ends with a result. Management does not: the owner’s report generates the next task. That is why the AI CEO loop is closed, and the sixth stage feeds back into the first.
intake
The task is recorded together with the expected outcome and the company context. Nothing is executed at this stage — it is accepted and checked for contradiction with the current goals.
decompose
A plan of subtasks, each with its own definition of done. This is also where the system decides what can run in parallel, what runs in sequence, and where the owner’s approval will be needed.
assign
Subtasks go to the departments with their inputs, a deadline and an autonomy level. A department sees its own part rather than the whole task — but with the context of why that part matters.
watch
Stage-by-stage tracking over time: what is on plan, what has stalled, where inputs are missing. A stall escalates to the owner immediately, not after the deadline has already been missed.
verify
Department answers are compared against the definition of done. A poorly supported conclusion goes back for rework; contradictions between departments are resolved before everything is merged into one answer.
report
One consolidated answer: what was done, which department owned what, which problems were found and which solutions are proposed. Then the owner’s decision becomes the next task.
The loop closes: the owner’s decision on the report becomes a new task at stage 1
03 · Trust
The main fear in business is “the agent will make a mess”. The answer is not reassurance but explicit levels: every department starts under human supervision and moves up only once its results have been checked. The autonomy level is set by the owner, not by the system.
Every consequential action is shown to the owner or an authorised employee first and runs only after approval. The department prepares — a person decides.
Routine actions run without confirmation, but strictly inside the rules the owner defined: limits, allowed scenarios, forbidden topics. Anything that crosses a boundary automatically drops back to L1 — to be confirmed.
The department sets subtasks for executors itself, coordinates stages that last weeks and re-plans as things change. Accountability for the result stays with the AI CEO: it is the AI CEO who reports to the owner for the whole chain.
How this works as a path. The level is set per department: marketing may sit at L2 while finance stays at L1, because the cost of a mistake differs. Moving up is the owner’s decision, taken after the department’s results at the previous level have been checked. Moving down is available at any moment.
The idea of the scale is borrowed as a proven product model: Artisan describes autonomy levels as “L1 — under human supervision, L2 — functions independently, L3 — manages multistep campaigns” (the company’s public blog, see research/extra-10.md, section 7.4). The content of the levels at VOIR is ours, applied to departments and to the AI CEO role. The scale itself is target architecture and is not implemented in the product.
04 · Explainability
Almost everyone has observability: call logs, latencies, statuses. All of it is written for an engineer. What is still unoccupied is the other half — translating the same information into the owner’s language: what was done, why that decision, what it cost and what it delivered.
Demonstration
Both panels below are a fictional example of the format, written by hand for illustration. This is not the output of a working system: the AI CEO is not implemented, so the project has no real logs and no real reports. The numbers, names and identifiers in the example are arbitrary.
What an engineer sees: the system trace
The format is deliberately technical: identifiers, latencies, response codes, token counts. This is how a trace looks in most observability platforms, and it is meant to be read by an engineer.
What the owner sees: a report in business language
On customer N’s request. The order was indeed never delivered: according to the order system the shipment status has not changed for five days. Payment was received in full, with no deductions. The refund is justified, so I put it up for your approval — you granted it, and the money is being returned.
The same set of events, without call identifiers or token counts: what happened, who worked on it, where your decision was needed and what is worth fixing. The technical detail is not lost — it stays in the journal for whoever needs it.
Turning a trace into a narrative cannot be done by simply “formatting the log nicely”: you have to know which of dozens of calls matter for the owner’s decision and which are plumbing. That is work for the Agentic layer, not for a report template.
The full journal of calls, costs and statuses is not replaced by the narrative — it exists alongside it: the owner reads the report, a specialist opens the trace of the same task when needed. Both views describe the same piece of work.
05 · Reference points
The idea of a central orchestrator is not new, but in every reference case it lives inside a technical or an industry-specific task. Below are the three closest prototypes from our research, and how the VOIR approach differs.
Salesforce Agentforce
An engine that “breaks down the initial prompt into smaller tasks, evaluating at each step and proposing a plan for how to proceed until the complete answer or action is achieved”. That is multi-step planning with self-evaluation — architecturally the same thing VOIR puts into decomposition and result checking.
Source: research/extra-10.md, Salesforce Agentforce section (public description of the Atlas Reasoning Engine)
Cognition · Devin
A large task is split across parallel cloud agents: one Devin acts as the orchestrator, manages the executors and reports the result. The company states it directly — “engineers should operate more like architects and delegate execution to swarms of agents”. This is the closest working model of function F10.
Source: research/extra-10.md, Cognition sections 10.3 and takeaways (public Series E blog and Devin swarms descriptions)
Sierra
“Long-horizon planning — break complex outcomes into specific steps that improve over days or months”, plus memory connecting conversations, systems and touchpoints. This confirms the requirement behind function F5: deadline control only makes sense for tasks that outlive a single session.
Source: research/extra-10.md, Sierra section (public description of Horizon and the single-agent-across-channels statement)
What this means for VOIR
Decomposition, parallel execution and long-running plans already exist — separately, and inside their own domains. What is still unoccupied is the same machinery pointed at the whole business, with an owner-language input and an owner-facing report as output. That is a product model of “the organisation as a system”, not a new algorithm.
Source: research/OPPORTUNITY-MAP.md (N1) and research/extra-10.md (summary across 20 companies)
06 · Limits
The manager’s authority is bounded as explicitly as its duties. These boundaries are set by the rules of the Control layer and do not depend on a department’s autonomy level.
At any autonomy level, including L3. The finance department prepares the calculation and assesses the consequences; a payment, a transfer and any operation involving money happen only after the owner’s explicit permission.
Hiring, firing, performance assessment and workload distribution between people stay with the owner or a manager. The AI CEO prepares materials and criteria but does not decide about a person.
If the data is insufficient, the report says so — naming exactly what is missing and where it could be obtained. An answer of “there is no data” counts as a correct result, not as a failure.
Every assignment, every rejected department conclusion and every action that required approval ends up in the journal. The narrative report is a view of that journal, not a replacement for it.
Moving a department from L1 to L2 or from L2 to L3 is the owner’s decision. The system can show the results that make such a decision reasonable, but it never changes the level automatically.
The AI CEO is target architecture. None of the ten functions and none of the levels of the autonomy scale is implemented; the sample report on this page was written by hand as an illustration of the format and is labelled as a demonstration.
07 · What next