What Smeldr is
A team that works with AI agents makes decisions all the time, and most of them are made without a record: a call, a chat thread, a pull request comment, a ticket someone closes. The people who were there remember. The agent that starts work tomorrow does not, and neither does the colleague who joins next month.
Then two people act on two versions of the same decision, both in good faith. Work gets built on something that changed last week. A settled question gets argued again, because nobody can show that it was decided, by whom, and what it replaced. Agents write code fast, so this happens more often.
Smeldr is not context management. Context is the data that reasoning and decisions are based on. Adding more data does not give more clarity.
The question is not what was said but what holds: which decision is in force, who had the right to make it, and what rests on it. Now. Always updated. An agent may remember wrong. The organization may not.
Decisions stay put, and you can still change your mind
Smeldr keeps decisions as items that cannot be quietly changed. A Decision is proposed, and someone with the right to do so can ratify it. After that it can never be edited: an edit to a ratified Decision is refused. When it has to change, a new Decision supersedes it, and the old one stays on record as superseded. So at any moment there is one answer to "what is decided now", and a history of how it got there.
Places and rights
A Decision is placed where it applies: the whole organization, a Domain, or an Area. You name Domains and Areas yourself. An Area covers files in a repository through coverage rules, such as internal/billing/** in acme/app, and a Domain groups Areas.
Rights follow the places. The people who hold ratify for a place ratify its Decisions. The people who hold approve-change for an Area approve changes to its files. An AI agent can approve changes in one Area when a person who holds that right gives it to the agent, for as long as the person says. A token classed as an agent can't ratify a Decision. It can propose one, and a person decides.
Who did what, on every item
Every write records who did it and what kind of actor it was: a person, an AI agent or a job. An actor without a class, such as the bootstrap token, is recorded as unclassified and never shown as a person. With provenance on (ENABLE_PROVENANCE), a Decision's history shows who proposed it, who ratified it and who replaced it, with the reasons they gave. Everyone works under the same recorded rules, and nobody's actions are invisible.
Connected to the work
Smeldr brings the decisions to whoever acts:
- An agent, before it writes code. It asks over MCP which Decisions apply to the files it is about to change, and gets the Areas that cover them, the Decisions in force there, and the paths no Area covers.
- A pull request. With the GitHub integration, a pull request that touches an Area's files lists the Decisions in force for those paths and goes to the Area's approver. In an Area set to require approval, with the check required in GitHub, the merge waits for the answer. GitHub holds the merge, through a required status check that the repository owner sets.
- A Decision you want to replace. You can ask what rests on it first, and Smeldr flags a Decision whose premise has left force. See When a premise leaves force.
Smeldr does not read code against the text of a Decision, and it approves nothing by itself. It puts the Decisions in front of the person or agent who judges, and records what they answered.
How it runs
Smeldr is self-hosted and open source (AGPL v3). SQLite is built in, the database is a file, and nothing has to be installed beside Smeldr. Postgres is optional, through a separate module that is not in the release binary. Your data stays on your own infrastructure.
To try it, Getting started takes you from the download to a first ratified Decision.