Managed Agents, DRIs, and the TPM: What Actually Moves the Needle

TL;DR: Google's new Managed Agents in the Gemini API (background tasks, remote MCP) finally make agents reliable enough for real program work. But the tool that actually saves you is old: assigning a Directly Responsible Individual to every risk. Combine the two and your status reports write themselves.

The news that matters this week

Two things landed on my radar. First, Google announced new capabilities in Managed Agents in the Gemini API — background tasks and remote MCP support so you can build production-ready agents that don't fall over the moment they run for more than 30 seconds. Second, Simon Willison wrote a short piece resurfacing the Directly Responsible Individual (DRI) concept.

On the surface these have nothing to do with each other. In practice, they're the two halves of how I want to run programs in 2026. One automates the mechanical work. The other makes sure a human still owns the outcome. Skip the second and you've just built a very expensive way to be confused faster.

Where agents actually help a TPM

I've been a TPM for 20+ years and I'll be blunt: most of the job is not glamorous. It's chasing status, reconciling three versions of the truth, and turning a messy standup into something an exec will read in 45 seconds. That's exactly the work these tools are good at.

1. Release planning

A background agent with access to your issue tracker via MCP can now do the thing I used to do manually every Monday morning: pull all open items in the milestone, flag anything with no assignee, cross-reference the ones blocked on dependencies, and draft a go/no-go summary. It runs while I'm asleep. I read it with coffee. I've cut my Monday prep from 90 minutes to about 15.

2. Stakeholder sync

The bottleneck in stakeholder comms is never the information — it's translating the same update into five dialects. Engineering wants dependencies. The VP wants risk and date. Legal wants the compliance line. I now keep a single source-of-truth doc and let the model generate the five variants. I still edit every one, because tone is where trust lives, but the first draft is done in seconds.

3. Risk tracking

This is where the DRI idea earns its keep. An agent is great at listing risks. It is terrible at owning them. So my risk register now has a hard rule: every row has a named DRI, not a team. "Platform team" is not a person. "Platform team" cannot be paged. The agent maintains the register and nags the DRI; the DRI makes the call. That division of labor is the whole game.

4. Retros

I dump the raw retro notes — the messy, contradictory, half-sentence ones — and ask for themes, not conclusions. The model clusters 40 comments into six themes in seconds. Then I do the human part: deciding which two we'll actually fix. Never let the model pick the action items. It optimizes for plausible, not for what your team will actually commit to.

A mistake I made so you don't have to

Early last year I got excited about automating a program's weekly status entirely. I wired up a pipeline that pulled from the tracker, summarized it, and posted to the stakeholder channel automatically. No human in the loop. It worked beautifully for three weeks.

Then it confidently reported a critical milestone as "on track" because the tracker still said so — even though everyone on the team knew, from a Slack thread the agent couldn't see, that a key vendor had slipped two weeks. The status was technically accurate and completely wrong. An exec made a resourcing decision off it. That was a bad week.

The lesson wasn't "agents are bad." It was that automation without a DRI is just faster misinformation. Now every automated summary I ship has my name on it as the reviewer before it goes out. The agent drafts. I own. That's non-negotiable.

The enterprise signal

The Deutsche Telekom and Microsoft 365 Copilot news (now running GPT-5.6) tell you where this is heading. Big organizations aren't experimenting anymore — they're rewiring core operations around AI-native workflows. For TPMs that means two things. One: the tools inside your suite are getting genuinely useful, so learn them before they learn your job. Two: the coordination overhead these tools create — governance, model choice, data access — is itself a program that needs a TPM. That's opportunity, not threat.

Related: see The TPM's AI Stack: What Actually Moves the Needle on Release Planning and AI Tools for TPMs: Cutting Through the Hype to Real Impact.

What I'm doing about this

• Piloting a Gemini background agent on one low-stakes program to auto-draft the Monday release summary. Read-only access, human review before anything ships. If it saves me an hour a week for a month with zero errors, it graduates to a second program.
• Rewriting my risk register template to enforce a named DRI per row. No teams, no "TBD." I'm testing whether the "UNOWNED" flag alone shortens the time-to-owner on new risks.
• Killing all fully-automated stakeholder posts. Draft-and-review only. My name goes on it, my judgment gate stays.
• Running one retro where the model does clustering and the team does action selection, then measuring whether we actually complete more action items than usual.

The pattern I keep coming back to: let the machine do the mechanical toil, keep a human accountable for the call. The DRI concept is 15 years old and more relevant now than the week it was written. Use the new tools. Just don't let them tell you nobody's responsible.