Gartner names Port as a key AI software factory platform provider

This month, Gartner published its first research on AI software factories, and it names Port as a platform companies can build their factory on.

Over the past few weeks, X and LinkedIn have exploded with engineers talking about AI software factories and sharing the ones they're building. 

More companies tell us they've already tried building a factory in-house and are now comparing vendors, which rarely happened a few months ago. Practitioners named the category first, and now Gartner has confirmed it. 

For me, this means the market is ready to move from AI-assisted coding to an entirely AI-led SDLC.

Below, I walk through what Gartner found and add what we've learned from hundreds of customer conversations.

What is an AI software factory?

According to Gartner, 71% of software engineering teams use agents in their SDLC. Yet most don't actually ship faster. The reason they found is that humans still have to move the work from stage to stage: handoffs, approvals, and context between stages.

We see another factor as a bottleneck. Most agents still run siloed on a developer's laptop. That makes it impossible to work as a team. But when agents run centrally in the cloud, that opens up the possibility of a team of humans and agents seamlessly working together to ship software. When the work runs in the cloud, every agent created by the team works from the same context and rules.

That connected system is what Gartner calls an AI software factory: agents move work from ticket to production, with context, guardrails, and approvals built into every step. Gartner calls it the "North Star" for AI-enabled engineering. They expect 45% of large engineering organizations to run one by 2028.

Gartner is also clear that a software factory doesn't remove humans. I agree, but I think most people have the new role wrong. The common assumption is that engineers will spend their days approving, rejecting, and iterating on agent work. In our view, that will be about 10% of the job.

The other 90% will be building and improving the factory itself: the flows, the standards, the context agents use, and the rules for when a human needs to step in. 

Engineering will be measured on metrics around how efficient the software factory is, the quality of the work that flows through it, and throughput. It will no longer be measured by DORA metrics.

What are the three ways to build one?

Gartner describes three paths:

1. DIY: assemble the factory yourself from separate tools.
2. Buy: buy an all-in-one factory product.
3. Horizontal AI software factory platform: build your factory on a platform that connects to the tools you already run.

Port leads you on the third path. Gartner also cautions that not choosing is a choice too. If every team connects its own agents and tools, you end up with a “factory” nobody designed. As it grows, it becomes harder to know which agents exist, what they can access, and whether they follow your standards, not necessarily increasing effectiveness but definitely increasing chaos and risk.

I think this is the most important point in the research. In most of our first calls, the conversation starts with which agent to buy. But the bigger decision is actually the architecture those agents will run on.

Which option works across your whole company?

Here's what we've learned from our customers: building a factory is easy, and managing it at scale is hard.

The first flow almost always works. It's usually a simple automation that sends tickets to Claude for one team. The trouble starts when that turns into hundreds of flows and thousands of agents across dozens of tools. Then new questions appear:

• Which data can each agent see?
• Are agents using approved skills?
• Who owns each agent?
• How much can each team spend?
• Who reviews hundreds of AI pull requests a day?
• How do you prove ROI to leadership?

These are the questions where most factories stall. They're about access, ownership, and cost, not code quality, so a better model answers none of them. Here's how each option handles them:

Uber built its own context graph, MCP gateway, LLM gateway, and environments. It works for them because they have a very large platform team. But very few companies have the kind of bandwidth needed to support it. Even fewer can keep it all current as models keep changing.

Products like 8090 and Factory.ai focus on improving their own agents, which puts them closer to competing with Anthropic and OpenAI than to helping you build a factory. To scale, you don't need another agent. Most enterprises we work with already run more than one agent, such as Claude Code, Copilot, and Cursor.

Above all else, agents working in the factory need support, just like a traditional factory needs machines, assembly lines, managers, and reports. Without them, adding workers or agents just adds chaos. That's the operating layer a horizontal platform gives you:

• Context Lake: one live map of your services, owners, dependencies, and standards. Instead of searching repos and wikis to figure out who owns a service or how a team codes, agents look it up, so they make fewer mistakes and spend fewer tokens.
• Governance: an identity and list of privileges for every agent, cost limits per team, and a full audit log of every agent and human action.
• Agent, skill, and MCP registry: every agent, skill, and MCP server in one place, approved, owned, and reusable, so teams stop rebuilding the same thing.
• Human in the loop: approve or reject agent work at critical checkpoints right from within their Slack, Jira, Claude, or the IDE. Review is based on risk, so a config change can merge automatically while a payments change waits for a senior engineer. If every agent change needs a human, reviewers become the bottleneck, or they start approving without really looking. Gartner flags that second risk too.
• Orchestration: the assembly lines, like ticket to PR, incident fixes, and vulnerability fixes.
• ROI, Efficiency & Quality measurement: quality, cost, and throughput across the whole factory.

When these standards are built into the platform, every new factory line and agent automatically gets them. Teams can build freely without anyone chasing them later for compliance.

Success story: How did dLocal scale its AI Software factory?

dLocal took the horizontal platform path. They process more than 500 million payments a month with 400 engineers across 60 teams and maintain a 99.99% uptime SLA. Needless to say, a bad change is expensive. CTO Alberto Almeida noticed early that the problem wasn't tools, it was context. Agents working from scattered data make confident, costly mistakes.

dLocal made two separate decisions, one for the agent and one for the foundation.

For the agent, dLocal built its own. Instead of buying a packaged agent like those from Factory.ai or 8090, it built dCoder in-house, shaped around its own codebase and payment systems. When a better model comes out, dLocal can plug it into dCoder or replace dCoder entirely.

For the foundation, dLocal chose Port. It connected its services, infrastructure, repos, teams, and policies in Port's Context Lake, and it kept every tool it already ran. Port does the work around dCoder at each step:

1. A ticket arrives, and Port triggers dCoder.
2. dCoder pulls context from Port: which services are involved, who owns them, where the code lives, and how the team codes.
3. dCoder plans within dLocal's standards, writes the code, and runs security and QA checks.
4. dCoder opens a PR, and an engineer approves it or sends it back.

Port also gives dLocal leadership a view of the whole factory. Alberto tracks one metric above all: end-to-end agentic coverage. He watches it in Port along with rejection rates and how engineers work with the agent. In his words: "My entry point for all of that is Port."

Today, dCoder resolves 45% of tickets end-to-end, and lead time and MTTR are both down 50%.

How do you choose?

My advice is to treat these as two separate decisions, as dLocal did: which agents you use and which foundation they run on.

The decision on which agent will keep changing. New coding agents and models ship every few weeks, and the best one for your team today probably won't be the best next quarter. You want to be free to switch or to run several agents side by side for different jobs.

The foundation decision should last. Your context, permissions, audit trail, ownership, and metrics take real work to set up, and you shouldn't have to rebuild them every time you change agents. Gartner warns about this as well, noting that a factory can lock you into one vendor, model, or workflow.

Keeping the two decisions separate lets you use the best agent for each job without breaking the foundation it runs on. For the foundation itself, Gartner suggests weighing your current tools, your compliance needs, and the strength of your platform team.

Whatever you pick, pick it on purpose. As Gartner states, if you don't, scattered tools will make the choice for you.

If you’re interested in reading the full Gartner report, you can download a copy here. And If you want to see what an AI Software Factory looks like in practice, book a demo with one of our experts, and we’ll show you how Port is helping teams achieve faster end-to-end delivery.

{{from_manual_to_autonomous_engineering}}