Commitments

"Who promised what, and did it land?" is a question no notetaker or CRM can answer, because the promise and the evidence live in different products. The promise is said in a meeting; the proof is an invoice in the ledger, an issue closed in the tracker, an email in a mailbox. Memtro already pulls all of those into one memory, which is the only place the two halves can meet.

Dashboard → Memory → Commitments shows them: who undertook what, by when, and what the other systems have recorded since. Commitments are off until you turn them on, under Organisation → Features.

Where commitments come from

Meetings and team chat, read overnight. Connect a notetaker — Granola, Fireflies, Google Meet, Zoom or Gong — and the nightly pass reads the meetings recorded since it last ran and pulls out the commitments made in them: a named person or team undertaking to do something.

Slack is read too, and a little differently: messages are taken as a run in time order rather than one at a time, because a promise in a channel is usually two messages — somebody asks, somebody else takes it on. A request on its own is never a commitment; "can you add those accounts?" becomes one only when the person asked says they will. It is attributed to whoever undertook it, not whoever asked. Only channels the connected account belongs to are read, public and private; direct messages are never read, so nothing said in private reaches a page the whole organisation can see.

It records a commitment when someone took something on ("Will to provide Jade with an anonymised login", "Adam will send the pricing by Friday"). It deliberately does not record decisions with no owner, things already done, hopes and ideas, or standing duties. Relative deadlines are resolved against the date the promise was made — the meeting's own date, or the message's — so "by Friday" becomes that week's Friday, and when no deadline was given, none is invented.

The owner is matched against the people and teams already in your graph, so a commitment points at the same entity as everything else about that person — which is what makes "what is Priya on the hook for?" answerable. A name that matches nobody is kept as plain text rather than invented as a new person, and the page says it was not matched.

A commitment is a commitment entity in the graph — there is no separate store behind this page. It is joined by a promised edge to whoever made it and a promised_in edge to the meeting it came from, and carries its state, dates, verdict and evidence as properties. So it turns up in Memory, in memtro_search and in memtro_explore alongside everything else known about that person.

That is deliberate, and it has a consequence worth knowing: as the graph changes, commitments change with it. When the memory a promise was read from is corrected, superseded by a newer fact, consolidated away or erased, the commitment falls away too — a promise with no surviving record of having been made is not a promise any more. One you have settled by hand stays, because your judgement outlives the note it came from.

It also reads the facts Memtro distils from its own conversations. Ask about a customer, let the agent read the CRM, the ledger and the tracker to answer, and the promises it finds there are recorded like any other — so a commitment can reach the graph without ever having been said in a meeting.

How "did it land?" is answered

Once a commitment is due, the nightly pass looks for evidence: memories recorded after the promise was made, about the thing promised, from any connected system. It then judges them and writes a verdict with the evidence attached, so every answer can be followed back to a record.

Two rules make the verdict trustworthy:

• Nothing is marked landed without a citation. A "yes" you cannot trace to a record is not an answer, so the check must name the memory that proves it.
• Nothing is ever marked missed. Finding no evidence means none of your systems recorded anything — which is not the same as the work not happening. The commitment stays open, and the verdict says what was looked for. Overdue is simply its due date against today.

Only a person settles a commitment: Mark landed when you know it happened, Cancel when it stopped applying, Reopen if you were wrong. Who settled it is recorded.

Reading the register

Every commitment carries how pressing it is, so the list opens with what matters rather than with what happened to be extracted last. Where the extraction had a view on it from the wording, that judgement stands; otherwise it is worked out from the dates and how clearly the promise was made — something overdue or due within the week is high, a deadline this month is medium, and a promise with no deadline at all is low. A promise the extraction was unsure about is held back a rung, because ranking a maybe above a certainty costs trust in the whole register. Hovering the badge says which of the two it was.

The register can also be filtered by team — Memtro's own teams, so a commitment belongs to a team through the person it was matched to. Someone outside the organisation, a supplier or a customer, is in no team and is reachable by owner instead. A team with nothing outstanding is listed as empty rather than left out, which is the more useful answer to "what does Customer Care owe?".

Only the organisation's own people appear. The graph learns what everybody in a meeting undertook, customers and suppliers included, and that is useful in a conversation but noise in a list of who owes what — so the register is read for the addresses this organisation has in Memtro: its members, and anyone holding a live invitation. A promise matched to nobody has no address and is left out with them.

The four states

State	What it means
Open	Recorded, not yet settled, and either undated or not yet due.
Overdue	Open, with a due date that has passed. It is not a separate state in the record, only its date read against today — which is why nothing has to run for a promise to become overdue.
Landed	Settled by a person, or by the nightly check with a record named as evidence.
Cancelled	It stopped applying. A promise dropped rather than kept, said out loud.

Nothing moves to landed on inference alone, and nothing is ever moved to a "missed" state, because there isn't one. Reopen puts a settled entry back to open; who settled it, when, and the note they left are kept either way, because a hand-settled commitment rests on somebody's judgement and that judgement is the thing worth keeping.

Asking in chat

memtro_commitments is available to the model, so the question works in Chat, over the API and through MCP:

• "What did we promise BigCo, and has any of it happened?"
• "What is overdue, and who owns it?"
• "What is Priya on the hook for this week?"
• "Did the pricing sheet ever go out?"

Each answer comes back with the verdict and the evidence behind it. The tool is explicit that a verdict is the last nightly judgement, not a live check, and tells the model to confirm anything consequential against the system that would hold the proof — the invoice in the ledger, the issue in the tracker — and to say which it checked. Memtro's record of a promise is authoritative; Memtro's view of whether it was kept is only as fresh as the last sync.

Sending a promise to a tracker

A commitment that is really a piece of work can be sent to the system that tracks work. In the commitment's drawer, Tracker offers the GitHub, Linear, Jira and Twenty connections you may act with: pick one, then the repository, team or project it belongs in (Twenty makes a task on the owner's own record), and Memtro creates the issue with the promise as its title and the owner, dates and source in its body, and keeps the link on the commitment. The row then shows it, "↗ GitHub acme/web#412", and the drawer can unlink it.

From then on the nightly check reads the ticket before it reads anything else. A ticket that is closed, done or merged settles the commitment as landed, with a note saying where and when and the ticket as evidence; one marked won't do, duplicate or declined is left open and counted, because a promise dropped in a tracker is still a promise. Sending needs "Settle and record commitments" and the connector's action grant; reading the ticket back at night runs as the organisation's owner through the same connection.

What it does not do

• It reads meetings and Slack, not every system. A promise made in an email, a ticket or another chat tool is not picked up yet.
• In chat it needs the agreement in writing. A thumbs-up reaction is not a message, so a promise accepted with one is invisible to it.
• It sees what a notetaker wrote down. If the notes do not mention the commitment, neither will Memtro. Google Meet records attendance and makes the transcript available for 30 days, but its summary is not written into memory, so a Meet-only call yields less than a Granola or Fireflies one.
• The overnight check looks at what has synced, not at a live query of every system, so something that happened an hour ago may not be visible until the next sync. Ask in Chat and the agent can go and look for real.
• It never decides someone failed. It reports what is outstanding and what the evidence shows; the judgement stays with you.

Also worth reading

• Action items that get checked — the same thing, written for somebody looking for it.
• Memtro in Slack — asking for your commitments in a channel and settling them with a button.
• Memory — the graph a commitment is an entity in.
• Contradictions — the same shape, for beliefs that cannot both be true.