Since my last post "Welcome to Program Engineering," I've had the opportunity to speak with Engineering and TPM leaders at Apple, AWS, Netflix, and other high-velocity engineering organizations.
Every one of them is being asked the same question right now. How do you use AI? What are you automating? How are you scaling yourself?
And I see a clear pattern.
Here's what their journey looks like so far, where they're looking next, and where their visions converge toward Agentic TPM.
What the best have built: Memory
The TPMs who are ahead of the curve have pieced together what you might call temporal program memory. A structured view of the program over time: not just what the status is today, but the sequence of states the program moved through. Decisions made. Scope changes. Risks that surfaced and how they were resolved. Which teams were involved at which moment. How the plan evolved.
They built this out of what was already available: meeting transcripts, Slack threads, GitHub activity, tracker updates. AI made the synthesis tractable. What used to take a day of manual work now takes 20 minutes of pulling signal and letting a model produce the first draft. The tooling varies but the pattern is consistent: a combination of Claude Code, a personal library of prompts and skills checked into a GitHub repo, wired together into something that runs on demand.
The reporting is automated. In high-velocity engineering organizations, it is standard now. TPMs are sending better status updates, catching risks earlier, producing sharper executive summaries. The individual productivity gain is real.
(If you are building this program memory layer yourself, we have documented the patterns and practices in our open source guide to program memory.)
What comes next: Infrastructure
And then they notice something. The report is not where the value lives. The value is in the shared evolving program memory underneath it that they have built. The same way a TPM's value to the organization is not in the reports they produce, but in their oversight of program goals, milestones, and the decisions that keep them on track. They manage the memory the organization uses as a foundation to make decisions upon. The report is just a window into it. A window that closes the moment it lands in someone's inbox.
The report travels. The context does not.
When you send a status report, it carries the conclusions. It does not carry the single source of truth that produced them.
What they look to do next is scale their impact. Not by producing better reports, but by sharing the program memory itself. When goals, constraints, milestones, and resources live in a shared layer rather than a local file on someone's laptop, alignment becomes checkable and drift becomes detectable. A stakeholder can see when execution has moved away from a stated constraint. A dependency owner can verify that their assumptions match current program reality. Another team can read what this program is actually committed to before they plan against it. This is the single version of truth the DRI has signed off on.
Today, the approaches that get you here are limited to shared prompts, skills, or GitHub repos of both. The practitioners who have built them are running them locally, fragmented across individual machines. The results are real but the infrastructure is not yet shared. Every team is solving the same problems independently.
The reason is structural: agent workflows still live on the machines of the people who built them. The program memory one TPM built cannot easily be read by an agent another TPM is running. Sharing the outputs is possible. Sharing the live context underneath them is not, yet. The next biggest unlock the TPM leaders I've spoken with are eagerly anticipating is cloud workflows paired with shared memory. The same prompts and skills running against a shared program memory layer rather than a local one. The context stops being locked to whoever built it.
(Through our conversations with TPMs building this, a few practical questions keep coming up: how to handle entity resolution across sources, how to manage the program lifecycle as goals evolve, and how to think about access patterns as the memory layer gets shared. None of these are blockers. They are the design decisions that determine how well the foundation scales. We share resources on each as we go. Follow us on LinkedIn to get them when they publish.)
Scaling the human oversight
Here is the pattern I noticed across every conversation. The function of a TPM is the sum of its impact, not its outputs. And the shared converging vision is this: the Agentic TPM needs to scale the impact the role has on the organization. That impact has always been that TPMs are the source of truth infrastructure the organization depends on. The live knowledge of what is being built, why, by whom, and what it connects to. Only when you can scale that source of truth to support every cross-functional team, every management agent and loop, and every coding agent running downstream does the role reach its full leverage. Their role becomes the management of the live, shared memory that aligns and orchestrates the organization.
Where it's all headed: Live Connections
The vision the leaders I spoke with seem to converge on is program intelligence as shared, live infrastructure. In their minds, it enables the organization in three ways: other humans work from the same ground truth without needing a meeting, management agents and loops run oversight autonomously, and engineering agents execute with full program context. Agents are invoked; loops run themselves. The difference is whether a human has to remember to ask.
Other humans
| Who | What becomes possible |
|---|---|
| Stakeholders | Ask program history questions directly, no meeting needed |
| New team members | Onboard into real decisions, not reconstructed context |
| Adjacent program owners | Verify cross-team assumptions against live program state |
| Planning teams | Ground quarterly planning in what programs actually required |
Management agents and loops
| Use case | Mode | Watches | Produces |
|---|---|---|---|
| Drift detection | Live | Sprint activity, PRs, task completion vs declared milestones and constraints | Alerts when work diverges from declared goals or constraints |
| Risk register | Live | Meeting transcripts, Slack decisions, dependency changes, milestone updates | Risk register updated to reflect current program state |
| Product roadmapping | Live | Program state, alignment artifacts, code state | Roadmap kept accurate against what is actually committed |
| Goal distribution | Live | Program charter updates, constraint changes, milestone revisions | Downstream teams notified when program goals or constraints shift |
| Compliance and review | Live | Scoping decisions involving user data, integrations, or regulated features | Legal, security, or privacy flags raised before ship |
| Blocked status | Trigger | Program status field and owner updates | Escalation draft with what is blocked, how long, who must act |
| Dependency slip | Trigger | Dependency due dates and owner commit signals | Downstream impact analysis and revised plan options |
| Scope change | Trigger | Charter or milestone scope edits | Affected stakeholders notified immediately with reasoning |
| Decision anniversary | Trigger | Decision log timestamps | Review prompt with original reasoning and current program state |
| Milestone approach | Trigger | Milestone dates and delivery signals | Delivery confidence assessment based on real trajectory |
Engineering agents and loops
| Use case | Mode | Watches | Produces |
|---|---|---|---|
| Task breakdown | Live | Current program state | Predicted engineering task breakdown proposed to engineers to roll up into program planning |
| Coding | Live | Program context and constraints | Longer autonomous sessions at the right priority |
| Process updates | Live | Completed execution | Program memory updated with process changes as work lands |
| Conflict detection | Live | Parallel executions and overlapping code symbols | Flags conflicts with program constraints before work starts |
| Prioritization ping | Live | Ambiguous task priority | Real-time escalation to humans when tradeoffs need a decision |
What you're actually building: Agentic TPM
The arc is the same across every conversation I've had. You automate your own busywork. In doing that, you piece together the technologies that make it possible. Then you share your know-how, your prompts, your patterns with others. Then you look to build a shared source of truth, so you introduce some infrastructure to support it. The tools and the choices might all be different, but the end goal is the same: scale your impact, not just your output.
That is the path to Agentic TPM. In this future, human TPMs have fully delegated the coordination to AI. They have scaled their function into an AI-augmented source of truth infrastructure that the entire organization, human or agent, depends on.
The best TPMs have already started. The next step is onboarding the rest of the organization.
Skip ahead with Serro
Whether you're a TPM who's already deep into this and still rebuilding context every quarter, a TPM who's just getting started, or a founder or engineering leader without dedicated TPM support yet — Serro can help you skip ahead.
Serro is building the first and the best Agentic TPM platform. We provide advanced, temporal program memory infrastructure that you can set up in a single day for the entire organization so that you can start building impact-multiplying applications on top of it without having to start from scratch.
If you are at the stage where automated reports feel like the ceiling, want to scale your impact beyond your own workflows, or want to learn more about how Agentic TPM translates into greater org velocity, see how Serro works or schedule a quick call with me.