The software factory after the prompt

The phrase ‘AI-assisted development’ still makes many enterprise conversations sound like a faster version of autocomplete. That description is now too small. A capable agent can read a repository, form a plan, call tools, change several services, run tests, open a pull request, and continue operating while its human operator is doing something else. The scarce resource is no longer the ability to produce a plausible first draft. It is the ability to let that draft enter a real organization without losing ownership, context, or the ability to explain what happened.

That distinction matters because enterprise software is not judged at the moment a model prints code. It is judged when a customer relies on the result, when a security team asks which identities could reach production, when a compliance reviewer asks for evidence, and when an incident commander needs to reconstruct the chain of decisions under pressure. A generated change can be technically correct and still be operationally unacceptable if nobody can say which business request authorized it, which tenant it belongs to, what data it saw, what permissions it exercised, or who accepted the remaining risk. The output is not the unit of trust. The accountable change is.

An enterprise software factory is the system that turns a business intention into a released, operated, and reviewable software change. It includes the visible tools—repositories, issue trackers, CI, environments, scanners, model providers—but the tools are not the factory by themselves. The factory is the set of boundaries and handoffs that makes those tools produce a dependable outcome. It answers five questions for every piece of work: what are we trying to accomplish, who is authorized to act, what may the system touch, what evidence must be preserved, and what conditions permit release?

Agents make this operating model more important, not less. A human tends to create friction simply by being slow: they ask a question, wait for an answer, and notice when context is missing. Multiple agents can cross the same seam in milliseconds. That speed is valuable only when the seam is explicit. Otherwise the system compounds ambiguity at machine speed—copying an incorrect assumption into a plan, widening a repository scope, reusing a credential in the wrong tenant, or declaring success because a local test passed while the business requirement was never verified. The software factory therefore needs a control plane that is durable even when its workers are disposable.

A control plane is not another dashboard and it is not a central prompt router. It is the authority that sits above execution and below business governance. It binds an authenticated principal to a tenant and a workspace; turns a request into a bounded work intent; issues only the capabilities required for that intent; records the transitions; and refuses actions when the evidence or authority is stale. The execution layer can be elastic, multi-model, and aggressively sandboxed because the durable system is holding the identity, scope, lease, and release decision.

This is the practical difference between an agent that merely acts and an agent that can be trusted with a consequential queue. The control plane should be able to answer, without replaying an entire chat: which request created this run; which version of the plan was approved; which repositories, secrets, and environments were in scope; which agent and model acted; which tests and policy checks ran; which human or service approved promotion; and whether the final artifact is the one that was actually reviewed. These are not after-the-fact reporting fields. They are preconditions for safe execution. If the answer is missing, the correct behavior is not to guess—it is to stop, ask, or route the work back to review.

Most security programs still draw the important line at production deployment. For agentic software work, that line is too late. The blast radius begins when context is admitted. A repository URL, a pasted log, a ticket attachment, or a tool response can carry secrets, malicious instructions, or a misleading identity. The agent can make a security-relevant mistake while selecting a project, before it has written a single line of code.

NIST’s AI Risk Management Framework asks organizations to govern, map, measure, and manage AI risk across the lifecycle [1]. NIST’s Secure Software Development Framework similarly treats secure development as a set of practices integrated into the lifecycle, not a final scan [2]. The implication for an agentic factory is concrete: admission must establish tenant, principal, purpose, data classification, repository scope, and allowed tools before the first autonomous step. Each later capability should be narrower than the one before it. A build agent may read a checkout and write a branch; a release agent may propose promotion but not approve its own risk; a compliance agent may assemble evidence without gaining access to the proprietary source it is describing. The factory earns speed by making these distinctions machine-checkable.

The most ambitious software factories will contain learning loops: agents evaluate their own work, critique failed runs, update plans, and delegate to specialized sub-agents. That is where the architecture must become more disciplined. A learning loop should improve behavior inside a tenant without becoming an uncontrolled channel for proprietary data to an external orchestrator. The outer coordinator needs contracts, state transitions, budgets, and outcome signals—not the customer’s source code, credentials, or private conversation.

This separation is more than a privacy preference. It limits what a compromised or over-curious coordinator can learn, makes vendor substitution possible, and gives the customer a defensible answer when an assessor asks where their data went. Tenant-local agents can inspect the code and artifacts they are authorized to inspect; the orchestration layer can schedule work against opaque run identifiers and typed capabilities. The interface between them should be explicit enough to log and test: admitted, running, waiting for review, failed with a reason class, or ready for promotion. Recursive systems become safer when the loop can improve its policy and planning without silently expanding its authority.

A PDF assembled at the end of a quarter is a narrative about a system, not necessarily evidence of what the system did. If the factory cannot connect a release to its originating request, its approved scope, its test results, and its actor-attributed changes, the reporting team is forced to reconstruct history from fragments. That reconstruction is expensive, slow, and vulnerable to omission precisely when the organization is under scrutiny.

The better design is an evidence spine created by normal operation. An admitted run produces an immutable intent receipt. Capability grants record what the agent was permitted to do. Execution events record what actually happened. Review and promotion produce decisions with an actor, a timestamp, and a version fence. The release artifact carries the digest of the source and checks that were reviewed. None of these receipts prove that a system is safe by themselves; together they make the safety claim inspectable. This is the difference between compliance theater and operational evidence: the latter exists because the factory needed it to prevent an unsafe transition, not because someone remembered an audit deadline.

Armalo is building this as a working software factory: people define outcomes and retain authority; agents plan, implement, test, and explain; and the tenant boundary remains visible throughout the loop. The product is not an autonomous black box that asks a company to surrender its engineering judgment. It is a control surface for making more work safely executable. The useful primitives are mundane by design—workspace identity, capability scope, sandbox leases, durable run state, review fences, evidence receipts, and billing authority—because those are the primitives that keep a real business operating when the novelty wears off.

The external claim is therefore deliberately narrower than ‘AI writes your software.’ Armalo helps an enterprise build a software factory in which agents can be fast without becoming unaccountable. It lets the organization keep proprietary data inside the tenant while coordinating work through typed, inspectable contracts. It makes a good change easier to review, a bad change easier to stop, and a successful change easier to defend. That is the standard: not how much code the model can produce, but how much consequential work the business can trust the factory to carry.

Before adopting an agentic development platform, ask for a walk-through of one complete change rather than a demo of one impressive generation. Start with the request. Show the authenticated tenant and principal. Show the exact capabilities granted. Introduce a deliberately failing test and a policy denial. Ask what the system records, what it hides, and how a second operator resumes the work. Then promote a small change and inspect the evidence without asking the vendor to prepare a special report.

The questions are intentionally uncomfortable. Can the system prove that an agent did not cross a tenant boundary? Can it distinguish a failed verification from a successful deployment? Can an external orchestrator coordinate progress without seeing the customer’s proprietary data? Can a human revoke a capability and know that in-flight work will fail closed? Can finance explain what a unit of autonomous work cost and why it was authorized? If the answer depends on a screenshot, a promise, or a future roadmap, the factory is still a prototype. If the answer is a durable receipt produced by the normal path, the organization has something it can operate.