PodFlow is Sidetrade's AI-native R&D operating model. It takes an idea and carries it all the way to something that lands in a customer's hands.
In June, Sidetrade won The Hackett Group's 2026 Innovation Award in the Technology Operations category.
What follows is what PodFlow is, what was hurting before it, where every human decision sits, and how we know a change to it helped.
From a hunch to something a customer can use
Most delivery frameworks assume an epic already exists. Getting to a good epic was the expensive part for us, so that is where PodFlow starts, and it does not stop at the merge.
Every phase in that diagram is a skill someone invokes by name. A product manager types /discovery, an engineer types /start-work, and each gets that stage's workflow.
It starts with a named problem. /discovery exists to prove the problem is worth solving at all, and it produces a problem brief with a single-paragraph opportunity statement. /framing asks what success would actually look like, meaning the constraints, the stakeholders who need to sign, and the metrics that will settle the argument later. /exploration generates real options and puts a cost against them, with a technical challenge and a simplification pass built in, because the cheapest scope to cut is the scope you never committed to.
Only then does /create-epic write the epic, sized in days with MoSCoW applied, and hand it to a pod.
The phases adapt to the maturity of the product line. A new capability gets the full evidence build. An evolution of something we have shipped for years gets a compressed version that asks what we already know rather than making a team re-prove it. Three things never get skipped, no matter what. The technical challenge, the simplification, and the sizing.
What was slowing us down
Three things cost us more than the code ever did. None of them were engineering problems, which is why they went unaddressed for years.
Shaping the idea, deep technical and architecture reviews, a presentation back to the squad, backlog cleansing, sprint planning, and a real chance of being sent to the drawing board to run the whole thing again. Weeks of it, before anyone wrote a line. Then the stories arrived inconsistent anyway.
An engineer picked up a ticket and spent the first hours working out which repositories it touched and which patterns the codebase already had. Someone had usually solved it before. That knowledge left with them when they moved squad.
The process lived as written guidance. You could improve it, announce it, and have no idea six weeks later which teams had adopted it and which were still working the old way.
The process moved into the tools people already use
We saw the third one last, and once we did, the other two had obvious fixes.
Written guidance has no release, no test suite, and no rollback. Improving how 22 teams worked was guesswork, and the only way to check whether a change had landed was to ask people how they felt. In March 2026, we packaged 18 skills out of a shared repository, mostly to stop people copying them between projects. The packaging turned out to be the answer, and PodFlow was born.
Two plugins, one internal marketplace, versioned with semver, 26 releases between March and August 2026. Each one runs inside the tool that side of a pod already works in, so the process lives where the work already happens.
That bottom box is what makes the rest work. The skills know nothing about your stack. Each repository declares its own layers, test commands, coverage minimum, and branch rules, which is how one delivery skill runs against a .NET API, a React front end and a Python service without being rewritten for any of them.
Every gate belongs to a person
PodFlow runs inside each stage of delivery. It never runs between them or decides that a stage is finished. Every transition belongs to a person by design. These gates are permanent, and PodFlow is built to keep them. Above all, design where the model stops.
What is worth building at all is the product manager's call. Discovery is allowed to end with "not this one", and that counts as a finished phase. Framing forces the success metrics to be agreed before anything is built, so the team commits up front to how it would know it was wrong. Exploration prices the options, and the product manager picks which cost is worth paying. All three are judgments about the business.
Planning belongs to the pod. /epic-planning produces a breakdown, and the pod's job in the room is to attack it by naming the edge cases it missed, challenging the sizing, and refusing anything too vague to build from. Nothing reaches Jira until they approve it. One gate argues on the product manager's behalf, an implementation leakage review that rejects any story where a term existing only in code has crept into a section they have to read.
The first stop comes before any code exists. An engineer starts a story with/start-work, and the run assembles everything and then waits. The repositories in scope, the files likely to move, the acceptance criteria are laid out as a table, and whatever the learnings catalog turned up about this codebase. The engineer approves it, redirects it, or throws it out and says why.
That is the single most valuable minute in this run, because everything after it is cheap to produce and expensive to read. An engineer who spots a wrong assumption there saves a day of reviewing code built on top of it.
There is a second stop, and it only fires when the evidence falls short. If tests still fail, or coverage is under that repository's own minimum after the missing tests are written, the run stops and asks how to proceed. It does not lower the bar. Between the two stops it repairs what the gates find, so a reviewer receives finished work rather than triage on a list of known problems.
Review is two passes and only one of them can approve. Every pull request is reviewed by our autonomous review agent, which posts its findings as comments on the pull request itself. Alongside it, a verification from a pod member who did not write the code.
That agent carries a constraint that is more important than any finding it raises. Its review is correlation only. It can flag a concern, and that concern can strengthen a reviewer's doubt about an acceptance criterion that looks thinly covered, but it can never count as test evidence and it can never tick a criterion off. Only a test and a person do that.
On one release it flagged a regression on a create path the feature tests never exercised. The finding landed right beside a criterion a human could already see was thin, so the two doubts arrived together and the engineer had enough to act on
The work we removed was never engineering. Reassembling context, chasing which criteria were covered, formatting a description. Every judgment that mattered stayed exactly where it was, with the engineer.
The mechanisms that carry the weight
Their name goes on the pull request, because it is their work. An engineer who cannot explain a line of it has not finished the story, and no gate will catch that for them.
After the merge, the loop closes. /release-documentation writes the internal and external pages. Weeks later, /learning pulls adoption and feedback from the tools that already hold it and writes the outcome back against the feature. That answer is what the next idea is measured against.
Three mechanisms do most of the work. One of them, the configuration each repository writes about itself, is the foundation in Figure 2. Here are the other two.
If I could only keep one, it'd be the acceptance criteria table without a doubt.
The criterion
- One row each, straight from the ticket, never summarized or combined
- "A user with no export history sees the empty state, not an empty table"
Implemented in
- The files that satisfy it, filled in as the work lands
- Empty at planning time, and that is the point
Covered by
- The tests that prove it
- A row cannot be ticked while this cell or the one before it is empty
The acceptance criteria table, one row per criterion.
What a team learns, written so a later run can use it
Almost every incomplete implementation I have seen came from a fifth acceptance criterion that nobody read, found in review, or worse, found by the product manager in the demo.
The other mechanism is the catalog each repository keeps of what earlier work found out about it, which every run reads before planning. Capture is deliberately narrow. A learning is written down only if it answers one template.
"The export service is complex" clears nothing. "Next time a new export format is added, follow the page-at-a-time shape already there and do not add a fetch-all helper, because the second one exhausts memory in production" is a rule a later run can act on.
Next time X, do Y instead of Z.
What changed, and what the numbers cover
80 person-days to three came from one epic within a focused and fully committed workshop, which is a long way from R&D running twenty-five times faster. Complexity varies with every deliverable, and the speed changed what we take on. The epics in front of us now are bigger than the ones we would have attempted before. Clearing one bottleneck surfaces the next, and our bottleneck is shifting more toward review and verification.
The target we are working to is R&D three times more efficient overall by the end of 2028.
The payback period is the number I'd put in front of our CFO. A single fast epic can be luck. 22 teams and a six-month payback is a different kind of claim altogether.
On the initial pilot, measured against the estimate the same team made before they started.
Running PodFlow by June 2026. The program paid back its costs within six months.
From our Q2 pod review, where no pod reported slower. Every pod scored PodFlow 4 or 5 out of 5 for implementing every acceptance criterion.
How we test a process that never repeats itself
The same skill can produce different output on two runs, so a change to one cannot be judged by reading it. It has to be run.
Each one runs a skill to completion the way a pod would: a real ticket, a real repository with its own configuration, layers and test commands, and the full transcript graded against a written rubric. The fixtures are a .NET API, three React applications and a Python service, and two of them carry deliberate traps, defects planted to see whether a run catches them rather than confirming the happy path. Assertions are weighted, so hallucination and criteria tracking outrank stylistic preference.
These guard the failure nobody notices: someone edits one skill and forgets the other three, a shared value drifts apart, a load-bearing gate quietly disappears in an edit that looked like tidying. A deterministic verdict costs nothing to run and does not drift between runs, so anything a script can decide gets moved out of the grader and into one.
They sit where a silent wrong answer would be worse than a crash: resolving which repositories a ticket touches, the Jira layer, and the service dependency map that tells a run what it may already assume is there.
What we would tell another team
One eval caught something no amount of reading would have found. A UI planning run mapped an outcome indicator to a status dot rather than a status tag. That reads as a style preference until you check the installed types: the dot takes a variant and has no children property, while the design called for the visible words "Completed" and "Failed". The component it chose could not render the label at all.
That is a governance question before it is a technical one. Settle it first and the automation has somewhere safe to stop. Get it wrong and you will be retrofitting judgment into a pipeline that has already learned to run without it.
Fine as a document for one team, a problem at four. Retrofitting a release process onto something twenty-two teams already depend on is harder than starting with one.
The first question anyone asks of a change is whether it helped. That question needs a before.
Complexity used to be a veto
Previously, the size of a piece of cross-cutting work decided whether it got built. The question was whether we could afford the risk, and often the answer was no. That has turned into a much simpler one: is it the priority right now. Work that would have been ruled out a year ago is now a queue position.
If you want to try this, here's your first move. Take one epic, write down every point where a person currently says yes, and ask which of those decisions you would genuinely hand over. In our experience the answer is none of them, and that list becomes the specification for everything else.
Questions this post answers
What is PodFlow at Sidetrade? PodFlow is Sidetrade's AI-native R&D operating model, covering the whole arc from an idea nobody has validated to a feature in a customer's hands and the measurement afterwards that says whether it worked. It installs as versioned plugins rather than living as written guidance, so a change to the process is released, tested and adopted by every pod at once. Twenty-two R&D teams were running it as of June 2026.
Do AI coding agents replace engineers? No, and the design depends on them. Engineers direct the work, and PodFlow never decides that a stage is finished. An engineer approves the plan before any code is written, chooses the base branch, resolves every gap the run raises, verifies the result, and puts their name on the pull request. What the framework took away was context reassembly, criteria chasing and formatting, which was never the engineering. Every judgment that decides what ships is still made by a person, and an engineer who cannot explain a line of their pull request has not finished the story.
Where should a human stay in the loop in AI-assisted delivery? At every transition between stages. In PodFlow that means the product manager deciding a problem is worth solving and what success will be measured as, the pod approving a plan before anything reaches Jira, the engineer approving the implementation plan before any code, a stop when tests or coverage fall short, and a review from someone who didn't write the code. An autonomous review agent reviews every pull request alongside that person, but its findings are correlation only and can never satisfy an acceptance criterion.
Why package a delivery process instead of documenting it? Written guidance has no release, no test suite and no rollback, so every team reads it differently and nothing measures the drift. A package makes improving the process an engineering job. Each repository then supplies its own specifics through configuration, which is how one skill runs across different stacks.
What results has Sidetrade seen from PodFlow? Sidetrade won The Hackett Group's 2026 Innovation Award in the Technology Operations category for the agentic operating model PodFlow belongs to. Features which previously took 80 person-days were delivered in three on the initial pilot, and the program paid back its costs within six months.
-900x386.png)