You write to your coding agent. This is, step by step and without jargon, what panoma does so that sentence ends up as a rule every one of your agents receives, and to check that they received it. Scroll to see it.
For example, to Claude Code: “Keep the journal append-only until the migration finishes.” It is a sentence inside a conversation, like any other.
Nobody stores it as a rule. If you open another session tomorrow, the agent does not remember it.
The agent writes down everything that happens — what you tell it and what it does — in a file. That file belongs to the agent and lives on your disk.
panoma does not touch it: it may read it if you allow that, but it never writes into it.
You decide, agent by agent. And they are three separate permissions:
Permission to read in panoma: capture: panoma may open the file and write down what the agent did — which files it touched, whether the tests passed. It never copies what was said.
Permission to ask the AI in panoma: extraction: panoma may send your sentences — only yours, never the agent's — to an AI to look for rules in them.
Permission to learn your taste in panoma: Twin: panoma may notice what you keep repeating and propose taste criteria (you will see it in step 9).
Without the first, nothing is read. Without the second, nothing leaves your computer. This journey uses the first two.
Only a short list of facts, without the conversation's text: the agent read 3 files, changed 1, the tests passed.
It reads a little at a time and in the background, so your computer is not slowed down.
panoma gathers your sentences (masking any password) and the facts it wrote down, and asks the AI: is there anything here that should be a rule of this project?
Asking costs money, so there is a cap: 12 questions a day at most. When the cap runs out, it waits for tomorrow.
It returns a short sentence and points at the message of yours it came from.
It is only a proposal: it counts for nothing yet and no agent sees it.
The proposal shows up in the panoma app, in the project's Memory tab. Only you can approve or discard it: no agent can, not even with its key.
There are never more than 20 proposals waiting, so reviewing them never becomes an endless chore.
Short (500 characters at most) and numbered: version 1. If you change it one day, panoma keeps how it was before.
You can add details: which folder it applies to, what must stay true (for example, that a file exists) and until which date.
With the third permission, panoma notices what you tell your agents again and again — “short answers”, “no colours outside the colour file” — and turns it into taste criteria. That part of panoma is called the Twin.
The criteria are written into a file of yours, TASTE.md, which the agents receive too. You can edit it by hand: delete a line and panoma reads it as a no; rewrite one and it reads it as a yes in your own words.
A new criterion publishes itself only when panoma has seen it in at least three different conversations and you have said, once, that it may. Otherwise it waits for your yes like any proposal.
panoma gathers the project's rules and your taste criteria into one package and hands it to the agent when the session opens.
Before handing it over, it keeps a copy of exactly what it sent, with a fingerprint: a unique code that identifies that content.
Later it looks at the file of that new conversation and searches for the package, byte by byte, in the place where the agent stores what it receives.
If it is there: it arrived whole. If it is missing or partial, panoma writes that down as it is. It does not trust; it checks.
A rule can stop being true. panoma checks your files every so often: if the rule said “this file exists” and it no longer does, it sets the rule aside and tells you, with the evidence.
And if one day you want to delete a rule, panoma shows you first what it is going to delete and writes it into a log.