Answers
How team decisions reach the AIs doing the work
A decision reaches an AI when it is put in front of that AI before it acts — in the read the assistant makes at the start of a task, not in a document someone hopes it will find. Arroway keeps decisions as material of a project, marks the ones that must apply always, orders the rest by the task in front of the assistant, and says in the same breath how much fit and what did not.
Last updated August 22, 2026
A decision that was stored but never delivered changed nothing
Writing the rule down is the easy half. What matters is whether it was in front of the assistant at the moment it mattered — and most systems cannot tell you. Arroway's read comes with a count: how many memories came, how much room they took, how many did not fit. A rule that matched real work and was not delivered is treated as a defect of the product, measured and fixed, not as something a person has to work around by repeating themselves.
Always-on rules and everything else are handled differently
A rule whose breach is expensive or irreversible can be marked always-on: it appears in every read, in every session, whatever the task — which costs room every time, so it is a deliberate choice rather than the default. Everything else is ordered by the task the assistant declares, with the most recent as a tiebreaker. The daily log is ordered by subject too, so the history a new task should learn from is not pushed out by whoever wrote most recently.
Each project says what it is for, and that is what keeps decisions from leaking
Every project states its purpose in plain words, and a person can correct that statement. The assistant is told to write into the project the work belongs to — not into the nearest one it can find — and to read only from the projects the person belongs to. That is what stops a decision made in one context from governing work in another.
What it looks like in practice
The team decides not to build a particular integration, and the reason is recorded. Weeks later someone asks an assistant to plan that same integration. The assistant reads the project first, finds the decision with the reason attached, and says so — instead of producing a good plan for work the team already refused.
Questions people ask about this
- How do I know the AI actually received a decision?
- The read says what it delivered and what it cut. And the audit screen shows when a memory matched real work after the last time it was delivered — which is the room running out, made visible instead of assumed.
- What if two memories contradict each other?
- The assistant is instructed to say so and bring both to a person, rather than pick one quietly. Contradictions also show up on the review screen, side by side, for someone to settle.
- Does the assistant have to be told to read?
- Once, while the habit is new: one sentence at the start of a conversation. After that the instruction travels with the product — the server repeats it in what it returns, and where your tool supports the plugin, the reminder comes on its own. It does not depend on each person's setup.
Where this is verifiable
The sanctioned product spec in the repository, the read protocol served by the MCP server, and the audit surface in the product, which reports what was delivered and what was cut.
https://www.arroway.app/en/answers/how-team-decisions-reach-ai