Explore in 3DBook a demo
The Plan wing · 5 agents

Turn the goal into testable requirements.

Plan is where an idea becomes a specification a team can build and test. Five agents each write one part of it, from the business requirements to the backlog, and each reads what the one before it wrote. Nothing is a chat log: every requirement has an ID, a state and an owner, and the whole plan is approved before a line of code exists.

Book a 30-minute demoMeet the agents
BABusiness analyst#0216UXUI/UX designer#0279SASolution architect#0241QAQA analyst#0264PMProject manager#0258
Reads
Your goal, briefs and notes, plus Analyze’s documentation when there is an existing system
Produces
BRD, flows and wireframes, architecture, test suites, a backlog in your tracker
Gate
You approve the requirements

Greenfield projects start here. Each agent saves its own documents, so the phase leaves an auditable paper trail, not a conversation.

How it works

Five specialists. One specification.

Requirements first, then design and architecture, then the tests and the backlog that prove and deliver them. Each step reads the one before.

Reads

Your goal
Briefs & notes
Analyze docs, if any

Agents

BABusiness analystAgent #0216
UXUI/UX designerAgent #0279
SASolution architectAgent #0241
QAQA analystAgent #0264
PMProject managerAgent #0258

Produces

BRD
Flows & wireframes
Architecture & threat model
Test suites & cases
Epics, stories, tasks

Gate

You approve the requirementsA. Novak · 11:40
Build
The agents

Meet the 5 agents.

Each one has a codename, one job and a record of everything it did. These views show a sample project.

BABusiness analystAgent #0216

Writes the BRD, and questions it.

It turns your goal and source material into atomic, typed requirements, each with an ID, and publishes the business requirements document from them. It also reads critically: conflicting statements, unlabeled assumptions, everything marked “must have”, vague words like “fast” or “simple”. It lists what it found and asks you to decide.

Reads

  • Your goal
  • Briefs, specs and Analyze output

Produces

  • The BRD
  • Typed requirements with IDs
  • Questions for you to decide
Business analyst · sample project, illustrative
UXUI/UX designerAgent #0279

Designs the flows before the screens.

From the approved requirements it maps the user journeys and lays out wireframes for every screen they touch, then writes a design brief your designers, or your design tools, can work from. Every screen traces back to the requirements it serves.

Reads

  • The BRD
  • Analyze’s screen walkthrough

Produces

  • User flows
  • Wireframes
  • A design brief
UI/UX designer · sample project, illustrative
SASolution architectAgent #0241

Draws the architecture, then attacks it.

It writes the solution architecture as a structured, reviewable document and models threats while the design can still change. Each threat becomes a typed policy linked to the requirements it constrains, so security is visible to every agent downstream instead of buried in an appendix.

Reads

  • The BRD
  • Flows and wireframes

Produces

  • Architecture document
  • Threat model
  • Policies linked to requirements
Solution architect · sample project, illustrative
QAQA analystAgent #0264

Writes the tests before the code exists.

From the requirements, acceptance criteria and architecture, it writes test suites and test cases, each traced to the requirement it proves. Because the tests exist first, Build can practice Test-Driven Development and Verify knows exactly what “done” means.

Reads

  • BRD and acceptance criteria
  • Architecture
  • Wireframes

Produces

  • Test strategy
  • Test suites
  • Test cases, traced to requirements
QA analyst · sample project, illustrative
PMProject managerAgent #0258

Cuts the backlog and pushes it to your tracker.

It breaks the plan into epics, stories and tasks, with dependencies and acceptance criteria, and pushes them to Jira or GitHub Projects. Your team keeps working in the tools it already uses, and every ticket carries the ID of the requirement it implements.

Reads

  • The BRD
  • Architecture
  • Test suites

Produces

  • Epics, stories and tasks
  • Dependency order
  • Tickets in Jira or GitHub Projects
Project manager · sample project, illustrative
The gate · Plan → Build

You approve the plan before code exists.

The cheapest place to fix a wrong requirement is before it becomes code. The gate can stop the work, and it does: on a live project it held the plan because two critical open items had no owner.

Gate checklistPlan → Build
  • Requirements are atomic, typed, owned and testable
  • Every open item has an owner
  • Assumptions are labeled as assumptions
  • The BRD is approved before it becomes the source of truth
AN
A. Novakproduct owner
Approved · 11:40
Guardrails

What the Plan wing never does.

  • Every requirement carries an ID that follows it to production.
  • Agents surface conflicts and ambiguities. People decide.
  • Threats are modeled in design, not bolted on before go-live.
The red thread

One ID, through Plan.

  1. GoalOBJ-0001
  2. RequirementBRQ-0014
  3. PolicyPOL-0003
  4. TestTC-014-02
  5. Ticket#162

One goal becomes a requirement, a policy that constrains it, a test that proves it and a ticket that implements it, all linked before Build begins.

  1. AnalyzeRead the system you already have
  2. PlanTurn the goal into testable requirements
  3. BuildTests first, then the code
  4. StageStand it up somewhere real
  5. VerifyProve it works, requirement by requirement
  6. ReleaseShip it, with a way back
  7. OperateKeep watching, close the loop
See it on a real project

Watch Plan run, in thirty minutes.

We open Orlian on a live project and walk you through the Plan wing: what goes in, what the agents produce, and where a person signs. No slides.

Book a 30-minute demoSee it on the campus