Software Factory Architecture for Agentic Engineering Teams

Software factory architecture for agentic engineering teams starts from one premise: the infrastructure most companies run today was built for humans who type at human speed, and that infrastructure is now the thing standing between agent output and anything a business can actually ship. This piece walks the stack layer by layer, from CI/CD through merge queues, harness design, transcript review, and code storage, to show where the old assumptions break and what replaces them.

Why agentic engineering breaks the assumptions of human-centric infrastructure

Andrej Karpathy named the earlier phase "vibe coding": a developer prompting a model, eyeballing the output, and moving on. What he named next, agentic engineering, is a different animal. It's the disciplined practice of orchestrating fleets of AI coding agents while a human stays accountable for the spec, the security posture, and the quality bar. That distinction matters because it changes who the infrastructure has to serve.

Structurally, agents write the code, open the pull requests, and keep pipelines running around the clock. The factory metaphor holds up because the hard problem doesn't disappear, it just moves. It shifts upstream, into the design of the line itself: how work gets planned, how it gets checked, how a batch of concurrent changes gets reconciled without anyone's afternoon getting eaten by a broken build.

The urgency here isn't theoretical. A survey found trust in AI accuracy dropped from 40% to 29% year over year. Adoption is racing ahead of confidence, and that gap doesn't mean agentic engineering is broken. It means the scaffolding around it, the pipelines, the review gates, the merge logic, hasn't caught up to what these systems actually produce at scale. Teams are pouring machine-speed output into tooling that assumes a person is typing it in real time, and the mismatch appears everywhere downstream.

The software factory's throughput ceiling in 2026

An AI software factory is a system for producing software with fleets of autonomous agents instead of hand-written commits, where humans define business intent up front and review outcomes on the back end. That's a meaningfully different animal from AI-assisted development, where a person leans on autocomplete or asks a chat window for a function. Here, agents run persistent loops across multi-step workflows: they plan the task, implement it, test it, self-correct when something fails, and open the PR without a human in the loop at each step.

Production examples already exist at real scale. Stripe's Minions system takes tasks straight from Slack, writes the code, passes CI, and opens pull requests, with more than 1,000 merged so far. Spotify's Honk system has merged over 1,500 AI-generated pull requests across hundreds of repositories since mid-2024, addressing agent reliability through verification loops. BCG Platinion reports that organizations running at this level see productivity gains of 3 to 5x on average, and OpenAI's own case is more extreme still: a million-line product built in five months by three engineers, with no manually written code, a 10x speed improvement over what a conventional team would need https://www.bcgplatinion.com/insights/the-agentic-software-factory.

None of that means the bottleneck vanished. The bottleneck moved rather than vanished. Writing code was never really the expensive activity, not anymore. The cost sits in trusting the code once it exists. Agents produce output at machine speed, but review, testing, and validation still run on something closer to human time, and that mismatch is exactly where 2026's throughput ceiling sits.

Agent-scale volume breaking a CI/CD pipeline designed for human typing speed

Traditional continuous integration tests a pull request against the main branch as it existed the moment the PR was opened. On a fast-moving team, main keeps changing underneath that snapshot, so by the time a human approves the PR, the version it was tested against is stale. Multiple pull requests can each show a green checkmark and still break main the instant they're merged together, because none of them were ever tested against each other.

The scale of that gap is not small. Across 200,000 merges pulled from 477 organizations, a PR that had already passed CI still broke main 0.77% of the time on teams of 2 to 5 engineers https://mergify.com/product/merge-queue. Past 40 engineers, that number jumps to 12.5%, or roughly one merge in eight https://mergify.com/product/merge-queue. The broken-main rate scales 16x with team size, and private codebases break main 4.5x more often than open-source equivalents https://mergify.com/blog/looking-for-a-bulldozer-alternative-meet-mergify. It's about coordination at volume.

Agent adoption throws gasoline on this. Teams with high AI adoption merge 98% more pull requests than teams without it, but that same cohort sees code review times stretch 91% longer and PR sizes balloon 154% https://www.bunnyshell.com/guides/agentic-development/. More PRs, bigger PRs, slower review, all landing on a pipeline that was already struggling to keep main honest before agents arrived.

Merge queue design options and the tradeoffs that matter for agent-heavy repos

A merge queue built for agent-scale volume has to serialize merges so every PR is tested against a realistic future-main, handle batch grouping and bisection on failure, and manage flaky tests without stalling the line. Get any one of those wrong and the queue becomes exactly the bottleneck it was supposed to remove.

The 2026 benchmark baseline for teams that adopt an automated merge queue is a 24% reduction in PR cycle time, which is a meaningful number on its own, but the tooling choices underneath it vary in how they get there https://cms.gitar.ai/automated-merge-queues-graphite-2026/. One widely used approach runs pricing on a free tier for open source and teams up to five users, then $21 per seat afterward, and uses a two-step CI process where lightweight checks run first before anything heavier kicks in https://mergify.com/product/merge-queue. Auto-retry and quarantine logic keep the queue moving past flaky failures, and batch processing groups PRs together and bisects the batch when something breaks, so a single bad change doesn't block everyone behind it. In a 153,000-merge dataset studied under this model, AI-assisted PRs broke main about half as often as non-AI PRs, which is a useful data point against the assumption that agent-written code is inherently riskier https://mergify.com/blog/looking-for-a-bulldozer-alternative-meet-mergify.

A second approach ties the merge queue to the shape of the codebase's dependency stack, batching and testing multiple PRs in parallel with awareness of how they stack on top of each other.

A third pattern tests independent changes in parallel by computing exactly which build targets each PR actually touches, using tools like Bazel or Nx to work that out automatically rather than re-running the whole suite every time. Flaky tests get handled by holding a PR in place while downstream PRs continue testing, then merging once a later PR clears, instead of stalling the entire queue on one unreliable test.

The reasoning problem underneath queue management itself is what none of these approaches fully solve. All of them still need a human, or a fixed rule set, to decide how conflicts get resolved, how a CI failure gets triaged, and what order the queue runs in. None of them reason about the queue the way an agent could, weighing context and adjusting order on the fly. That's the open design space right now, and it's likely where the next generation of merge tooling ends up competing. Graphite's stack-aware merge queue batches and tests multiple PRs in parallel, and Shopify reported 33% more PRs merged, with 75% of PRs flowing through Graphite.

The harness layer's greater influence on agent performance than the model

"Harness engineering" is the term most commonly credited to Mitchell Hashimoto, the co-founder of HashiCorp and creator of Terraform, from a blog post published in early February 2026. It names something that had been happening in practice without a clean label: the layer of infrastructure that sits around a model and makes it able to do a job reliably, as opposed to just answering a prompt well.

The distinction that matters is deterministic versus probabilistic control. Telling an agent to follow the team's coding standards inside a prompt is a request, and the agent complies with some probability, not a guarantee. Wiring a linter that blocks the pull request outright when standards are violated is deterministic: the outcome doesn't depend on the model having a good day. Harness engineering formalizes that gap and pushes as much enforcement as possible into the deterministic category, leaving the model to do what models are actually good at.

The numbers make the case for why this layer deserves as much attention as model selection. On SWE-bench Verified, top models paired with a well-built harness hit success rates of 70% to 90%, up from roughly 4% back in 2023 https://www.webfuse.com/blog/agentic-coding-in-2026. That is not a story about models getting smarter in isolation. The scaffolding around the model, the harness, carries as much of that improvement as the underlying weights do. Picking the best model on the market and dropping it into a weak harness causes performance to fall off a cliff. Picking a merely good model and wrapping it in a harness that handles context resets, structured handoffs, and phase gates properly will outperform the fancier model running bare.

Transcript analysis as an operational practice for tuning agent harnesses

Most teams configure a harness once and never look at it again, leaving it unmonitored indefinitely. That's the gap nobody notices until it costs them: agents accumulate dead skills, tools that get loaded into context but never called, and redundant instructions that pile up and quietly degrade performance while inflating token cost, all without throwing any visible error.

Reading the transcripts of actual agent runs is how that gap gets found. Transcript analysis reveals which tools an agent actually invokes across a batch of runs, which ones sit there unused, where the agent gets stuck in a loop it can't reason its way out of, and which chunks of loaded context never get referenced at all. An agent handed too many tools has to spend part of its reasoning budget just deciding which tool to reach for, so trimming unused skills matters as much as adding useful ones, the same principle behind cutting tool sprawl on a human engineering team.

The most detailed public look at how this plays out inside a production system came from an April 2026 reverse-engineering of Claude Code's architecture. It documented a five-stage progressive compaction pipeline, budget reduction, snip, microcompact, context collapse, and auto-compact, along with subagent isolation that rebuilds permission contexts from scratch for each subagent, and a hook pipeline spanning 27 distinct event types. It stands as the most granular public account to date of the internal design choices behind a production agent loop, and it's a useful reference point for any team trying to figure out how much compaction and isolation logic their own harness actually needs.

Code storage and version control requirements when agents are the primary readers and writers

Version control built for humans optimizes for a specific set of behaviors: a responsive UI, people pulling code to browse it at their own pace, and merges that happen occasionally and in large chunks. None of that matches how agents actually touch a repository. Agents clone it, scan large stretches of it for context, make many small targeted edits, and often do all of this concurrently across separate worktrees. The access pattern is high-frequency, programmatic, and parallel, closer to a database workload than to a person clicking through a pull request in a browser.

A cost risk buried in this transition is easy to miss during a fast rollout. In the rush to get agents into the workflow, organizations often let individual developers expense whatever single-vendor subscription they like. This problem doesn't appear on a dashboard until the invoice or the security review does.

OpenAI's Codex is a concrete example of where the storage layer has to go to keep up. It uses multi-agent worktrees so parallel tasks can run without stepping on each other. Each agent needs fast, isolated access to a consistent state of the repository, and it needs that without blocking every other agent working the same codebase at the same time.

Thinking about the full infrastructure stack as a composable set of decisions, not a platform selection

Lay the layers out side by side, merge management, harness design, transcript analysis, code storage, and a pattern becomes visible: each one has its own distinct failure mode under agent load, and a weak point in any single layer drags down everything built on top of it. A perfect merge queue sitting behind a bloated harness doesn't save the team anything. A tuned harness feeding into version control that can't handle parallel worktrees just moves the traffic jam one layer over.

This is where all-in-one platforms tend to struggle. They were designed around human-centric workflows from the ground up, so adapting one to agent volume means fighting its defaults at every layer instead of building for how agents actually behave from day one. The more useful posture is composability: take what's actually needed from purpose-built tooling at whichever layer is the current bottleneck. An agent-aware merge queue where queue management is choking throughput. Transcript analysis where harness bloat is quietly eating performance. Storage built for concurrent agent access where the old locking model has become the ceiling.

None of this works as a substitute for engineering discipline that should already exist. Agentic AI amplifies whatever foundation is already there, it doesn't replace it. Teams with solid CI/CD, real test automation, and a platform engineering function that actually has authority can turn agent velocity into gains that compound predictably. Teams without those foundations will just generate chaos faster than they used to, and they'll generate it at machine speed. 80% of developers are now using AI coding agents in their workflows https://www.bunnyshell.com/guides/agentic-development/. Trust in AI accuracy stood at 40% one year prior to 2026 https://www.bunnyshell.com/guides/agentic-development/. Trust in AI accuracy fell to 29% in 2026, down from 40% year-over-year https://www.bunnyshell.com/guides/agentic-development/. Performance on more difficult "pro" variants of the SWE-bench benchmark reached 50–77% in 2026 https://www.webfuse.com/blog/agentic-coding-in-2026. PRs merged per developer increased 33% after Graphite adoption at Shopify https://cms.gitar.ai/automated-merge-queues-graphite-2026/. 75% of PRs now flow through Graphite at Shopify https://cms.gitar.ai/automated-merge-queues-graphite-2026/. Stripe Minions agents merge 1,000 pull requests each week in a Ruby codebase https://www.augmentcode.com/guides/what-is-a-software-factory. Spotify's Honk system has merged 1,500+ AI-generated PRs across hundreds of repositories since mid-2024 https://www.augmentcode.com/guides/harness-engineering-ai-coding-agents. Cursor has reported annual recurring revenue of $2 billion https://www.webfuse.com/blog/agentic-coding-in-2026. McKinsey found that AI-centric organizations see EBITDA margin increases of 12–14 points https://www.cio.com/article/4134741/how-agentic-ai-will-reshape-engineering-workflows-in-2026.html. 90% of professional developers were using AI coding agents at work at least weekly https://ai.plainenglish.io/ai-coding-agents-in-2026-how-developers-are-changing-the-way-they-code-88c2dbd237ab. By 2028, 75% of enterprise software engineers are projected to use AI coding assistants https://www.coderio.com/blog/innovation/agentic-ai-software-development-changes-tools-start-making-decisions/. By the end of 2026, 40% of enterprise applications are expected to include task-specific AI agents embedded in their workflows https://www.coderio.com/blog/innovation/agentic-ai-software-development-changes-tools-start-making-decisions/.