How do I know the AI actually received a decision?

The read states what it delivered, and the audit surface shows when a memory matched real work after its last delivery — that is the budget cutting something, made visible instead of assumed.

What if two memories contradict each other?

The assistant is instructed to surface the conflict rather than pick silently, and to bring it to a person.

Does the assistant have to be told to read?

The protocol asks for the read at the start of any task tied to a project, and the server repeats that instruction in what it returns — so the rule travels with the product rather than depending on each person's setup.

Answers

How team decisions reach the AIs doing the work

A decision reaches an AI when it is served to that AI before it acts, in the read the assistant makes at the start of a task. Arroway does that by holding decisions as project material with a stated scope, ranking them against the task, and pinning the ones that must apply always — and by declaring, in the answer itself, how much fit and what did not.

Delivery is the capability, not a side effect

A decision that is stored but not delivered has changed nothing. So the read is budgeted and honest about the budget: it says how many memories came, what they cost, and how many did not fit. A rule that matched real work and was never delivered is a retrieval failure — measurable, and treated as a product defect rather than something a routine works around.

Always-on rules and task-ranked material are separate

A rule whose breach is expensive or irreversible is pinned: it sits in the fixed block of every read, and it costs tokens in every session, so pinning is a deliberate decision rather than a default. Everything else is ranked by the task the assistant declares, with recency as a tiebreaker. The daily log is ranked by subject too, so the history a new task should mirror is not crowded out by whoever wrote most recently.

Scope is what keeps one circle's decisions out of another

Each project states what it is for, and the statement is visible so a person can correct it. That is the defence against a decision from one context governing work in another — and it is why the assistant is told to route by scope instead of writing into the closest project it can find.

What it looks like in practice

The team decides an integration will not be built. Weeks later someone asks an assistant to plan the same integration; it reads the project first, finds the decision with the reason attached, and says so — instead of producing a plan for work that was already refused.

Questions people ask about this

How do I know the AI actually received a decision?: The read states what it delivered, and the audit surface shows when a memory matched real work after its last delivery — that is the budget cutting something, made visible instead of assumed.
What if two memories contradict each other?: The assistant is instructed to surface the conflict rather than pick silently, and to bring it to a person.
Does the assistant have to be told to read?: The protocol asks for the read at the start of any task tied to a project, and the server repeats that instruction in what it returns — so the rule travels with the product rather than depending on each person's setup.

Install Arroway See how it works →

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