AI agents have made writing code fast. The bottleneck has shifted to everything surrounding the code: planning, review, approvals, and handoffs. For platform teams, the opportunity is to turn those steps into a governed, scalable factory line - rather than a collection of disconnected automations.

TL;DR: Main insights

• The bottleneck has moved from writing code to the process around it. You must redesign the entire delivery flow, not just add agents to existing steps.
• A unified context layer is the foundation. It gives every agent the same view of services, owners, dependencies, and standards - and can reduce agent costs by up to 80%.
• Agents need to run on deterministic rails: owned, certified, scoped, and wrapped in risk-based human-in-the-loop gates.
• Measurement closes the loop. Track what ships, how much ran without human intervention, and which step creates the most friction.

Matar Peles, Field CTO at Port, works with engineering organizations navigating the shift to AI-native delivery. He brings a practitioner's perspective on what goes well, what breaks down, and what platform teams need to build to make agentic workflows scale responsibly across an organization.

You can watch the full discussion here if you missed it.

What an AI software factory is

Matar opens with a framing borrowed from Anthropic's AI-native SDLC playbook: code is no longer the bottleneck. In a traditional software development lifecycle (SDLC), every stage runs at human speed, and building was historically the longest step. Now that agents write code quickly, the slowest points are the stages where work waits for a person.

The contrast between two models makes this concrete:

• Traditional SDLC: Planning, design, build, test, deploy, and maintain are each owned and executed by a human - even if practitioners use tools like Cursor or Claude Code within a step.
• AI-native SDLC: Each stage works like a factory line. An agent picks up the task and produces a draft. The human owner reviews it, iterates if needed, or skips review entirely when risk is low.

Adding AI tools to a traditional process does not make it AI-native. The process itself must change. Anthropic's version runs on markdown files and specs stored in a repository. An agent writes an intent file, a human approves it, and the merge triggers a hook that starts the next agent on the spec, then the build, and so on. Skills, sub-agents, evals, and branch protection provide governance at the repo level. OpenAI and Uber have published similar architectures.

The most common starting point is an idea-to-production factory line, but teams also build lines for cloud resource provisioning with Terraform pull requests, incident remediation, CI/CD fixes, and security vulnerability remediation.

Why scaling is the real challenge

Matar is direct: "The challenge about software factory is not to chain agents." The hard part begins after the first working flow, when you extend it across teams, services, and processes.

Teams that have built a first flow quickly encounter questions like these:

• How do we control what data each agent can access?
• How do we block an agent from a risky operation?
• How do we certify skills against our standards?
• How do we cap budgets per team or factory line?
• How do we assign owners to factory lines, skills, agents, and plugins?
• How do we measure ROI, quality, and efficiency, and audit every operation?

One webinar participant framed the core issue well: putting agentic workflows on deterministic rails with proper guardrails. Matar agreed. The factory defines a static, step-by-step process. Agents handle the non-deterministic work inside each step. That separation is what makes the system governable.

The platform pillars

Matar describes five components he sees in mature agentic SDLC platforms.

Unified context layer. This is the shared source of truth every agent reasons over. It connects services, Kubernetes workloads, cloud resources, incidents, pull requests, owners, and the standards that apply to each. Two benefits stand out:

• Cost: Instead of each agent making many MCP calls and loading large inputs and outputs, agents read one prepared layer. Port's research found this can reduce agent costs by up to 80%.
• Quality: Agents get a consistent answer every time, which reduces hallucinations and drift.

Agent, skill, and MCP registries. Enterprises need visibility into which agents, skills, and Model Context Protocol (MCP) servers exist - plus the ability to certify and govern them. That includes lifecycle definitions, activity tracking, and enforcement of what tooling and data each agent can access.

Factory lines. Each line is a deterministic flow where every step is owned by an agent workflow, with a named persona assigned for human review.

Governance. This layer controls who can modify factory lines, who can build them, and who steps in as the human in the loop. At enterprise scale, you must define clear owners and approval flows for every workflow, or you lose control.

Self-improvement and ROI tracking. The most advanced factories analyze their own runs and suggest fixes. They also measure cost, time per feature, rework rate, and artifact quality - giving platform teams the data they need to prove value to the business.

Seeing it in practice: The demo

Matar demonstrates a factory modeled on Anthropic's playbook, with stages for plan, design, build, test, deploy, and maintain. He cautions that your factory will differ based on how your teams work and the types of features you release.

The context layer

The demo represents the context layer as a data model - a set of connected entity types similar to tables in a database. Entities include services, products, teams, skills, AI agents, and Jira issues. The business process itself is modeled too: signals, intents, specs, and plans each have an entity type. When an agent finishes an artifact, the factory stores it so you can track, score, and learn from it over time.

You do not ingest this data manually. Connectors discover information from tools you already use - such as GitHub, Kubernetes, cloud providers, and Jira - so those tools remain the source of truth. Agents then query the layer through MCP.

This also addresses a common question about whether context should live in markdown files or MCP. Matar explains that markdown files in a repo work well for single-repo architectures, but become limiting when one service spans multiple repositories. Some teams build their own database or RAG system instead. The same layer can ingest signals from sources like Slack, Gong, and field teams, connecting those signals to feature ideas at the first factory step.

The agent registry and certification

Enterprises often want to provision agents on platforms they already trust - such as AWS Bedrock AgentCore, Claude Managed Agents, or Azure AI Foundry - rather than a single vendor's runtime. The demo registry integrates with these platforms and surfaces each agent's runtime, owning team, cost, tools, skills, and session activity.

Visibility alone is not enough. The demo adds:

• A production readiness score that encodes your standards for what makes an agent trustworthy.
• A certification workflow that runs whenever an agent or skill is created or updated, using AI agents to score it based on prompt, metadata, and sessions.
• A self-service action that lets engineering teams provision a new agent on the golden path - with a service account and monitoring - so it starts with a full readiness score.

Factory lines on deterministic rails

Each step in the demo is a workflow, not just an agent call. Around the agent step, the workflow includes conditions, guardrails, approvals, and human-in-the-loop branches. Importantly, some steps do not need an agent at all. A deploy step, for example, can remain a deterministic GitHub workflow.

Human intervention is risk-based. Conditions can use assessed risk, service tier, blast radius, or domain classification - and each branch decides whether to involve a person. In the demo, an agent assesses the risk of a new feature to drive that decision automatically.

The factory control room

A dashboard tracks agent spend, cost per feature, budget status, active stages, and rework rate. A scoring system rates artifacts such as PRDs, tech specs, and code plans. You can drill into low-scoring specs, open the file, fix it, and watch quality improve over time. Because everything is queryable through MCP, engineers can also pull this data directly from their IDEs.

What this means for your platform team

Matar does not expect a single factory line to serve an entire company. A payments team and a front-end team likely need different lines. The platform team provides a governed playground where each team builds its own lines or reuses existing agents, within company standards.

He also expects the core responsibility of platform engineers to evolve: from building a platform that gives developers autonomy, to building the AI software factory infrastructure that enables every team to build their own lines safely. Platform teams cannot become a bottleneck when every team is a builder - so they provide the foundation instead.

His advice aligns with platform engineering fundamentals: start with an MVP, measure from day one, and iterate on metrics.

If you are starting this work, a practical sequence emerges from the talk:

1. Map the end-to-end process from the moment work arrives to the moment it ships, so the line has defined steps.
2. Build the context layer and connect it to the tools your teams already run.
3. Stand up registries and certify agents and skills before trusting them in a line.
4. Assemble the first factory line with scoped agents, named owners, and risk-based human gates.
5. Add dashboards for cost, rework, and quality, then use them to find the step holding everything up.

​

If you enjoyed this, find more great insights and events from our Platform Engineering Community.

For more comprehensive guidance, check out the Platform Engineering Certified Architect Course and learn best practices from industry experts.

​

Key takeaways

• Redesign the process, not just the tooling. Adding agents to a human-paced SDLC does not remove the bottlenecks. Map the full flow and decide where agents lead and where humans review. The process itself must change for the factory to work.
• Invest in the context layer first. A shared, connector-fed graph of services, owners, and standards improves answer quality and - based on Port's research - can reduce agent costs by up to 80%. It also keeps your source of truth in the tools you already use.
• Put agents on deterministic rails. Certify agents and skills, assign owners, scope access, and wrap each agent step in conditions and risk-based human gates. Deterministic steps such as deploys can remain automations.
• Measure from day one and plan for many lines. Track cost, rework, and artifact quality to prove ROI and find bottlenecks. Expect different teams to build different lines, with your platform providing the governed foundation that makes that safe.