Answers
Where does team memory fit in an AI-native software lifecycle?
The AI-native loop is usually described as a chain of artefacts: an intent written down, a plan derived from it, code produced against the plan, and a review closing the circle. That describes how one piece of work travels. It does not carry what stays true between pieces of work — which rule is in force, who decided it, why an approach was abandoned, and what the people who never open the repository already settled. That standing layer is what Arroway holds, and it is put in front of the assistant before it plans anything.
Last updated August 26, 2026
The loop moves work forward; it does not remember why
Every artefact in the loop belongs to one piece of work. An intent describes this feature, a plan sequences this change, a review judges this diff — and when the work lands, the reasoning behind it lands too, finished and never consulted again. The next piece of work starts from the same blank page. Standing knowledge is the opposite shape: it belongs to no single piece of work, it outlives all of them, and it is what an assistant needs before it writes the first line.
Name where each artefact lives — and notice the row with no file
The practice already asks teams to say where each artefact is kept, and that discipline is what makes the loop legible. Do it honestly and one row comes back empty: decisions and norms have no artefact. Not the pricing rule, not what may be sent to a client, not why a supplier was dropped, not the convention agreed in a meeting by someone who does not commit code. Arroway is the answer to that row — the repository holds the code, Arroway holds what the team decided.
Half the people who decide never open a repository
The loop is written for the people who commit, and the decisions that govern their work are often made by others. If knowledge is tied to a codebase, a rule set by someone in sales, support or finance either gets copied into a file by a developer or never reaches an assistant at all. Arroway is organised by project rather than by repository, so a decision written by someone who never touches git is in the read of someone who does.
What it looks like in practice
A team adopts the loop and it works: intents are written, plans are derived, reviews are tight. Six weeks in, an assistant proposes an approach the team abandoned in month one — with good reasoning, because nothing it can read says the approach was tried and rejected. The rejection was real and was argued at length. It just had no artefact, so it was never in front of the model. The loop was followed correctly and produced the same wrong answer twice.
Questions people ask about this
- Is this a replacement for the intent and plan files?
- No. Those describe one piece of work and are right where they are. Arroway holds the layer underneath — what is in force across all of them — and the two meet when an intent is written: an intent drafted against the team's standing decisions is a different document from one drafted against a blank page.
- Why not keep decisions in the repository too, next to the artefacts?
- Some teams do, and it works until two things happen. A decision is overturned and the old line keeps reading as current, because a plain file has no way to say it was superseded. And someone outside the repository makes a call, and the knowledge either gets copied by hand or never arrives. Arroway carries the condition that ends a decision, a pointer from a replaced memory to what replaced it, and a boundary that is a project rather than a codebase.
- Where does the assistant get this during the loop?
- At the start of the work, before it plans anything, through the same connection it uses to write back. The read is ordered by the task the assistant declares and comes back saying what it delivered and what did not fit, so “the assistant knows our rules” is something you can check. What the assistant learns along the way it records as proposals, and a person approves them in review — only what a person approved governs the next read.
Where this is verifiable
Product documentation on this site (How it works, Install) and the sanctioned product spec in the repository. The description of the AI-native loop refers to the publicly published practice of naming an artefact and its source of truth per stage; this page makes no claim about any specific tool's behaviour, and no claim about the built-in memory of any AI product.
https://www.arroway.app/en/answers/team-memory-in-the-ai-native-sdlc