 |
VOOZH | about |
|
VOOZH | about |
We’re so glad you’re here. You can expect all the best TNS content to arrive Monday through Friday to keep you on top of the news and at the top of your game.
Check your inbox for a confirmation email where you can adjust your preferences and even join additional groups.
Follow TNS on your favorite social media networks.
Become a TNS follower on LinkedIn.
Check out the latest featured and trending stories while you wait for your first TNS newsletter.
AI beats us at coding.
But it’s also better and faster at nearly everything else: planning, QA, working with all the tools in your SDLC.
So why aren’t we letting agents take features and bugs all the way, from ticket to production?
All we should have to do is decide what to build and let agents do what they do best.
But they can’t.
Because everyone’s SDLC is manual today.
Approvals, reviews, handoffs. All things that make us feel comfortable but are mostly unnecessary.
“Everyone’s SDLC is manual today. Approvals, reviews, handoffs. That all looks like theater to agents because they just want to run forward.”
That all looks like theater to agents because they just want to run forward.
So we need to redesign software delivery to serve agents first.
That means 3 things have to be in place: context, guardrails, and visibility.
Let’s build the infrastructure to support it, from the moment a ticket lands to the moment it ships.
Before getting into the details, here’s the shape of the whole thing.
It’s five phases that alternate between agent work and human gates.
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.
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.
Phase 3: In Development – A Cursor or Claude Code agent works on the ticket and keeps the entity updated as the agent works.
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.
Phase 5: Deploy – Live checks against current incidents and freeze windows, generates release notes, and deploys it.
The rest of this post walks through each phase, starting with what you need in place before any of it works.
For 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.
Specifically for this guide, you’ll need three things to be in their context:
The workflows we’re about to build can also pull data via MCP as they need.
For example, if agents want to write accurate tech specs, they may want to read past ADRs, runbooks, or past specs in Notion or Confluence.
To improve the PRD, we will connect to real customer problems, so you might also want to connect MCPs for Zendesk or Intercom.
The whole workflow is triggered when a ticket is created. It could be in Jira, Linear, or just in Port.
We recommend creating a generic blueprint like work_item so every step reads from and writes to these fields:
service → linked to service entity in catalog team → from catalog ownership tier → T1 / T2 / T3 blast_radius → low / medium / high (calculated) open_prs → count against linked repo active_incidents → boolean from incident tracker prd → markdown, written by workflow tech_spec → markdown, written by workflow stage → incoming / enriched / prd_draft / prd_ready / spec_draft / spec_ready / ready
The workflow queries the context lake to resolve any missing details in the work item, such as its component or label. It might also add the service tier, owner, and repo from the catalog, calculate the 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.
Port AI runs a PRD skill against the ticket, the enriched entity, and similar PRDs from your knowledge base. Draft lands on the entity; the stage moves to prd_draft; PM gets a Slack ping.
The skill you write defines the structure.
If the first draft is structurally complete but thin on evidence. The PM can open Port AI chat from the entity and question the gaps:
“How many customers have asked for this in the last 6 months?”
“Which services would this affect? What’s been touched recently?
“Why shouldn’t we build this?”
Port AI will then update the PRD based on this conversation.
Once they’re happy with the PRD, the PM marks it ready, and it moves along.
Same 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.
The engineer can then open Port chat and iterate on the tech spec:
“What’s changed in this area in the last 30 days? Who’s been active there?”
“Are there existing patterns we should follow? Anything we’re duplicating?”
“What could go wrong? What files have caused incidents recently?”
Based on the chat, the tech spec gets updated.
Once the engineer marks it ready, it moves to the next stage.
Before 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.
The 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:
If any rule fails, the entity is marked as blocked with the reason.
If everything passes, then it moves to ready and continues.
A reasonable starting set of rules:
| Rule | Fails if | Reason |
| Service tier | T1 | T1 service, requires human delivery |
| Blast radius | High or unassessed | Too risky to automate without scoped review |
| Active incidents | Any open on the service | No changes while the service is unstable |
| Priority | P0 / P1 | Urgent work goes directly to an engineer |
| Acceptance criteria | Empty | PRD incomplete, can’t validate output |
One 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.
“One thing that breaks down fast with agentic workflows is that the work becomes invisible. Multiply that by ten parallel agents, and you’ve lost track of your work.”
The fix is a dashboard in Port that puts all work items on one page, grouped by pipeline stage.
I decided to show work in a 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.
At this point, your work item or ticket should be enriched with ample context, a PRD, a tech spec, and approval from a PM and an engineer.
It’s time to pass it to a coding agent to implement.
Build 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.
The point is that the coding agent starts with a complete picture of the work: what to build, how to build it, which files are in scope, and the architectural decisions already in place. It can still reference Port while it’s working, but it’s better to have as much information up front as possible.
Keeping 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.
3 Port automations listen to GitHub events and update the entity in real time:
Engineers can see which tickets have active PRs, which are stuck in CI, and which are done, without opening agent logs or GitHub notifications.
If 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.
Once the agent’s PR is open and ready for human eyes, the work moves to Phase 4.
Once the agent’s PR is open, the work moves into the preview phase.
I 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.
Pick what solves your current bottleneck.
Before human review, run a Port AI check that compares the diff against the tech spec and flags any deviations, such as modifications to “do not touch” files or missed acceptance criteria.
Add a self-service action or automation that provisions a cloud environment for the PR branch and posts the link on the PR.
Build a personal dashboard for each engineer showing every PR assigned to them, the preview environment to check it, and how long it’s been pending.
Add an automation or workflow on the work item entity that pings the assigned reviewer in Slack with the PR link and work item context.
This 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.
Before anything ships, the workflow runs live checks against the current state.
Here’s the general flow:
If 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.
If you want to go further, you can run a full release risk assessment before the deployment even starts by automatically scoring change volume, blast radius, and rollout strategy. That’s a separate pattern covered in the release risk assessment guide.
When 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.
Every stage in this workflow writes back to the work item: the stage transitions, who acted, when, so the data is already in the ticket.
So what you end up with is:
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.
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.
Delegation rate: what percentage of work items actually got delegated to an agent versus handled manually. The single number that tells you whether the system is in use.
Human intervention points: which stages needed someone to step in. Buildup points in this workflow show that agents might need more context, better guardrails, or a different scorecard rule.
Those 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.
That’s the full workflow. We started with a two-line ticket and ended up with a monitored production deploy. And we had a human in the loop at every gate that needed one.
If you build any agentic workflow, I hope you build this one to see what agentic engineering is all about.
