Real enterprise work · Practical guide
How do you build an AI software factory for enterprise work?
Define a repeatable software product, specify the input each run accepts, and build a controlled pipeline that produces and independently verifies that product. Agents may plan, implement or diagnose failures, but a factory also needs durable run state, isolated environments, versioned evidence and an accountable release decision. Begin with one class of change your team repeatedly delivers.
For Engineering leaders, platform teams, technical delivery owners and enterprise teams building repeatable software delivery processes.
A design guide with fictional worked examples. It does not report an executed implementation or customer result.
Here, an AI software factory repeatedly produces a defined family of software outputs. A run might turn an accepted website-change specification into a candidate patch, checks and handoff package, or an explicit failure.
An agentic workflow coordinates a case. A factory adds a reusable product definition, repeatable stages and a verifier whose rules the builder cannot casually rewrite. Agentic workflows may implement individual stages; the factory remains responsible for the complete product.
What you need before you build
- A narrow product family
- Choose repeated work with similar acceptance needs, such as adding an approved field to an internal request form. Avoid starting with any application anyone might ask for.
- A versioned input contract
- Require a change identifier, repository baseline, business requirement, affected user roles, interface constraints and acceptance cases. Reject incomplete requests before building.
- An enterprise build environment
- Confirm repository access, dependencies, test accounts, representative data, allowed network destinations and compute limits. Name owners for the specification, verification and release.
Build the software factory
1. Define the product and its acceptance contract
Define required outputs: a patch against a known baseline, migration notes, test results, user-journey evidence and reviewer summary. Exclude sensitive changes outside the agreed scope. Return requests outside the product family for scoping.
2. Codify the work into explicit stages
Map intake, specification review, implementation, verification, repair and handoff. Specify stage inputs, outputs and exit conditions. The owner accepts requirements; failed checks trigger repair or escalation. Persist transitions in the runner so a model cannot simply declare completion.
3. Create an isolated, reproducible build
Start a workspace from the recorded repository commit and dependency versions. Supply only the credentials and destinations needed for that run. Seed test records separately from production data. Record the model, instructions, tools and configuration used, so a later reviewer can distinguish a changed requirement from a changed execution environment.
4. Give each agent a specific build task
Implementation agents propose patches; diagnostic agents investigate failures. Supply the accepted specification and only necessary tools. Keep secrets out of artifacts and limit run time and spending. Parallel work requires separate workspaces and an explicit integration point.
5. Verify the product independently
Run owner-approved acceptance checks against the built application, not just the agent's account of what it changed. Use deterministic assertions for exact behavior and human review for judgments that cannot be reduced to those checks. Keep authoritative acceptance cases protected from the builder. A second model's positive opinion can add evidence, but does not establish independence if it shares the same blind spots.
6. Bound repair and preserve failures
Return a concrete failure record to the builder: the failing case, expected behavior, actual result and relevant evidence. Permit a limited repair cycle, then rerun all affected acceptance checks. If the requirement is wrong, the owner changes its version deliberately. Do not delete a failing test or rename the expected output to manufacture a passing run.
7. Package the result for a release owner
Produce the patch reference, specification version, check results, known gaps and operating notes as one reviewable package. Link evidence to the exact built commit. The release owner decides whether to merge, request changes or stop. Deployment, rollback and production access belong to separately agreed release controls, even when the factory can prepare their artifacts.
8. Improve the factory across runs
Track failures, reviewer corrections, rejected inputs and elapsed work by stage. Preserve failures as evaluation cases; replay them when instructions, models or dependencies change. Check whether faster builds create more review work. An overall success percentage can hide those costs.
Illustrative worked example
Worked design: repeated internal website changes
The factory produces change candidates for an employee portal. A sample request adds a cost-centre field and returns incomplete requests.
| Stage | Required artifact | Who decides it can continue |
|---|---|---|
| Intake | Approved field definition, allowed values, affected roles and baseline commit | Business owner resolves missing routing rules |
| Build | Patch and candidate tests in an isolated workspace | Runner confirms build artifacts exist; it does not certify behavior |
| Verification | Owner-controlled tests for valid, missing and unauthorized submissions | Verifier records pass or failure against the built commit |
| Repair | Revised patch tied to the original failing case | Verification reruns; unresolved failures remain visible |
| Handoff | Change candidate, evidence, limitations and rollback notes | Authorized reviewer decides on merge and release |
The product is the change candidate plus evidence. A build command or self-reported completion is insufficient.
What to check
- The factory rejects an invalid input
- Omit the cost-centre routing rule. Intake must return a precise missing requirement rather than inventing policy and continuing.
- A convincing but broken patch fails
- Seed a change that renders the field but accepts an empty value. The independently maintained acceptance journey must detect the defect.
- Evidence belongs to the actual build
- Change the candidate commit after verification. The previous results must no longer authorize handoff as a verified candidate.
- Recovery does not repeat side effects
- Stop the runner after artifact upload and resume the same run. It should preserve stage state without creating duplicate branches, review requests or releases.
- The builder cannot bypass acceptance
- Attempt to remove a required check or mark a failed stage complete. Protected policy and release controls must prevent that shortcut or send it for owner review.
Make this real in your enterprise
Bring a repeated software-delivery task, such as changes to an employee portal. Your team defines the request format, builds or configures the stages, and demonstrates the resulting change against agreed checks.
Reuse suitable repositories, CI and identity controls; agree any interfaces that must be simulated. Nuvepro scopes the project, environment and preparation. Name who maintains the checks and who can approve a release. Agree any ongoing operating support separately.
Scope and limitations
- Software factory is a design term here, not a claim that one universal platform can autonomously deliver every enterprise application. The right level of automation depends on the product and its risks.
- A factory demonstrated in a business environment still needs live integration, security, capacity and production acceptance decisions. It does not guarantee defect-free code or eliminate engineering judgment.
Questions about this project
Is an AI software factory the same as a multi-agent system?
No. Collaborating agents need not form a factory. A factory needs a repeatable product, controlled stages and verification, using agents and ordinary automation as appropriate.
Can our existing CI pipeline become part of the factory?
Reuse approved builds and checks, adding input contracts, state, agent boundaries and evidence packaging where needed. Verify required checks and bypass permissions in your configuration.
Can the same agent build and verify the software?
Development checks help, but acceptance needs protected criteria and independent execution. Builder-selected tests can repeat the implementation’s misunderstood requirement.
Sources and further reading
Check current product support, permissions and licences for your project. References do not imply a Nuvepro partnership or available connector.
- Anthropic: Effective harnesses for long-running agents
Describes structured progress and end-to-end testing for web applications.
- Anthropic: Demystifying evals for AI agents
Explains tasks, trials, graders and outcome evaluation. Domain-specific acceptance and meaningful test cases still need to be designed.
- GitHub: About protected branches
Documents required checks and review controls, including configuration-dependent bypasses. Branch protection must be configured; an agent does not create release assurance merely by using Git.