Software factories for engineering teams
A complete software factory, built for your organisation
Free up your engineers for actual engineering. We build and commission the infrastructure, agent workflows and verification that turn suitable work into reviewable changes — then train your team to operate the system.
A software factory takes scoped work through planning, isolated execution and agreed checks, returning changes and evidence for your team’s review. Phase 1 starts from work that is already ready to implement; event-driven intake is an optional add-on, not part of the base capability.
On your equipment, in your cloud tenancy, or both.
Capability phases
Choose how far the automation goes
-
Execute ready work
Phase 1 — Autonomous execution
Executes engineering work that is already specified and ready for implementation, through isolated agents, automated checks and controlled review.
Ready task → isolated agents → verified result
Fully functional on its own
-
Turn signals into work · Optional extension
Phase 2 — Event-driven orchestration
Listens for authorised events, interprets them under policy, and hands ready work — or a decision — to the existing Phase-1 factory.
Events → context → decision → ready task
Feeds the existing Phase-1 factory
Build Phase 1 first; Phase 2 sits upstream when added.
Phase 1 does not need Phase 2. If your team already has well-defined issues and approved plans, the factory can execute them immediately. Add Phase 2 when you want the system to respond to events and help turn incoming signals into executable work.
Starts from
Phase 1
Work already specified and ready for implementation.
Phase 2
Incoming events, messages and changes across authorised systems.
Primary question
Phase 1
How do we execute this work reliably?
Phase 2
Does this signal require action, and what should happen next?
Main activity
Phase 1
Dispatch, agent work, testing, bounded correction, evidence, review.
Phase 2
Capture, correlate, filter, interpret, clarify, plan, route and approve.
Typical output
Phase 1
A proposed change or PR with verification evidence.
Phase 2
A no-op, notification, issue update, proposal, approval request or executable task.
Can operate alone?
Phase 1
Yes.
Phase 2
No — it extends Phase 1 for work execution; non-code actions can route separately within agreed scope.
When to choose
Phase 1
You have a backlog or planned work ready to delegate.
Phase 2
Valuable work or decisions arrive fragmented across tools and need constant human triage.
You are not committing to a two-phase programme. A commissioned phase-1 factory is a complete engagement. If you later add Phase 2, it reuses the infrastructure, controls and execution path already in place — rather than requiring another factory.
Why Axiom Lane
Engineering the whole system
Our background combines software and infrastructure engineering with technology leadership. We bring that experience to the work between the components: coordinating agents, integrating delivery systems, controlling execution and making the result practical for a team to run.
-
Infrastructure and economics
Make existing, refurbished or new capacity work together within a measured plan.
-
Durable orchestration
Coordinate work, limits and recovery through deterministic code, with visible human decision points.
-
Delivery through handover
Integrate and commission the system, then transfer the documentation, workflows and operating knowledge.
More engineering capacity, less coordination overhead
The opportunity is to move routine execution and coordination into the system, so engineers can spend more attention on design, product judgement and decisions about change.
-
Provisions a clean environment for each task and cleans it up afterwards
Less repeated setup and less interference between workstreams
-
Coordinates bounded work, queues, retries and exceptions
Less manual session management; suitable work can continue between human review points
-
Runs agreed checks and collects their results
Reviewers receive proposed changes with the evidence needed to assess them
-
Allocates capacity and exposes usage, limits and status
The team can manage demand and operating cost using observed work
Useful throughput depends on task suitability, verification and review capacity; agree the baseline and measure it in a representative workflow.
What we deliver
A commissioned system your team can operate
This is the phase-1 foundation we commission: the parts of the system that execute ready work and the evidence for accepting them. Where an area can also serve Phase 2 — identity, orchestration, audit, observability — Phase 2 extends it rather than duplicating it. Scope is agreed per engagement, using what already works in your environment.
-
01
Hardware and capacity
Suitable compute, storage and a measured capacity plan; existing equipment, procurement and deployment as needed.
-
02
Network and security
Connectivity, identity, scoped access, secrets and execution boundaries.
-
03
Execution environments
Reproducible, isolated task environments with controlled provisioning and cleanup.
-
04
Orchestration
Workflows, scheduling, durable task state, bounded retries and provider integration.
-
05
Software delivery
Connections to intake, repositories, CI, verification, review and the agreed release boundary.
-
06
Visibility and cost control
Task status, diagnostics, resource use, quotas and spend visibility.
-
07
Team enablement
Training, runbooks, supervised operation and named operating responsibilities.
What we demonstrate before handover
| Delivery area | Typical acceptance evidence, where included in agreed scope |
|---|---|
| Hardware and capacity | Workload/capacity plan, bill of materials where needed and documented deployment |
| Network and security | Access design, threat assumptions, configuration and operational runbooks |
| Execution environments | Provision, execute, export and destroy demonstration; relevant isolation and cleanup checks |
| Orchestration | Working reference workflows and bounded failure/recovery demonstrations |
| Software delivery | End-to-end sample change with check results, review evidence and recorded approvals |
| Visibility and cost control | Operational views and scoped alerts, usage information and documented cost assumptions |
| Team enablement | Training material, operating walkthrough, runbooks and agreed responsibility transfer |
Operating evidence to date
Execution capacity Axiom Lane has already set up and operated for factory work:
- 52 CPU cores and 160 GB RAM across 2 servers — the dense, always-on baseline.
- 48 cores and 168 GB RAM across 5 consumer-grade laptops — whatever hardware was available.
Kubernetes keeps a pool like this flexible in how it is shaped: install a hypervisor, create a VM for the node, and everything else in the factory rolls out the same way — on a server or on whatever hardware is already in the room.
This explains how a delivered system is accepted; it is not a list of results already demonstrated to a customer.
See the illustrative engineering walkthroughAcceptance per phase
- Phase 1 handover: a representative ready issue yields a reviewable, verified output; failure, retry and cleanup are exercised; operators can see task state; approvals work.
- Phase 2 handover: at least one selected event source is ingested, correlated and routed; duplicate, no-op and ambiguous cases are demonstrated; a qualified event produces an authorised task consumed by the running Phase 1, with event and approval provenance available.
What Phase 2 adds
Everything below extends the commissioned phase-1 foundation — it does not replace or duplicate it.
- Event-source integrations: agreed issue trackers, chat systems, mailboxes and other services.
- Ingestion and normalisation: verified inputs, dedupe, retries, replay-safe processing where feasible.
- Context and interpretation: correlation, classification, policy-constrained reasoning.
- Decision and planning workflows: clarification, task drafting, dependency and acceptance preparation, approvals.
- Handoff: a traceable, policy-approved path into the existing Phase-1 ready-work interface.
- Additional monitoring: events received, filtered, actioned, rejected or awaiting human decision.
Clear control and responsibility after handover
The handover records the installation, configuration, workflows, documentation and training delivered, who controls the relevant accounts, and who operates the system. Third-party licences, implementation rights and any ongoing support are agreed in the engagement scope.
Control, rights and ongoing operation
-
Control
Who administers infrastructure, repositories, model-provider accounts and secrets?
-
Rights
Which custom implementation materials are delivered, under which agreed rights, and which components retain third-party licences?
-
Operation
Who handles incidents, updates, security, quotas, budgets and exceptions?
-
Support
What assistance, if any, is included after handover, and how is its scope agreed?
Start with a workflow worth improving
Phase 1 pays off from day one on work with clear boundaries, repeatable verification and someone able to review the result. Common starting points include:
Phase-1 starting workflows — illustrative applications, not customer case studies
-
Starting work
Dependency and maintenance backlog
With Phase 2
An issue comment reveals a new acceptance requirement — Phase 2 correlates it with the backlog, drafts the scoped update and routes it for approval before execution.
Illustrative factory output
Upgrade batches run as isolated workstreams, each producing proposed changes with verification evidence for review.
Key boundary
Approving the upgrade plan.
-
Starting work
Product changes
With Phase 2
A support email requests a bug fix — Phase 2 classifies and proposes it, and the required approval routes the ready task into Phase 1.
Illustrative factory output
Independent initiatives run concurrently in isolated environments, each producing reviewable changes against the same verification gates.
Key boundary
Release approval.
-
Starting work
Legacy modernisation
With Phase 2
A blocker status change flags re-evaluation — Phase 2 re-checks dependencies and dispatches the task once it is ready under policy.
Illustrative factory output
Modernisation is decomposed into bounded, verified steps with characterisation tests before and after each change.
Key boundary
Architecture sign-off.
Illustrative first workflow
A concrete first workflow
For example, select one repository and a dependency update with known acceptance checks. The factory prepares an isolated environment, proposes the change, runs those checks and returns the change with its evidence. A failed check triggers bounded correction or an exception for the team. A reviewer decides whether to accept it.
See the technical walkthroughAgree the scope, permissions and success measures before starting. Assess completion against the checks, review and rework effort, failures and recovery, elapsed time and total operating cost. The result informs whether and how to expand.
How we deliver either phase
From your starting point to an operating factory
Ways to work with us
Complete factory delivery
We take responsibility for integrating and commissioning the agreed system, then train your team and hand over the operating capability.
Build together
Deliver alongside your engineers, sharing implementation and transferring knowledge as the system takes shape.
Selected components or assessment
Improve an existing factory, establish a baseline, or deliver defined parts of the capability where that is the useful next step.
Existing capabilities and evidence count. Responsibilities can be internal, Axiom Lane-led or shared, and can differ by stage; scope, timing and cost are agreed around the work required.
Other starting situations
Work for new engineering functions, technical hiring assessment and onboarding can be scoped where it supports the operating capability.
Our implementation process (applies to each phase)
Assess
Environments, pipelines and meaningful tests against the work you intend to delegate.
Design
Workflows, worker classes, verification gates and economic assumptions from measured representative work.
Build
Infrastructure, orchestration, execution, verification and visibility — connected to your repositories, CI and review.
Commission
The real workflow, including failure and recovery.
Enable
Training, runbooks and supervised operation.
Gaps return to remediation; capacity findings can change the design. Expand only after reviewing the evidence.
Delivery stages in detail
-
01
Assess
Agree goals and intended work: define repositories, intended changes, volume, concurrency, turnaround, security and budget constraints, and choose a bounded pilot. Then inspect environments, pipelines, automated tests, critical-behaviour coverage, review workflow and operating responsibility against the proposed work; investigation and supervised test creation can begin in parallel rather than waiting for every prerequisite.
Output: Baseline, existing evidence, blocking gaps and an agreed next step
Note: Gap work begins in Assess and can continue alongside Design and Build; investigation, supervised test creation and infrastructure design do not wait for every prerequisite.
-
02
Design
Measure representative work: profile real changes, dependency installation, builds, full verification, test services and artefact export, and measure time, CPU, peak memory, storage, I/O, retries and contention; remeasure when material changes occur. Then use the measured workload mix, concurrency and queue targets to design worker classes, verification gates and headroom, considering existing equipment, cloud or hybrid, with local model inference assessed separately.
Output: Deployment recommendation, cost assumptions and acceptance plan
Note: Capacity findings can change the design; remeasure when material changes occur.
-
03
Build
Address gaps that block execution or verification, using existing foundations; the work can be internal, delivered by Axiom Lane or shared. Then integrate the actual system — infrastructure, orchestration, execution, verification and visibility connected to your repositories, CI and review.
Output: Working reference workflow and demonstrated required foundations
Note: Blocking gaps are addressed as needed.
-
04
Commission
Pilot the real workflow, including failure and recovery, and compare quality, runtime, resources, recovery and human review effort with agreed acceptance criteria. Acceptance gaps return to remediation or design; the evidence is rechecked before commissioning completes.
Output: Acceptance evidence or a defined return to remediation/design
Note: Acceptance gaps return to remediation or design; commissioning cannot silently bypass a blocking gap.
-
05
Enable
Transfer configurations, workflows, runbooks and training, then assign operational owners for incidents, upgrades, budgets and exceptions. Check readiness and demand again when expanding.
Output: Operating handover and measured expansion priorities
Start with the foundations for the selected work
- A reproducible environment with known setup, build and test commands.
- Checks that examine the behaviours the chosen work can break.
- Bounded tasks, acceptance criteria and scoped access.
- A clear review/release path and named operational owners.
Gaps can be addressed by your team, by Axiom Lane or together — and missing foundations are not a blocker: the factory's first delegated work can be readiness work itself, improving agentic readiness instead of producing features until the checks are ready. We check the evidence for the intended workflow; a coverage percentage or questionnaire answer cannot establish readiness on its own.
Check the readiness detail
| Foundation | What must be established | If missing |
|---|---|---|
| Reproducible execution | Known setup, build and test commands, dependencies and the test services the work needs. | Establish a reproducible baseline and document the commands. |
| Effective verification | Critical behaviours and failure paths, useful assertions, dependable test data, manageable flakiness. | Characterise behaviour, add targeted tests, stabilise the relevant pipeline. |
| Clear bounded work | Requirements, acceptance criteria, dependencies, and limits on delegated action. | Decompose and clarify the task before execution. |
| Controlled integration | Scoped repository and tool access, review and merge rules, release authority, escalation. | Configure the permitted path and name the decision owners. |
| Operational ownership | Someone owns exceptions, incidents, upgrades, quotas and budget. | Assign responsibilities and train the relevant people. |
Tests need to examine critical behaviours and failure paths, useful assertions, legacy characterisation, flaky tests and dependable test data. Line and branch coverage help locate gaps; no single percentage proves correctness or readiness.
Research behind this approach
DORA’s industry research describes AI as magnifying an organisation’s existing strengths and weaknesses. Our delivery approach therefore starts with the engineering system around the tools. DORA, State of AI-assisted Software Development (2025).
Fast, reliable tests belong in delivery pipelines throughout development. Examine critical behaviours, assertions and failure paths as well as coverage gaps. Test automation — DORA capability guidance (last updated 17 July 2025).
In five Java systems, coverage had a low-to-moderate association with fault detection after controlling for test-suite size. Coverage can locate gaps; this study evaluated test suites, not agent readiness. Inozemtseva and Holmes, ICSE (2014): Coverage Is Not Strongly Correlated with Test Suite Effectiveness.
DORA provides industry research and capability guidance; the ICSE paper is peer-reviewed research. These sources inform our approach, rather than certify our checklist. Establishing readiness for the selected workflow is our delivery requirement, based on evidence and agreed risk.
Find your starting point
Answer four questions for a suggested route; you can contact us without completing it.
Answer the four questions
Choose your phase first — phase 1 is complete on its own — then consider your situation, intended work, existing evidence and infrastructure constraints. Each stage can be delivered by Your team, Axiom Lane or Together; Decide later where responsibility is unresolved. Existing factories start with diagnosis and improvement after prerequisite checks.
Choose an answer to reveal the next area. You can revisit any answer. Owners can differ by stage; you can stop at assessment and lead later work internally.
Plan responsibilities
Optional now: you can read your suggested starting point without it. Choose independently for each stage — commissioning evidence and acceptance are agreed separately from implementation ownership.
Choose the infrastructure and running costs that fit
The factory can use existing or refurbished equipment, cloud capacity or a combination. We size execution from representative work and agree who will operate each part.
-
Placement
Owned or customer-controlled equipment
Useful when
You want the most control over data, placement and long-run cost.
What must be accounted for
The responsibility for running the equipment, from hosting to platform operation.
-
Placement
Cloud or hosted capacity
Useful when
You have an existing tenancy and skills to draw on, or you want hardware operations shifted to someone else.
What must be accounted for
Spend that continues as usage grows, and less direct control over data placement and unit costs.
-
Placement
Hybrid
Useful when
Steady workloads can run on owned capacity while bursts rent it — the most flexible option.
What must be accounted for
The most integration to operate across the two placements.
Who runs the system, and what it costs
Hardware hosting, platform operation, application review and model services can have different owners. Hosted hardware does not automatically include managed factory operation, and customer-controlled cloud may satisfy requirements that an on-premises design does not; placement alone does not establish security or data sovereignty.
-
Design and delivery
The work of designing, integrating, commissioning and handing over the system for the selected workflow.
-
Execution infrastructure
The capacity the factory runs on — owned, hosted or rented — sized from representative work and costed differently by placement.
-
Inference and external services
Model access, test services, integrations and subscriptions, with usage driven by the selected work and the chosen providers.
For sustained suitable work, owned capacity can replace recurring execution-compute rental with an upfront investment and ongoing running costs; the choice depends on measured utilisation, performance and operating effort.
Next step
Find the right first workflow
Tell us what you want your engineers to spend less time coordinating, what systems you already use and the constraints that matter. We will discuss whether Phase 1, a bounded pilot or improvement of an existing factory is the useful next step — and Phase 2 can wait until you want it. No detailed preparation or questionnaire is required.