A commitment is a debt with two names on it
A commitment is a debt, and every debt has two names on it. There is the person who owes and the person who is owed, and a record that names only one of them is not a record of the commitment. It is half of one. Most software that calls itself a meeting action item tracker keeps only the half that points back at you, and quietly drops the other name on the floor.
The dropped half is the expensive one. A task you owe yourself, you feel in your gut, and it nags until it is done. A task someone else owes you does not nag anyone. It just sits there, invisible, until you either chase it awkwardly or let it lapse. The follow-up a colleague promised three weeks ago is the one that erodes trust when it slips, and it is exactly the item a one-sided to-do list was never designed to hold.
We have argued elsewhere that meeting notes should be organized around people rather than dates, and that person-organized notes are the right foundation for everything built on top of them. This post takes that as settled and goes one level down. If a commitment is structurally a two-person debt, then what does an honest tracker actually owe you, and what has to run on your device to make the second direction more than a checkbox.
The trouble with a one-column meeting action item tracker
Watch what actually happens when a meeting action item tracker records only your side. It becomes a to-do list with an import step bolted to the front. A transcript goes in, a flat list of tasks comes out, and every one of them is implicitly assigned to the person holding the phone. The other party's obligations never enter the system, because the system has no column for them.
That is not a small gap. In any working relationship the balance that matters is the one between two people, not the one inside your own head. What did she say she would send over. What did you promise to review before Thursday. A tracker that captures only the second kind of question leaves you running the relationship with half the ledger blank, which means you run it from memory, which means you run it worse than you think you do.
People compensate by keeping the missing half in their heads, and heads are a terrible database for other people's promises. You remember the ones that burned you. You forget the ones that are quietly overdue. The obligation you are owed decays in silence, and the first time you notice is usually the moment you needed the thing and it was not there.
The fix is not a longer list. It is a different shape. A commitment has a direction, so the structure that holds it has to carry a direction too. Once you accept that, a single flat list stops being an adequate container, and you start needing something that knows, for every open item, who owes whom.
Two columns, because a debt points somewhere
Savory's per-person ledger splits open items into two buckets: what they owe you, and what you owe them. Same person, same page, two directions. Every open commitment between the two of you sits in one column or the other, so you can see at a glance both what you are waiting on and what someone is waiting on from you.
Because the ledger lives on the person rather than in a global inbox, it reads the way the relationship works. Open a person page and the two columns sit next to the meeting history that produced them. You are not diffing a task list against your memory of who said what in which call. That reconciliation already happened, and it is waiting for you in the exact shape you need it in.
It helps to say what this is not. The ledger is not a project manager, and it is not trying to be the one place you track every errand in your life. A general task app flattens everything into a single queue, where 'buy milk' and 'send the contract' sit at the same altitude with no sense of who is on the other end. The ledger throws that flatness away on purpose. Every item in it has a counterparty by construction, because it was born in a meeting with that counterparty in the room.
That constraint is what lets the two columns mean something. The instant you allow ownerless tasks in, the direction blurs and you are back to a pile with nicer styling. Anchoring each item to a person and a meeting is what keeps both directions crisp enough to act on without a second look.
Where the items come from
Items reach the ledger two ways. They are extracted when you generate a meeting summary, or you add them by hand. Both are first-class. A commitment you type in yourself is exactly as real as one the model pulled from a conversation, and it flows into the same two columns on the same page.
The extraction path deserves precision, because it is easy to imply more than is true. Automatic extraction only happens when you generate a summary, and generating one is an optional, opt-in, paid step that runs in the cloud. A meeting you only transcribe does not sprout action items on its own. Until you generate a summary or add items yourself, the ledger for that meeting stays empty, and that emptiness is correct behavior, not a failure.
This matters more than it looks. A tracker you cannot trust is worse than no tracker at all, because an unreliable ledger trains you to double-check everything, and a ledger you double-check saves you nothing. If items appeared sometimes and vanished other times for reasons you could not see, you would stop believing the empty columns, and an empty column you do not believe is just a low hum of anxiety.
So the rule is deliberately legible. Summaries produce items. Hand entry produces items. A bare transcript produces nothing until you ask for a summary or write the item down yourself. You always know why the ledger looks the way it looks, which is the only way an empty column can ever be reassuring instead of suspicious.
The resolver that puts a name on an item
Extracting a task is the easy half. The hard half is deciding whose task it is. When you generate a summary, an on-device AssigneeResolver takes each extracted item and matches its named owner against the people who were actually in that meeting. The owner named in a sentence becomes a specific person on your device, not a loose string floating in a list.
Your own identity is handled as a set rather than a single login. 'Me' is the collection of your identities across the accounts you use, so an item you own resolves to you no matter which of those identities the conversation happened to name. Your side of the ledger is always attributed, because the resolver always knows which of the people in the room is you.
The uncertain cases are where the design shows its hand. An item the resolver cannot confidently attribute is not guessed at. It stays unassigned, which means it lands in neither column, on nobody's page, until you place it with a single tap. That is a deliberate refusal, not a gap. A wrong name in a trust ledger is worse than a blank one, because a confident wrong answer is one you will act on. Better an item that waits for a tap than one filed against the wrong person and believed.
How well the resolver can name the other side depends on knowing who the other side is. It leans on your calendar attendees to put names to remote speakers, and the on-device diarization that helps separate and identify those remote voices is macOS-only. On iOS that signal is not available, though your own side is still always attributed. The engine would rather degrade honestly than claim a certainty the device cannot support.
Making the second direction real
Getting 'they owe you' right is mostly a naming problem. Getting 'you owe them' right is a harder one, and it is where most of the real work sits. A promise you made does not arrive with your name stamped on it. It is buried inside a sentence you said, in a particular room, to a particular person, and the tracker has to reconstruct after the fact who that promise was made to.
Savory reconstructs it through the identity of the meeting itself. Each commitment is joined back to the shared event that produced it, so a thing you agreed to in a specific call can be routed to the people who were on the other side of that call. The effect is that 'you owe them' surfaces on the page of the person you made the promise to, instead of collapsing into one undifferentiated list of your own tasks.
This is the direction competing tools tend to skip, and skipping it is not laziness so much as difficulty. It requires knowing that a call, a person, and a promise all belong together, and rebuilding that link from the record rather than asking you to tag it. Doing the join on the meeting both people share is what turns the second column from a nice idea into something actually populated.
The payoff is quiet but real. The debt shows up where you will encounter it, on the page of the person it is owed to, at the moment you are about to talk to them again. You do not have to remember that you owe someone. The page remembers on your behalf, and it puts the reminder exactly where it becomes useful.
Due dates that do not pretend
An item can carry a due date, and once it has one it appears on the relevant person page alongside the rest of what is open between you. That is the simple, useful version. The part worth reading slowly is what the tracker does and does not claim about time, because this is exactly the place software likes to overreach.
When a summary is generated, a phrase like 'by Friday' may be written onto an item as text you can read. That is display text, and only display text. There is no natural-language date parser quietly turning 'by Friday' into a real deadline behind the scenes. Savory will not start a countdown against a phrase it lifted from a transcript, because it has no reliable way to know which Friday, or whether the speaker even meant it as a commitment.
The urgency signals, overdue and due this week, switch on only after you set a numeric due date yourself. That is the line the tracker will not cross on its own. It will not flag a commitment as overdue on the strength of something the model thought it heard someone say. If you want a real countdown, you give it a real date, and from that instant it tracks the item precisely.
Until then, it shows you the words that were spoken and nothing more. This is the same restraint the rest of the ledger runs on: state what is known, mark what is uncertain, and never dress a guess up as a fact. A deadline the tracker was never actually given is not one it will pretend to enforce.
An engine that stays on your machine
The reason any of this can be honest is that the parts that assign, route, and reconcile commitments run on your own device. The resolver matches owners to people locally. The join that rebuilds the second direction happens on your machine, out of meetings that never had to leave it to become useful. The one step that reaches outward is summary generation, which stays optional, opt-in, and paid, and which you trigger on purpose rather than having it run behind your back.
That placement is precisely why the ledger can afford to refuse. A cloud tracker under pressure to look impressive will guess an owner, infer a deadline, and fill both columns so the demo lands. An engine that runs where your relationships already live has no such incentive to perform. It can leave an item unassigned, leave a date as plain words, and hand the judgment calls back to you, because it is not trying to win a screenshot.
Savory is pre-launch, so the honest framing is that you are looking at a tracker built on these rules rather than a mature product with years of polish behind it. The rules, though, are the durable part, and they are not going to soften. A commitment is a two-person debt. A tracker worth trusting has to keep both names, and it has to keep them somewhere that answers to you.
If you have a relationship where the second column has been quietly slipping, that is the one to look at first. Meet the ledger before your next meeting, and let it hold both directions so you do not have to.