System Requirements Document for 8080-ai-agentic

1. Introduction

8080.ai Agentic AI factory is a working environment where AI agents are configured and run to produce output. It is not a marketing site about agents and not a chat toy: it is a production line for agentic work, with a builder side that defines and configures the agents the factory runs, and an operator side that launches runs from those agents and follows them through to completed output.

The product intent derived from the authoritative requirement thread is: build a product named 8080.ai Agentic AI factory, where agents are configured and run to produce output. Everything in this document serves that intent and nothing beyond it.

The audience is technical, opinionated, and fluent in developer culture. They distrust marketing varnish and expect tools that behave like instruments with a strong point of view. The interface is therefore an industrial operator console — loud, mechanical, legible — rather than a hushed SaaS dashboard.

2. System Overview

8080.ai Agentic AI factory is delivered as a first-party custom web application with application-owned identity. Two active human roles use it:

• Agent Builder — defines and configures the durable agent definitions the factory runs.
• Factory Operator — starts factory runs from configured agents and follows each run through execution to its completed result.

The current delivery shape is a custom UI backed by application-owned identity and backend integration. Anonymous visitors can read the Landing surface. Self-service enrollment (Sign Up) and returning identity verification (Login) establish the identity that binds agent definitions and runs to the correct person. Agents and Agent Details are the builder's working surfaces; Runs and Run Details are the operator's working surfaces. Role-aware authorization distinguishes builder configuration work from operator run work.

Narrow exclusions for the current horizon: no marketplace, no billing or credit purchase, no team/organization administration, no third-party provider-owned identity, no invitation or provisioning flow, and no agent-to-agent orchestration designer beyond configuring an individual agent's setup. These are not current capabilities and must not be built.

2a. Product Interpretation and Delivery Boundary

The product is a factory, and the delivery boundary follows the production line. The first-party application owns the whole current experience: the public entry that explains what the factory is, the identity surfaces that let a self-starting person enroll and a returning person verify themselves, the builder surfaces where agents are defined and configured, and the operator surfaces where runs are launched and followed to completion.

Identity is application-owned. There is no invitation, provisioning, provider, or pre-existing-account boundary established anywhere in the source, so a person who wants to use the factory starts by enrolling themselves. The Landing surface is anonymous and readable without identity. Everything that touches durable factory state — agent definitions and factory runs — requires verified identity, and the work a person does there stays bound to that person.

Authorization is role-aware rather than uniformly open: builder configuration work and operator run work are distinguished. This is not a general permission-management system; it is the minimum distinction needed so that configuring an agent and running the factory are correctly attributed and correctly reachable.

Future horizons are kept out of the current build. Anything not listed as current in this document is not part of the delivered product.

2b. Source Content Inventory

Not applicable. No reference directive in this request declares a content_source, so no source content inventory is produced.

2c. Page Content and Component Coverage

The page contract is versioned and final. The following seven pages are the complete, ordered information architecture, with their access and identity ownership as given.

Landing

• Information and state: Anonymous public entry. Explains 8080.ai as an agentic AI factory where agents are configured and runs produce output. No durable factory state is shown; no run or agent data is exposed to an anonymous visitor.
• Primary actions: Enter the identity flow toward Sign Up (start using the factory) and toward Login (return to the factory).
• Supporting actions: Read the explanation of what the factory does; move between the explained concepts (configure agents, run the factory, produce output).
• Domain entities: None persisted. The page presents the product concept only.
• Component responsibilities: Full-viewport poster hero carrying the stacked display headline block; the rotated 8080 wordmark rail; the live-run ticker band; the two entry CTAs; the section flags that announce the factory's parts.
• States: Loading — not applicable, the page is static content. Empty — not applicable. Success — the page renders fully and both entry CTAs are reachable. Error — if the entry CTAs cannot resolve, the page still renders its explanation and the failure is surfaced without blocking reading. Recovery — the visitor can retry the entry action or continue reading.

Login

• Information and state: Anonymous identity-verification surface for returning Factory Operators and Agent Builders. Holds the entered credentials and the verification state; holds no durable factory state.
• Primary actions: Verify returning identity and proceed into the factory.
• Supporting actions: Move to Sign Up when the visitor does not yet have identity; correct an entry mistake.
• Domain entities: The person's application identity and its verification result.
• Component responsibilities: Credential entry controls; submit control; the link across to enrollment; the inline verification feedback region.
• States: Loading — verification in progress, submit disabled and progress indicated. Empty — no credentials entered yet, submit unavailable. Success — identity verified, the person is taken into the factory with their own agents and runs reachable. Error — credentials rejected, a clear message is shown, entered values are preserved for correction, and no factory state is revealed. Recovery — the person can correct and resubmit, or move to Sign Up.

Sign Up

• Information and state: Anonymous self-service enrollment surface for a person independently starting as a Factory Operator or Agent Builder. Holds the enrollment input and the enrollment result; holds no durable factory state.
• Primary actions: Establish a new application identity and enter the factory.
• Supporting actions: Move to Login when identity already exists; correct an entry mistake.
• Domain entities: The newly established application identity.
• Component responsibilities: Enrollment input controls; submit control; the link across to Login; the inline enrollment feedback region.
• States: Loading — enrollment in progress, submit disabled and progress indicated. Empty — no enrollment input yet, submit unavailable. Success — identity established, the person enters the factory and can begin configuring agents or starting runs. Error — enrollment rejected (for example, the identity is already taken or input is invalid), a clear message is shown, entered values are preserved for correction, and no factory state is created. Recovery — the person can correct and resubmit, or move to Login.

Agents

• Information and state: Identity-required, role-restricted builder surface. Shows the durable agent definitions that the factory runs, as a browsable collection owned by the signed-in Agent Builder. Each entry carries the agent's name and its configuration metadata.
• Primary actions: Open an agent to view or edit its configuration; begin creating a new agent.
• Supporting actions: Scan and compare agents across the collection; identify which agents are available to be run.
• Domain entities: Agent definition (name, configuration metadata, availability for runs).
• Component responsibilities: The agent plate list — wide horizontal slabs with the agent name set large on the left and a ruled metadata column on the right; the create-agent entry point; the collection-level empty and error regions.
• States: Loading — the collection is being retrieved, with the list region indicating progress. Empty — the builder has no agents yet, with a clear prompt to create the first one. Success — the collection renders as agent plates with their metadata. Error — the collection cannot be retrieved, a clear message is shown, and the builder can retry. Recovery — retry the retrieval; if an individual agent is unavailable, the rest of the collection remains usable.

Agent Details

• Information and state: Identity-required, role-restricted builder surface for a single agent. Holds that agent's configuration — its name and the setup that determines how it behaves when the factory runs it — and whether the agent is available to be run.
• Primary actions: Create a new agent's configuration; edit an existing agent's configuration; save the configuration.
• Supporting actions: Discard unsaved changes; return to the agent collection.
• Domain entities: Agent definition (name, configuration fields, availability for runs).
• Component responsibilities: The configuration form with its named fields; the save and discard controls; the validation feedback region; the agent identity header.
• States: Loading — an existing agent's configuration is being retrieved, with the form indicating progress. Empty — a new agent with no configuration entered yet, with the form ready for input. Success — the configuration is saved and the agent is available to be run; confirmation is shown. Error — validation fails or the save is rejected, the specific problem is shown against the offending field, entered values are preserved, and the agent is not left in a partially saved state. Recovery — correct the indicated problem and save again, or discard and return to the collection.

Runs

• Information and state: Identity-required, role-restricted operator surface. Shows the collection of factory runs belonging to the signed-in Factory Operator, each with the agent it was started from, its status, and its progress. Also holds the selection of which configured agent to run.
• Primary actions: Start a factory run from a configured agent; open an individual run to follow it.
• Supporting actions: Scan the run ledger and compare runs by status and progress; identify which runs are still in progress and which have completed.
• Domain entities: Factory run (originating agent, status, progress, start time, result availability); the set of configured agents available to run.
• Component responsibilities: The run ledger — ruled rows with tabular numerals, each row carrying a status chip plus word; the start-a-run control with its agent selection; the collection-level empty, loading, and error regions.
• States: Loading — the run collection is being retrieved, with the ledger indicating progress. Empty — the operator has no runs yet, with a clear prompt to start the first one from a configured agent. Success — the ledger renders runs with their status and progress, and a newly started run appears in it. Error — the collection cannot be retrieved, or a run cannot be started (for example, no configured agent is available), with a clear message and a retry path. Recovery — retry the retrieval or the start; the rest of the ledger remains usable.

Run Details

• Information and state: Identity-required, role-restricted operator surface for a single factory run. Holds that run's originating agent, its current status, its progress through execution, and its completed result once execution finishes.
• Primary actions: Follow the run through execution; inspect the completed result.
• Supporting actions: Return to the run ledger; re-check the run's state.
• Domain entities: Factory run (originating agent, status, progress, result output, failure information).
• Component responsibilities: The run status and progress region; the result output region; the failure and recovery region; the run identity header.
• States: Loading — the run's current state is being retrieved, with the detail region indicating progress. Empty — the run has not yet produced output, with its in-progress state shown clearly rather than an empty result. Success — the run completes and its result output is displayed and readable. Error — the run fails, with the failure clearly stated and the run's status reflecting the failure rather than appearing complete. Recovery — the operator can re-check the run's state, and can return to the ledger to start a new run from a configured agent.

3. Functional Requirements

FR-1 — Product identity As a visitor, I should encounter a product named 8080.ai Agentic AI factory, so that I know what I am looking at.

• Provenance: explicit.
• Lifecycle: initiated by the visitor arriving; observable result is the product's name and purpose presented on the Landing surface; no durable state changes.
• Acceptance: the Landing surface presents 8080.ai as an agentic AI factory.

FR-2 — Understand the factory As a visitor, I should understand that this is an agentic AI factory — a working environment where AI agents are configured and run to produce output — so that I can decide whether to start using it.

• Provenance: explicit.
• Lifecycle: initiated by the visitor reading the Landing surface; observable result is comprehension of the configure-agents / run-the-factory / produce-output model; no durable state changes.
• Acceptance: the Landing surface explains configuring agents and running them to produce output, and offers entry into the factory.

FR-3 — Self-service enrollment As a person starting independently as a Factory Operator or Agent Builder, I should be able to enroll myself, so that I can begin using the factory without an invitation or provisioning step.

• Provenance: required_inference (required to make the accepted current journeys executable; no invitation, provisioning, provider, or pre-existing-account boundary is established).
• Lifecycle: initiated by the person on the Sign Up surface; input is their enrollment details; observable result is an established application identity; material failure is a rejected enrollment (identity already taken, invalid input), which is reported with entered values preserved and no factory state created; continuation is entry into the factory.
• Access state: anonymous entry; the enrollment interaction itself is reachable without identity.
• Acceptance: a person with no prior identity can establish one and enter the factory.

FR-4 — Returning identity verification As a returning Factory Operator or Agent Builder, I should verify my identity before reaching my configured agents or factory runs, so that my durable factory state stays bound to me.

• Provenance: required_inference (required to make the accepted current journeys executable and to keep durable state bound to the correct participant).
• Lifecycle: initiated by the person on the Login surface; input is their credentials; observable result is verified identity and access to their own agents and runs; material failure is rejected credentials, reported clearly with no factory state revealed and entered values preserved; continuation is entry into the factory.
• Access state: anonymous entry; protected factory state remains unavailable until identity is verified.
• Acceptance: unverified visitors cannot reach agent definitions or factory runs; verified people reach their own.

FR-5 — Role-aware authorization As the product, I should distinguish Factory Operator run work from Agent Builder configuration work, so that each role reaches the work it is responsible for.

• Provenance: required_inference (required to keep configuration work and run work correctly attributed and correctly reachable).
• Lifecycle: applied when a verified person navigates to a factory surface; observable result is that builder surfaces serve configuration work and operator surfaces serve run work; material failure is a person reaching a surface their role does not cover, which is refused without exposing the underlying state; continuation is navigation to a surface their role does cover.
• Access state: identity required; role-restricted on Agents, Agent Details, Runs, and Run Details.
• Acceptance: Agents and Agent Details serve Agent Builder configuration work; Runs and Run Details serve Factory Operator run work.

FR-6 — Browse agent definitions As an Agent Builder, I should browse the durable agent definitions the factory runs, so that I can see what is available and choose one to work on.

• Provenance: required_inference (the factory runs configured agents; the builder needs the collection to manage them).
• Lifecycle: initiated by the Agent Builder on the Agents surface; observable result is the collection of their agent definitions with their metadata; material failure is the collection failing to load, reported with a retry path; continuation is opening an agent or starting a new one.
• Access state: identity required; role-restricted to Agent Builder.
• Acceptance: the builder sees their agent definitions as a browsable collection; an empty collection prompts creating the first agent.

FR-7 — Create an agent configuration As an Agent Builder, I should create an individual agent's configuration, so that the factory has an agent it can run.

• Provenance: required_inference (the factory runs configured agents; a new agent must be definable).
• Lifecycle: initiated by the Agent Builder on Agent Details; input is the agent's name and configuration fields; observable result is a saved agent definition available to be run; material failure is validation failure or a rejected save, reported against the offending field with entered values preserved and no partially saved agent; continuation is returning to the collection or continuing to edit.
• Access state: identity required; role-restricted to Agent Builder.
• Acceptance: a new agent can be configured and saved, and then appears in the collection and is available to run.

FR-8 — Edit an agent configuration As an Agent Builder, I should edit an existing agent's configuration, so that I can iterate on its setup until the factory produces usable results.

• Provenance: required_inference (the builder iterates on agent setup).
• Lifecycle: initiated by the Agent Builder opening an agent from the collection; input is the changed configuration fields; observable result is the updated agent definition used by subsequent runs; material failure is validation failure or a rejected save, reported against the offending field with entered values preserved; continuation is returning to the collection or continuing to edit.
• Access state: identity required; role-restricted to Agent Builder.
• Acceptance: an existing agent's configuration can be changed and saved, and the change is reflected in the agent's definition.

FR-9 — Start a factory run As a Factory Operator, I should start a factory run from a configured agent, so that the factory produces output.

• Provenance: required_inference (the operator's primary accepted work is starting and following runs).
• Lifecycle: initiated by the Factory Operator on the Runs surface; input is the selection of a configured agent; observable result is a new run in progress, appearing in the ledger; material failure is no configured agent being available or the start being rejected, reported clearly with a retry path; continuation is following the run.
• Access state: identity required; role-restricted to Factory Operator.
• Acceptance: selecting a configured agent and starting produces a new run that appears in the operator's ledger with a status.

FR-10 — Review the run collection As a Factory Operator, I should review the collection of my runs and their progress, so that I can see what is in flight and what has completed.

• Provenance: required_inference (the operator monitors progress toward completed output).
• Lifecycle: initiated by the Factory Operator on the Runs surface; observable result is the ledger of their runs with status and progress; material failure is the collection failing to load, reported with a retry path; continuation is opening an individual run.
• Access state: identity required; role-restricted to Factory Operator.
• Acceptance: the operator sees their runs as a ledger with status shown as a chip plus word and progress visible; an empty ledger prompts starting the first run.

FR-11 — Follow a run through execution As a Factory Operator, I should follow an individual factory run through execution, so that I can see where it is and whether it is still working.

• Provenance: required_inference (the operator follows runs through execution).
• Lifecycle: initiated by the Factory Operator opening a run from the ledger; observable result is that run's current status and progress on Run Details; material failure is the run's state failing to load, reported with a re-check path; continuation is inspecting the result or returning to the ledger.
• Access state: identity required; role-restricted to Factory Operator.
• Acceptance: an individual run's status and progress are visible and update as the run proceeds.

FR-12 — Inspect a completed run's result As a Factory Operator, I should inspect a completed run's result, so that I obtain the output the factory produced.

• Provenance: required_inference (the accepted outcome is produced output).
• Lifecycle: initiated by the Factory Operator on Run Details once execution finishes; observable result is the run's result output displayed and readable; material failure is the run failing, with the failure clearly stated and the run's status reflecting the failure rather than appearing complete; continuation is returning to the ledger to start another run.
• Access state: identity required; role-restricted to Factory Operator.
• Acceptance: a completed run's result is displayed; a failed run is clearly marked as failed and does not present as completed output.

4. User Personas

Factory Operator

Product context. The Factory Operator is the person who runs the factory. Their relationship to the product is with individual runs: they take an agent that has already been configured, launch it, and watch the production line move until output comes out the other end. They are not there to design agents; they are there to get work produced and to know the state of that work at any moment.

Primary goal. Start factory runs from configured agents and follow each one through execution to its completed result.

Distinct accepted responsibilities. Selecting a configured agent and starting a run; reviewing the collection of their runs and their progress; following an individual run through execution; inspecting a completed run's result; recognizing and responding to a failed run.

Relevant inputs and decisions. Which configured agent to run; whether a run is still in progress or has finished; whether a finished run produced usable output or failed.

Interactions with other accepted participants. The Factory Operator depends on the Agent Builder's work: a run can only be started from an agent that has been configured. The operator does not configure agents themselves; when no configured agent is available, that is the boundary of their work and the reason they cannot start a run.

Observable success. A run they started appears in their ledger with a status, progresses, and reaches a completed result they can read — or fails in a way that is clearly stated rather than disguised as completion.

What makes this role different. The operator's unit of work is the run, not the agent. Their state is temporal and in-flight: they care about what is happening now and what has finished. Their surface is a ledger of executions, and their success is measured in produced output.

Agent Builder

Product context. The Agent Builder is the person who defines what the factory's workers are. Their relationship to the product is with durable agent definitions: they create an agent, give it its configuration, and iterate on that setup so that when the factory runs it, the output is usable. They work on the definition, not on any individual execution of it.

Primary goal. Define and configure the agents the factory runs, iterating on their setup until the factory produces usable results.

Distinct accepted responsibilities. Browsing the collection of durable agent definitions; creating a new agent's configuration; editing an existing agent's configuration; saving configuration changes; recognizing and correcting configuration problems.

Relevant inputs and decisions. The agent's name and its configuration fields; whether a configuration is complete and valid enough to save; whether an existing agent's setup needs to change.

Interactions with other accepted participants. The Agent Builder produces the agents that the Factory Operator runs. Their work is upstream of the operator's: an agent that has been configured and saved becomes available to be run, and an agent left unconfigured is not.

Observable success. A saved agent definition appears in their collection, carries its configuration, and is available to be run by the factory.

What makes this role different. The builder's unit of work is the definition, not the execution. Their state is durable and persistent across runs: they change an agent once and every subsequent run uses the changed setup. Their surface is a collection of plates and a configuration form, and their success is measured in whether the factory's output is usable.

5. Core User Flows

Flow A — A person starts using the factory for the first time (Factory Operator or Agent Builder)

1. The person arrives at the Landing surface with no identity. The surface presents 8080.ai as an agentic AI factory: agents are configured, runs are started, output is produced.
2. The person reads the explanation and decides to start. They choose the entry action toward enrollment.
3. The person lands on Sign Up, an anonymous surface. They enter their enrollment details.
4. The person submits. The surface shows enrollment in progress with the submit control unavailable.
5. Success: an application identity is established and the person enters the factory. They can now reach the surfaces their role covers.
6. Failure: enrollment is rejected — for example the identity is already taken or the input is invalid. The surface states the problem clearly, preserves what was entered, and creates no factory state. The person corrects the input and resubmits, or moves to Login if they already have identity.
7. Continuation: the person proceeds to configure an agent (Flow C) or to start a run (Flow D), depending on their role.

Flow B — A returning person verifies identity (Factory Operator or Agent Builder)

1. The person arrives at the Landing surface and chooses the entry action toward verification.
2. The person lands on Login, an anonymous surface. They enter their credentials.
3. The person submits. The surface shows verification in progress with the submit control unavailable.
4. Success: identity is verified and the person enters the factory with their own agent definitions and runs reachable. No one else's factory state is exposed.
5. Failure: the credentials are rejected. The surface states the problem clearly, preserves what was entered, and reveals no factory state. The person corrects and resubmits, or moves to Sign Up.
6. Continuation: the person proceeds to their role's work — configuring agents (Flow C) or starting and following runs (Flow D).

Flow C — An Agent Builder creates a new agent

1. The Agent Builder is verified and enters the factory. They navigate to Agents, their role-restricted builder surface.
2. Agents loads the collection of their durable agent definitions as wide horizontal plates, each with the agent name set large on the left and its metadata in a ruled column on the right.
3. Empty state: the builder has no agents yet. The surface prompts them to create the first one. The builder takes the create action.
4. The builder arrives at Agent Details for a new agent. The configuration form is ready for input.
5. The builder enters the agent's name and its configuration fields.
6. The builder saves. The surface shows the save in progress.
7. Success: the configuration is saved, confirmation is shown, and the agent is available to be run. The builder returns to Agents, where the new agent now appears in the collection.
8. Failure: validation fails or the save is rejected. The specific problem is shown against the offending field, the entered values are preserved, and the agent is not left partially saved. The builder corrects the field and saves again, or discards and returns to the collection.
9. Continuation: the builder may open another agent to edit it (Flow D), or the configured agent is now available for a Factory Operator to run (Flow E).

Flow D — An Agent Builder iterates on an existing agent's configuration

1. The Agent Builder is verified and on Agents. They open an existing agent from the collection.
2. Agent Details loads that agent's current configuration into the form.
3. The builder changes the configuration fields that determine how the agent behaves when the factory runs it.
4. The builder saves. The surface shows the save in progress.
5. Success: the updated configuration is saved and confirmation is shown. Subsequent factory runs use the updated setup.
6. Failure: validation fails or the save is rejected. The problem is shown against the offending field, entered values are preserved, and the previously saved configuration is not corrupted. The builder corrects and saves again, or discards the changes and returns to the collection.
7. Continuation: the builder returns to Agents to continue working across the collection.

Flow E — A Factory Operator starts a factory run

1. The Factory Operator is verified and enters the factory. They navigate to Runs, their role-restricted operator surface.
2. Runs loads the ledger of their factory runs as ruled rows with tabular numerals, each row carrying a status chip plus word.
3. The operator takes the start-a-run action and selects a configured agent from the available set.
4. The operator confirms the start.
5. Success: a new run is created and appears in the ledger with a status, in progress. The operator can open it.
6. Failure: no configured agent is available, or the start is rejected. The surface states the problem clearly and offers a retry path. The operator retries, or waits for an agent to be configured.
7. Continuation: the operator opens the new run (Flow F).

Flow F — A Factory Operator follows a run through execution to its result

1. The Factory Operator is on Runs and opens an individual run from the ledger.
2. Run Details loads that run's originating agent, its current status, and its progress through execution.
3. The operator follows the run. The status and progress region reflects where the run is; while the run is in progress the result region shows the in-progress state rather than an empty result.
4. Success: execution finishes and the run's result output is displayed and readable. The operator inspects the output.
5. Failure: the run fails. The failure is clearly stated and the run's status reflects the failure rather than appearing complete; no output is presented as a successful result. The operator can re-check the run's state.
6. Failure (state retrieval): the run's current state cannot be loaded. The surface states the problem and offers a re-check path; the operator can return to the ledger.
7. Continuation: the operator returns to Runs to review the ledger and start another run from a configured agent.

Flow G — A Factory Operator reviews the run collection

1. The Factory Operator is verified and navigates to Runs.
2. The ledger loads their runs as ruled rows, each with the originating agent, a status chip plus word, and progress.
3. The operator scans the ledger to distinguish runs still in progress from runs that have completed.
4. Empty state: the operator has no runs yet. The surface prompts them to start the first one from a configured agent.
5. Failure: the ledger cannot be retrieved. The surface states the problem and offers a retry; the operator retries.
6. Continuation: the operator opens a run of interest (Flow F) or starts a new one (Flow E).

6. Visuals Colors and Theme

The creative direction is authoritative for this section. The muse is Paula Scher, and the headline idea is typography as the factory floor: words as architecture, colour-blocked zones, hard edges, systems that shout their structure. An agentic AI factory is a production line — inputs, workers, runs, output — and Scher turns a production line into a poster. The register is industrial confidence with wit: loud, mechanical, legible, never a hushed SaaS dashboard.

Colour tokens

Dark mode (primary mode):

Proportion: approximately 80% ink ground, 12% red, 6% yellow, 2% teal/cobalt tags. Colour is wayfinding, never decoration. Body text #F4F1E8 on #0E0E0C and on #171714 passes contrast comfortably; muted #8A857A is reserved for metadata at 14px and above.

Typography

• Headings: Anton, all caps, tracking -0.01em, leading 0.86, stacked into solid blocks that span the viewport edge-to-edge. Headlines are the largest element on every page and may sit over colour bands.
• Body: Archivo at 400/500/700 with slightly tightened tracking.
• Labels, status, metrics: Archivo at 12px uppercase with 0.14em tracking, so data reads like signage.
• Data numerals: 15px tabular.

Type scale — 1.25 modular with display exceptions:

Shape language

Hard edges everywhere: 0px radius on panels, buttons, inputs, and cards. Structure comes from 2px and 4px ink rules, colour-block bands that bleed to the viewport edge, and diagonal 6-degree separators between major sections. Buttons are solid rectangles of red or yellow with black uppercase labels. The only round object in the entire system is the live-run status dot.

Layout

A 12-column poster grid with a fixed left rail (72px on desktop, a bottom bar on mobile) carrying the 8080 wordmark rotated 90 degrees and the primary nav. Sections are announced by full-bleed colour bands with an oversized number-and-name flag (01 / AGENTS) that runs off the right edge. Dashboards are dense tabular ledgers: runs listed as ruled rows with tabular numerals, status shown as a colour chip plus word, never a coloured dot alone. Agents are browsed as a stacked list of wide horizontal plates, each with a huge Anton agent name on the left and its model/tool metadata in a right-hand ruled column. On mobile everything collapses to one column, colour bands stay full-bleed, and the oversized flags wrap to two lines rather than shrinking below 56px.

Imagery

Typography is the imagery. Where a visual is needed it is a high-contrast, two-tone cutout — a duotone red/ink photograph of machinery, a hand, a server rack — cropped hard to the grid and bled off one edge. Diagrams are drawn as thick 2px ink-on-yellow schematics showing agent → tool → run → output chains. No 3D renders, no gradient blobs, no stock people, no glowing particles.

Readability guarantee

Readable text and controls stay whole at every viewport. Headlines, wordmarks, labels, numbers, card 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. Imagery, decoration, and motion may be cropped, bled off an edge, rotated, overlapped, or cut exactly as the direction asks, as long as they cover no readable text or control. Moving and scrollable content (the live-run ticker, horizontally scrollable rows) may cross the viewport or container edge by design and is judged by whether it actually moves and whether every item becomes fully readable as it passes. Under prefers-reduced-motion it stops and shows whole items, wrapping into rows or sitting in a horizontally scrollable row (overflow-x: auto).

The generic indigo/blue-on-white SaaS template is forbidden for this project.

7. Signature Design Concept

The factory poster that is also the console.

The public entry is a full-viewport ink-black poster. The words AGENTIC AI FACTORY are stacked in five lines of Anton at clamp(56px, 11vw, 176px), flush left, each line a different width so the block forms a ragged right edge. The word FACTORY is set in Scher red #E8342A and bleeds past the right viewport edge by design — the word is decorative scale, while the readable headline is the stacked block itself, which stays fully inside the viewport at 375px, 768px, and 1280px.

Beneath the type block sits a solid yellow #F2C200 horizontal band containing a live-run ticker in black uppercase Archivo that scrolls continuously across the full width. To the left, the rotated 8080 wordmark runs vertically along the 72px rail. Two rectangular CTAs — a red Start a run and an outlined Configure an agent — are pinned under the type block, flush left, never centred. No gradient, no illustration, no centred stack.

The concept is implementable with the accepted content and controls only: the headline block, the wordmark rail, the ticker band, the two entry CTAs, and the numbered section flags. It recomposes accepted content and states; it introduces no new behaviour, page, or destination.

8. Interaction Model & Motion Direction

Interaction Model: Animated Motion Tempo: expressive Hero Dimensionality: flat

Landing Hero Motion Brief

Focal subject. The stacked Anton headline block — AGENTIC AI FACTORY in five ragged lines, with FACTORY in Scher red bleeding past the right edge — sitting above the yellow live-run ticker band, with the rotated 8080 wordmark locked in the left rail.

Input → transformation → outcome thesis. On entry, the headline block resolves line by line and the yellow ticker band wipes in from the left edge; the ticker then scrolls continuously, carrying the factory's live-run state as moving type. The visitor's input is arrival and reading; the transformation is the poster assembling itself into a legible factory floor; the outcome is a visitor who understands the product and can reach either entry CTA. No accepted behaviour is added — the ticker carries run state that the product already produces, and the CTAs lead to the accepted identity flow.

Motion vocabulary. Colour-block wipes that slide in from the left edge on section entry (240ms, cubic-bezier(0.2,0.8,0.2,1)); staggered word reveals for display headlines (60ms per line); a horizontal type marquee for the live-run ticker. Hover on a run row floods the row with red and inverts the text. No bounce, no float, no blur.

Composed first frame. Ink-black ground. The five-line Anton block flush left, ragged right, FACTORY in red running off the right edge. The rotated 8080 wordmark vertical along the 72px rail. The yellow ticker band beneath the type block, already scrolling. The red Start a run and outlined Configure an agent CTAs pinned flush left under the block. Nothing centred, nothing floating.

Reduced-motion state. Under prefers-reduced-motion all wipes and reveals resolve instantly, the ticker stops and wraps into static rows showing whole items, and the poster renders as a complete still composition with every readable element whole and inside the viewport.

9. Non-Functional Requirements

NFR-1 — Application-owned identity and durable state binding. Agent definitions and factory runs are durable state bound to the person who created them. Verified identity is required before either is reachable, and one person's factory state is never exposed to another. Provenance: required_inference from the accepted delivery shape (app_owned_identity: true) and the actor-continuity requirement. Rationale: without this binding, a builder's agent definitions and an operator's runs could not be resumed or attributed correctly.

NFR-2 — Role-aware access enforcement. Access to Agents, Agent Details, Runs, and Run Details is role-restricted; Landing, Login, and Sign Up are anonymously reachable. Enforcement happens on the server side of the application, not only in the interface. Provenance: required_inference from the accepted access contract. Rationale: the distinction between builder configuration work and operator run work must hold even if a person navigates directly.

NFR-3 — Backend integration. The product requires backend integration to persist agent definitions and factory runs and to execute runs. Provenance: explicit (requires_backend_integration: true). Rationale: the accepted behaviour is durable and stateful.

NFR-4 — Readability at every viewport. Readable text and controls remain whole and inside the viewport and their container at 375px, 768px, and 1280px. Provenance: explicit creative direction. Rationale: the direction's oversized typography must not cost legibility.

NFR-5 — Reduced-motion compliance. Under prefers-reduced-motion, all wipes and reveals resolve instantly, the ticker stops and wraps into static rows, and every item becomes fully readable. Provenance: explicit creative direction. Rationale: the expressive motion must not be a barrier.

NFR-6 — Contrast. Body text #F4F1E8 on #0E0E0C and #171714 passes contrast comfortably; muted #8A857A is used only for metadata at 14px and above. Provenance: explicit creative direction. Rationale: dense operator consoles fail when metadata becomes unreadable.

NFR-7 — Status is never colour alone. Run status is always shown as a colour chip plus a word, never a coloured dot alone. Provenance: explicit creative direction. Rationale: status must be legible without relying on colour perception.

10. Tech Stack

• Frontend: React, delivered as a custom web UI. Provenance: explicit (custom_ui: true).
• Backend: Python with FastAPI. Provenance: required_inference from the accepted backend integration requirement; no source-specified alternative exists.
• Storage: A persistent datastore appropriate to durable agent definitions and factory runs. Provenance: required_inference from NFR-1 and NFR-3.
• Containerization: Docker and docker-compose for local and single-host operation. Provenance: [Default — not specified by user].
• Orchestration: Kubernetes is not required by any accepted requirement and is therefore not included. Provenance: [Default — not specified by user].

No source-specified technology is replaced or substituted.

11. Assumptions and Constraints

Assumptions

• A-1. A person using the factory does so under one of the two accepted roles, Factory Operator or Agent Builder. Provenance: required_inference from the closed persona catalog.
• A-2. A person may hold builder work, operator work, or both; the role distinction governs which surfaces serve which work, not how many people exist. Provenance: required_inference from the accepted role-aware authorization requirement.
• A-3. A factory run executes against a saved agent definition and produces a result that the operator can read. Provenance: required_inference from the accepted outcome of produced output.
• A-4. Enrollment is self-service because no invitation, provisioning, provider, or pre-existing-account boundary is established anywhere in the source. Provenance: required_inference from the accepted enrollment requirement.

Constraints

• C-1. The current page contract is exactly seven pages: Landing, Login, Sign Up, Agents, Agent Details, Runs, Run Details. No page is added, removed, merged, split, renamed, or reordered.
• C-2. Landing, Login, and Sign Up are anonymously reachable. Agents, Agent Details, Runs, and Run Details require verified identity and are role-restricted.
• C-3. The generic indigo/blue-on-white SaaS template is forbidden. No blue–indigo primary or accent on a white ground; no rounded cards, soft shadows, or hover-lift grids; no gradient blob heroes or glassmorphism; no centred headline + subtext + pill button composition; no Inter, Roboto, Poppins, or DM Sans; no illustrated characters or pastel spot art; no 3D renders, particle fields, or glowing volumetric forms; no coloured status conveyed by a dot alone without a word.
• C-4. The following are outside the current horizon and must not be built: marketplace, billing or credit purchase, team or organization administration, third-party provider-owned identity, invitation or provisioning flows, and agent-to-agent orchestration design beyond configuring an individual agent's setup.

12. Glossary

• Agent definition — the durable, named configuration an Agent Builder creates and edits, which the factory runs. Persists across runs.
• Agent Builder — the accepted active human role that defines and configures the agents the factory runs.
• Factory Operator — the accepted active human role that starts factory runs from configured agents and follows them to completed output.
• Factory run — a single execution of a configured agent, with a status, progress, and a result or failure. The Factory Operator's unit of work.
• Run ledger — the ruled-row collection of a Factory Operator's runs on the Runs surface, with tabular numerals and status shown as a colour chip plus word.
• Agent plate — the wide horizontal slab representing one agent definition on the Agents surface, with the agent name set large on the left and a ruled metadata column on the right.
• Role-restricted — reachable only by a verified person whose role covers that surface's work: Agents and Agent Details for Agent Builder configuration work; Runs and Run Details for Factory Operator run work.
• Section flag — the oversized numbered-and-named announcement (01 / AGENTS, 02 / RUNS) that runs off the right edge of the viewport.
• Live-run ticker — the yellow band on the Landing surface carrying factory run state as continuously scrolling black uppercase type.
• Scher red — #E8342A, the working accent used for run buttons, live-run pulses, the active nav band, and section flags.
• Poster yellow — #F2C200, the second block colour used for status and machine zones.