Agentic SDLC in practice: Insights from engineering leaders

In recent months, I’ve had the pleasure of connecting with more than 200 senior engineering leaders, discussing their requirements, challenges, and tips around infusing their SDLC with AI. Where do you start? What’s next? How to get it right?

In May, I hosted 12 engineering leaders building agentic capabilities for a candid roundtable on their organizations’ agentic journeys. The conversation was candid, technical, and full of real-world examples. The goal was simple: learn from each other, not from vendors. We discussed what’s working, where teams are stuck, and how to scale adoption and maximize AI ROI.

Two agentic workflows in practice

Two teams shared what they actually built.

From ticket to PR: how a commerce engineering team built autonomous ticket resolution

The team built an autonomous developer agent to automate the full ticket lifecycle: developers tag Jira tickets, the agent plans the implementation, gets human approval, then a coding agent opens a PR. Port orchestrates everything: status updates, human approvals, agent invocations, with the Port MCP server feeding agents live SDLC context. Since February 2026, 540 Jira tickets were autonomously handled, with zero production incidents.

Agentic Incident Triage in practice at a sports data company

When a P1 or P2 incident fires in ServiceNow, Port triggers an AI agent that gathers context - service ownership, recent deployments, on-call engineers - and posts a structured summary to Slack in seconds. No custom Python. Built entirely on Port's workflow engine, with auto-discovering and ingesting of agents from AWS Bedrock. Bonus: the agent immediately exposed data quality gaps - when the context comes back empty during a live incident, everyone notices.

The current state of agentic SDLC: 3 Key learnings

1. Engineering teams are building agents and skills in silos

The most consistent pattern we’ve gleaned is that teams are building agents, skills, and MCPs independently - in Cursor, Bedrock, Copilot,vanilla Python. Most are invisible across the org. No shared registry. No governance.

One platform engineering lead described it: “in the last three weeks alone, four different teams independently built a merge request review agent. Same problem, four parallel solutions, zero coordination.

rganizations getting ahead aren't slowing agents down. They're building a registry - a single place where agents, skills, and MCPs are cataloged, discoverable, and Iinfrastructure, not bureaucracy.

2. Context Quality is the real bottleneck - not the model

One team's breakthrough: they asked the agent when a service was last deployed - and it knew. It found the right repo without being told, understood which team owned it, and followed their conventions. Not because the model was better. Because the context was there.

The sports data company's incident agent exposed the same truth from the opposite angle: when they launched the incident agent, developers immediately asked it: 'we've put all this data into Port - what are you going to do with it?' The agent answered that question. But it also exposed uncomfortable gaps - missing service ownership, incomplete runbooks, stale data. When an incident fires and the context enrichment comes back empty, everyone notices.

The lesson: the model is not the variable. The context is.

3. The platform team's role has fundamentally changed

The horse has bolted. Developers are not waiting for the platform team to hand them agent capabilities. They are building their own - with or without guardrails.

One platform engineering lead put it directly: gating agent creation is a losing battle. The platform team’s job isn’t to control who builds, but to define what safe building looks like. Frameworks. Governance Make the golden path the easy path.

Another leader described a progression many recognized: engineers building skills in their own repos → shared repositories → non-technical teams like product managers, HR, then asking for a marketplace (no Git access needed) so they can share and consume skills. . They now have w "nano engineers": non-technical people building internal tools on top of the Port platform. The platform team didn't plan for this. They designed for governance and it enabled something bigger.

3 Open questions

Three questions remained open following our discussion:

1. Who owns the outcome when an agent writes the code?

As agents become more autonomous, the accountability model breaks down. Is it the assigned engineer? The on-call? A dedicated AI team? No clear answer yet.

2. How do you make agents improve over time?

Mining session logs, building shared memory, identifying underperforming skills - some ideas are emerging, but the path is not yet clear.

3. How do you govern non-technical builders without becoming a bottleneck?

Everyone is becoming a builder. The risk is critical business functions built on ungoverned tooling - and engineers left cleaning up the mess. The platform built now must support everyone as builders while keeping the organization in control.

What the Best AI-SDLC Teams Have in Common

The organizations making real progress are not winning because they have better models or more AI budgets. They built the infrastructure first: context lake, governance, orchestration, human in the loop. Every agentic workflow they ship benefits from it.

Accelerate your AI-SDLC journey

If you are a platform team thinking about where to start - start there.

{{cta_8}}