THE TAM · PRODUCT
Meet @tam — the AI Delivery Partner for the work around code.
@tam turns goals into delivery plans, coordinates engineers and coding agents, follows blockers and dependencies, connects repository evidence back to the plan, and prepares work for human review.
The Tam is the delivery system behind it.
Meet @tam ↗Prepare the new onboarding flow for release.
@tam drafted the plan- 01Onboarding screens design→ Mark
- 02Signup API changes↳ after the design→ Claude Code
- 03Data migration→ Codex
- 04Security review↳ decision needed→ Anna
- 05Release notes→ @tam
I spent years running this loop by hand.
I've spent years running software delivery. The teams changed, the scale changed, and the tools changed, but a surprising amount of the job stayed the same: keeping the goal, plan, ownership, dependencies, decisions, code, review and release connected to one current reality.
Coding agents changed the execution side much faster. Codex, Claude Code and similar tools can now take on meaningful chunks of implementation. But the work around execution did not disappear. Someone still has to decide what happens next, notice when work stops moving, reconcile a pull request with the plan, surface a missing decision and work out whether the release is actually ready.
In most teams, that someone is still a founder, engineering lead, product manager or senior engineer. The Tam started from a simple question: how much of that delivery work can the system itself take responsibility for?
The part I want the system to carry.
You give @tam a goal or a brief. It turns that into work with owners, dependencies and a plan the team can inspect.
People and coding agents do the execution. @tam keeps their work attached to the same delivery thread instead of turning every agent session into another stream someone has to reconcile.
When work stalls, it follows up. When delivery needs a product, technical or risk decision, it brings the question back to the person who owns it instead of quietly inventing authority.
And it stays with the work. A coding-agent session ends. A chat ends. The delivery responsibility does not.
If you think of this as an AI project manager, the useful part is not generating tasks. It is carrying the operational thread between executions.
What that looks like on real work.
Say the goal is to prepare a new onboarding flow for release. @tam breaks it into design, API work, migration, security review and release notes. Some work goes to people, some to Claude Code or Codex.
@tam · Onboarding v2following the workAssigned the API to Claude Code and the UI to Anna
Linked PR #142 to TAM-58 and moved it to Review
TAM-61 has waited 2 days for design. Asked Mark.
→ Product lead
Design will not land this week. Cut the empty states or move the release by 3 days?
As commits and pull requests arrive, the related work stays current. If design has not moved, @tam follows up. If security needs a human decision, it surfaces the question and its effect on the plan. When the implementation is ready, review, acceptance and release stay with the people responsible for them.
The point is not that @tam can call other agents. Agent orchestration is one mechanism inside the job. The harder part is keeping people, agents, decisions, repository evidence and the plan attached to the same goal over time.
An agent like this needs more than a chat history.
For @tam to do that job, it needs a project reality it can trust. The goal cannot live in one chat, tasks in another system, code in GitHub and decisions somewhere else while every agent carries a slightly different version of the project.
northstar/checkout · pull request
Add per-workspace rate limits
#151 · codex/tam-73-rate-limits
- Build passed
- Tests passed
- 1 approving review
Rate limits for the public API
- Owner
- svc-codex-release
- Goal
- Stable bulk imports
- Reviewer
- Mark
kept in sync
That is why The Tam is more than @tam. It holds the working state around the delivery: projects, tasks, dependencies, documents, decisions, people and AI identities, repository activity, review state and the history of how the project got there.
The same state is available to people and to the agents working on the project. Coding agents can keep using the tools that make sense for them; their work comes back into the same delivery record instead of becoming another stream a person has to reconcile manually.
Where I think this goes
I do not think the end state is a better project tracker with an AI assistant attached to it. And I do not think it is a manager sitting in front of ten autonomous-agent windows and routing work between them.
I think the delivery system itself should run much more of the process between the decisions that genuinely need a person.
People define the goal, constraints and priorities. They make product, architecture, risk, acceptance and release decisions. People and specialised agents do the execution. The system keeps the current plan and project reality, gives the right work and context to the right executor, notices when something does not move, follows dependencies, checks whether claimed progress is supported by the available evidence, brings decisions to the right person and keeps going afterwards.
I want The Tam to become the system that runs software delivery, rather than the database people maintain while they run it themselves.
Today the most visible part of that idea is @tam. Over time, the same model can extend across planning, delivery processes, engineering agents, reviews, releases, organisational knowledge and the recurring work around a software team.
The goal is not to remove the people responsible for the product. It is to remove more and more of the coordination machinery they currently have to operate by hand.