Define
Start with the note you'd write anyway.
File a GitHub issue with acceptance criteria. Or send the rough idea to Hyper, the chat assistant, and the planner writes the issue.
Evidence-gated software delivery
Different models. One delivery team. The decisions stay yours.
Give Manufactoria a task and say what done looks like. A planner, developer, reviewer and QA carry it to a pull request, each on the model you pick.
More agent chats mean more reports to trust. Here a report can flag a problem, but only a fact the engine checked moves work forward. You decide what merges, by hand or by rules you set.
Bring your kind of work
You decide
Approve the plan. Merge the pull request, or set the rules that do it. Choose what happens when a limit is hit.
waiting for you
The engine checks
Commits, review files, re-run commands, CI results. A gate opens only on a fact it confirmed itself.
not confirmed yet problem found
Agents do the work
Planner, developer, reviewer, QA, each in its own copy. Their reports can flag problems. They can't open gates.
outlines are claims
01
A founder with more backlog than hours
Keep the product.
Hand off the delivery.
You know what the feature should do. You don't have time to supervise every step. Write down what done means, approve the plan, and let separate roles build it.
Clarify
The planner asks before it plans.
If the criteria are thin, the planner asks on the task card. Your answer goes into the definition of done.
Accept
Every task needs a definition of done.
The engine refuses an issue without an acceptance criteria section and says why. Work with no definition of done can't be checked.
Approve
Approve the plan before any code exists.
The planner proposes a plan from a read-only copy. If it's heading the wrong way, stop it here.
Your note
customers keep asking to export their invoices. csv? only their own account obviously. want it before the Q4 billing email
Planner asksShould refunded invoices be in the export?
You answerYes, marked as refunded.
Issue #117 · no acceptance criteria section
Refused. Reason shown on the card.
Issue #118 · example-co/billingDemonstration
Export invoices as CSV
Definition of done you
- Account owners can export invoices for a date range as CSV
- The file holds only the signed-in account's invoices
- Totals match what the app shows
- Refunded invoices are included and marked from your answer
Acceptance criteria present · task accepted
Direction you
- Export endpoint scoped to the signed-in account
- CSV writer with a refunded column
- Tests for scope, totals and refunds
Proposed by the planner · read-only copy
Waiting for your approval
Plan approved by you09:14
Work separate roles
Starts after approval
Evidence engine
Fills in as gates are checked
Merge you decide
By you, or by a rule you set
The delivery team
One specialist for each job.
Planning, development, review, and QA each have their own role. You can change the model behind a role without changing its job.
- Role fixed.
- Model configurable.
- Runtime configurable.
Watch one task
Approve the plan. Then the roles take it from there.
The developer writes code in its own copy. The reviewer finds a problem and sends it back. QA tests the fix in a clean copy. The engine re-runs QA's command before the pull request reaches you.
Other tasks keep moving behind it.
02
A small team with too much in flight
Ten tasks in flight. Not ten chat windows.
Bugs, upgrades and cleanup run at the same time, each in its own working copy on its own branch. You don't watch them. Tasks that need a person come to you.
- Separate copies. The developer writes in its own worktree. Planner, reviewer and QA get read-only or clean copies and can't push.
- Nobody grades their own work. The reviewer didn't write the diff. QA tests the commit without the developer's description of it.
Task slots
6 of 10
Demonstration · illustrative tasks · not live activity
About the ten 10 tasks at once is the supported limit. How many your installation sustains depends on its resources and your workload. More tasks in flight doesn't mean proportionally faster delivery.
03
A business improving its own tools
Agents report. The engine checks.
Stock views, approval queues and ops dashboards run the business too. Your team knows the rules. Write them as acceptance criteria. Reviewer and QA test against them, and the engine checks what they report before the work moves on.
-
Commit
Every reported commit is checked.
The developer reports a commit. The engine confirms it exists, builds on the recorded base and changes something.
-
Send back
A finding sends the work back.
The reviewer finds a case the change got wrong. The work goes back to the developer and counts against the project's send-back limit.
-
Review
Approval has conditions too.
The review must match its schema, and the reviewer must not change any file. A reviewer that edits code fails its attempt.
-
Re-run
The engine re-runs QA's command.
QA tests the exact commit in a clean copy and reports the command it ran. The engine runs it again in a fresh copy. If the exit codes differ, the gate stays shut.
Not a no-code tool You still need a repository, tests, clear criteria and someone qualified to review the merge. Manufactoria hands that person a checked change and its record.
04
A consultant handing over work, or a lead who has to explain it later
Hand over a change someone else can accept.
Whoever accepts the work needs to know what changed, what was checked and what is still their call. The task record answers all three, and it is still there six weeks later when someone asks why this was merged.
The request Demonstration
From: dispatch lead, client
Can the orders list filter by delivery status? In the morning dispatch only wants to see what's out for delivery, and keep that view. And please, it can't get slower. Monday if possible.
Acceptance criteria
- The orders list filters by one or more delivery statuses
- The chosen filter is kept in the URL, so dispatch can bookmark it
- The existing orders-list performance test still passes
The handoff · from the task record
PR #58 · Filter orders by delivery status
What changed
- Status filter on the orders list
- Filter kept in the URL
- 5 files changed, tests added
What the engine checked
- Commit 5e1c0aa builds on base 88b2f41
- Review approved, 1 finding resolved
- QA command re-run in a clean copy: exit 0 as claimed
- GitHub checks passed on 5e1c0aa
You decide
- Merging this pull request
- Releasing it to the dispatch team
- Whether these were the right criteria
The task record exports as one JSON and Markdown bundle. Anything that looks like a credential is redacted.
When the loop runs out
At the limit, the task stops.
Issue #220 · Checkout total roundingDemonstration
Stopped · limit: same finding, 3 rounds in a row
Review returned finding F-2 three rounds in a row. The engine recorded the limit and put the task on your list. Running out of retries never moves work forward.
Your call:
Raise this task's limit
Cancel the task
Tokens, attempts and send-backs each have a limit. Set them per project and raise them per task.
Missing looks missing
If a provider reports no price, the record says cost not reported, never $0.00.
Autonomy is your setting
Auto approve and auto merge stay off until you switch them on. Auto approve only covers sub-task plans with no open questions. Auto merge needs final review, the reviewed commit still at the head, and no change to the same files on main.
What passing means
The listed checks passed on that exact commit. It doesn't prove the software correct.
Different kinds of work. One delivery team.
Progress you can inspect. Decisions you still own.
Other work it carries Investigations have their own template. Recurring maintenance runs from a saved template on a cron schedule and arrives as a normal task.
Two ways of working
| Question | One coding agent in a chat | Manufactoria |
|---|---|---|
| Who plans | The agent, inside the conversation | The planner drafts a plan. You approve it before work starts. |
| Who writes, who reviews | Usually the same agent, then you | A developer writes. A separate reviewer reads the diff in a read-only copy. |
| Which models | The model chosen for the chat | Each role can use a different model from the supported set. |
| What gets checked | What you check yourself | The engine confirms each commit, the review file and a re-run of the reported tests before work moves on. |
| When it goes wrong | You notice and step in | Every loop has a limit. At the limit the task stops and waits for you. |
| Who merges | You | You decide: merge it yourself, or switch on auto merge for a project. |
| What is left afterwards | The chat history | A record for each task: claims, checks, findings, decisions and costs. |
Where it runs
Your own installation.
Your choice of models.
We run a separate installation for each customer, with its own engine and its own database. Your task history and evidence record live there and are never shared with another customer. Only the people you list can sign in.
Each role can use a different model from the supported set. The relevant source for each task goes to that model's provider.
How models are paid for
Your own subscription
You pay the model provider directly. We never see your model bill.
Manufactoria credits
Use a configured set of models without managing provider keys.
Your installation · run by Manufactoria
- Engine · one per customer
- Database · tasks, attempts, gates, costs, audit log
- Working copies · one per task
- Evidence record
issues in · pull requests out
GitHubyour repositories
relevant source out
Model providerreceives the relevant source for each task
Start with real work
Give Manufactoria your repositories and a real backlog.
A useful pilot starts with work your team already understands: bugs, small features and investigations with clear acceptance criteria.
We set Manufactoria up around your workflow and measure whether it cuts the human effort per accepted change.
- ConnectConnect the repositories you want and pick a repeatable class of work to start with.
- RunLet real tasks move through planning, implementation, review and verification.
- ReviewLook at accepted work, returned work, evidence and the human effort required.