System Requirements Document for ai-business-operator

1. Introduction

AI Business Operator is a modern web application that functions as an agentic AI workspace. Its purpose is to help a person with a business idea turn that idea into a practical, testable action plan by running a multi-agent workflow over a project.

The product must not feel like a normal chatbot. It must feel like an AI team working on a project: a status-driven operator console where the important content is state (working / completed / waiting / needs approval / error) and numbers (budget, cost ranges, break-even, progress), and where the agents produce structured, readable, editable artifacts rather than chat messages.

The audience is founders and solo operators — power users who want density, status, numbers, and machine-readable artifacts. The single active human role is the Business Idea Owner.

The V1 is a polished working prototype. It runs entirely in the browser with local persistence and a fully functional demo mode using realistic mock AI responses, so it works without an AI API key. The code is structured so real AI providers can be connected later.

2. System Overview

AI Business Operator is a client-side React + TypeScript + Vite application. There is no unnecessary backend for V1; local persistence is acceptable for demo projects. The application is responsive and mobile-first, and works well on Android screens.

The core workflow is:

User Goal
  ↓
Orchestrator Agent
  ↓
Research Agent + Finance Agent
  ↓
Critic Agent
  ↓
Business Blueprint
  ↓
Human Approval
  ↓
Action Plan

The system clearly shows which agent is working, completed, waiting, or requires human approval.

Actors

• Business Idea Owner (active human persona): creates a project, starts the AI team, watches the orchestrator plan tasks and the specialized agents work, inspects agent outputs and structured artifacts, reviews the Critic's challenges, reads the final Business Blueprint, and approves, rejects, or edits proposed next actions.
• Agent team (system actors, not personas): Orchestrator, Research, Finance, Critic. These are simulated in demo mode and are structured so real AI providers can be connected later.
• External actions (outbound, simulated in V1): emails, published content, purchases, and other externally consequential actions. These are never performed automatically.

Accepted behavior

• Project creation with name, business idea/goal, available budget, target location, optional target customer, and optional additional context, then "Start AI Team".
• A multi-agent workflow that produces structured artifacts: Market Research, Financial Analysis, Risk Review, Business Blueprint, Action Plan.
• A project dashboard, agent cards with distinct visual states, an activity log with inspectable events, and human approval gates.
• Demo mode with realistic mock AI responses and visible progress and agent status changes.

Narrow exclusions

• No authentication.
• No payment systems.
• No subscriptions.
• No unnecessary features.
• No unnecessary backend for V1.
• No automatic external actions: do not send emails, publish content, make purchases, or perform external actions automatically. For V1, actual execution is simulated.
• The Orchestrator does not perform every task itself.
• The Research Agent never presents an assumption as a verified fact.
• The Critic does not simply agree with the other agents.

2a. Product Interpretation and Delivery Boundary

AI Business Operator is delivered as a first-party web application. All accepted human-facing work — creating a project, starting the AI team, watching the workflow, inspecting agents, reading and editing artifacts, reviewing the blueprint, and deciding on approvals — happens inside the application's own pages.

There is no authentication in V1. The application does not require an account, and it does not establish application-owned identity. Projects, workflow state, artifacts, and activity events are persisted locally in the browser so a demo project survives a reload. Because there is no account, there is no cross-device or cross-user continuity, and no differentiated permissions or role-based visibility: the single active human role has full access to its own locally persisted projects.

The agent team is simulated in demo mode. The application must work even without an AI API key. The agent, workflow, and provider boundaries are structured so that real AI providers can be connected later, but no real provider is required for V1.

Human approval is a first-party interaction. Before any action that could have external consequences, the application shows "Human approval required" with Approve, Reject, and Edit. Execution of approved actions remains simulated in V1: no emails are sent, no content is published, no purchases are made, and no external actions are performed automatically.

Future work (real AI providers, real external execution) is out of scope for the current V1 and is listed in the future section.

2b. Source Content Inventory

Not applicable. No reference directive in this project declares content_source; the authoritative product facts come from the user-authored requirement thread and the Planning Scope contract.

2c. Page Content and Component Coverage

The page inventory below is the closed, ordered page contract for this project. Each page appears exactly once.

Landing

• Information/state: Anonymous first impression of AI Business Operator. Explains that it is an agentic AI workspace, not a chatbot; that it runs an AI team on a project; and that the outcome is a practical, testable action plan. Shows the seven-step workflow (User Goal → Orchestrator → Research + Finance → Critic → Business Blueprint → Human Approval → Action Plan) as a hairline node graph.
• Primary actions: Enter the workspace (go to Dashboard / Projects). Start a new project (go to Project Setup).
• Supporting actions: Read the workflow explanation; view the demo-mode note that the app works without an AI API key.
• Domain entities: Workflow step, agent role, product description.
• Component responsibilities: Hero block with product name and one-line value statement; workflow node graph (SVG hairline nodes and connectors); primary CTA; secondary CTA to create a project; short capability strip (dashboard, agent cards, artifacts, activity, approval).
• States: Loading (static content, no async load required); empty (not applicable — static entry); success (CTAs navigate); error (not applicable); recovery (not applicable).

Dashboard

• Information/state: The primary project workspace. Shows project name, original user goal, overall progress, current agent activity, completed tasks, pending tasks, warnings, and key findings. Example content: project "Home Frozen Food Business", progress 72%, agent statuses (Orchestrator — Planning complete, Research — Analysis complete, Finance — Working, Critic — Waiting), key finding "Startup estimate: $1,800–$2,100", warning "3 assumptions require verification".
• Primary actions: View Business Blueprint. Open a project. Start a new project.
• Supporting actions: Open an agent card's View details. Open an activity event. Open an artifact.
• Domain entities: Project, agent, task, warning, key finding, progress, activity event.
• Component responsibilities: Project header (project name, goal sentence, segmented progress readout with oversized tabular percentage numeral); agent status row (4-up instrument strip of agent cards, collapsing to 2×2 at 768px and a vertical stack at 375px); Key Findings / Warnings panel; Activity timeline panel; "View Business Blueprint" action.
• States: Loading (workflow running — show live agent activity and progress); empty (no project selected or no projects yet — prompt to create a project); success (project with completed or in-progress workflow); error (agent error state surfaced as an agent card error and a warning); recovery (retry or re-open the project; the workflow resumes from persisted state).

Projects

• Information/state: List of existing projects with name, goal summary, budget, target location, overall progress, and last activity time.
• Primary actions: Open a project (go to Dashboard). Create a new project (go to Project Setup).
• Supporting actions: Sort or scan by recency; view a project's status at a glance.
• Domain entities: Project, project metadata, progress.
• Component responsibilities: Project list; project row/card with name, goal, progress, and status; empty-state prompt; "New project" action.
• States: Loading (reading local persistence); empty (no projects — prompt to create the first project); success (one or more projects listed); error (local persistence read failure — show a recoverable message); recovery (retry read; create a new project).

Project Setup

• Information/state: The project creation form. Fields: project name, business idea/goal, available budget, target location, optional target customer, optional additional context.
• Primary actions: "Start AI Team" — creates the project and starts the multi-agent workflow.
• Supporting actions: Cancel/return to Projects; review entered values before starting.
• Domain entities: Project, project name, business goal, budget, target location, target customer, additional context.
• Component responsibilities: Form with labeled inputs; required-field validation for project name, business idea/goal, available budget, and target location; optional fields for target customer and additional context; "Start AI Team" primary action; inline validation messages.
• States: Loading (submitting — brief, then navigate to Workflow/Dashboard); empty (blank form); success (project created, workflow started, navigate to the running project); error (validation failure — required fields missing or budget not a valid amount); recovery (correct the field and resubmit; entered values are preserved).

Workflow

• Information/state: The running multi-agent workflow for a project. Shows the current step in the pipeline (User Goal → Orchestrator → Research + Finance → Critic → Business Blueprint → Human Approval → Action Plan), which agent is working, completed, waiting, or requires human approval, and visible progress and agent status changes.
• Primary actions: Watch the workflow progress. Open an agent's details. Open a produced artifact. Respond to a human-approval gate.
• Supporting actions: Inspect the current task and latest finding per agent; open the activity log.
• Domain entities: Workflow, workflow step, agent, task, status, progress, artifact, approval gate.
• Component responsibilities: Workflow node graph (completed nodes filled, active node pulsing, pending nodes hollow); agent status strip; current-step detail; progress readout; approval gate panel when a step requires human approval; links to artifacts as they are produced.
• States: Loading (workflow initializing); empty (no workflow started — prompt to start the AI team); success (workflow running or complete); error (an agent enters the error state — surface the failing agent and step); recovery (retry the step or continue from the last completed step using persisted state).

Agents

• Information/state: The agent team workspace. Shows the four V1 agents — Orchestrator, Research, Finance, Critic — each as a visual card containing agent name, role, status, current task, progress, latest finding, and a View details button. Uses different visual states for Working, Completed, Waiting, Needs approval, and Error.
• Primary actions: View details for an agent (go to Agent Details).
• Supporting actions: Scan the agent row as a status instrument strip; read each agent's latest finding.
• Domain entities: Agent, agent role, status, current task, progress, latest finding.
• Component responsibilities: Agent card grid; per-card status rail colored by state; status chip; progress indicator; latest-finding line; View details button.
• States: Loading (agent states being read); empty (no agents active — no project running); success (four agent cards with current states); error (an agent card in the Error state); recovery (open the agent's details to inspect and retry).

Agent Details

• Information/state: Focused view of a single agent. Shows the agent's name, role, status, current task, progress, and latest finding, plus the agent's responsibilities and its contribution to the current project.
• Primary actions: Return to Agents or Workflow. Open the artifact this agent produced.
• Supporting actions: Inspect the agent's current task and progress; read its latest finding.
• Domain entities: Agent, role, status, current task, progress, latest finding, produced artifact.
• Component responsibilities: Agent header with name, role, and status; status rail; progress indicator; current-task block; latest-finding block; responsibilities list; link to the produced artifact.
• States: Loading (agent state being read); empty (agent has not started — waiting); success (agent working, completed, waiting, or needs approval); error (agent in the Error state with the failing task shown); recovery (retry the agent's step; return to Workflow).

Artifacts

• Information/state: The structured outputs produced by the agents. Artifact sections: 1. Market Research, 2. Financial Analysis, 3. Risk Review, 4. Business Blueprint, 5. Action Plan. Each artifact is readable and editable by the user.
• Primary actions: Open an artifact for reading/editing (go to Artifact Editor).
• Supporting actions: Scan artifact status (produced / in progress / not yet produced); open the Business Blueprint.
• Domain entities: Artifact, artifact section, artifact status, producing agent.
• Component responsibilities: Artifact list with the five sections; per-artifact status and producing agent; open action; empty-state prompt.
• States: Loading (artifacts being read); empty (no artifacts yet — workflow not started or not far enough); success (one or more artifacts available); error (artifact generation failed — show which artifact and which agent); recovery (retry generation from Workflow; open the artifact once produced).

Artifact Editor

• Information/state: A readable and editable workspace for a single artifact. Supports Market Research, Financial Analysis, Risk Review, Business Blueprint, and Action Plan. Market Research renders every claim as an inline tagged row distinguishing verified information, assumptions, and unknown information, each with a source slot. Financial Analysis renders cost tables with tabular numerals and right-aligned money columns.
• Primary actions: Read the artifact. Edit the artifact. Save edits.
• Supporting actions: Navigate between artifact sections; open the Business Blueprint; return to Artifacts.
• Domain entities: Artifact, artifact section, claim, tag (verified / assumption / unknown), source, cost table, pricing assumption, scenario, break-even estimate.
• Component responsibilities: Artifact reader with a sticky section index on desktop and a horizontal scrollable tab strip on mobile; editable fields; save action; tagged claim rows for Market Research; numeric tables for Financial Analysis; approval gate panel when the artifact contains an externally consequential proposed action.
• States: Loading (artifact being read); empty (artifact not yet produced); success (artifact readable and editable); error (save failure or artifact unavailable); recovery (retry save; revert to last saved content; return to Artifacts).

Blueprint

• Information/state: Focused review of the complete Business Blueprint. Contains: Business Concept (what the business does), Target Customer (who it is intended for), Problem (what customer problem it solves), Product/Service (what is being offered), Market Findings (important research findings), Financial Overview (startup cost, recurring cost, pricing assumptions, and basic scenarios), Risks (important risks and uncertainties), Validation Plan (the smallest experiments the user can perform to test the business idea), and Action Plan (a prioritized list of concrete next steps).
• Primary actions: Review the full blueprint. Open the Action Plan. Proceed to human approval for proposed next actions.
• Supporting actions: Open the underlying artifacts (Market Research, Financial Analysis, Risk Review); edit the blueprint.
• Domain entities: Business Blueprint, blueprint section, validation experiment, action-plan step, risk, financial overview.
• Component responsibilities: Blueprint reader with all nine sections; section navigation; link to the Action Plan; link to the approval gate; edit action.
• States: Loading (blueprint being assembled); empty (blueprint not yet produced — workflow not complete); success (complete blueprint readable); error (blueprint assembly failed); recovery (retry assembly from Workflow; open produced artifacts individually).

Approval

• Information/state: Presents human approval decisions for actions that could have external consequences. Shows "Human approval required" with the proposed action, and offers Approve, Reject, and Edit. For V1, execution is simulated.
• Primary actions: Approve. Reject. Edit.
• Supporting actions: Inspect the proposed action and its context; return to the artifact or blueprint that proposed it.
• Domain entities: Approval request, proposed external action, decision (approved / rejected / edited), simulated execution result.
• Component responsibilities: Approval gate panel with the proposed action set in monospace; Approve, Reject, and Edit as three equal-width buttons; decision recording; simulated execution confirmation.
• States: Loading (approval request being prepared); empty (no pending approval requests); success (decision recorded and simulated execution confirmed); error (decision could not be recorded); recovery (retry the decision; the request remains pending until recorded).

Activity

• Information/state: An activity timeline showing what the AI team is doing. Example events: "10:31 — Project created", "10:32 — Orchestrator created task plan", "10:33 — Research Agent started market analysis", "10:35 — Research Agent completed", "10:36 — Finance Agent started cost analysis", "10:38 — Critic identified 3 assumptions". The user can inspect each event.
• Primary actions: Inspect an event (go to Event Details).
• Supporting actions: Scan the timeline chronologically; filter or scan by agent.
• Domain entities: Activity event, timestamp, actor (agent or system), event description, related project.
• Component responsibilities: Chronological timeline; per-event row with timestamp, actor, and description; inspect action.
• States: Loading (events being read); empty (no events yet — project not created); success (events listed chronologically); error (event read failure); recovery (retry read).

Event Details

• Information/state: Focused inspection of a single activity event and its workflow context. Shows the event timestamp, actor, description, and the related project, agent, task, or artifact.
• Primary actions: Return to Activity. Open the related agent, artifact, or workflow step.
• Supporting actions: Inspect the event's workflow context.
• Domain entities: Activity event, timestamp, actor, related agent, related task, related artifact.
• Component responsibilities: Event header with timestamp and actor; event description; related-context links; return action.
• States: Loading (event being read); empty (event not found); success (event details shown); error (event read failure); recovery (return to Activity and retry).

3. Functional Requirements

Each requirement is a distinct story point with provenance, lifecycle facts, and observable acceptance.

3.1 Project Creation and Start

FR-1 — Create a business project (explicit) As a Business Idea Owner, I should create a project by entering a project name, a business idea/goal, an available budget, a target location, an optional target customer, and optional additional context, so that the AI team has a defined project to work on.

• Trigger/input: The user opens Project Setup and fills the form.
• Observable result: A project exists with the entered values, visible in Projects and Dashboard.
• Access state: No authentication; local persistence.
• Failure/recovery: Required fields missing or budget invalid — inline validation, entered values preserved, resubmit.
• Continuation: The user can start the AI team.

FR-2 — Start the AI team (explicit) As a Business Idea Owner, I should click "Start AI Team" after entering my project details, so that the multi-agent workflow begins.

• Trigger/input: "Start AI Team" on Project Setup.
• Observable result: The project is created and the workflow starts; the user is taken to the running workflow/dashboard.
• Access state: No authentication.
• Failure/recovery: If the workflow cannot start, the project is still created and the user can retry from Workflow.
• Continuation: The Orchestrator begins planning.

3.2 Multi-Agent Workflow

FR-3 — Run the multi-agent workflow (explicit) As a Business Idea Owner, I should have the system run the workflow User Goal → Orchestrator → Research + Finance → Critic → Business Blueprint → Human Approval → Action Plan, so that my idea becomes a practical, testable action plan.

• Trigger/input: Starting the AI team.
• Observable result: Each step executes in order and produces its output; the current step is visible.
• Access state: No authentication.
• Failure/recovery: A failing step surfaces an error state on the responsible agent; the workflow can resume from the last completed step using persisted state.
• Continuation: The next step begins automatically until a human-approval gate is reached.

FR-4 — Show agent state clearly (explicit) As a Business Idea Owner, I should clearly see which agent is working, completed, waiting, or requires human approval, so that I always know the state of the team.

• Trigger/input: Workflow execution.
• Observable result: Agent cards and the workflow graph show Working, Completed, Waiting, Needs approval, and Error states.
• Access state: No authentication.
• Failure/recovery: If state cannot be read, show a recoverable message and retry.
• Continuation: The user can open any agent's details.

3.3 Orchestrator Agent

FR-5 — Orchestrator understands the goal (explicit) As a Business Idea Owner, I should have the Orchestrator Agent understand my goal, so that the plan reflects what I actually asked for.

• Trigger/input: The user's goal from Project Setup.
• Observable result: The Orchestrator's understanding is reflected in the task plan.
• Access state: No authentication.
• Failure/recovery: If the goal is ambiguous, the Orchestrator proceeds with stated assumptions surfaced in the plan.
• Continuation: Task breakdown.

FR-6 — Orchestrator breaks the goal into tasks (explicit) As a Business Idea Owner, I should have the Orchestrator break my goal into smaller tasks, so that the work is decomposed and trackable.

• Trigger/input: The understood goal.
• Observable result: A task plan exists with individual tasks.
• Access state: No authentication.
• Failure/recovery: If task generation fails, the workflow surfaces an error and can retry.
• Continuation: Task assignment.

FR-7 — Orchestrator assigns tasks to specialized agents (explicit) As a Business Idea Owner, I should have the Orchestrator decide which specialized agent handles each task, so that work goes to the right agent.

• Trigger/input: The task plan.
• Observable result: Each task is assigned to Research, Finance, or Critic as appropriate.
• Access state: No authentication.
• Failure/recovery: Unassignable tasks are surfaced rather than silently dropped.
• Continuation: Specialized agents begin work.

FR-8 — Orchestrator tracks overall progress (explicit) As a Business Idea Owner, I should have the Orchestrator track overall project progress, so that I can see how far the project has advanced.

• Trigger/input: Task and agent state changes.
• Observable result: Overall progress is shown on the Dashboard and Workflow.
• Access state: No authentication.
• Failure/recovery: If progress cannot be computed, show the last known progress.
• Continuation: Progress updates as steps complete.

FR-9 — Orchestrator combines agent outputs (explicit) As a Business Idea Owner, I should have the Orchestrator combine agent outputs into a coherent result, so that I get one coherent blueprint rather than disconnected fragments.

• Trigger/input: Completed Research, Finance, and Critic outputs.
• Observable result: A coherent combined result feeding the Business Blueprint.
• Access state: No authentication.
• Failure/recovery: If combination fails, individual artifacts remain available.
• Continuation: Business Blueprint assembly.

FR-10 — Orchestrator does not do everything itself (explicit constraint) As a Business Idea Owner, I should see the Orchestrator delegate work rather than perform every task itself, so that the workspace reads as a team.

• Trigger/input: Workflow execution.
• Observable result: Specialized agents perform their own tasks; the Orchestrator plans, assigns, tracks, and combines.
• Access state: No authentication.
• Failure/recovery: Not applicable.
• Continuation: Specialized agent work.

3.4 Research Agent

FR-11 — Research analyzes the target market (explicit) As a Business Idea Owner, I should have the Research Agent analyze the target market, so that I understand the market context.

• Trigger/input: Assigned research task and project goal/location.
• Observable result: Market analysis appears in the Market Research artifact.
• Access state: No authentication.
• Failure/recovery: If analysis cannot be completed, the artifact shows what is unknown.
• Continuation: Findings feed the blueprint.

FR-12 — Research identifies potential customers (explicit) As a Business Idea Owner, I should have the Research Agent identify potential customers, so that I know who the business serves.

• Trigger/input: Assigned research task and optional target customer.
• Observable result: Potential customers appear in the Market Research artifact and inform Target Customer.
• Access state: No authentication.
• Failure/recovery: If customers cannot be identified, mark as unknown.
• Continuation: Target Customer section.

FR-13 — Research identifies competitors or alternatives (explicit) As a Business Idea Owner, I should have the Research Agent identify competitors or alternatives, so that I understand the competitive landscape.

• Trigger/input: Assigned research task.
• Observable result: Competitors/alternatives appear in the Market Research artifact.
• Access state: No authentication.
• Failure/recovery: If none can be identified, mark as unknown.
• Continuation: Risk Review and blueprint.

FR-14 — Research identifies relevant market assumptions (explicit) As a Business Idea Owner, I should have the Research Agent identify relevant market assumptions, so that I know what the analysis rests on.

• Trigger/input: Assigned research task.
• Observable result: Assumptions are listed and tagged as assumptions.
• Access state: No authentication.
• Failure/recovery: If assumptions cannot be identified, mark as unknown.
• Continuation: Critic review.

FR-15 — Research collects findings and sources when web research is available (explicit) As a Business Idea Owner, I should have the Research Agent collect research findings and sources when web research is available, so that findings can be traced.

• Trigger/input: Assigned research task; web research availability.
• Observable result: Findings include sources when web research is available; when it is not, findings are marked accordingly.
• Access state: No authentication.
• Failure/recovery: If web research is unavailable, findings are marked as not verified.
• Continuation: Findings feed the blueprint.

FR-16 — Research distinguishes verified, assumption, and unknown (explicit constraint) As a Business Idea Owner, I should see verified information, assumptions, and unknown information clearly distinguished, so that I never mistake an assumption for a fact.

• Trigger/input: Research output.
• Observable result: Every claim is tagged as verified, assumption, or unknown, with a source slot.
• Access state: No authentication.
• Failure/recovery: If a claim cannot be classified, it is shown as unknown.
• Continuation: Critic review and blueprint.

FR-17 — Research never presents an assumption as verified (explicit constraint) As a Business Idea Owner, I should never see an assumption presented as a verified fact, so that I can trust the distinction.

• Trigger/input: Research output.
• Observable result: Assumptions are always tagged as assumptions.
• Access state: No authentication.
• Failure/recovery: Not applicable.
• Continuation: Critic review.

3.5 Finance Agent

FR-18 — Finance estimates startup costs (explicit) As a Business Idea Owner, I should have the Finance Agent estimate startup costs, so that I know the initial outlay.

• Trigger/input: Assigned finance task and project budget.
• Observable result: Startup cost estimate appears in the Financial Analysis artifact.
• Access state: No authentication.
• Failure/recovery: If insufficient information, show a range with stated assumptions.
• Continuation: Financial Overview.

FR-19 — Finance estimates recurring costs (explicit) As a Business Idea Owner, I should have the Finance Agent estimate recurring costs, so that I know ongoing expenses.

• Trigger/input: Assigned finance task.
• Observable result: Recurring cost estimate appears in the Financial Analysis artifact.
• Access state: No authentication.
• Failure/recovery: If insufficient information, show a range with stated assumptions.
• Continuation: Financial Overview.

FR-20 — Finance suggests a basic pricing structure (explicit) As a Business Idea Owner, I should have the Finance Agent suggest a basic pricing structure, so that I have a starting point for pricing.

• Trigger/input: Assigned finance task.
• Observable result: A basic pricing structure appears in the Financial Analysis artifact.
• Access state: No authentication.
• Failure/recovery: If pricing cannot be suggested, mark as unknown.
• Continuation: Revenue scenarios.

FR-21 — Finance calculates simple revenue scenarios (explicit) As a Business Idea Owner, I should have the Finance Agent calculate simple revenue scenarios, so that I can see possible outcomes.

• Trigger/input: Assigned finance task and pricing structure.
• Observable result: Simple revenue scenarios appear in the Financial Analysis artifact.
• Access state: No authentication.
• Failure/recovery: If scenarios cannot be calculated, mark as unknown.
• Continuation: Break-even estimates.

FR-22 — Finance calculates break-even when enough information is available (explicit) As a Business Idea Owner, I should have the Finance Agent calculate break-even estimates when enough information is available, so that I know when the business could break even.

• Trigger/input: Assigned finance task; sufficient cost and pricing information.
• Observable result: Break-even estimate appears when enough information is available; otherwise it is marked as not calculable.
• Access state: No authentication.
• Failure/recovery: If information is insufficient, state what is missing.
• Continuation: Financial Overview.

FR-23 — Finance identifies assumptions behind calculations (explicit) As a Business Idea Owner, I should have the Finance Agent clearly identify the assumptions behind calculations, so that I know what the numbers depend on.

• Trigger/input: Finance calculations.
• Observable result: Assumptions are listed alongside the calculations.
• Access state: No authentication.
• Failure/recovery: If assumptions cannot be identified, mark as unknown.
• Continuation: Critic review.

3.6 Critic Agent

FR-24 — Critic reviews outputs from other agents (explicit) As a Business Idea Owner, I should have the Critic Agent review the outputs from other agents, so that the work is challenged.

• Trigger/input: Completed Research and Finance outputs.
• Observable result: A Risk Review artifact containing the Critic's review.
• Access state: No authentication.
• Failure/recovery: If review cannot be completed, surface an error and retry.
• Continuation: Blueprint assembly.

FR-25 — Critic detects unsupported assumptions (explicit) As a Business Idea Owner, I should have the Critic detect unsupported assumptions, so that weak claims are flagged.

• Trigger/input: Agent outputs.
• Observable result: Unsupported assumptions are listed in the Risk Review artifact.
• Access state: No authentication.
• Failure/recovery: If none are found, state that none were detected.
• Continuation: Human verification questions.

FR-26 — Critic identifies missing information (explicit) As a Business Idea Owner, I should have the Critic identify missing information, so that I know what is not yet known.

• Trigger/input: Agent outputs.
• Observable result: Missing information is listed in the Risk Review artifact.
• Access state: No authentication.
• Failure/recovery: If none is found, state that none was detected.
• Continuation: Human verification questions.

FR-27 — Critic identifies contradictions (explicit) As a Business Idea Owner, I should have the Critic identify contradictions, so that inconsistent claims are surfaced.

• Trigger/input: Agent outputs.
• Observable result: Contradictions are listed in the Risk Review artifact.
• Access state: No authentication.
• Failure/recovery: If none is found, state that none was detected.
• Continuation: Blueprint Risks section.

FR-28 — Critic identifies potential risks (explicit) As a Business Idea Owner, I should have the Critic identify potential risks, so that I understand what could go wrong.

• Trigger/input: Agent outputs.
• Observable result: Potential risks are listed in the Risk Review artifact and the blueprint Risks section.
• Access state: No authentication.
• Failure/recovery: If none is found, state that none was detected.
• Continuation: Blueprint Risks section.

FR-29 — Critic suggests questions needing human verification (explicit) As a Business Idea Owner, I should have the Critic suggest questions that need human verification, so that I know what to check myself.

• Trigger/input: Agent outputs.
• Observable result: Verification questions are listed in the Risk Review artifact.
• Access state: No authentication.
• Failure/recovery: If none are found, state that none were detected.
• Continuation: Validation Plan.

FR-30 — Critic does not simply agree (explicit constraint) As a Business Idea Owner, I should see the Critic challenge the other agents rather than simply agree, so that the review has value.

• Trigger/input: Agent outputs.
• Observable result: The Risk Review contains challenges, not just agreement.
• Access state: No authentication.
• Failure/recovery: Not applicable.
• Continuation: Blueprint assembly.

3.7 Dashboard

FR-31 — Dashboard shows project workspace (explicit) As a Business Idea Owner, I should see a visual project workspace showing project name, original user goal, overall progress, current agent activity, completed tasks, pending tasks, warnings, and key findings, so that I have one place to monitor the project.

• Trigger/input: Opening Dashboard.
• Observable result: All listed elements are visible.
• Access state: No authentication.
• Failure/recovery: If data cannot be read, show a recoverable message.
• Continuation: Open the Business Blueprint or an agent.

FR-32 — Dashboard View Business Blueprint action (explicit) As a Business Idea Owner, I should have a "View Business Blueprint" action on the Dashboard, so that I can go straight to the blueprint.

• Trigger/input: Clicking "View Business Blueprint".
• Observable result: The Blueprint page opens.
• Access state: No authentication.
• Failure/recovery: If the blueprint is not yet produced, show that it is pending.
• Continuation: Blueprint review.

3.8 Agent Cards

FR-33 — Agent card contents (explicit) As a Business Idea Owner, I should see a visual card for each agent containing agent name, role, status, current task, progress, latest finding, and a View details button, so that I can scan the team at a glance.

• Trigger/input: Opening Dashboard, Agents, or Workflow.
• Observable result: Each agent card shows all listed fields.
• Access state: No authentication.
• Failure/recovery: If a field is unavailable, show it as pending.
• Continuation: View details.

FR-34 — Agent card visual states (explicit) As a Business Idea Owner, I should see different visual states for Working, Completed, Waiting, Needs approval, and Error, so that state is readable at a glance.

• Trigger/input: Agent state changes.
• Observable result: Each state has a distinct visual treatment.
• Access state: No authentication.
• Failure/recovery: Unknown states fall back to Waiting.
• Continuation: View details.

FR-35 — View agent details (explicit) As a Business Idea Owner, I should be able to open an agent's details, so that I can inspect its role, task, progress, status, and latest finding.

• Trigger/input: View details button.
• Observable result: Agent Details opens for that agent.
• Access state: No authentication.
• Failure/recovery: If the agent is not found, return to Agents.
• Continuation: Open the produced artifact.

3.9 Artifacts

FR-36 — Structured artifacts instead of only chat (explicit) As a Business Idea Owner, I should receive structured artifacts instead of only chat messages, so that outputs are usable documents.

• Trigger/input: Agent work.
• Observable result: Artifacts exist as structured documents.
• Access state: No authentication.
• Failure/recovery: If an artifact cannot be produced, show which agent failed.
• Continuation: Read/edit the artifact.

FR-37 — Five artifact sections (explicit) As a Business Idea Owner, I should have artifact sections for Market Research, Financial Analysis, Risk Review, Business Blueprint, and Action Plan, so that outputs are organized.

• Trigger/input: Agent work.
• Observable result: All five sections exist.
• Access state: No authentication.
• Failure/recovery: Missing sections are shown as not yet produced.
• Continuation: Open a section.

FR-38 — Artifacts are readable and editable (explicit) As a Business Idea Owner, I should be able to read and edit each artifact, so that I can correct or extend the output.

• Trigger/input: Opening an artifact.
• Observable result: The artifact is readable and editable; edits are saved.
• Access state: No authentication.
• Failure/recovery: If saving fails, keep the last saved content and allow retry.
• Continuation: Return to Artifacts or Blueprint.

3.10 Business Blueprint

FR-39 — Blueprint contents (explicit) As a Business Idea Owner, I should receive a final blueprint containing Business Concept, Target Customer, Problem, Product/Service, Market Findings, Financial Overview (startup cost, recurring cost, pricing assumptions, and basic scenarios), Risks, Validation Plan (the smallest experiments to test the idea), and Action Plan (a prioritized list of concrete next steps), so that I have a complete plan.

• Trigger/input: Completed agent outputs.
• Observable result: All nine sections are present and readable.
• Access state: No authentication.
• Failure/recovery: If a section cannot be produced, show it as pending with the reason.
• Continuation: Human approval of proposed next actions.

3.11 Human Approval

FR-40 — Human approval required before externally consequential actions (explicit) As a Business Idea Owner, I should see "Human approval required" with Approve, Reject, and Edit before any action that could have external consequences, so that nothing irreversible happens without me.

• Trigger/input: A proposed action with external consequences.
• Observable result: An approval gate appears with the proposed action and the three options.
• Access state: No authentication.
• Failure/recovery: If the decision cannot be recorded, the request stays pending.
• Continuation: The decision is recorded and execution is simulated.

FR-41 — Agents do not perform irreversible external actions automatically (explicit constraint) As a Business Idea Owner, I should have agents never automatically perform irreversible external actions, so that I retain control.

• Trigger/input: Any externally consequential action.
• Observable result: The action is gated behind human approval.
• Access state: No authentication.
• Failure/recovery: Not applicable.
• Continuation: Approval decision.

FR-42 — V1 execution is simulated (explicit constraint) As a Business Idea Owner, I should have actual execution simulated in V1 — no emails sent, no content published, no purchases made, no external actions performed automatically — so that the prototype is safe.

• Trigger/input: An approved action.
• Observable result: The action is recorded as simulated; no external effect occurs.
• Access state: No authentication.
• Failure/recovery: Not applicable.
• Continuation: The project continues.

3.12 Activity Log

FR-43 — Activity timeline (explicit) As a Business Idea Owner, I should see an activity timeline showing what the AI team is doing, so that I can follow the work.

• Trigger/input: Project and workflow events.
• Observable result: Events appear chronologically with timestamps and descriptions.
• Access state: No authentication.
• Failure/recovery: If events cannot be read, show a recoverable message.
• Continuation: Inspect an event.

FR-44 — Inspect each event (explicit) As a Business Idea Owner, I should be able to inspect each event, so that I can see its context.

• Trigger/input: Selecting an event.
• Observable result: Event Details shows the event's timestamp, actor, description, and related context.
• Access state: No authentication.
• Failure/recovery: If the event is not found, return to Activity.
• Continuation: Open the related agent, artifact, or workflow step.

3.13 Demo Mode

FR-45 — Demo mode with realistic mock AI responses (explicit) As a Business Idea Owner, I should have a fully functional demo mode using realistic mock AI responses, so that the app works without an AI API key.

• Trigger/input: Running the app without an AI API key.
• Observable result: The workflow runs with mock responses.
• Access state: No authentication.
• Failure/recovery: If demo data is unavailable, show a recoverable message.
• Continuation: The full workflow completes.

FR-46 — Demo simulates the full pipeline with visible progress (explicit) As a Business Idea Owner, I should see the demo simulate Orchestrator → Research → Finance → Critic → Blueprint with visible progress and agent status changes, so that the workflow feels real.

• Trigger/input: Starting the AI team in demo mode.
• Observable result: Progress and agent statuses change visibly through the pipeline.
• Access state: No authentication.
• Failure/recovery: If simulation stalls, allow retry.
• Continuation: Blueprint and approval.

FR-47 — Structure code for real AI providers later (explicit) As a Business Idea Owner, I should have the code structured so real AI providers can be connected later, so that the prototype can grow.

• Trigger/input: Not user-facing.
• Observable result: Provider boundaries are separated from UI and workflow logic.
• Access state: No authentication.
• Failure/recovery: Not applicable.
• Continuation: Future provider integration.

3.14 Data Architecture and Persistence

FR-48 — Modular TypeScript structures (explicit) As a Business Idea Owner, I should have clean, modular TypeScript structures separating agents, workflows, projects, artifacts, activity events, business calculations, and UI components, so that the codebase is maintainable.

• Trigger/input: Not user-facing.
• Observable result: These concerns are separated in the codebase.
• Access state: No authentication.
• Failure/recovery: Not applicable.
• Continuation: Future development.

FR-49 — No giant single component (explicit constraint) As a Business Idea Owner, I should not have the entire application in one giant component, so that the code stays maintainable.

• Trigger/input: Not user-facing.
• Observable result: UI is composed from multiple components.
• Access state: No authentication.
• Failure/recovery: Not applicable.
• Continuation: Future development.

FR-50 — Local persistence (required_inference) As a Business Idea Owner, I should have my projects, workflow state, artifacts, and activity events persisted locally, so that my demo project survives a reload.

• Trigger/input: Any state change.
• Observable result: State is restored on reload.
• Access state: No authentication; local persistence only.
• Failure/recovery: If persistence fails, show a recoverable message and keep in-memory state.
• Continuation: The user continues where they left off.

4. User Personas

Business Idea Owner

Product context The Business Idea Owner is a founder or solo operator with a business idea or goal — for example, "I want to start a frozen food business from home with a budget of $2,000." They are a power user who wants density, status, numbers, and machine-readable artifacts rather than a friendly assistant conversation. They are working on a phone as often as a desktop, so the workspace must work well on Android screens.

Primary goal Turn a rough business idea into a practical, testable action plan they can act on, with verified information, assumptions, and unknowns clearly distinguished.

Distinct accepted responsibilities

• Create a project with a name, business idea/goal, available budget, target location, optional target customer, and optional additional context, then click "Start AI Team".
• Watch the Orchestrator create tasks and see the specialized agents work.
• Inspect agent outputs and structured artifacts.
• See the Critic challenge assumptions.
• Review the final Business Blueprint.
• Approve, reject, or edit proposed next actions before any externally consequential step.
• Read and edit artifacts to correct or extend the output.

Relevant inputs or decisions

• The business goal, budget, target location, optional target customer, and optional additional context.
• Whether to approve, reject, or edit a proposed externally consequential action.
• Edits to artifacts and the blueprint.

Interactions with other accepted participants The Business Idea Owner interacts with the agent team (Orchestrator, Research, Finance, Critic) as system actors. The Orchestrator plans and assigns; Research, Finance, and Critic produce outputs; the Critic challenges the others. The Business Idea Owner is the only human participant and the sole decision-maker at approval gates.

Observable success A complete Business Blueprint with all nine sections, a prioritized Action Plan, and a recorded approval decision — with verified information, assumptions, and unknowns clearly distinguished throughout.

Constraints carried from source No authentication, no payment systems, no subscriptions, no unnecessary features. The application must work without an AI API key. Execution of externally consequential actions is simulated in V1.

5. Core User Flows

Flow 1 — Create a project and start the AI team

1. The Business Idea Owner opens the application and lands on Landing, which explains that AI Business Operator is an agentic workspace, not a chatbot, and shows the seven-step workflow.
2. The owner chooses to start a new project and arrives at Project Setup.
3. The owner enters the project name, business idea/goal (e.g. "I want to start a frozen food business from home with a budget of $2,000"), available budget, and target location, and optionally a target customer and additional context.
4. The owner clicks "Start AI Team".
5. Observable result: The project is created and the workflow starts; the owner is taken to the running Workflow / Dashboard.
6. Failure/recovery: If a required field is missing or the budget is invalid, inline validation appears, entered values are preserved, and the owner corrects and resubmits.
7. Continuation: The Orchestrator begins planning.

Flow 2 — Watch the Orchestrator create tasks

1. From the running Workflow, the Business Idea Owner watches the Orchestrator step.
2. The Orchestrator understands the goal, breaks it into smaller tasks, and decides which specialized agent handles each task.
3. Observable result: A task plan appears; tasks are assigned to Research, Finance, or Critic; overall progress updates on the Dashboard and Workflow.
4. The owner can open the Activity timeline and see "Orchestrator created task plan".
5. Failure/recovery: If task generation fails, the Orchestrator's agent card shows an error state and the owner can retry from Workflow.
6. Continuation: Specialized agents begin work.

Flow 3 — See specialized agents work

1. The Business Idea Owner watches the Workflow and Agents views as Research and Finance run.
2. Each agent card shows agent name, role, status, current task, progress, latest finding, and a View details button, with distinct visual states for Working, Completed, Waiting, Needs approval, and Error.
3. Observable result: The owner sees "Research Agent started market analysis", "Research Agent completed", "Finance Agent started cost analysis", and so on, in the Activity timeline and on the agent cards.
4. The owner opens Agent Details for an agent to inspect its role, task, progress, status, and latest finding.
5. Failure/recovery: If an agent enters the Error state, the owner opens its details, sees the failing task, and retries the step.
6. Continuation: The Critic runs after Research and Finance.

Flow 4 — Inspect agent outputs and structured artifacts

1. The Business Idea Owner opens Artifacts and sees the five sections: Market Research, Financial Analysis, Risk Review, Business Blueprint, Action Plan.
2. The owner opens an artifact in the Artifact Editor.
3. In Market Research, every claim is rendered as an inline tagged row — verified, assumption, or unknown — each with a source slot, so the distinction is structural rather than a footnote.
4. In Financial Analysis, cost tables render with tabular numerals and right-aligned money columns; startup cost, recurring cost, pricing assumptions, and basic scenarios are visible.
5. The owner edits the artifact and saves.
6. Observable result: The artifact is readable and editable; edits are saved.
7. Failure/recovery: If saving fails, the last saved content is kept and the owner can retry.
8. Continuation: The owner returns to Artifacts or opens the Blueprint.

Flow 5 — See the Critic challenge assumptions

1. The Business Idea Owner watches the Critic step in Workflow.
2. The Critic reviews the outputs from the other agents, detects unsupported assumptions, identifies missing information, identifies contradictions, identifies potential risks, and suggests questions that need human verification.
3. Observable result: The Risk Review artifact lists the Critic's findings, and the Activity timeline shows "Critic identified 3 assumptions".
4. The owner opens the Risk Review artifact and reads the challenges.
5. Failure/recovery: If the Critic cannot complete its review, its agent card shows an error state and the owner can retry.
6. Continuation: The Business Blueprint is assembled.

Flow 6 — Review the final Business Blueprint

1. The Business Idea Owner opens Blueprint (from the Dashboard's "View Business Blueprint" action or from Artifacts).
2. The owner reads all nine sections: Business Concept, Target Customer, Problem, Product/Service, Market Findings, Financial Overview, Risks, Validation Plan, and Action Plan.
3. Observable result: The complete blueprint is readable, with the Validation Plan listing the smallest experiments to test the idea and the Action Plan listing prioritized concrete next steps.
4. The owner can open the underlying artifacts (Market Research, Financial Analysis, Risk Review) or edit the blueprint.
5. Failure/recovery: If a section could not be produced, it is shown as pending with the reason, and the owner can retry assembly from Workflow.
6. Continuation: Human approval of proposed next actions.

Flow 7 — Approve, reject, or edit proposed next actions

1. When a proposed action could have external consequences, the Business Idea Owner sees "Human approval required" on the Approval page (and as an approval gate panel interrupting the artifact reader or blueprint).
2. The proposed external action is shown, with its context.
3. The owner chooses Approve, Reject, or Edit.
4. Observable result: The decision is recorded and execution is simulated — no email is sent, no content is published, no purchase is made, and no external action is performed automatically.
5. Failure/recovery: If the decision cannot be recorded, the request remains pending and the owner can retry.
6. Continuation: The project continues with the recorded decision.

Flow 8 — Inspect the activity log

1. The Business Idea Owner opens Activity.
2. The timeline shows events chronologically, e.g. "10:31 — Project created", "10:32 — Orchestrator created task plan", "10:33 — Research Agent started market analysis", "10:35 — Research Agent completed", "10:36 — Finance Agent started cost analysis", "10:38 — Critic identified 3 assumptions".
3. The owner selects an event and opens Event Details.
4. Observable result: The event's timestamp, actor, description, and related context are shown.
5. Failure/recovery: If the event is not found, the owner returns to Activity.
6. Continuation: The owner opens the related agent, artifact, or workflow step.

Flow 9 — Browse and reopen projects

1. The Business Idea Owner opens Projects.
2. The list shows existing projects with name, goal summary, budget, target location, overall progress, and last activity time.
3. The owner opens a project and returns to its Dashboard.
4. Observable result: The project's persisted state is restored.
5. Failure/recovery: If no projects exist, an empty-state prompt invites the owner to create the first project.
6. Continuation: The owner continues watching or reviewing the project.

6. Visuals Colors and Theme

The creative direction is authoritative for this section. The muse is Rasmus Andersson: systematic product craft with an opinion — a dark operator console, not a chatbot. The headline is: the interface is the imagery; the important content is state and numbers.

Color tokens (dark mode)

Graphite ground (#141517) with slightly raised panels (#1B1D20) separated by 1px hairlines at rgba(237,234,228,0.10). Body text is warm off-white #EDEAE4, never pure white. One hot accent — tangerine #F5A623 — carries the primary CTA, the active progress bar, the "working" pulse, and the human-approval flag; it is used on roughly 5% of pixels. A second signal, mint #7DE2B8, is reserved exclusively for verified facts and completed ticks, so the verified / assumption / unknown triad in the Research agent is legible by color alone. Muted #8B8F96 is for metadata, timestamps, and labels. Warnings use the tangerine; errors use #E5484D on a tinted panel. No blue anywhere — the entire blue–indigo band is banned in this project.

Typography

• Headings: Space Grotesk, medium 500, tight tracking (-0.02em), sentence case for section titles and UPPERCASE with +0.12em tracking for micro-labels ("AGENTS", "KEY FINDINGS", "ACTIVITY").
• Body: Inter Tight.
• Numbers and money: JetBrains Mono (tabular monospace) at the same optical size as the surrounding text, so a cost table reads as a column of aligned digits.
• Scale: 1.25 modular on a 16px base, with one editorial outlier for the hero: 40px / 32px / 24px / 18px / 15px / 13px / 11px. Hero project title clamps 34px on mobile to 72px on desktop; agent-card titles 18px; artifact body 15px with 1.6 line-height; labels 11px uppercase.

Shape language

Rectilinear and precise. 6px radii on cards and inputs, 4px on buttons and status chips, 2px on hairline dividers. No pills except status chips, no blobs, no soft shadows — depth comes from a 1px border plus a 2px inner top highlight, like a machined panel. The one signature shape is a 4px-wide vertical status rail running the full height of every agent card, colored by state.

Layout

A persistent left rail (72px collapsed icon rail on mobile as a bottom tab bar; 232px expanded at 1280px) carrying Dashboard / Projects / Agents / Artifacts / Activity. Content is a 12-column grid with a 24px gutter, max-width 1440px. Dashboard is a three-band stack: (1) full-width project header with the goal sentence and a segmented progress bar, (2) a 4-up agent status row that collapses to a 2×2 at 768px and a vertical stack at 375px, (3) a two-column split — Key Findings / Warnings on the left, Activity timeline on the right, stacking on mobile. Artifacts open as a full-width reader with a sticky section index on the left at desktop and a horizontal scrollable tab strip on mobile. Every numeric table is a real table with tabular numerals and right-aligned money columns.

Imagery

The interface is the imagery. No stock photos, no 3D renders, no illustration. Instead: schematic diagrams drawn in SVG (the workflow graph User Goal → Orchestrator → Research + Finance → Critic → Blueprint → Approval → Action Plan shown as a hairline node graph with the live node glowing tangerine), sparkline cost curves, and monospace cost tables. Where an artifact needs a visual, it is a data graphic built from the project's own numbers.

7. Signature Design Concept

The first screen is the workspace, not a marketing hero.

A full-bleed graphite canvas (#141517). Top-left, a 34–72px Space Grotesk project title ("Home Frozen Food Business") sitting directly above the user's original goal sentence set in warm off-white at 18px, with a 1px hairline under it. To the right of that block, right-aligned and vertically aligned to the title baseline, a segmented progress readout: 16 hairline segments, 11 filled in tangerine, with the numeral "72%" set in tabular monospace at 40px — the biggest number on the screen.

Below, the agent status row reads as an instrument strip: four equal panels, each with a 4px colored left rail, agent name in 11px uppercase tracked label, a one-line status ("Planning complete", "Working", "Waiting"), and a live tabular progress figure. The single tangerine pulse dot sits on the Finance panel.

No gradient blob, no centered stack, no blue button — the dominant element is the progress numeral and the goal sentence, and the whole composition reads as a control panel that is already mid-operation.

Signature moves carried through the product:

• The segmented progress readout: 16 hairline segments that fill in tangerine one at a time as tasks complete, paired with an oversized tabular-monospace percentage numeral that is the largest type on the dashboard — progress is a number, not a bar.
• A 4px vertical status rail down the left edge of every agent card, colored by state (tangerine = working, mint = completed, muted grey = waiting, tangerine with a hazard notch = needs approval, red = error), so the agent row scans as a color-coded instrument strip.
• The Research artifact renders every claim as an inline tagged row — a mint "VERIFIED" tag, a tangerine "ASSUMPTION" tag, or a muted "UNKNOWN" tag, each with a hairline rule and a monospace source slot — so the verified/assumption/unknown distinction is structural, not a footnote.
• A live workflow node graph in the project header: the seven-step pipeline drawn as hairline SVG nodes and connectors, with completed nodes filled mint, the active node pulsing tangerine, and pending nodes as hollow outlines — the diagram is the status indicator.
• Human-approval gates render as a full-width tangerine-bordered panel that interrupts the artifact reader, with the proposed external action set in monospace, its blast radius listed line by line, and Approve / Reject / Edit as three equal-width buttons where Approve is the only filled one.

8. Interaction Model & Motion Direction

Interaction Model: Static (direction) Motion Tempo: restrained Hero Dimensionality: flat

Landing Hero Motion Brief

• Focal subject: The seven-step workflow node graph (User Goal → Orchestrator → Research + Finance → Critic → Business Blueprint → Human Approval → Action Plan) drawn as hairline SVG nodes and connectors on the graphite canvas.
• Input → transformation → outcome thesis: As the workflow advances, completed nodes fill mint, the active node pulses tangerine, and pending nodes remain hollow outlines — so the diagram itself is the status indicator, and the visitor reads the product as a running team rather than a chat.
• Motion vocabulary: Functional and fast — 140ms ease-out for state changes, 180ms for panel reveals, no bounce, no float, no particles. The only continuous motion in the whole app is a 1.6s opacity pulse on the tangerine dot of whichever agent is currently working — one pulse, one place, so "who is working" is readable at a glance from across the room. Progress bars animate their width over 400ms when a step completes.
• Composed first frame: Full-bleed graphite canvas; project title in Space Grotesk above the goal sentence; segmented progress readout with the oversized tabular percentage numeral; the four-panel agent instrument strip below with a single tangerine pulse dot on the working agent.
• Reduced-motion state: Under prefers-reduced-motion, the pulse becomes a static filled dot and all transitions drop to 0ms.

9. Non-Functional Requirements

NFR-1 — Responsive, mobile-first design (explicit) The application must be responsive and mobile-first, and must work well on Android screens. Readable text and controls stay whole at every viewport: headlines, wordmarks, labels, numbers, cards' text, and controls stay entirely inside the viewport and their container at 375px, 768px, and 1280px, wrapping or scaling (for example font-size: clamp(...) with its mobile size) to fit, and no other element covers any part of them. Rationale: the source explicitly requires mobile-first responsive design that works well on Android screens.

NFR-2 — Avoid excessive animations (explicit) Animations must be restrained. Rationale: the source explicitly requires avoiding excessive animations; the creative direction sets a restrained tempo with a single continuous pulse.

NFR-3 — Avoid a generic ChatGPT clone (explicit) The interface must not look like a generic ChatGPT clone. No chat-bubble UI, no avatars for agents, no typing indicators, and no message composer as the primary surface. Rationale: the source explicitly requires avoiding a generic ChatGPT clone and the product must feel like an AI team working on a project.

NFR-4 — Use cards, status indicators, progress indicators, tabs, and structured artifacts (explicit) The UI must use cards, status indicators, progress indicators, tabs, and structured artifacts. Rationale: explicit UI/UX requirement.

NFR-5 — No authentication (explicit constraint) Do not add authentication yet. Rationale: explicit constraint.

NFR-6 — No payment systems (explicit constraint) Do not add payment systems. Rationale: explicit constraint.

NFR-7 — No subscriptions (explicit constraint) Do not add subscriptions. Rationale: explicit constraint.

NFR-8 — No unnecessary features (explicit constraint) Do not add unnecessary features. Rationale: explicit constraint.

NFR-9 — No unnecessary backend for V1 (explicit constraint) There must be no unnecessary backend for V1; local persistence is acceptable for demo projects. Rationale: explicit constraint.

NFR-10 — Works without an AI API key (explicit constraint) The application must work even without an AI API key. Rationale: explicit constraint; demo mode provides realistic mock AI responses.

NFR-11 — Clean component architecture and strong typing (explicit) The codebase must have clean component architecture and strong typing. Do not put the entire application into one giant component. Rationale: explicit technical requirement.

NFR-12 — Do not over-engineer (explicit constraint) Do not over-engineer the V1. Rationale: explicit constraint; the V1 is a polished working prototype.

NFR-13 — No blue or indigo in the primary/accent range (creative direction) Any blue or indigo in the primary/accent range (#0057FF, #2563EB, #4F46E5, #6366F1, #7C3AED and neighbours) is forbidden. The project is graphite plus tangerine plus mint only. Rationale: creative direction; the generic indigo/blue-on-white SaaS template is forbidden for this project.

NFR-14 — Banned fonts (creative direction) Inter, Roboto, Arial, Helvetica, Open Sans, Lato, Poppins, or system-ui must not be used as heading or body font. Rationale: creative direction.

NFR-15 — No decorative looping animation, particles, 3D scenes, or bounce easing (creative direction) Rationale: creative direction; motion is functional and fast.

NFR-16 — Assumptions must never carry the same visual weight as verified facts (creative direction) The tag colors must never be used decoratively. Rationale: creative direction; the verified/assumption/unknown distinction must be structural.

10. Tech Stack

Source-specified technology is preserved exactly.

• React (explicit) — UI framework.
• TypeScript (explicit) — language, with strong typing.
• Vite (explicit) — build tool.
• Local persistence (explicit) — acceptable for demo projects; no unnecessary backend for V1.
• Modular TypeScript structures (explicit) — separating agents, workflows, projects, artifacts, activity events, business calculations, and UI components.
• Provider boundary for future AI providers (explicit) — the code is structured so real AI providers can be connected later; demo mode uses realistic mock AI responses and requires no AI API key.

No backend, database, container, or orchestration technology is required for V1. Docker, docker-compose, and Kubernetes are not specified by the user and are not needed for this client-side prototype.

11. Assumptions and Constraints

Assumptions

• A-1 (required_inference): Projects, workflow state, artifacts, and activity events are persisted locally in the browser so a demo project survives a reload. This is required to make the accepted journey executable without adding a product capability.
• A-2 (required_inference): Demo mode supplies realistic mock AI responses so the workflow works without an AI API key. This is required to make the accepted journey executable.
• A-3 (required_inference): Human review through Approve, Reject, or Edit occurs before any externally consequential action, and execution remains simulated. This is required to make the accepted journey executable.
• A-4 (required_inference): Because there is no authentication and no application-owned identity, there is no cross-device or cross-user continuity and no differentiated permissions or role-based visibility. The single active human role has full access to its own locally persisted projects.
• A-5 (required_inference): The agent team (Orchestrator, Research, Finance, Critic) is a set of system actors, not human personas. They are simulated in demo mode and structured so real AI providers can be connected later.

Constraints

• C-1 (explicit): Agents must not automatically perform irreversible external actions; before an action that could have external consequences, show "Human approval required" with Approve, Reject, and Edit.
• C-2 (explicit): For V1, keep actual execution simulated: do not send emails, publish content, make purchases, or perform external actions automatically.
• C-3 (explicit): The Orchestrator should not perform every task itself.
• C-4 (explicit): The Research Agent must never present an assumption as a verified fact; verified information, assumptions, and unknown information must be clearly distinguished.
• C-5 (explicit): The Critic must not simply agree with the other agents.
• C-6 (explicit): Do not add authentication yet.
• C-7 (explicit): Do not add payment systems.
• C-8 (explicit): Do not add subscriptions.
• C-9 (explicit): Do not add unnecessary features.
• C-10 (explicit): No unnecessary backend for V1; local persistence is acceptable for demo projects.
• C-11 (explicit): The application must work even without an AI API key.
• C-12 (explicit): Do not put the entire application into one giant component.
• C-13 (explicit): Avoid excessive animations.
• C-14 (explicit): Avoid making it look like a generic ChatGPT clone.
• C-15 (explicit): Do not over-engineer it.
• C-16 (creative direction): No blue or indigo in the primary/accent range; the project is graphite plus tangerine plus mint only.
• C-17 (creative direction): Banned fonts as heading or body font: Inter, Roboto, Arial, Helvetica, Open Sans, Lato, Poppins, system-ui.
• C-18 (creative direction): No gradient-blob heroes, glassmorphism/frosted panels, or soft multi-colour gradients; no grid of identical hover-lift cards with drop shadows; no pure white text on pure black or pure black panels on pure white.
• C-19 (creative direction): No decorative looping animation, particles, 3D scenes, or bounce easing.
• C-20 (creative direction): Presenting an assumption with the same visual weight as a verified fact is forbidden; the tag colours must never be used decoratively.

Future Requirements (out of scope for current V1)

• F-1: Connecting real AI providers. The code is structured so real AI providers can be connected later, but no real provider is required for V1.
• F-2: Real execution of externally consequential actions. In V1, execution is simulated; real execution is future work and remains gated behind human approval.

12. Glossary

• Agent: One of the four V1 system actors — Orchestrator, Research, Finance, Critic — that perform work on a project. Agents are not human personas.
• Agent Card: A visual card for an agent containing agent name, role, status, current task, progress, latest finding, and a View details button, with distinct visual states for Working, Completed, Waiting, Needs approval, and Error.
• Approval Gate: The "Human approval required" panel shown before an action that could have external consequences, offering Approve, Reject, and Edit.
• Artifact: A structured output produced by an agent. The five artifact sections are Market Research, Financial Analysis, Risk Review, Business Blueprint, and Action Plan. Each artifact is readable and editable by the user.
• Assumption: A claim that is not verified. Assumptions are tagged as assumptions and must never be presented as verified facts.
• Business Blueprint: The final combined output containing Business Concept, Target Customer, Problem, Product/Service, Market Findings, Financial Overview, Risks, Validation Plan, and Action Plan.
• Business Idea Owner: The single active human persona — the person with a business idea or goal who creates a project, starts the AI team, inspects outputs, reviews the blueprint, and approves, rejects, or edits proposed next actions.
• Critic Agent: The agent that reviews other agents' outputs, detects unsupported assumptions, identifies missing information, contradictions, and risks, and suggests questions needing human verification. It must not simply agree with the other agents.
• Demo Mode: The fully functional mode using realistic mock AI responses that lets the application work without an AI API key, simulating Orchestrator → Research → Finance → Critic → Blueprint with visible progress and agent status changes.
• Finance Agent: The agent that estimates startup and recurring costs, suggests a basic pricing structure, calculates simple revenue scenarios and break-even estimates when enough information is available, and identifies the assumptions behind its calculations.
• Human Approval: The required human decision before any action that could have external consequences. In V1, execution is simulated.
• Orchestrator Agent: The agent that understands the goal, breaks it into smaller tasks, decides which specialized agent handles each task, tracks overall project progress, and combines agent outputs into a coherent result. It does not perform every task itself.
• Project: A unit of work created from a project name, business idea/goal, available budget, target location, optional target customer, and optional additional context.
• Research Agent: The agent that analyzes the target market, identifies potential customers, competitors or alternatives, and relevant market assumptions, and collects findings and sources when web research is available, clearly distinguishing verified information, assumptions, and unknown information.
• Unknown: Information that is not known. Unknowns are tagged as unknown and are distinct from both verified information and assumptions.
• Verified Information: Information supported by a source. Verified facts are tagged as verified and are visually distinct from assumptions and unknowns.
• Workflow: The multi-agent pipeline User Goal → Orchestrator → Research + Finance → Critic → Business Blueprint → Human Approval → Action Plan.