OTP vs Agile and Scrum, sprints, standups, and an agent on the team

This is the most concrete comparison in the series, and there is a reason. Of all the frameworks I have written about, Agile and Scrum live closest to where AI agents already do real work. Software and product delivery is the first place agents got hired in practice. They write code. They triage tickets. They run tests. They open pull requests. If you run an engineering team in 2026, there is a decent chance an agent already touched your last sprint.

So the question I want to sit with here is not whether Agile works. It works. The question is narrower and more interesting. When an agent is doing real work inside a sprint, where does it sit? Is it a tool a developer picks up, or is it a teammate with a name, a scoreboard, and a seat in the standup? That is the line between a delivery cadence and an organizational model, and it is exactly the line OTP cares about.

What Agile and Scrum are

Agile started as a statement of values. The 2001 Agile Manifesto laid out four value pairs and a set of principles for iterative software delivery. Individuals and interactions over processes and tools. Working software over comprehensive documentation. Customer collaboration over contract negotiation. Responding to change over following a plan. It is a philosophy of delivery, not a rulebook.

Scrum is the most widely used framework built on top of those values. It was created by Ken Schwaber and Jeff Sutherland, and it is specific where the Manifesto is broad. Scrum defines three accountabilities: the Product Owner, who owns the priority of the work, the Scrum Master, who owns the health of the process, and the Developers, who build the increment. It defines artifacts: the Product Backlog, the Sprint Backlog, and the Increment itself. And it defines events, the ceremonies most people know it by. The Sprint is the container. Inside it run Sprint Planning, the Daily Scrum or standup, the Sprint Review, and the Sprint Retrospective.

Underneath all of it is empirical process control. Three pillars: transparency, inspection, and adaptation. You make the work visible, you inspect it on a fixed cadence, and you adapt. Time-boxed sprints exist so that inspection happens often enough to catch drift before it compounds. Scrum was built for product and software teams, and it is now spreading well beyond them. It is mature, battle-tested, and genuinely good at what it does.

What OTP is

OTP is the Organization Transport Protocol. It is not a delivery cadence and it is not trying to be one. It is the operating layer that sits underneath the team and answers a different question: who are the people and agents doing this work, and what is each one accountable for.

The wedge is an accountability chart where AI agents have seats, the same way humans do. Not a box on an org chart that says "automation." An actual seat with a name, a scope, a set of KPIs, and a scoreboard that the agent reports its own numbers into. Most tools that touch AI right now bolt an assistant onto a dashboard and call it done. OTP treats AI as Agent Employees. An agent has a role, owns metrics, and shows up on the chart as accountable, not as a feature someone toggled on.

That framing changes what you can see. When an agent is a tool, its work is invisible inside whoever used it. When an agent is a seat, its work is its own, and you can hold it accountable the same way you hold a human teammate accountable.

The real difference: a delivery cadence is not an org model

Here is the honest distinction. Scrum coordinates work inside a sprint. OTP defines who is accountable across sprints.

Scrum tells you how the team moves through a fixed window of time. Pick the work, build it, inspect it, adapt, repeat. It is a loop, and a very good one. But Scrum does not tell you who the doers are at the org level or what each of them is on the hook for over the long run. That is by design. Scrum deliberately stays quiet about org structure. The team is the team.

OTP works on the other axis. It does not run the loop. It holds the org. It says this is the Product Owner seat, this is the senior engineer seat, and this seat right here is an agent that owns test coverage and reports its own quality numbers. Sprints come and go. The accountability chart persists. One is a cadence. The other is a model of who is responsible. They are not competing for the same job.

Where they fit together

This is where it gets practical, and where I think most engineering orgs will actually land.

Picture a Scrum team where one of the Developers is an agent. Run it through the ceremonies.

Sprint Planning. The agent takes backlog items the same as any developer. It pulls the tickets scoped to its capability, estimates, and commits to the sprint goal alongside the humans.
Daily Scrum. The agent reports its status in the standup. What it finished, what it is working on, where it is blocked. Not a dashboard the team reads around. A teammate giving its update.
The scoreboard. The agent owns a metric on the OTP chart. Velocity contribution, test coverage, defect escape rate, time to triage. A number it is accountable for, visible on the same chart as every human seat.
Sprint Review. The increment the agent contributed is inspected like everyone else's work. It either met the definition of done or it did not.
Sprint Retrospective. The agent surfaces items in the retro. Patterns it noticed, friction it hit, suggestions for the next sprint. It participates in inspect-and-adapt rather than being a thing that gets adapted around.

In that picture, Scrum runs the loop and OTP holds the seat. The ceremonies do not change. The cadence does not change. What changes is that the agent is no longer invisible. It is on the chart, it has numbers, and it is accountable. The two frameworks compose. They are close to orthogonal, and that is a feature.

The agent-employee dimension

There are two things OTP adds that a delivery cadence was never meant to provide.

The first is auto-populated scoreboards. A human teammate's numbers usually arrive through a manager pulling reports or the person self-reporting in a meeting. An Agent Employee can write its own numbers directly into its scoreboard as it works. The velocity, the coverage, the triage time, updated continuously, with no human transcribing anything. The scoreboard stops being a weekly ritual and becomes a live readout of an accountable seat.

The second is OOS, the cross-org learning layer, and this is the part I care most about. When many teams run Scrum with agents in the loop, each team learns things. What estimation patterns hold up. Where agents reliably help and where they reliably do not. Which retro signals actually predict trouble. OOS is the mechanism for that knowledge to move between organizations as shared operating intelligence rather than staying locked inside one team's tribal memory. That is the moat, and it is a protocol property, not a feature you ship. Protocol, not product.

A practitioner read

Let me be honest about maturity, because the series demands it.

Scrum is mature. Decades of practice, a global community, certifications, a mountain of tooling, and a track record that speaks for itself. OTP is early. The accountability-chart-for-agents wedge is new, and I am building it in the open. I am not going to pretend the comparison is between two equally proven things. It is not.

So who should actually care about putting them together? An engineering org that is already shipping with AI agents in the loop and wants those agents accountable rather than invisible. If your agents are doing real work but living inside individual developers' workflows, untracked and unscored, you have a visibility gap that Scrum was never designed to close. That is the gap OTP is built for. If you are a team that has not put agents into delivery yet, you do not need this today. Run your sprints. Come back when an agent is doing enough work that you want to know its number.

Close

Scrum runs the loop. OTP holds the seat. Agile teams are where AI agents already earn their keep, which makes this the one framework in the series where the question is not theoretical. The agent is already on your team. The only thing left to decide is whether it shows up on the chart, or stays a tool nobody can hold accountable.

More in this series

This post is part of a series comparing OTP to the operating frameworks companies actually run on. Start anywhere, each one stands alone.

Or read the full series index.

Looking for the head to head against named tools rather than frameworks? See OTP vs Ninety and EOS One.