The owner sets a task — the AI CEO breaks it into subtasks and assigns them across departments — digital employees execute — an independent agent verifies — the AI CEO accepts the result and reports back to the owner. Every step has its own roles and its own artifacts: a task card, a decomposition plan, an execution trace, a verification verdict, a final report. Below you will find an interactive diagram of the cycle, a breakdown of each step, and an honest status of what works today and what is still target architecture.
Target architecture · product implementation is a separate P1 task
Five stations of a closed loop. On the left are the cycle nodes: click one (or switch with the arrow keys from the keyboard) and the step card opens on the right, with roles, artifact and status. Switching works in pure CSS — even with JavaScript disabled. Target architecture
Step 01 · INTAKE
Target architectureThe cycle starts not with a prompt but with a contract. The owner states the task the way they would state it to a strong executive: what result is needed, by when, and by which signs the result counts as done. The AI CEO clarifies what is missing — budget, constraints, irreversible actions — and turns the conversation into a task card with a unique number. From that moment the task exists as an object: it has an owner, acceptance criteria and a status, not just text in a chat.
Step 02 · PLAN
Target architectureThe AI CEO decomposes the task into subtasks, determines which departments own them — marketing, sales, operations, finance, people, research, development, support — and appoints executors. For each subtask it fixes a deadline, an autonomy grade (what the agent does on its own and what only with human confirmation) and the dependencies between subtasks. The decomposition plan is saved as an artifact: the result will later be checked against it, and the owner can see why the task was split exactly this way.
Step 03 · EXEC
Target architectureSubtasks go to the digital employees of the departments. Each executor works along its own pipeline: accepts the subtask with context, plans the steps, carries them out and keeps a trace of every action — which data it read, which decisions it made, what came out. The trace is not a log “for show”: independent verification reconstructs the course of work from it, and the owner gets an explainable answer instead of “magic happened”. The finished result is packaged as an artifact: a document, a calculation, a campaign draft, a piece of code or a report.
Step 04 · QA
Target architectureThe key step that makes the cycle closed rather than linear. The result is checked by an agent that did NOT do the work: it compares the artifact against the acceptance criteria fixed back at step 01, reproduces the checks and issues a verdict — VERIFIED or REJECT with a list of defects and evidence. “Done” and “verified” are different statuses: until there is a verdict, the task is not considered complete. On rejection the cycle returns to step 03 — the executor receives not “redo it” but a concrete list of mismatches against the criteria.
Step 05 · REPORT
Target architectureThe AI CEO consolidates department results into a single answer for the owner: what was done and accepted, what was rejected and why, which decisions remain with a human, what the system remembered for future tasks. The report is not a retelling of the thread but a structure: verdicts, artifacts, rejections, escalations. This is also where the cycle closes: conclusions and mistakes go into memory so the next task of the same type runs faster with fewer revisions. At any moment the owner can descend from the report to the execution trace and check any claim themselves.
The diagram above answers “what kind of step is this”; this timeline answers “what exactly happens, who takes part, and what remains at the end”. Each item expands; inside — a description of the process and a facts card: roles, artifacts, and the fallback point on rejection.
Most “AI assistants” begin with a prompt and end with an answer: the context is lost, there are no criteria, and no one is accountable. The AI CEO cycle begins differently — by fixing a contract. The owner describes the desired result in their own words, and the AI CEO brings the description to a checkable form: what counts as done, by when, which constraints apply, which actions require human confirmation. If the task contains something irreversible — a payment, a publication, a data deletion — it is flagged at intake and cannot be executed silently.
The output of this step is a task card: an object with a number, an owner, acceptance criteria and a status. It survives any restart and serves as the single source of truth for all subsequent steps.
The AI CEO breaks the card into subtasks and lays them across the eight departments: marketing, sales, operations, finance, people, research, development, support. Assignment is not “send to everyone” but choosing an executor by department competence and current load, with explicit dependencies: what can run in parallel and what only after a neighbouring subtask.
Each subtask gets an autonomy grade. The lowest — the agent prepares a draft and a human confirms every external action. The middle — the agent works on its own within agreed boundaries. The highest — for repetitive routines with accumulated acceptance statistics. A grade is never granted “by default”: raising it is a separate decision of the owner.
Digital department employees carry out the subtasks. An executor does not “answer a question” but runs the work: plans the steps, performs them, and keeps a trace — which sources it read, which intermediate decisions it made, what it changed. The trace makes the result explainable: any claim in the report can be expanded into a chain of actions and checked.
Inside a department, subtasks may go to individual agents — their own pipeline of “intake → plan → execute → verify → report” is described on the “AI Agents” page. Important: an executor has no right to declare its own work accepted. It passes the artifact and the trace onward — to independent verification.
Verification is performed by an agent that took no part in the execution. It takes the acceptance criteria from step 01 — the very ones fixed BEFORE the work started — and checks the artifact against them: reproduces the checks, measures what was claimed, looks for mismatches. The verdict is binary: VERIFIED (the artifact meets the criteria, evidence attached) or REJECT (a list of defects and what exactly did not match).
This guards against two typical failures of “AI teams”: self-acceptance (the executor declared success — and was believed) and false-green checks (the test passed because it tested the wrong thing). On REJECT the cycle neither closes nor “gets talked into agreement” — it returns to execution with a concrete list of mismatches, and keeps doing so until the verdict turns positive or the task is escalated to the owner.
The AI CEO accepts the verified artifacts and consolidates them into a single report for the owner: what was done and accepted, what was rejected and on which points, which decisions remain with a human, which risks the system sees. The report is structured — verdicts, artifacts, rejections, escalations — and from any of its points you can drill deeper: to the execution trace of a specific subtask.
This is also where the cycle closes in the true sense: conclusions, typical mistakes and successful breakdowns go into shared memory, and the next task of the same class does not start from scratch. For the owner it looks simple: the task went out — some time later a report came back with a result that someone already tried to disprove and could not.
The cycle is valuable not for “smart answers” but for the checkable objects that remain after it. Six artifacts — with them a task can be reconstructed, disputed and repeated. Target architecture
The task as an object: number, owner, statement, acceptance criteria, deadline, list of irreversible actions. The single source of truth for every step of the cycle.
task T-2291 owner raman goal reclaim 10 h/wk of ops done report accepted by QA irr payments — manual only
The breakdown into subtasks with executor departments, dependencies, deadlines and autonomy grades. The completeness of the result is later checked against this same plan.
sub 1 RES market research L2 sub 2 OPS playbooks L2 sub 3 FIN impact estimate L1 dep 3 ← 1,2 · due in 5 days
A record of every executor action: sources, decisions, intermediate results. It makes the answer explainable — any claim expands into a chain of actions.
10:02 read crm-deals.csv (1,240) 10:07 calc saving 11.4 h/wk 10:15 draft playbook v1 10:40 self-check → sent to QA
The independent reviewer's decision: VERIFIED or REJECT — with the list of mismatches and evidence. Without a verdict the task is not considered complete.
verdict VERIFIED checks 18/18 · criteria of step 01 proof report, screenshots, metrics by qa-agent-04 (not executor)
The cycle summary: accepted, rejected, escalated. A structure instead of a retold thread, with drill-down to the trace of any subtask.
accepted 3/3 subtasks effect −11.4 h/wk (confirmed) escalate 1 decision is yours memory conclusions recorded
Cycle conclusions, typical mistakes and successful breakdowns — into the shared context. The next task of the same class does not start from scratch: this is what distinguishes a cycle from a series of one-off requests.
lesson refunds without SLA → REJECT pattern FIN decomposition depends on RES (noted in the plan) next task template updated
This page describes the target management cycle. It is not its implementation: the product implementation of the AI CEO cycle — real task assignment to agents, execution control and acceptance — is split into a separate priority-P1 task and tracked in the project requirements register independently of this series of presentation pages.
check-local gate verifies links, anchors, language pairs and the SEO minimum of every page before publication.The product cycle does not exist yet — but the management cycle already exists as the process in which this site is created. Here is how the five steps mapped onto a real task: “publish the cycle page”.
The project owner restored the requirements register and set the task: an integration landing page for the AI CEO cycle, ru + en, with closure criteria — live 200, local checks, screenshots, sitemap, honest badges, a git commit, independent verification.
The work was assigned to an executor; acceptance — to a separate independent-reviewer role that does not take part in writing the code. The “build it and accept it yourself” ban is fixed in the project rules.
Two pages were created (ru/en), with their own CSS layer, a menu item in the i18n dictionaries and sitemap entries. Existing pages were not modified: everything new was added additively.
The local gate checks links, anchors, language pairs and SEO; a headless browser captures three viewports and checks contrast, mid-word breaks and the absence of horizontal scroll. A failing gate means going back to rework, not publishing “as is”.
After publication — a report: live URLs with response codes, the git commit, screenshots, check results and an honest list of what remains. The page counts as closed only after the independent reviewer's verdict.
When the product implementation of the cycle starts working, the same five steps will stop being a contract description: the task will get a real orchestrator, execution will get real agents, acceptance will get an automatic verdict. The statuses on this page will be updated as facts arrive.
As a product — no. None of the five steps is implemented in code; the page describes the target architecture and carries the corresponding stamps. The product implementation of the cycle is a separate priority-P1 task in the requirements register. The actual project status is published in the flight log.
An executor must not accept its own work: a plausible but wrong result would reach the owner as finished. An independent agent checks the artifact against the criteria fixed before the work started and issues a VERIFIED or REJECT verdict with evidence. The “DONE ≠ VERIFIED” principle is applied to the development of this site right now.
A bot replies to a message and bears no responsibility for the outcome. The cycle is a closed loop of accountability: a task card with criteria, assignment across departments, execution with a trace, acceptance by someone other than the executor, and a report with a verdict and a list of decisions that remain with a human.
No. Payments, publishing on behalf of the company, deleting data and any irreversible external actions always require the owner's confirmation — this is an architectural constraint, not a default setting. The cycle prepares everything needed and escalates the decision to a human.
The cycle is the process; employees and agents are the executors. At step 03 subtasks go to the digital employees of the eight departments (“AI Employees”), and the pipeline of a single executor — from accepting a subtask to returning the artifact to the cycle — is described on the “AI Agents” page. The role that orchestrates the whole cycle is the AI CEO.