Documentation
Everything it does, and everything it does not.
Agentic PM reads meeting notes you already have and keeps every commitment as a history. These pages describe exactly how, including the parts that are inconvenient.
Live
Version 0.13.3, after 39 releases. Sixty-one skills ship in the library today. Anything on the roadmap rather than in the build is marked roadmap.
Install
Agentic PM is a desktop app. There is no terminal step and no developer tooling to buy.
| Platform | Requirement | Download |
|---|---|---|
| macOS | 14 Sonoma or later, Apple silicon or Intel | AgenticPM.dmg |
| Windows | 11, x64 or ARM | AgenticPM-setup.exe |
| Linux | Roadmap | .AppImage |
The free tier needs no account and no card. Sign in only when you start a trial.
Your first run
Point it at the meeting notes you already have. Nothing else is required.
- Open the app and create a workspace. Name it after the product or team, not yourself.
- Drag in a folder of exported meeting notes, or connect a note taker below.
- Wait for the ingest to finish. Fifteen meetings takes under a minute.
- Open Drift. That is the screen that matters.
What good looks like
On a healthy team the first Drift screen is short and slightly embarrassing. On an unhealthy one it is long and very embarrassing. Either result is worth the minute it cost you.
Connect a note taker
Agentic PM does not record or transcribe anything. It reads what your existing tool produces.
| Source | How | Status |
|---|---|---|
| Markdown or text folder | Drag the folder in, or watch it for changes | v1 |
| Fathom | Export, or connect the account | v1 |
| Granola | Export folder watch | v1 |
| Otter, Fireflies, Circleback | Export folder watch | v1 |
| Google Docs, Notion | Read a folder or database of notes | Roadmap |
| Jira, Linear | Cross-check commitments against tickets | Roadmap |
The ledger
Every other tool stores the latest status of an action item. Agentic PM stores its whole history. That single difference is what makes drift visible.
// one commitment, as stored
{
id: "cmt_8f21",
canonical: "Ship the launch page",
kind: "commitment",
owner: "ops assistant",
counterparty: "founder",
touches: ["date", "dependency"],
due: "2026-06-25",
status: "open",
history: [
{ meeting: "wk-2026-06-22", owner: "content lead", due: "2026-06-25" },
{ meeting: "wk-2026-06-30", owner: "ops assistant", due: null }
],
flags: ["owner-drift", "silent-slip"]
}
An owner recorded as null is treated as a defect, not an empty field. It
shows up in Drift as unowned rather than sitting quietly in a table.
The context file
One plain markdown file per workspace describing your product, your people, your vocabulary and the decisions already made. Every agent and every skill reads it before it starts.
You never sit through a setup interview. The file is written and extended as a side effect of ingesting meetings, and you can edit it directly at any time. After roughly six weeks it knows your team better than a new hire does.
Why this matters more than the agents
A skill without context produces a generic template. The same skill with real context produces something you can send. This is the layer most tools charge for and hide.
The five detectors
| Name | Fires when |
|---|---|
silent-slip | Open in meeting N, due date passed, and completely unmentioned in N+1. |
owner-drift | Same commitment, different owner across meetings, with no explicit handover. |
silent-drop | Present in N, absent from N+1 and N+2, never marked done or cancelled. |
undecided-change | A date, scope or estimate changed between meetings with no decision record beside it. |
load-risk | Too much open work on one owner, or a keystone item with no second owner. |
Thresholds are configurable. load-risk defaults to 50% of open commitments held
by one person.
Scope, date, dependency, money
Every commitment is tagged with what it touches. Anything touching none of the four sinks to the bottom of the list.
This is the line between a PM tool and a generic to-do app. A to-do app does not care that a date moved without a decision. A product manager is judged on precisely that.
Agents
| Agent | Runs | Status |
|---|---|---|
| Commitment watchdog | On every ingest, and on a schedule | v1 |
| The context keeper | Continuously, as a side effect | v1 |
| Recap writer | On demand, or weekly | Roadmap |
| Chaser | Daily, drafts only | Roadmap |
| Fact gate | Before any document leaves | Roadmap |
| Meeting brief | Before each calendar event | Roadmap |
Nothing sends without you
The chaser drafts. It never sends. Any agent action that would leave your machine and reach another human waits for an explicit approval, every time, with no global "always allow".
Skills
Sixty-one on-demand skills across six groups, included on every paid plan. Skills read the same context file the agents do, so output is about your product rather than a template.
| Group | Skills |
|---|---|
| Discovery | Interview synthesis, JTBD extractor, feedback clusterer, opportunity map |
| Strategy | Bet sizing, tradeoff table, kill criteria, narrative memo |
| Specs | PRD draft, edge case sweep, acceptance criteria, spec versus reality diff |
| Delivery | Risk register, dependency map, launch checklist, release notes |
| Communication | Exec update, stakeholder recap, bad news memo, decision log |
| Data | Metric tree, experiment read, funnel pull, cohort question |
Custom skills are plain markdown files you drop into the workspace. Yours are never uploaded.
CLI companion
The app is the product. The CLI exists for people who want to script it, and it is optional.
$ apm ingest ~/meetings/*.md
read 15 meetings · 128 commitments · 41 open
$ apm drift
owner-drift launch page content lead → ops assistant
silent-drop balance transfer last seen 22 Jun · touches money
load-risk 10 of 16 open items on one owner
$ apm owed --to-me
$ apm standup
$ apm history cmt_8f21
Export and portability
Everything exports to plain markdown and JSON, on every tier including free. There is no export paywall and no proprietary format.
If you cancel, the ledger stays on your machine and stays readable. Cancelling removes the agents, not your history.
Privacy and data
- The ledger is local. It lives on your device, not on a server.
- Transcripts are never uploaded. Not for indexing, not for training, not for support.
- Commitment text is sent to a model. Matching the same promise across meetings needs language understanding, because the wording changes weekly. What is sent is the commitment line, not the meeting.
- Nothing trains anything. Your content is not used to improve any model.
- Team plans share context, not transcripts. The shared layer is the context file and the commitment ledger, both of which you can read and edit.
Say it plainly
If a fully offline mode matters to you, it is on the roadmap and it is not here yet. That is a real limitation, not a footnote.
Known limits
- It needs an API key or a paid plan for cross-meeting matching. There is no free lunch on the language model.
- No time-saving figure is claimed anywhere, because none has been measured. When one exists, taken on real work with a readable method, it will be published with the method.
- The evidence so far is one operator's own meetings. Fifteen meetings, one team. Enough to prove the failure is real, not enough to say how often it hits you.
- The watchdog does not chase anyone yet. v1 nags inside the app only.
- It is not a note taker and never will be. No recording, no bots in your calls.
FAQ
Will it work if my team writes notes by hand?
Yes, as long as the notes end up as text files somewhere. Quality of detection tracks quality of notes, so hand-written notes with clear owners work better than a transcript with none.
What if the same commitment is worded differently every week?
That is the normal case, and it is exactly why matching uses a language model rather than keywords. "Build the landing page" and "update the site for launch" resolve to one commitment with one history.
Can it be wrong?
Yes. A false drift flag is annoying but cheap, and every flag shows the exact lines from each meeting so you can dismiss it in a second. Dismissals feed back into matching.
Does it work for non-PM roles?
Probably, but it is not designed for them. The touches tags and the detectors are shaped around how product work fails, not how work in general fails.
Changelog
| Version | Date | What changed |
|---|---|---|
0.13.3 | Aug 2026 | Current release |
0.2.0 | Jul 2026 | First public build. 39 releases between the two |
0.0.x | Aug 2026 | Spec written, detectors validated by hand against 15 real meetings |