A decision log that writes itself

The problem

• The reason a thing was built one way lives in a closed pull request nobody will reopen.
• A new engineer asks why, and the answer is a shrug or a twenty-minute archaeology session.
• Architecture decision records are written for the first month and abandoned by the third.
• The same debate is had again six months later, with the same conclusion, because the first one left no trace.

How it works

• Every night Memtro reads the pull requests, issues and conversations in the systems you connect, and lifts out the decisions: what was chosen, over what, and why.
• Each decision becomes an entity in the memory graph, joined to the code, the ticket and the people, so it can be found from any of them.
• The Decisions tab under Memory lists them with what each is joined to; ask in chat and the answer cites the pull request.
• When you want the reasoning where the code is, one click posts it back as a comment on the pull request or issue it came from.
• A decision that is later reversed is superseded, not deleted, so the history of the choice stays readable.

Ask it like this

• › Why did we move retries into the worker instead of the API?
• › What did we decide about multi-region in the platform channel last month?
• › List the decisions that touched the billing service this quarter
• › Who argued against the event-sourcing approach, and what changed their mind?

Setting it up

1. 01Turn Decisions on under Organisation → Features. It is off to begin with, because it writes to shared memory and spends model calls every night.
2. 02Connect the systems where the reasoning actually lives: GitHub, GitLab or Bitbucket for pull requests, Linear or Jira for tracker comments, Slack for the threads where an approach was argued out.
3. 03Wait for the nightly pass, or have an administrator look for decisions now from the Decisions tab.
4. 04To put reasoning back onto a pull request, grant the GitHub connection's comment tool to the team that should be able to. There is no separate switch for posting: it is the connector's own action grant.

The tools behind it

• memtro_whyWhy a file, path or repository is the way it is: the decisions joined to it, what else touches it, the facts remembered about any of it, and the people.
• memtro_searchA decision is an ordinary entity in the graph, so it is also found from the ticket, the person or the customer it concerns.
• memtro_timelineHow the thinking changed: what was decided, what reversed it, and when.

Available wherever Memtro answers: the Chat page, the API and any MCP client. Every input is in the tools reference.

What it does not do

• It reads prose, not diffs. A decision visible only in the code, with nothing written about it anywhere, is not recorded.
• A proposal is not a decision, and a decision nobody wrote down is never inferred.
• A reason that was not given is left empty rather than invented. A wrong reason in the graph is worse than a missing one, because it will be read as the reason by whoever is deciding whether to change the code.
• GitLab and Bitbucket are read but not posted to. The reason can be put on a GitHub pull request or issue; for the others it stays in the register.
• A decision that is later reversed is superseded rather than deleted, so the register grows a history instead of changing its mind quietly.

Questions

Other things it does

• Chat with your databaseAsk the warehouse a question in plain English. The agent reads the schema, writes the query, shows the SQL and remembers what worked.
• Action items that get checked, not just listedWho promised what, by when, read from meetings and chat, then checked against the systems where the work would show up.