{"slug": "how-we-delegate-40-of-tickets-to-ai-in-our-agentic-sdlc", "title": "How we delegate 40% of tickets to AI in our agentic SDLC", "summary": "A company redesigned its software development lifecycle to delegate 40% of tickets to AI agents, moving tasks from planning to production with human gates. The system uses context lakes, guardrails, and visibility to let agents handle coding, planning, and QA autonomously. This approach aims to accelerate delivery by minimizing manual approvals and handoffs.", "body_md": "# How we delegate 40% of tickets to AI in our agentic SDLC\n\n### We redesigned our SDLC to make sure AI can take tasks from ticket all the way to production\n\nAI beats us at coding.\n\nBut it’s also better and faster at nearly everything else: planning, QA, working with all the tools in your SDLC.\n\nSo why aren’t we letting agents take features and bugs all the way, from ticket to production?\n\nAll we should have to do is decide **what** to build and let agents do what they do best.\n\nBut they can’t.\n\nBecause everyone’s SDLC is manual today.\n\nApprovals, reviews, handoffs. All things that make us feel comfortable but are mostly unnecessary.\n\nThat all looks like theater to agents because they just want to run forward.\n\nSo we need to redesign what software delivery looks like, **serving agents first**.\n\nThat means 3 things have to be in place: context, guardrails, and visibility.\n\n**Context** so the agent starts from a complete picture of the work, not just a ticket title.**Guardrails** so it knows what’s in scope, what to leave alone, and when to stop and ask.**Visibility** so engineers can see what’s happening without watching agent logs all day.\n\nLet’s build the infrastructure to support it, from the moment a ticket lands to the moment it ships.\n\n**What we’re building**\n\nBefore getting into the details, here’s the shape of the whole thing.\n\nIt’s five phases that alternate between agent work and human gates.\n\n**Phase 1: Planning - **Turn a raw ticket into something an agent can actually work on with rich context, a detailed PRD, and a comprehensive tech spec.\n\n**Phase 2: In review** - A scorecard validates that the work is safe and scoped enough for an agent. A PM signs off on the PRD and the engineer signs off on the tech spec. They pass it on to a coding agent.\n\n**Phase 3: In Development** - A Cursor or Claude Code agent works on the ticket and keeps the entity updated as the agent works.\n\n**Phase 4: Preview** - Once the PR is open and running in a cloud environment, an engineer and PM can preview it. Then they can hand it off to a deploy flow.\n\n**Phase 5: Deploy** - Live checks against current incidents and freeze windows, generates release notes, and deploys it.\n\nThe rest of this post walks through each phase, starting with what you need in place before any of it works.\n\n**Prerequisites: your context lake**\n\nFor agents to do their best work, they need the best context - a live model of your engineering systems that every workflow and agent can read from.\n\nSpecifically for this guide, you’ll need three things to be in their context:\n\nServices, with tier (T1/T2/T3), owning team, repo links\n\nGitHub data synced via Port’s native integration: repos, open PRs, recent commits, CODEOWNERS\n\nWork items from Jira, Linear, or GitHub Issues, linked to the services they touch\n\nThe workflows we’re about to build can also pull data via MCP as they need.\n\nFor example, if agents want to write accurate tech specs, they may want to read past ADRs, runbooks, or past specs in Notion or Confluence.\n\nTo improve the PRD we will connect to real customer problems, so you might also want to connect MCPs for Zendesk or Intercom.\n\n**Phase 1: Planning**\n\nThe whole workflow is triggered when a ticket is created. Could be in Jira, Linear, or just in Port.\n\nWe recommend creating a generic blueprint like work_item so every step reads from and writes to these fields:\n\n```\nservice          →   linked to service entity in catalog\nteam             →   from catalog ownership\ntier             →   T1 / T2 / T3\nblast_radius     →   low / medium / high (calculated)\nopen_prs         →   count against linked repo\nactive_incidents →   boolean from incident tracker\nprd              →   markdown, written by workflow\ntech_spec        →   markdown, written by workflow\nstage            →   incoming / enriched / prd_draft / prd_ready / spec_draft / spec_ready / ready\n```\n\n**Step 1: Enrich the tickets with details from the context lake**\n\nThe workflow queries the context lake to resolve any missing details in the work item like its component or label. It might also add the service tier, owner, and repo from the catalog or calculate blast radius from the dependency graph, fetch open PRs, and check for active incidents. Everything gets written to the entity and the ticket moves on to the next stage.\n\n**Step 2: Draft the PRD based on a PRD skill**\n\nPort AI runs a PRD skill against the ticket, the enriched entity, and similar PRDs from your knowledge base. Draft lands on the entity, stage moves to prd_draft, PM gets a Slack ping.\n\nThe skill you write defines the structure.\n\n**Step 3: Pause for PM review**\n\nIf the first draft is structurally complete but thin on evidence, the PM can open Port AI chat from the work item and question the gaps:\n\n*“How many customers have asked for this in the last 6 months?”*\n\n*“Which services would this affect? What’s been touched recently?*\n\n*“Why shouldn’t we build this?”*\n\nPort AI will then update the PRD based on this conversation.\n\nOnce they’re happy with the PRD, the PM marks it ready and it moves along.\n\n**Step 4: Draft the tech spec based on a tech spec skill**\n\nSame pattern as before but different inputs. Port AI runs a tech spec skill against the PRD, codebase data in the catalog or MCPs, and ADRs from your knowledge base. The draft lands on the entity and the engineer gets pinged.\n\n**Step 5: Pause for engineer review**\n\nThe engineer can then open Port chat and iterate on the tech spec:\n\n*“What’s changed in this area in the last 30 days? Who’s been active there?”*\n\n*“Are there existing patterns we should follow? Anything we’re duplicating?”*\n\n*“What could go wrong? What files have caused incidents recently?”*\n\nBased on the chat, the tech spec gets updated.\n\nOnce the engineer marks it ready, it moves to the next stage.\n\n**Phase 2: In review**\n\nBefore a ticket can be handed off to an agent, two things need to happen: it has to clear an automated scorecard, and an engineer has to actually pick it up off the board (if you want).\n\n**The scorecard check**\n\nThe scorecard is your governance layer (it can also work as a condition in the workflow). It asks two questions about every work item leaving Phase 1:\n\nIs it scoped enough for an agent to do?\n\nIs it safe to automate right now?\n\nIf any rule fails, then the work item gets marked blocked with the reason.\n\nIf everything passes, then it moves to ready and continues.\n\nA reasonable starting set of rules:\n\n**Service tier is T1**→ T1 service, requires human delivery** Blast radius is high or un-assessed**→ Too risky to automate without scoped review** Active incidents on the service**→ No changes while the service is unstable** Priority is P0 / P1**→ Urgent work goes directly to an engineer** Acceptance criteria is empty**→ PRD incomplete, can’t validate output\n\n**The Kanban dashboard**\n\nOne thing that breaks down fast with agentic workflows is that the work becomes invisible. You delegate something, the agent runs, and unless you’re watching the agent’s logs you have no idea where it is. Multiply that by ten parallel agents and you’ve lost track of your work.\n\nThe fix is a dashboard in Port that puts every work item on one page, grouped by where it is in the pipeline.\n\nI decided to show work in a [custom widget](https://docs.port.io/customize-pages-dashboards-and-plugins/dashboards/custom-widgets/#custom-widget) that renders a Kanban board off the work item entities, with columns running on statuses: Incoming → Planning → For review → Ready to Delegate → In Development → Preview → Deployed\n\n**Phase 3: In Development**\n\nAt this point your work item or ticket should be enriched with plenty of context, a PRD, a tech spec, and approval from a PM and engineer.\n\nIt’s time to pass it to a coding agent to implement.\n\n**Let’s build a delegation action**\n\nBuild a self-service action in Port called “Delegate to Claude Code/Cursor.” It lives on the work item entity and shows up as a button on the Kanban card. When you click it, the action constructs a prompt based on the work item and kicks off the agent.\n\nThe point is that the coding agent starts from a complete picture of the work: what to build, how to build it, which files are in scope, and the architectural decisions that already apply. It can still reference Port while it’s working, but it’s better to have as much information up front as possible.\n\nKeeping the board honest while the agent runs. Remember the “ten parallel agents and you’ve lost the plot” problem from Phase 2? This is where we solve it.\n\n3 Port automations listen to GitHub events and update the entity in real time:\n\nPR opened → write the PR link to the entity, move stage to delegated\n\nPR merged → set stage to done, record the timestamp\n\nCI fails → flag the entity and move it to needs_attention\n\nEngineers can see which tickets have active PRs, which are stuck in CI, and which are done, without opening agent logs or GitHub notifications.\n\nIf you want the agent to diagnose and retry CI failures rather than just flagging them, that’s a separate pattern covered in the [auto-healing CI article](https://newsletter.port.io/p/how-to-build-self-healing-ci-pipelines).\n\nOnce the agent’s PR is open and ready for human eyes, the work moves to Phase 4.\n\n**Phase 4: Preview**\n\nOnce the agent’s PR is open, the work moves into the preview phase.\n\nI won’t go into too much detail here, but just give you some idea of things you can add to Port, each one independently useful.\n\nPick what solves your current bottleneck.\n\n**AI as judge**\n\nBefore human review, run a Port AI check that compares the diff to the tech spec and flags any deviations, like if it modified “do not touch” files or missed acceptance criteria.\n\n**Spin up a preview environment**\n\nAdd a self-service action or automation that provisions a cloud environment for the PR branch and posts the link on the PR.\n\n**See your PR queue**\n\nBuild a personal dashboard per engineer showing every PR assigned to them, the preview environment to check it, and how long it’s been sitting.\n\n**Nudge reviewers**\n\nAdd an automation or workflow on the work item entity that pings the assigned reviewer in Slack with the PR link and work item context.\n\n**Phase 5: Deploy**\n\nThis phase is triggered when the reviewer from the preview phase is happy with the agent’s work. It can happen with a status change or a self-service action.\n\nBefore anything ships, the workflow runs live checks against the current state.\n\nHere’s the general flow:\n\nGate check, against live state:\n\nActive incident on any service in the blast radius? Query PagerDuty. Hold if yes\n\nOpen freeze window, or another deploy already in progress? Hold\n\nBlast radius high? Require explicit engineer approval on the entity\n\nDeploy. The work gets deployed through a self-service action in Port\n\nGenerate release notes. Port AI builds them from the entity: what was built (from the PRD), what changed (from the PR diff), what was tested. (Optionally, you can push it to your release notes system)\n\nIf something goes wrong, rollback is one click (for you or an agent). It’s an action on the entity, pre-loaded with the deployment reference so you don’t waste any time.\n\nIf you want to go further, you can run a full release risk assessment before the deploy even starts by scoring change volume, blast radius, and rollout strategy automatically. That’s a separate pattern covered in the [release risk assessment](https://newsletter.port.io/p/how-to-build-a-release-risk-assessment-agent) guide.\n\n**Measure how fast work flows**\n\nWhen investing in a workflow like this one, you need to see how well it’s working. So let’s measure lead time: how long it takes to go from ticket creation to production.\n\nEvery stage in this workflow writes back to the work item: the stage transitions, who acted, when, so the data is already in the ticket.\n\nSo what you end up with is:\n\n**Lead time per service:** how long the average ticket takes from “Ready for ATR” to deployed, broken down by service. Tells you which services are genuinely autonomous and which are still bottlenecked on humans.\n\n**Time spent per stage:** where work actually sits. If everything is piling up at “Ready to Delegate,” your scorecard is too strict. If it’s piling up at “Preview,” reviewers are overloaded.\n\n**Delegation rate: **what percentage of work items actually got delegated to an agent versus handled manually. The one number that tells you whether the system is being used.\n\n**Human intervention points:** which stages needed someone to step in. Buildup points in this workflow shows that agents might need more context, better guardrails, or a different scorecard rule.\n\nThose numbers tell you something cycle time never will: where in the delivery process your team is actually bottlenecked, and which steps are saving time versus adding friction.\n\nThat’s the full workflow. We started from a two-line ticket to a monitored production deploy. And we had a human in the loop at every gate that needed one.\n\nIf you build any agentic workflow, I hope you build this one to see what agentic engineering is all about.", "url": "https://wpnews.pro/news/how-we-delegate-40-of-tickets-to-ai-in-our-agentic-sdlc", "canonical_source": "https://newsletter.port.io/p/how-we-delegate-tickets-to-agentic-sdlc", "published_at": "2026-05-28 18:52:36+00:00", "updated_at": "2026-06-17 19:22:00.975355+00:00", "lang": "en", "topics": ["ai-agents", "ai-tools", "ai-infrastructure", "developer-tools", "ai-products"], "entities": ["Cursor", "Claude Code", "Port", "Jira", "Linear", "GitHub Issues", "Notion", "Confluence"], "alternates": {"html": "https://wpnews.pro/news/how-we-delegate-40-of-tickets-to-ai-in-our-agentic-sdlc", "markdown": "https://wpnews.pro/news/how-we-delegate-40-of-tickets-to-ai-in-our-agentic-sdlc.md", "text": "https://wpnews.pro/news/how-we-delegate-40-of-tickets-to-ai-in-our-agentic-sdlc.txt", "jsonld": "https://wpnews.pro/news/how-we-delegate-40-of-tickets-to-ai-in-our-agentic-sdlc.jsonld"}}