Projects Now Decompose Before They Are Built: the Frozen Process for Private Automations

On Agentic Engineering Infrastructure, content already had a frozen process: a compound request becomes an order sheet, the whole queue is written to disk, and only then does the work start — we told that story in MCP coding: one messy request becomes a development pipeline. But private projects — the automations you run for yourself, like "summarize my YouTube channels to Telegram every morning" — were still built the way AI usually builds things: the model held the plan in its head. Today the platform for agentic engineering closes that gap. A project is now decomposed BEFORE it is built, and the decomposition itself is the deliverable you approve.

Why Automations Built by AI Agents Were Doomed Without Decomposition

An automation is not one task — it is a chain: fetch this, transform that, publish there, on this schedule, with these API keys. When an AI agent plans a chain like that implicitly, three things go wrong. The plan is invisible — you cannot read or correct it. The plan is fragile — a crash, a context reset or a subscription limit erases it. And the plan is unverifiable — nobody gates whether each piece was actually specified before someone started coding it. Our own verdict inside the team was blunt: without deep decomposition, a project of this kind is doomed to fail.

The fix is the same discipline that already worked for content, applied with a different machine. Content decomposes deterministically by the state of your site. A project is decomposed by the model — it proposes the graph — and a frozen engine then does what engines do best: validates, gates, documents, and materializes. The engine never writes the automation code itself.

A Graph of Small Nodes, Validated Before Any Development

Every node in the proposed graph carries its own contract: a title, a kind (trigger, action or transform), an exhaustive task description, the tools it uses, the environment keys it needs (never hardcoded — they are set through the same rebuild-safe channel as every build-time setting), its inputs and outputs, a to-do list, and the nodes it depends on. The engine checks the dependency graph for cycles and broken links, and then applies the real gate: specification completeness. A node with an empty task, a missing description or no to-do items is refused — with a precise list of what is missing — and nothing is written to disk until the graph is complete.

• The order sheet: one resolved human line per node, shown to you verbatim before anything happens.
• The approval token: a real run requires the exact plan you confirmed — a changed plan cannot start.
• The MVP guard: a graph over ten nodes gets a recommendation to launch a ten-node MVP first and grow each node by separate future tasks — so you always understand exactly how your project works. The decision stays with you.

One README That Explains the Whole Project — Born From the Decomposition

On approval, the first thing materialized is not a step — it is the project-root README, generated from the graph itself: why the project exists, how it works (an auto-built table of every node in execution order), what makes it efficient, what it reuses, and what the result should be. Every agent instruction on the platform — all six agent entities — now requires reading that README first when working on any project step. It is the single source of truth for what the project is, and every specification and handoff step points back to it.

Calling the Coder Is Its Own Step in the Agentic Engineering Pipeline

After the README, the engine writes the queue into the same Development Steps system we described in how architecture records become development steps: one rich specification step per node, plus one separate coder-handoff step per node. The handoff step is exhaustive — the fixed first actions (read the README, open the spec), the deliverable, the tools and keys at a glance, the acceptance criteria, and the finish protocol. So when the orchestrator delegates a node to a coding agent, it hands over exactly one thing: a step number. And handing over the number does not close the node — the orchestrator watches for real completion (the step closed, the deployment recorded) before opening any dependent node.

Self-Sufficient by Design: a Skill in Every Agent and an MCP Tool

Like every capability on the platform, the frozen project process does not depend on the orchestrator existing. It ships as a self-sufficient skill in every agent entity — a lone agent, even a workspace running a single CLI with no central brain, runs the identical process directly. For the conversational path, the same engine is exposed as an owner-tier MCP tool, `owner_projects_orchestrate_decomposition`, with the same dry-run, the same order sheet and the same approval token. One more piece of the operating contract rides along: the process covers only projects and automations — public site pages keep their own frozen pipeline, and the two never mix.

Plans are worthless, but planning is everything — the trick is to make the planning itself the artifact.