Product intent in. Working software out.
The Agent² Software Factory is autonomous software delivery: people express outcomes and grant approval, and AI agents do the design, planning, implementation, review and release.
A standing factory, not a one-off generation #
Software delivery is still largely a hand craft, and it scales the way hand crafts do, by hiring. The bottleneck is not typing code, it is the chain of judgement, coordination and verification around it. The difference between a coding assistant and a factory is exactly that chain: an assistant produces a suggestion, while a factory orders the work so it can be built safely in parallel, proves each piece against real deployments, promotes it, and then watches it in production.
It is also reflexive. Agentycs is built by exactly this machinery, which means production signals, live-test regressions and delivery telemetry come back in as new, structured work. Defects, drift and regressions become tasks the factory plans and fixes without anyone filing them.
Agents are interchangeable and disposable. The plan, the dependency graph, the quality gates and the event-sourced release path are the durable parts.
How the factory works #
A pipeline with fail-closed gates, not one very capable agent. Each stage hands the next a structured artefact rather than a conversation.
-
Intent becomes a specification #
Requests and desired outcomes are captured in plain language with their provenance and business context. Agents interview the requester only on the genuine product and architectural forks, then synthesise a structured brief of goals, scope, constraints and acceptance criteria. That brief is the contract every later stage builds against.
-
Competing designs, adversarially scored #
Independent agents generate rival approaches from different angles, risk-first, simplicity-first and reuse-first, rather than iterating one guess. A judge panel scores them for correctness, security, fit to established patterns and blast radius, and the chosen design and its rationale are recorded as a durable decision record.
-
One plan the whole fleet works from #
The design becomes a hierarchy of streams, milestones, phases and work items, each the smallest safe unit of change with explicit acceptance criteria and modelled dependencies. Unique identity, ordering, acyclicity and reference resolution are enforced on every write, and any write that would violate the model is rolled back.
-
Agents claim, build and prove #
An agent claims the next dependency-ready task atomically, works in its own isolated workspace, and cannot advance past a gate that is not green: repository validation, automated tests, adversarial code and security review, then live tests against actually deployed services with request, trace, log and metric diagnostics attached.
-
Release, observe, and feed it back #
Immutable artefacts are promoted by declaring desired state, with convergence waited on rather than assumed, canary rollout and automatic rollback. Alerts, regressions and drift then arrive as structured work items, so production writes the next batch of the plan.
In more detail #
The full machinery, grouped by the job it does.
Intake and design
The single front door, and how a decision survives the person who made it.
- Intent capture and elicitation
- A durable intake of requests and desired outcomes in plain language, with provenance, priority and business context, followed by an interview that covers the genuine forks and skips the boilerplate.
- Specification synthesis
- A structured brief of goals, scope, constraints, acceptance criteria and the surface affected. It is the contract every later stage builds against.
- Adversarial design review
- Independent agents generate competing approaches and a judge panel scores them for correctness, security, fit to established patterns and blast radius, then synthesises the strongest design from the field.
- Decision records and architecture model
- The chosen design and its rationale are captured as referenceable decision records, and the architecture model is regenerated continuously from the real subsystems so the system's description of itself stays true by construction.
Implementation planning
A fully ordered, dependency-aware plan that is validated structurally rather than reviewed by eye.
- Decomposition
- A design becomes a hierarchy of streams, milestones, phases and work items, each the smallest safe unit of change with explicit acceptance criteria.
- Dependency graph
- Inter-task dependencies are modelled with cycle detection and forward-only ordering, so readiness is computed and provable rather than guessed.
- Validation on every write
- Unique identity, ordering, acyclicity, reference resolution and structured work-item rules are enforced intrinsically, and any write that would violate the model is rolled back.
- Projection to the board
- The validated plan is projected onto the task board the fleet claims from, keeping the plan and its execution one and the same thing.
Orchestration and workforce
Who is building what, what they may start next, and where they build it.
- Worker registry and atomic claim
- First-class records for every agent worker, its harness, current model, status and active task, and an atomic claim of the next dependency-ready task so no two agents collide and no blocked work is ever started.
- Autonomous distribution
- A dispatcher assigns and rebalances work across the fleet from priority, blockers, focus and worker history, and runs leader-only across the cluster.
- Isolated workspaces
- Per-agent worktrees and reproducible development environments, so many agents build in parallel without interfering with one another.
- Session capture
- Every session, its turns, tool calls, model, tokens, cost and outcome, streams into a durable, queryable timeline for audit and improvement.
Layered quality gates
Nothing ships unproven. Each layer must be green before the next one runs.
- Repository validation
- Configuration, dependency-graph, schema, contract and lint checks: fast, deterministic gates that fail closed on any drift.
- Automated testing
- Unit and integration tests run on every change as the first proof of correctness.
- Code and security review
- Adversarial review agents hunt correctness bugs, simplifications and security issues, defaulting to refute-and-verify rather than rubber-stamp.
- Live testing
- Declared suites run against actually deployed services in production-like environments, with request, trace, log and metric diagnostics attached. This is the proof a feature truly works.
Integration and release
Parallel agent work integrates continuously and promotes immutably, gated on real outcomes rather than on elapsed time.
- Structured branch model
- A three-tier hierarchy from task to story to the shared integration line keeps parallel work isolated while it continuously integrates, with changes shepherded and merged through scripted, idempotent steps.
- Artefact-driven promotion
- Immutable build artefacts are promoted across environments by declaring desired state, so what was tested is exactly what ships.
- Convergence waits
- Deployment events are subscribed to and waited on, so deployed means observed-healthy rather than fire-and-forget.
- Canary and rollback
- Progressive rollout with automatic rollback the moment health or live tests regress.
Feedback and self-correction
The loop that closes the factory back on itself and makes it improve.
- Observability feedback
- Dashboards, alerts and metrics from running software surface regressions and operational risk as first-class signals into planning.
- Defect capture
- Failures and live-test regressions are captured as structured defects and fed back into the plan automatically.
- Drift detection
- Divergence between the plan, architecture, contracts and documentation, and reality, is detected, and corrective work is opened to close the gap.
- Retrospectives
- Captured sessions and delivery telemetry are mined to improve prompts, rules and process over time. The factory learns from its own output.
What it changes #
Four things it changes about how software arrives.
Execution compresses, judgement does not
Our founder's claim for the factory is blunt: a one-year team project becomes a one-week automated delivery. It is a statement of what the machinery is for rather than a measured benchmark. What it does not compress is deciding what to build, which is why the intake stage puts the genuine forks to a person and why acceptance of the result stays with people.
The backlog stops being a queue
Work is claimed as soon as its dependencies are ready, in parallel, by as many agents as you have capacity for.
Verification moves left and gets harder
Every change is tested against real deployments before promotion, because the pipeline will not advance without it. Gates prove the declared checks pass; they cannot prove the specification was the right one.
Production feeds the plan
Alerts, regressions and drift arrive as structured work items rather than as tickets somebody has to write.
The substrate it runs on #
Shared fabric every stage uses, which is also what makes the pipeline auditable end to end.
- One command line
- An event substrate
- A living knowledge base
- The delivery board
What each interface gives you
- One command line
- A single toolchain to scaffold, validate, plan, merge, deploy and wait, through which agents and people operate the whole factory.
- An event substrate
- Source control, deployment, registry, cluster, live-testing and migration events normalised into one stream, so every automated step waits on real outcomes rather than assumptions.
- A living knowledge base
- Repository rules, per-stage operating reminders, feature catalogues, decision records and the architecture model, generated and validated so agents never work from stale guidance.
- The delivery board
- Epics, stories and tasks projected from the validated plan, with worker registry, claims, dependencies and throughput all queryable, and every agent session retained as a durable timeline.
See what autonomous delivery looks like
Agentycs is pre-revenue and signing its first deals with its first customers, so the working example we can show you today is our own: this platform is built by the factory that runs on it. Bring us a real piece of work from your backlog and we will walk you through how it would be taken from intent to a verified release.