Why current AI coding agents can't actually ship 0→prod — and what we did about it

The most-quoted promise of multi-agent AI tools in 2026 is “a team of agents takes your idea from zero to production.” Read the marketing pages of Devin, Replit Agent, Factory.ai, Cursor’s agent mode — they all imply it. Some demo it on toy projects.

The problem: none of them actually do it on a real customer’s infrastructure. Not reliably. Not safely. The reason is the same one nobody wants to put in their landing page: shipping code to prod is mostly not coding. It’s infra, secrets, deploy state, supply-chain attestation, audit trail. And those are exactly the parts current agentic tools are worst at.

We split the problem into two products on purpose. Simple Container is the open-source infrastructure substrate. Forge is the multi-agent workflow engine that knows how to use it. Together they actually deliver 0→prod; alone neither would.

What “0 to prod” really requires

Walk through a realistic feature delivery — a new /api/orders endpoint backed by a Postgres table, with a Stripe webhook, deployed behind ai.your-domain.com. The steps:

1. Understand the requirement. PM scope, edge cases, acceptance criteria.
2. Design the schema + endpoint shape. Architecture decisions, data model, API contract.
3. Write the code. Handler, migration, validation, tests.
4. Provision the infrastructure. Postgres database, Stripe webhook secret, ACM cert, DNS record, secret store.
5. Wire credentials. Postgres connection string, Stripe API key, OpenAI key if it’s AI-using — encrypted at rest, decrypted only at deploy.
6. Build + scan the artifact. Docker image, CVE scan, cosign signature, CycloneDX SBOM, SLSA provenance.
7. Deploy with rollback safety. State tracked in Pulumi/Terraform, blue/green or canary, rollback to the previous version atomically.
8. Verify in prod. Hit the endpoint, check logs, look for errors.
9. Commit + audit. Git history of every change, signed commits, change description, who-approved-what.

A single-agent CLI (Claude Code, Cursor’s agent) handles steps 1–3 fluently. It collapses at step 4 onward. Try asking Claude Code to “provision a Postgres database on AWS and a Cloudflare DNS record” — you get plausible-looking Terraform that doesn’t actually run, or worse, runs and leaves state corrupted because no one was tracking it. Ask it to “wire Stripe credentials” — you get plaintext API keys committed to a .env.local that ends up in the LLM’s context window five minutes later and quite possibly in its next chat completion.

That’s not Claude Code being bad. It’s that a CLI talking to a filesystem isn’t the right abstraction for steps 4–9.

Why we built Simple Container open-source first

Simple Container is the substrate. It’s been in production for 5 years across a roster of paying design-partner businesses. It is:

• One declarative model for a service deployment. server.yaml for shared infrastructure, client.yaml for a service that uses it, three deployment types (cloud-compose, single-image, static).
• Multi-cloud by design. AWS Lambda / ECS Fargate / RDS, GCP Cloud Run / GKE Autopilot / Cloud SQL, self-hosted Kubernetes. Same service definition; swap the template.
• Encrypted-at-rest secrets in git. Encrypted with your SSH key — RSA or Ed25519 — multi-key (every authorized teammate decrypts with their own key). The post-AI threat model: AI agents reading your repo see ciphertext, never values.
• Built-in supply chain. sc release create -s my-service -e prod runs build → scan → sign → SBOM → provenance → deploy. Cosign + CycloneDX + SLSA Build L3 in one command.
• CI/CD generation from the parent stack’s cicd: config block. sc cicd generate -s <stack> produces GitHub Actions workflows; you commit and forget.
• MCP server built into the CLI — sc assistant mcp --port 7331 exposes SC primitives as Model Context Protocol tools.

That last bullet is the bridge to Forge.

What Forge adds on top

Forge is a workflow engine for AI agent teams. You describe a team in plain English — “I need a PM, an architect, a developer, a QA, and a reviewer; the PM validates each handoff” — and Forge generates a workflow spec of named personas with transitions and a designated management agent. Each persona runs on the right runtime; every handoff is a commit on a workflow-scoped git branch; a manager agent validates every transition with a verdict (advance / enrich / escalate). Read the engine page →

For the 0→prod problem specifically:

• Steps 1–3 are still LLM-shaped work. Forge’s PM, Architect, Developer characters do them in sequence with structured handoffs, not a single agent slurping the whole task into one context window.
• Steps 4–6 happen through SC primitives that Forge talks to over MCP. Forge’s Developer agent doesn’t shell out and run terraform apply — it issues typed tool calls to sc deploy, sc image scan, sc release create. The agent never holds plaintext credentials in its own address space; SC’s egress proxy substitutes them at the boundary.
• Step 7 is sc release create -s my-service -e prod. Pulumi-backed state, scan + sign + SBOM + provenance attached as artifacts, rollback is pulumi stack rollback or the destroy command.
• Step 8 — the verification round — is Forge’s QA character running against the freshly-deployed environment with a scoped session token.
• Step 9 — git audit — is by construction. Every persona’s handoff is a signed commit on a workflow-scoped branch. git log is the audit trail. gh attestation verify proves the build is legitimate.

The slot we filled in our architecture isn’t “make agents write better code.” It’s “make sure when an agent says ‘I deployed it,’ something verifiable actually got deployed, and the credentials it used never leaked.”

Why this split is the architecture, not an accident

A common question we get from prospective customers: “Can’t you just bundle SC into Forge?” Sure, but that misses the point.

Simple Container is intentionally open-source and intentionally usable without Forge. A DevOps team that doesn’t want AI agents anywhere near their pipeline can still adopt SC tomorrow and get all of the above — declarative service definitions, encrypted secrets, supply-chain attestations. They get value before AI is part of the conversation.

Forge is intentionally agent-only and intentionally Forge-only. Forge is where the agentic orchestration lives — multi-persona workflows, manager-agent validation, NL-driven spec generation. It would be wrong to ship that bundled into SC because most SC users don’t want it, and shipping the agent layer separately is what makes it possible for non-engineering buyers (agency owners, clinic admins, operators at SMBs without a platform team) to adopt.

The split also matches the customer journey. SC adoption is the cheap on-ramp: get the infra primitives, encrypted secrets, supply-chain pipeline, multi-cloud abstraction. Forge is the upsell: now that your infra is described declaratively and your secrets are safe-from-agents, you can let agents drive the workflow. The same architecture, two products, two markets, one substrate underneath both.

What this means if you’re evaluating us

If you’re at a company evaluating “can AI agents actually deliver production software for us” — the honest answer in 2026 is: not by themselves, no. But the architecture is starting to exist:

• You need a declarative infra substrate. Pick SC, or Terraform + Helm + Vault + Snyk + Sigstore wired together yourself. The latter is what most teams do; it’s expensive and brittle.
• You need an agent-aware secrets workflow. Plaintext-on-disk secrets are not safe in a world where AI agents read your repo files. SC’s encrypted-in-git approach is one answer; others exist (Infisical Agent Vault, AgentCore Identity).
• You need verifiable artifacts. Cosign signatures, SBOMs, SLSA provenance — not because compliance asks, but because in a world where agents commit code, you need an out-of-band way to verify the supply chain wasn’t compromised between agent run and prod.
• You need a multi-agent layer that knows how to use the above. This is where Forge fits, but the same pattern would work on top of any sufficiently declarative substrate.

If you’re already convinced of those four things and want to take SC for a spin, the parent-stack feature page walks through the YAML shape, and the open-source CLI is on GitHub .

If you’d like to see what the multi-agent layer looks like on top, try Forge . The same workflow that ships a Forge release is, recursively, the workflow Forge runs for our customers.

We’re not pivoting. We’re widening the lens.