Upcoming Workshop: Citizen Developer Agentic Software Factory on AWS

Register Here!

Run an agentic software factory on the path production already trusts.

A software factory runs coding agents in a loop from issue to merged pull request. The loop usually works. It stalls at deploy, where someone has to decide what infrastructure an agent may create, which credentials it uses, and who approves the move to production. Massdriver answers those questions with the catalog, policy checks, and approvals your engineers already use.

The coding loop works. Deployment is where it stops.

Most factory projects start the same way. A team rolls out Claude Code, Codex, or Cursor, and an agent produces a working service in an afternoon. Then somebody asks the agent to give the service a database, and the project turns into questions nobody planned for. Which database is the agent allowed to create? Does it get an AWS key? Can it write whatever Terraform it likes? How does the service move from dev to production, who approves that, and who owns it next quarter?

Published factory designs are detailed up to the merge and thin after it. They describe how specs get written, how agents pick up issues, and how tests are held out so the agent cannot game them. Release and operations get a paragraph. We wrote about that gap in What Software Factories Leave Out.

The gap matters more as the factory gets better. A factory multiplies the number of infrastructure changes reaching your cloud, and the number of people who can review those changes stays the same. Whatever path the agents use to reach production has to hold up at that volume.

How teams connect factory agents to infrastructure

Each option below solves part of the problem. The difference is what your platform and security teams still have to build or watch.

Give the agent cloud credentials

What it gives you

The fastest demo. The agent can do anything the role allows, and nothing waits on a person.

What it leaves to you

The role limits where the agent can act. It says nothing about which architecture to build. The key sits in the agent’s environment and its transcripts, and agent changes reach production by a different route than your engineers’ changes.

A sandbox account per agent

What it gives you

A contained blast radius while the agent experiments. A bad change stays inside one account.

What it leaves to you

No answer for how the work reaches production. The sandbox fills with resources that have no owner, and each one is a second estate to clean up.

The agent writes Terraform and opens a pull request

What it gives you

Review before apply, and a history in Git. This is a real improvement over direct access.

What it leaves to you

The agent designs new infrastructure for every request. Reviewers read generated HCL as fast as the agent writes it, and the modules drift from your standards one pull request at a time.

Backstage templates, HCP Terraform, or Spacelift

What it gives you

Mature execution, state, and policy. HCP Terraform supports Sentinel and OPA, and Backstage templates can call custom actions.

What it leaves to you

Strong parts that your team assembles. The catalog, permissions for non-human callers, approvals, and the inventory of what each agent created still have to become one model.

Massdriver

What it gives you

Agents choose from the Terraform, OpenTofu, and Helm modules your platform team published. They hold a scoped Massdriver token, and their changes get the same policy checks and approvals as everyone else’s.

What it leaves to you

Your team still writes and owns the modules and the policies. Massdriver runs them for every caller.

One factory change, from issue to audit record

The issue says the reporting service needs a Postgres database. Here is what the agent does, and what your team can see afterward.

  1. 01
    What happens

    The agent picks up the issue and asks Massdriver, through the MCP server, which database bundles its team may use in dev.

    What the record shows

    A read. Nothing in your cloud changes, and the agent learns the approved options before it plans.

  2. 02
    What happens

    The agent proposes an instance of the approved Postgres bundle and sets the parameters the bundle exposes, such as size and engine version.

    What the record shows

    The bundle’s schema rejects any value your platform team did not allow. The proposal names the agent’s service account as the actor.

  3. 03
    What happens

    Policy checks (SOC 2, HIPAA, CIS) run against the plan, the same checks a change from an engineer gets.

    What the record shows

    The policy results are attached to the change.

  4. 04
    What happens

    The agent’s grant allows deploys in dev, so the database comes up and the agent runs its tests against it.

    What the record shows

    The deploy is recorded with its diff and result.

  5. 05
    What happens

    The agent proposes the same change for production. A person with deploy permission on that environment reviews it and approves it.

    What the record shows

    The approver is named on the change, next to the agent that proposed it.

  6. 06
    What happens

    The database appears in the inventory, connected to the reporting service.

    What the record shows

    Owner, environment, dependencies, and deployment history sit in one place for whoever runs the service next.

What a factory agent can see, propose, and deploy

Each of these is a separate permission, granted by policy on environment, team, and blast radius. Most teams start narrow and widen the grants as the factory earns trust.

01

Read the catalog and the graph

The agent sees the bundles its team may use and what is already running, so its plans match what is actually deployed.

02

Propose changes where you allow it

A proposal changes nothing on its own. It waits for someone with deploy permission on that instance.

03

Deploy where the grant allows it

Dev and preview environments are the usual place to start. The agent gets a fast loop there, and production stays gated.

04

Leave approval to people

Proposing a change and deploying it are separate permissions. An agent can propose a production change while a person decides whether it ships.

One path for the factory, your developers, and CI

A factory with its own deployment pipeline gives your security team a second system to audit and keep in sync with the first. Massdriver gives every caller the same way in. The portal, the CLI, the API, and the MCP server all go through the same catalog and the same policy, so an agent change and a developer change leave the same kind of record.

The agent never authenticates to your cloud. Massdriver holds the cloud credentials and uses them only for deploys that policy allows. Revoking the agent’s Massdriver token, or removing its service account from its group, ends its access with no change to cloud IAM.

Questions platform and security teams ask

Why not let the agent write Terraform directly?

It can, and for some work it should. For production infrastructure, generated Terraform lets the agent design something new every time. With Massdriver the platform team decides which modules make up the platform, and the agent chooses among them and sets their parameters.

Does the agent get cloud credentials?

No. The agent holds a scoped Massdriver token. Massdriver keeps the cloud credentials on its side and uses them only for deploys that policy allows.

Do agents need their own deployment process?

No. Agents, developers, CI jobs, and business workflows reach your cloud through the same catalog, policy checks, and approvals. One path means one set of controls to keep correct.

Can an agent deploy to production?

Only if you grant it. Most teams start with agents that propose production changes and people who approve them, then widen the grants for low-risk changes once they trust the results.

Does Massdriver replace our coding agents or our SDLC tools?

No. Your agents, repositories, and CI stay as they are. Massdriver governs the infrastructure changes underneath them.

When you do not need this yet

If one team runs a factory experiment in a sandbox account, with no production path and no regulated data, an isolated account and a short-lived IAM role are enough. These controls matter once the factory’s output has to run in production next to everything else, and someone will ask who approved it.

Watch an agent work inside these controls

A two-minute demo: a developer describes an app in Claude Code, and Architect builds it only from the approved catalog, under the same policy as every other change.

The same path, in production

UniDoc runs its infrastructure through Massdriver. A blue/green release that took three engineers more than three hours now takes one engineer less than an hour.