Hear me out: Agentic TPMs (Technical Program Managers)

Steve Yegge · tweet · 2026-09-22 source ↗ Reader 🖥️

AI Employee vs Tool Framing Knowledge Base Organizational Legibility

An agent playing the technical-program-manager role — owning delivery outcomes while holding no authority and no resources, limited to asking, observing, documenting and reporting — is the most immediate, lowest-risk way for AI agents to spread beyond engineering into the rest of the enterprise, because that constraint structurally rules out the kind of damage builder or operator agents can cause.

practical · argumentative — A pitch/call-to-action ('feel free to start now') for a specific agent role, argued from the author's own practice (TPM agents in his 'Wheelhouse' factory) rather than from study or data.

Structure

Part	Role
Contrast: builder agents (confined to the SDLC, dev-only) and operator agents (narrowly scoped, dev-dependent) vs. a proposed TPM-role agent	sets up the gap the proposal fills
Definition of the TPM role by its structural constraint: owns delivery, no authority, no resources, can only ask/observe/document/report	the load-bearing premise
Personal case: TPM agents in the author's own 'Wheelhouse' factory, with external email/Slack access, using 'Progress By Nagging'	evidence (anecdotal, single-practitioner)
Claims about low cost, low risk, universal (non-engineer) deployability, and social/organizational side-effects	elaboration and call to action

Key terms

Agentic TPM
An AI agent playing the technical-program-manager role: it owns delivery of a cross-functional project or program but has no authority and no resources, so its only tools are asking, observing, documenting and reporting.
Builder agents / operator agents
Builder agents write code and stay inside the SDLC, used by developers; operator agents run narrowly-scoped, 24x7 unmanned tasks (e.g. customer-issue queues) but still require developer setup and maintenance. Both are contrasted with the proposed TPM-role agent, which needs neither.
Progress By Nagging
The operating method the author's TPM agents use to drive delivery absent any authority: repeated, documented follow-up (asking, checking in, flagging) rather than directive control.

Propositions

explicitAgentic TPMs are, in the author's view, the most immediate and direct way coding agents can enter the enterprise beyond engineering, ahead of true 'AI employees' which he expects to follow next.conf: high
explicitBuilder agents stay confined to the SDLC and are used mainly by developers; operator agents are narrowly scoped and still require developers to set up and maintain them — neither class is spreading virally beyond engineering or helping run the company as a whole.conf: high
explicitA TPM owns delivery but has no authority and no resources; the role's toolkit is limited to asking, observing, documenting, and reporting — this exact constraint is what makes the role safe to hand entirely to an agent.conf: high
explicitTPM agents have low risk and small blast radius specifically because they cannot act, unlike builder agents, which create new problems such as merge-queue and code-review bottlenecks.conf: high
supportsGitHub Brings Stacked Pull Requests to Public Preview · p1 — Independently names the same code-review/merge-queue bottleneck as a cost specifically created by builder agents, used here as the contrasting case that makes the author's TPM-agent proposal look safer by comparison.
explicitIn doing TPM work, agents will extensively document tribal knowledge, unwritten rules, and topological maps of project/org dependencies and workflows — producing organizational legibility as a byproduct of pursuing their assigned role, not as a separate deliberate initiative.conf: high
extendsPresentation: From Retrieval to Reasoning: Building Production-Ready Agentic AI Systems with Knowledge Graphs · p14 — Proposes a concrete practical mechanism (an agent in a role whose job is explicitly to surface and document it) for exactly the tribal/institutional-knowledge-inaccessibility problem that proposition names, though without addressing that proposition's implicit reconciliation challenge.
explicitAnyone in a company, not only engineers, can stand up a TPM agent with no product to buy, no technology to install, and no dependency on engineering — making this the one class of agent whose organizational spread does not gate on IT/engineering rollout pace.conf: high
explicitTPM agents will function as a forcing mechanism that trains the rest of the organization in human-agent interaction (replying to agent emails and DMs), independent of further progress on SDLC-side agent tooling.conf: medium
explicitFindings recorded by independently-running TPM agents, regardless of the format each uses, will merge trivially into a shared organizational knowledge store ('company brain') once compiled.conf: low

Arguments

TPM-role agents are the most promising near-term vector for AI agents to spread into the enterprise beyond engineering. strength: low

Explicit premises:

Builder agents remain confined to engineering (the SDLC) and dev users.
Operator agents are narrowly scoped and dev-dependent to set up and maintain.
The TPM role, by definition, carries no authority and no resources, so an agent filling it structurally cannot cause the kind of damage a builder or operator agent with real access could.
Any employee can deploy a TPM agent without engineering involvement, a product purchase, or new infrastructure.

Implicit premises:

The primary barrier to broader non-engineering AI-agent adoption has been risk/blast-radius and engineering-dependency rather than capability — once both are removed, adoption follows readily.
Documentation and organizational-mapping work is valuable enough on its own to justify deploying an agent purely for it, independent of whether it meaningfully 'runs' the project.

Inferences:

If this pattern holds, the first widely-adopted 'AI employee' analog inside most companies may be a coordination/documentation role rather than a production-code or revenue-facing one.

Narratives

The author recounts being a TPM at Amazon in 1999, where Bezos brought in high-powered engineers with people skills to run difficult cross-functional projects, and that TPMs remain in high demand and short supply at Google, Uber, Netflix and elsewhere.
→ Establishes the TPM role's real-world value and scarcity as a human role, implicitly justifying why automating it (rather than, say, a generic coordinator role) is a meaningful target.
The author reports that his own TPM agents 'built that missing context as their exhaust' for his game 'without me even asking,' and discovered that '3 teams [were] doing the same thing.'
→ Illustrates the claim that organizational legibility emerges as a side effect of TPM-agent work rather than a deliberately engineered deliverable.

Questions addressed

✅ Why haven't non-engineering parts of the enterprise meaningfully adopted AI agents the way engineering has?
Builder and operator agents both stay in engineering-adjacent lanes by design/dependency; no agent class has yet targeted a role with no engineering dependency and no action-based risk.
✅ What makes a role safe enough to hand entirely to an agent in a domain previously unreachable by coding/operator agents?
A role defined by owning outcomes without authority or resources — ask/observe/document/report only — is proposed as structurally low-risk.
⭕ Will independently-run TPM agents' heterogeneous, differently-formatted outputs actually merge coherently into one shared knowledge store?
Asserted ('will all translate trivially') without any account of the mechanism — not resolved, not even argued for.
⭕ Is giving a 'low risk, cannot act' agent external email/Slack access and direct lines to accountants and lawyers actually consistent with that risk framing?
Not addressed — the piece presents external communication access as an unremarkable feature of the setup in the same breath as claiming the agent 'cannot act.'

Gaps

illogicalThe piece claims TPM agents are 'low risk' specifically 'because they cannot act,' while in the same breath describing agents with external email and Slack access that communicate directly with accountants, lawyers, and other outside parties on the author's behalf — autonomously sending external communications is itself a consequential action (reputational, legal, social-engineering-surface risk), which the stated risk framing doesn't account for.
Read next: Corpus material on agent identity/attribution and on the lethal-trifecta pattern (private data + untrusted content + external action) for a more rigorous risk model that would classify unsupervised external messaging as action, not passive observation.
incompleteThe claim that heterogeneous findings from many independent TPM agents will 'translate trivially' into a shared company brain, regardless of format, never addresses how conflicting, duplicate, or stale findings across agents get reconciled — the same unresolved reconciliation problem this corpus has already flagged for institutional/tribal knowledge capture generally.
Read next: extract-knowledge-graphs-agentic-ai-systems and other corpus material on knowledge-graph/company-brain provenance and conflict resolution.
incompleteNo treatment of what happens once a TPM agent's legibility-producing work surfaces politically inconvenient truths (e.g. '3 teams doing the same thing') — the people or silos whose redundancy or inefficiency gets exposed have an incentive to resist, limit, or route around such agents, which the piece's 'bulldoze through silos and knowledge-hoarders' framing treats as a straightforward win rather than a source of organizational friction.
Read next: Change-management and organizational-politics literature on how legibility-increasing initiatives are typically received and resisted by the parts of an organization they expose.