All work Platform Feature Alera AI-Native Workflow
Alera Planning

From a page of notes
to a production system,
through one workspace.

Alera's Planning tool turns rough product notes into a fully specified, dependency-ordered build plan — then coordinates an army of specialist AI agents to actually ship it. This is how we build client software now.

What it is A planning workspace
inside Alera
Used by Recursive AI on
every client engagement
Inputs Notes, context files,
conversation
Outputs Real routines, agents,
components, pages
Alera Planning tool showing a Plan Overview for the Riemer Admin Dashboard — 220 specs total, 212 to create and 8 to update, broken down into 60 routines, 49 web components, 44 data models, 32 web pages, 14 swarms, 12 concepts, 8 JS libs, and 1 middleware, all marked complete.
The Problem

AI agents can write code.
They can't decide
what to build.

Every software project starts the same way: a few pages of notes, half a whiteboard, a Slack thread, some screenshots of the system being replaced. Somewhere in all of that is the real shape of the thing — but it's never stated cleanly.

Hand that pile to a capable engineer and they'll ask a hundred questions, write down decisions, check the database schema, and eventually produce a plan. Hand the same pile to an AI agent and it will confidently write the wrong system.

The gap isn't coding ability. The gap is the structured middle layer between a user's intent and the agents that do the work — the place where questions get asked, gaps get filled, trade-offs get resolved, and the whole thing gets written down in a form agents can actually execute against.

That layer is what Alera Planning is. It's the workspace where we take the rough input — ours and the client's — and grind it into a spec tree precise enough for agents to build from, with every decision captured along the way.

The thesis

If you want AI agents to build real software for real clients, you need a tool that makes human thinking legible to agents — and agent suggestions legible to humans — in the same workspace. That's the gap Planning fills.

What It Is

A plan is a swarm —
with notes, context, specs,
and execution in one place.

Planning isn't a separate product. A plan is just an Alera swarm with a particular shape — NOTES.md, a context/ folder, a generated plan.yaml, and an execution log. Every phase of the work lives in that one directory.

Phase 1

Notes

Rough markdown. The user types, pastes, and chats with the notes editor until the picture is clear.

Phase 2

Context

Supporting material — DB schemas, mockups, existing code, research. Dropped in or fetched by agents.

Phase 3

Plan

A generator agent produces a spec tree — every artifact to create, nested and dependency-ordered.

Phase 4

Execution

An orchestrator spawns creator agents for every spec, answers their questions, escalates blocks to the user.

Phase 1 · Notes

The AI interviews you
about your own project.

Great specs come from answering questions you didn't know you hadn't answered. The notes editor lives next to your markdown and offers four active ways to pull missing knowledge out of your head and onto the page.

It starts simple — a Q&A tab that generates targeted questions about what you've written, suggests a likely answer based on cues in the text, and lets you accept the suggestion with a single click. No typing prose to explain what you meant. Pick the option that matches your intent, and the notes update themselves.

Alera Planning notes view for a Riemer Admin Dashboard plan. The left sidebar shows Notes, Context, and Plan tabs plus a list of swarm specs. The center column shows the NOTES.md file with Confirmed Priorities and Key Decisions sections. The right column shows a Q&A panel with Suggested Topics pills, a list of 5 generated questions, and one question expanded with three multiple-choice answers — option B pre-marked as SUGGESTED with a WHY SUGGESTED explanation underneath.
Q&A — structured interview. The editor reads your notes, generates topic-scoped questions, proposes a likely answer with reasoning, and lets you apply selections directly back into the markdown.
The same notes view with the Gaps tab selected on the right. A Gap Analysis panel lists 3 identified gaps — 1 high priority and 2 medium — with the first expanded: 'Reporting dashboard — which metrics and KPIs' flagged HIGH, with a 'Why this?' explanation pointing to the specific section of the notes, two concrete suggestions presented as checkboxes, and a free-text response field.
Gaps — what you forgot to specify. The Gaps tab hunts for unspecified behaviors, missing roles, undefined edge cases. Each gap cites the exact note section that triggered it and offers concrete suggestions.
The notes view with the Evaluation tab selected. A section titled 'Overall Assessment' describes the notes as 'unusually thorough and domain-rich, but carry a handful of unreconciled architectural tensions.' Below it, five numbered cards list specific observations: Dense domain context well-structured, Role/auth story is half-landed, Product model carries a known dual-write shape, Priority language under-describes the actual scope, and Simplicity vs granular permissions pull against each other.
Evaluation — an honest critic. Evaluation reads the whole notes document as a document and calls out contradictions, under-specified priorities, unresolved architectural tensions, and known failure modes.
Continued Evaluation view showing an Issues list with 5 items tagged by category — Contradiction, Risk, Known failure mode. One high-priority Risk is expanded: 'Fresh role model collides with Drupal-based admin detection.' It contains a detailed explanation of the architectural collision, a 'why surfaced' breadcrumb pointing to the exact notes path, two suggestion checkboxes, a free-text response field, and a disabled 'Discuss this with the agent first' option.
Every finding is actionable. Issues come categorized (Contradiction, Risk, Known failure mode), cite the sections that produced them, and include checkboxable suggestions you can apply straight into the notes.
Why this matters

The hardest part of building software is figuring out what to build. Notes editing in Alera Planning turns that from a blank-page problem into a structured conversation — one where the AI asks the questions, proposes the answers, and writes the agreed output back into a form agents can use.

Phase 2 · Context

The supporting evidence
agents will need later.

Notes say what you want to build. Context gives the agents the raw material they'll need to build it correctly — a legacy database schema, a screenshot of the tool being replaced, a sample API payload, an internal wiki page, a mockup sketch.

Files are dropped into the context/ folder by hand, fetched from the web by research agents, or generated on the fly. When the planner turns notes into specs, it automatically attaches the right context files to each spec — so the creator agent that builds the Customer data model gets the legacy customer schema, and the one building the Meetings page gets the meetings mockup.

Context view with a Files browser showing a planning-board-screenshots folder containing accounts.png, admin-system-misc.png, ar-data-file-transfers.png, customers.png, dev-tools.png, meetings.png, products.png, and README.md. The currently selected file — accounts.png — is previewed below, showing a digital whiteboard with sticky notes about Accounts module behavior. On the right, a Research agent conversation log shows the agent running execute_terminal_command and list_files and write_file tools, then a Task Complete panel summarizing that 7 screenshots were copied into context/planning-board-screenshots/ along with a README index file.
Context is lived-in, not archived. Files arrive from drag-and-drop, from web research agents, from terminal commands — all visible, browsable, and previewable in the same workspace where the notes live.
Phase 3 · Plan

220 specs,
one dependency-ordered tree.

When the notes are ready, the planning agent reads everything — notes, context files, the full swarm the plan targets — and produces plan.yaml: a nested tree of artifact specs, each one describing exactly one thing to build or modify.

The scale can be large. The plan on this page builds an entire admin dashboard from scratch: 60 routines, 49 web components, 44 data models, 32 web pages, 14 child swarms, 12 concepts, 8 JS libs, 1 middleware — 220 specs total. Every one is linked to its context attachments and wired into the right position in the dependency graph.

Plan Overview view for /riemer/admin/initial-build-plan. Three big stat cards show 220 specs total, 212 to create, 8 to update. A 'By Artifact Type' row breaks this down into pills: 60 routines, 49 web-components, 44 data-models, 32 web-pages, 14 swarms, 12 concepts, 8 js-libs, 1 middleware. A '220 complete' status indicator is shown. Below, a Resume Execution block has a button to return to the running Plan Orchestrator, and a Revise the Plan section contains a chat history with the Plan Generator showing a detailed breakdown of top-level modules with their routine, component, page, and concept counts.
Plan Overview. Every plan surfaces its scope — spec count, breakdown by artifact type, completion status — and gives you two live agents: Plan Orchestrator for execution, Plan Generator for revisions.
Spec detail view for the Customer data-model spec, showing it as status COMPLETE and of mode CREATE. The Artifact Spec form fields show URI, Name (Customer), Description, and a multi-line Spec field with the full data model definition — fields pulled from Oracle's CUSTOMER table, aliases, credit application tracking, tier count, account status. The right panel shows a Creator Agent conversation log with a detailed summary of the agent's work — reading the 159-column schema, performing pre-flight analysis, resolving 13 ambiguities, writing 35 files in parallel including 10 model.yaml files and 18 JSON example files, then verifying the tree. Six numbered steps document the process.
Every spec is editable. Click into any spec and you see its full definition, the agent that built it, and a log of exactly how it was built — complete with the decisions made along the way.
Editable, not locked in

The generated plan is a starting point, not a contract. You can edit any spec by hand, add or remove nodes, re-attach context, or chat with the generator to rewrite whole branches. Only then do you press Execute.

Phase 4 · Execution

An orchestrator agent
walks the tree
and builds the system.

Press Execute and a plan orchestrator takes over. It walks the spec tree in dependency order, spawns the right creator agent (or updater agent) for each spec, passes it the targeted swarm context and attached context files, and proactively manages the build.

When a creator agent asks a question, the orchestrator answers it from the notes when it can — and escalates to the user when it can't. When two specs need to be built in parallel, it dispatches them concurrently. When one fails, it retries or marks it blocked and moves on.

Execution view showing a progress bar at 100%, 220 of 220 specs complete, with summary tiles: 220 complete, 0 in progress, 0 blocked, 0 failed, 0 pending. Below is the Plan Orchestrator's running log with a numbered list of 12 build decisions — things like 'Email dispatch in manage-admin-notification is log-only', 'Meeting cancel uses a [CANCELLED: reason] prefix on MESSAGE column as a soft-cancel', and 'Permission-model gaps in the starter auth-model roles'. A Summary panel underneath describes executing the remaining 86 specs across 3 rounds of parallel dispatch — 19 batches, 22 sub-agents — covering customers, AR data, meetings, admin-misc, dev tools, and 28 module components. The left sidebar lists data-model specs, all marked complete.
Orchestration log. Every decision the orchestrator makes — questions asked, gaps tracked, escalations, parallel batches — is visible in real time. And when it's done, the summary is a record of how the system was built, not just that it was.
  1. 01

    Dependency-ordered dispatch

    Data models before routines that use them. Swarms before their children. Parent specs complete before dependents fire. Independent branches run in parallel.

  2. 02

    Specialist agents do the work

    Each spec type has a dedicated creator agent — routine-creator, data-model-creator, web-component-creator, web-page-creator, agent-creator, and so on. The orchestrator routes each spec to the right specialist.

  3. 03

    Questions resolve automatically when possible

    Most creator questions are already answered in the notes. The orchestrator looks there first, answers inline, and only escalates genuinely novel decisions to the user.

  4. 04

    Execution state is separate from the plan

    Progress, blocks, retries, and results live in plan-execution.yaml — so you can keep editing plan.yaml while a build is in flight, without two systems fighting for the same file.

  5. 05

    The plan is the audit trail

    When it's done, the plan swarm remains as the record of why the system was built the way it was. Notes, context, specs, and execution log — all still in the same directory, months later, next to the code they produced.

What It Means For Clients

Every engagement we run
starts as a plan.

Planning isn't a feature we occasionally use. It's how Recursive AI builds everything. When we engage with a client, the first deliverable is a plan swarm — notes, context, a reviewable spec tree — that the client can see, challenge, and revise before a single line of code is written. Once the plan is agreed, execution is measured in days, not quarters.

220

specs orchestrated end-to-end in the plan featured here — a complete admin dashboard build

8

artifact types handled natively — routines, components, pages, data models, swarms, concepts, JS libs, middleware

1

workspace — notes, context, specs, execution, and audit trail all in one swarm directory

100%

of decisions captured — every question the AI asked, every answer, every override, preserved alongside the output

The bigger picture

Planning is the piece that makes AI-native software delivery actually work. It's the bridge between what a client wants and what our agents build. Without it, you get fast slop. With it, you get a specified, auditable, buildable system — and a record of how every decision was made.

Work With Us

Have something ambitious
you want built quickly,
without the usual waste?

Alera Planning is how we ship complete production software systems for clients in weeks, not quarters — with the full decision trail preserved. If you've got a project that's been sitting on the shelf, let's talk about planning it in.

Start a conversation See the platform