# Arroway > Arroway orchestrates people and AI agents around the decisions in force. Arroway orchestrates people and AI agents around current decisions. Agents can read context, record changes and hand off work; people decide what stands. ## Install - [Install Arroway](https://www.arroway.app/en/install): Choose one environment. We show one route at a time — without asking you to sign in until it is needed. - [Add Arroway to a repository](https://www.arroway.app/en/install/agents.md): Instructions for coding agents, as plain text - MCP server: `https://www.arroway.app/api/mcp` — The MCP server connects Arroway to your AI; the plugin is what makes the AI use it. With the plugin, every session opens by reading what is in force and closes by recording what was done, without anyone asking. Without it, the AI calls Arroway only when your request asks for it. ## Where Arroway is listed - [Glama](https://glama.ai/mcp/connectors/app.arroway/arroway): since 2026-09-25 - [Anthropic Connectors Directory](https://claude.ai/directory/arroway): since 2026-09-28 - [Smithery](https://smithery.ai/servers/alexandreviola/arroway): since 2026-09-28 - [MCP Servers](https://mcpservers.org/servers/www-arroway-app-en-install): since 2026-09-29 - [Official MCP Registry](https://registry.modelcontextprotocol.io/v0.1/servers?search=io.github.oaleviola): since 2026-09-28 - [Tedix](https://tedix.dev/apps/arroway/): since 2026-08-17 - [ClaudePluginHub](https://www.claudepluginhub.com/plugins/oaleviola-arroway-plugin): since 2026-10-05 - [cursor.directory](https://cursor.directory/plugins/arroway): since 2026-10-06 ## Profiles - [LinkedIn](https://www.linkedin.com/company/arroway-app/) - [YouTube](https://www.youtube.com/channel/UC1RZId878kTcZbj0vZdORig) - [GitHub](https://github.com/oaleviola/arroway-plugin) ## How it works - [How Arroway works](https://www.arroway.app/en/how-it-works): Follow one decision through Arroway: read, work, remember and correct — with human control and clear limits. - [Audit your CLAUDE.md](https://www.arroway.app/en/audit): Paste your CLAUDE.md and see what it actually costs: how much reaches the model, what is a decision, a rule, a fact, dated state or noise. - [Trust](https://www.arroway.app/en/trust): Where Arroway keeps your data, how it is encrypted, which providers process it, how long it is kept and how to delete it. - [Data Processing Addendum](https://www.arroway.app/en/dpa): Arroway's data processing addendum: roles, security measures, sub-processors with their regions, international transfers, incident notice and deletion. ## Answers - [Answers about shared memory for people and AI](https://www.arroway.app/en/answers): Start with the question in front of your team. Each answer explains one part of how shared context reaches the AI before work starts. - [Shared memory for teams that work with AI](https://www.arroway.app/en/answers/shared-memory-for-ai-teams): Shared memory for a team is one place — outside every assistant — where the team's decisions, rules and daily record are written down, and which each person's AI reads before it starts a task and writes to when it finishes. - [AI memory a person approves before it counts](https://www.arroway.app/en/answers/human-sanctioned-ai-memory): Human-sanctioned memory means a person decides what becomes a rule, and the AI cannot promote its own guess to that status. - [Should team knowledge for AI live in versioned files, or in curated memory?](https://www.arroway.app/en/answers/context-files-vs-curated-memory): Files in the repository — a CLAUDE.md, a folder of skills, notes committed next to the code — are where most teams put what their AI should know, and that is where the trouble starts: whatever lands in them governs every later session, and nobody sees it arrive or approves it — an assistant's guess, a status that went stale, a decision the team never knew was made. - [Shared context across Claude, ChatGPT and Codex](https://www.arroway.app/en/answers/shared-context-across-ai-tools) - [How team decisions reach the AIs doing the work](https://www.arroway.app/en/answers/how-team-decisions-reach-ai) - [How to install and use Arroway in the main AI ecosystems](https://www.arroway.app/en/answers/install-across-ai-tools) - [Where does team memory fit in an AI-native software lifecycle?](https://www.arroway.app/en/answers/team-memory-in-the-ai-native-sdlc) - [Your CLAUDE.md outgrew a page. What comes out of it?](https://www.arroway.app/en/answers/context-file-outgrew-a-page) - [Shared memory for law firms: the house position, in every partner's AI](https://www.arroway.app/en/answers/shared-memory-for-law-firms) - [AI memory and client confidentiality: how one client's matter stays out of another's](https://www.arroway.app/en/answers/ai-memory-and-client-confidentiality) - [The partner on the account changes. What does the next one inherit?](https://www.arroway.app/en/answers/handoff-between-partners-on-the-same-account) - [Shared memory for VC funds: the thesis your AI already knows](https://www.arroway.app/en/answers/shared-memory-for-vc-funds) - [One rule, four prompts: why your AI automations drift apart](https://www.arroway.app/en/answers/one-rule-four-prompts-and-they-drift) - [Handing work between your own AI routines, without re-narration](https://www.arroway.app/en/answers/handoff-between-your-own-scheduled-ai-routines) - [I keep a spreadsheet of facts to paste into every AI. Is there a better way?](https://www.arroway.app/en/answers/tracking-ai-facts-without-a-spreadsheet) - [We are switching AI tools. Do we lose what the team already decided?](https://www.arroway.app/en/answers/switching-ai-tools-without-losing-team-decisions) - [How does an AI agency keep one client's rules out of another client's work?](https://www.arroway.app/en/answers/shared-memory-for-ai-agencies) - [New associates using AI: how the partner's call reaches them first](https://www.arroway.app/en/answers/keeping-new-associates-aligned-with-partner-calls) - [Shared memory for multi-partner consultancies: what the firm standardises, what stays yours](https://www.arroway.app/en/answers/shared-memory-for-multi-partner-consultancies) - [We tried a shared doc of client rules and nobody updated it](https://www.arroway.app/en/answers/retiring-the-shared-doc-nobody-updates) - [Why not just run RAG over our repository instead of another AI memory tool?](https://www.arroway.app/en/answers/why-rag-doesnt-replace-sanctioned-memory) - [How does an AI agency change the person on a client without losing what the account knows?](https://www.arroway.app/en/answers/ai-agency-client-handoff-without-losing-context) - [How do we show a client that our AI followed their rules instead of inventing one?](https://www.arroway.app/en/answers/showing-clients-the-ai-followed-their-rules) - [Can we recommend an AI memory tool to our portfolio without becoming its support desk?](https://www.arroway.app/en/answers/recommending-ai-memory-to-your-portfolio) - [Each partner runs diligence with a different AI and the notes never reconcile. What fixes that?](https://www.arroway.app/en/answers/keeping-due-diligence-notes-consistent-across-partners) - [Our scheduled AI routines start from zero every run. How do they keep the thread?](https://www.arroway.app/en/answers/keeping-scheduled-ai-routines-from-losing-the-thread) - [I keep a second brain for myself. What is the second brain for the AIs my team uses?](https://www.arroway.app/en/answers/the-second-brain-for-your-ais) - [We run several AI agents and people on the same work. Is an orchestration tool what we need?](https://www.arroway.app/en/answers/orchestrating-ai-agents-and-people-on-one-shared-memory) - [Won't a big enough context window fix this without an AI memory tool?](https://www.arroway.app/en/answers/context-window-wont-fix-what-memory-fixes) - [Isn't out-of-date AI memory worse than having no memory at all?](https://www.arroway.app/en/answers/stale-memory-is-worse-than-no-memory) - [Why does the AI drop a rule we agreed on five messages ago?](https://www.arroway.app/en/answers/rules-that-slip-five-messages-later) - [Whose memory is it when it lives on the AI vendor's server?](https://www.arroway.app/en/answers/memory-that-lives-on-someone-elses-server) - [Isn't AI memory without a write policy just a faster way to hallucinate?](https://www.arroway.app/en/answers/memory-without-a-write-policy-is-just-faster-hallucination) - [Doesn't a knowledge graph solve this by linking the facts together?](https://www.arroway.app/en/answers/the-graph-links-facts-it-doesnt-decide-which-is-current) - [Our AI writes 400-line handoffs and the next agent reads half of one. What fixes that?](https://www.arroway.app/en/answers/chatty-handoffs-bloat-every-agent-that-reads-them-next) - [There are already dozens of AI memory tools. Why would we evaluate another one?](https://www.arroway.app/en/answers/a-crowded-memory-market-doesnt-mean-a-sanctioned-one) - [I don't want AI tools remembering me. I keep context per project. Isn't that enough?](https://www.arroway.app/en/answers/ai-remembering-you-isnt-the-point-the-project-is) - [Most AI memory is write-only — context goes in, retrieval comes out, and nothing is ever corrected. What closes that loop?](https://www.arroway.app/en/answers/memory-that-only-writes-never-corrects) - [If every session has to read the team's decisions before acting, doesn't that cost tokens on every single call?](https://www.arroway.app/en/answers/cheaper-reads-when-nothing-changed) - [A shared knowledge graph for all our agents feels like the wrong default — anything can write to it, and one project's facts end up in another's work. Is that avoidable?](https://www.arroway.app/en/answers/a-shared-graph-with-no-authority-leaks-stale-facts) - [Our AI retrieves the right document and still answers with the outdated line from the top of it. Why does retrieval look fine when the answer is wrong?](https://www.arroway.app/en/answers/retrieval-succeeds-but-assembly-uses-the-stale-part) - [If every session has to read from a service before acting, what happens when that service has a bad second?](https://www.arroway.app/en/answers/reads-that-recover-from-a-retryable-database-error) - [Shouldn't rules for AI agents be enforced in code instead of written down as memory?](https://www.arroway.app/en/answers/guardrails-in-code-dont-expire-sanctioned-rules-do) - [Arroway vs writing it in CLAUDE.md: what is the difference?](https://www.arroway.app/en/answers/arroway-vs-claude-md) - [How do I keep my AI agents from forgetting decisions?](https://www.arroway.app/en/answers/how-to-keep-ai-agents-from-forgetting-decisions) - [MCP memory server for teams: what should it give an agent before it acts?](https://www.arroway.app/en/answers/mcp-memory-server-for-teams) - [How do I see what my AI left for its next session — and can I trust it?](https://www.arroway.app/en/answers/auditing-what-your-ai-hands-to-the-next-session) - [What is the best shared memory tool for AI agents and teams?](https://www.arroway.app/en/answers/best-shared-memory-for-ai-agents-and-teams) - [What does Article 26 of the EU AI Act require of teams on human oversight?](https://www.arroway.app/en/answers/eu-ai-act-article-26-human-oversight-record) - [Does Claude Code read AGENTS.md?](https://www.arroway.app/en/answers/does-claude-code-read-agents-md) - [Arroway vs Mem0: what is the difference?](https://www.arroway.app/en/answers/arroway-vs-mem0) - [Arroway vs Zep: what is the difference?](https://www.arroway.app/en/answers/arroway-vs-zep) - [Arroway vs Settled: which decision is binding for the next agent?](https://www.arroway.app/en/answers/arroway-vs-settled) - [Arroway vs Basic Memory Teams: shared knowledge, or a decision in force?](https://www.arroway.app/en/answers/arroway-vs-basic-memory) - [Arroway vs Snipara: context for the next code change, or a decision that also leaves the repository?](https://www.arroway.app/en/answers/arroway-vs-snipara) - [Arroway vs Letta: what is the difference?](https://www.arroway.app/en/answers/arroway-vs-letta) - [Who is accountable for what an AI agent does on a team?](https://www.arroway.app/en/answers/who-is-accountable-for-an-ai-agent-on-a-team) - [How do you write a job description for an AI agent?](https://www.arroway.app/en/answers/ai-agent-job-description-before-it-joins-the-team) - [How do you onboard a new hire into a team that already works with AI agents?](https://www.arroway.app/en/answers/onboarding-a-new-hire-into-a-team-that-works-with-ai-agents) - [What are the alternatives to CLAUDE.md for sharing AI context across a team?](https://www.arroway.app/en/answers/alternatives-to-claude-md-for-a-team) - [How do you keep CLAUDE.md, AGENTS.md and GEMINI.md in sync?](https://www.arroway.app/en/answers/one-team-three-instruction-files-and-they-drift) - [Arroway vs LangMem: what is the difference?](https://www.arroway.app/en/answers/arroway-vs-langmem) - [How do you share a Claude Project with your team?](https://www.arroway.app/en/answers/share-a-claude-project-with-your-team) - [How do you share rules between Cursor and Claude Code?](https://www.arroway.app/en/answers/cursor-rules-and-claude-md-in-the-same-team) ## Other languages - [Português](https://www.arroway.app/pt-BR): A Arroway coordena pessoas e agentes de IA em torno das decisões que estão valendo. - [Español](https://www.arroway.app/es): Arroway coordina a personas y agentes de IA en torno a las decisiones vigentes. --- # Answers in full ## Shared memory for teams that work with AI https://www.arroway.app/en/answers/shared-memory-for-ai-teams Shared memory for a team is one place — outside every assistant — where the team's decisions, rules and daily record are written down, and which each person's AI reads before it starts a task and writes to when it finishes. Arroway is that place. The memory belongs to the project, not to anyone's chat window, so the second person's assistant starts from what the first person already settled, instead of from a blank. It works the same with one person and one agent, because the next session is a reader too, and it installs in the tool you already use: Claude, ChatGPT or Codex, Cursor, or anything that connects over MCP. ## Shared context across Claude, ChatGPT and Codex https://www.arroway.app/en/answers/shared-context-across-ai-tools One connection, and every assistant reads the same project. Arroway runs as a server your AI tools connect to — Claude, ChatGPT, Codex and any other tool that speaks the same connection standard — so they all read and write one memory. What you settled in one tool is already there when you open the next, and changing tools does not start you over. ## AI memory a person approves before it counts https://www.arroway.app/en/answers/human-sanctioned-ai-memory Human-sanctioned memory means a person decides what becomes a rule, and the AI cannot promote its own guess to that status. In Arroway an assistant writes freely as it works, but anything it worked out on its own is filed as a proposal. A person turns proposals into standing rules — or edits them, or throws them out — on a review screen, after the fact. The work never waits on that review. ## How team decisions reach the AIs doing the work https://www.arroway.app/en/answers/how-team-decisions-reach-ai 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. ## How to install and use Arroway in the main AI ecosystems https://www.arroway.app/en/answers/install-across-ai-tools You pick the tool you already work in, connect Arroway to it, and start working. The installation page asks one question — where do you use AI? — and shows one route, not a menu of every possibility. It does not ask you to sign in until the moment a sign-in is actually needed. ## Should team knowledge for AI live in versioned files, or in curated memory? https://www.arroway.app/en/answers/context-files-vs-curated-memory Files in the repository — a CLAUDE.md, a folder of skills, notes committed next to the code — are where most teams put what their AI should know, and that is where the trouble starts: whatever lands in them governs every later session, and nobody sees it arrive or approves it — an assistant's guess, a status that went stale, a decision the team never knew was made. A file also cannot say which rule is in force today, who decided it, or whether the model actually received it. Arroway holds what should hold: written by people and their assistants, approved by a person, ordered by the task, and delivered with a count of what fit. The file can stay empty. ## Where does team memory fit in an AI-native software lifecycle? https://www.arroway.app/en/answers/team-memory-in-the-ai-native-sdlc 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. ## Your CLAUDE.md outgrew a page. What comes out of it? https://www.arroway.app/en/answers/context-file-outgrew-a-page The usual advice is to keep a CLAUDE.md under a page and trim it when it grows. Trimming treats size as the problem. The problem is that everything in the file governs every session, and nobody sees what goes in or approves it: an assistant's guess, a status line from March and a decision made in a meeting the reader never attended all carry the same weight as the build command. So what comes out is all of it. What still holds moves to Arroway, where a person approves it and the read picks it by task; what is stale or noise is deleted. The file can end up empty. ## Shared memory for law firms: the house position, in every partner's AI https://www.arroway.app/en/answers/shared-memory-for-law-firms A firm's position on a recurring question belongs to the firm, but each partner's AI only knows what that partner typed into it. Arroway is a shared place, outside every assistant, where those positions are written down and approved by a person at the firm. From then on, when any partner's AI starts work on a matter, it reads the positions that apply before it drafts anything. Nobody re-explains the house view in a prompt, and nobody finds out that a colleague answered the opposite after the advice has already gone to the client. ## AI memory and client confidentiality: how one client's matter stays out of another's https://www.arroway.app/en/answers/ai-memory-and-client-confidentiality Memory lives inside a project, and a read never crosses from one project to another. A matter, a client, a practice group — each is its own project, and what is written there is served only to the people who belong to it, on connections that identify them personally. Nothing is shared by default, nothing spreads because two matters look alike, and what should never be within an AI's reach is kept out by the only control that actually holds: a person decides what gets written down at all. ## The partner on the account changes. What does the next one inherit? https://www.arroway.app/en/answers/handoff-between-partners-on-the-same-account What a successor should inherit is the decisions the account already carries — not a folder of e-mails to mine and a calendar of calls nobody wrote up. With Arroway the account remembers instead of the person: each decision taken with that client is written down as it happens, approved by a person, and read by the next partner's AI the moment they open the work. The handoff meeting stops being the only transfer — and stops being the place where whatever nobody thought to mention is lost. ## Shared memory for VC funds: the thesis your AI already knows https://www.arroway.app/en/answers/shared-memory-for-vc-funds A fund's thesis and screening criteria are settled once by the partners and then applied to every deal that arrives — but the AI doing the applying only knows what somebody pasted into it that morning. Arroway is a shared place, outside every assistant, where the thesis, the criteria and the hard lines are written down and approved by a partner. From then on, when any partner's AI opens a deal, it reads the criteria that apply before it forms a view. Nobody retypes the thesis into a prompt, and nobody finds out afterwards that a screen ran against last year's version of it. ## One rule, four prompts: why your AI automations drift apart https://www.arroway.app/en/answers/one-rule-four-prompts-and-they-drift When the same rule is pasted into four automation prompts, you do not have one rule — you have four copies that will stop agreeing. Correcting it means finding every file that carries it, and the copy you miss keeps running. With Arroway the rule is written and approved once, in a shared place outside the prompts, and every routine reads it when it starts. The correction is a single edit, and no prompt is left holding a version nobody remembered to update. ## Handing work between your own AI routines, without re-narration https://www.arroway.app/en/answers/handoff-between-your-own-scheduled-ai-routines Scheduled AI routines usually pass work to each other by retelling it — a note in a file, a message in a channel, last night's transcript — and a retold fact drifts. With Arroway a run that stops unfinished leaves an explicit handoff: where it stopped, the one next step, the risk left open, and who it is for. That handoff is served first to whatever reads next, and it stays there until someone closes it. Nothing is inherited as a summary of a summary, and nothing quietly falls off the list. ## I keep a spreadsheet of facts to paste into every AI. Is there a better way? https://www.arroway.app/en/answers/tracking-ai-facts-without-a-spreadsheet Yes, and the spreadsheet is the right instinct in the wrong place. Keeping a short, chosen list of facts and decisions is exactly what makes an assistant useful — the part that breaks is that you are the delivery mechanism. Arroway keeps that same list on a server your AI tools connect to, so each assistant reads it at the start of the work instead of waiting to be given it. You keep the part that was always yours, which is deciding what belongs in the list, and stop doing the part no person should be doing, which is carrying it from tool to tool. ## We are switching AI tools. Do we lose what the team already decided? https://www.arroway.app/en/answers/switching-ai-tools-without-losing-team-decisions Not if the decisions were never inside the tool. What a team loses in a migration is whatever it kept in a vendor's own memory, its settings and its per-tool configuration files — those belong to that tool, and no export makes them arrive intact somewhere else. Arroway holds decisions in a different place: a server your tools connect to. The new assistant reads the same sanctioned set the old one read, on its first day, so the switch costs you configuration instead of context. ## How does an AI agency keep one client's rules out of another client's work? https://www.arroway.app/en/answers/shared-memory-for-ai-agencies By keeping each client in its own project, and the agency's own way of working in a separate one. Memory in Arroway is scoped to a project and never global: an assistant working on an account reads that client's sanctioned rules plus the agency's house method, and nothing from any other client — because the other accounts are not in scope for that read, not because someone remembered to leave them out. The same person and the same assistant can work six accounts in a day without the sixth inheriting the voice of the first. ## New associates using AI: how the partner's call reaches them first https://www.arroway.app/en/answers/keeping-new-associates-aligned-with-partner-calls An associate working with AI answers with whatever the AI knows, and what it knows is what that associate told it — not what the partners settled on the same question two years ago, in a matter the associate never touched. Curated memory changes the order: the position the firm already sanctioned is served to the associate's AI when the work opens, before a first draft exists, and whatever that assistant works out on its own is stored as a proposal rather than as the firm's answer. The associate starts out knowing where the house stands, instead of someone catching the contradiction in review. ## Shared memory for multi-partner consultancies: what the firm standardises, what stays yours https://www.arroway.app/en/answers/shared-memory-for-multi-partner-consultancies In a consultancy each partner has their own clients and their own way of running an engagement, and both are worth keeping — so the useful question is not how to make every partner's AI answer the same way, it is which part of the answer belongs to the firm. Curated memory draws that line explicitly: what the firm sells — the method, the standards, the things it will not do, the register it writes in — is written once and sanctioned, and it reaches any AI any partner connects. How each partner runs their own account stays in their own project, unstandardised on purpose. ## We tried a shared doc of client rules and nobody updated it https://www.arroway.app/en/answers/retiring-the-shared-doc-nobody-updates The shared document did not fail for lack of discipline; it failed because keeping it current and reading it were both extra gestures, and an extra gesture loses to billable work every time. Curated memory removes both. The assistants already inside the work write what was decided at the moment it is decided, and the norm is read when an assistant opens the work rather than when somebody remembers to look it up. What is left for a person is a short review — approve or correct what was written — which is a few minutes over work already done, not a chore waiting to be done. ## Why not just run RAG over our repository instead of another AI memory tool? https://www.arroway.app/en/answers/why-rag-doesnt-replace-sanctioned-memory Because retrieval and sanction answer different questions. RAG finds the passages most similar to what was asked, out of everything it indexed — including the decision the team reversed last quarter, the design that was never built, and the two documents that contradict each other. It has no way to say which of them is in force, because nothing in an index carries that. Arroway holds a much smaller set: the rules and decisions a person on the team approved, each with the name of who approved it and the condition that ends it. An assistant reads that set before it acts. Retrieval still finds text for you; it is not what tells the assistant which text still counts. ## How does an AI agency change the person on a client without losing what the account knows? https://www.arroway.app/en/answers/ai-agency-client-handoff-without-losing-context By keeping what the account knows in the account's own project, written as it is decided, instead of in the head of whoever is currently on it. When someone is taken off the client they lose access to that project, and everything they recorded there stays — under their name, with the date and the reason. The person taking over reads the client's rules in force on their first day, and their assistant reads the same set. The only thing that leaves with the person is what nobody ever wrote down, which is why the writing happens during the work rather than in a handover the week someone goes. ## How do we show a client that our AI followed their rules instead of inventing one? https://www.arroway.app/en/answers/showing-clients-the-ai-followed-their-rules By showing the record the assistant read, rather than a summary written afterwards. Every rule in force in a project carries what was decided, when, and which person approved it — and a rule an assistant proposed that nobody approved is visibly still a proposal. So the answer to a client asking where a rule came from is a dated line with a name on it. What the record does not do is prove that one particular deliverable came out of it: it shows what governed the work, and your own review is what ties a specific piece to it. Claiming more than that would be claiming more than the record holds. ## Can we recommend an AI memory tool to our portfolio without becoming its support desk? https://www.arroway.app/en/answers/recommending-ai-memory-to-your-portfolio Yes, because nothing about it routes through you. Each company signs up on its own, in its own account, and connects the assistants its own people already use — the fund holds no licence, no admin seat and no key on their side. The honest half of the recommendation is what installing does not do: connecting takes minutes and works unattended, but nothing changes until someone at that company writes down the first few decisions their assistants should be reading. That step belongs to them, and a recommendation that leaves it out produces a company that installed the tool and never used it. There is no referral link and no reseller arrangement to sign — the recommendation is a link and an opinion. ## Each partner runs diligence with a different AI and the notes never reconcile. What fixes that? https://www.arroway.app/en/answers/keeping-due-diligence-notes-consistent-across-partners Putting what the diligence has already established in one place that every partner's assistant reads, instead of in two sets of notes that only meet at the committee. Each finding goes in once — the revenue figure that was confirmed and the document that confirmed it, the customer reference that came back weak, the question still open — and from then on any partner's assistant opens the work already holding it, whichever tool that partner uses. What this removes is not disagreement between partners, which is the job: it removes two assistants reporting different numbers with equal confidence because each one read a different half of the material. ## Our scheduled AI routines start from zero every run. How do they keep the thread? https://www.arroway.app/en/answers/keeping-scheduled-ai-routines-from-losing-the-thread By writing what each run established into a place the next run reads before it does anything. A scheduled routine has no memory of its own past runs — every trigger is a fresh context — so tonight's run re-derives what last night's already worked out, and either reaches the same conclusion at the same cost or reaches a different one with nothing there to contradict it. The habit that fixes it has two halves: the run opens by reading the rules in force and what recent runs recorded, and it closes by recording what it found in a line or two, including when it found nothing. A run that recorded nothing is indistinguishable from a run that never fired, and that is the failure worth designing against. ## I keep a second brain for myself. What is the second brain for the AIs my team uses? https://www.arroway.app/en/answers/the-second-brain-for-your-ais It is a shared record the AIs read before they act, holding what your team has actually decided. A personal second brain is written to be re-read by its author: you wrote the note, so on opening it you silently supply everything it left out — that this one was a maybe, that it stopped being true in March, that the tone rule is for client work and not for internal drafts. An AI has nobody sitting beside it to supply any of that. So the second brain for your AIs has to say out loud three things a personal one never needs to: what is a decision and what is still somebody's proposal, when each thing stops being true, and who put it there. That is what makes it safe for a tool to read the record and act on it without checking with you first. ## We run several AI agents and people on the same work. Is an orchestration tool what we need? https://www.arroway.app/en/answers/orchestrating-ai-agents-and-people-on-one-shared-memory Two different problems get called orchestration, and only one of them is about scheduling. Ordering the work — what runs when, what waits for what, what retries after a failure — is what an orchestrator does, and this page does not send you to buy one. The failure most teams actually hit looks nothing like it: two agents run correctly, at the same time, on different premises about what the team decided. Nothing is late, nothing is stuck, nothing retries, and the two outputs contradict each other. That is not fixed by deciding who commands whom. It is fixed by every agent and every person reading the same decision in force before acting, and recording what they did. A queue coordinates order; a shared record coordinates agreement — Use Arroway when the failure is the second one: every agent and every person reads the same decision in force before acting. ## Won't a big enough context window fix this without an AI memory tool? https://www.arroway.app/en/answers/context-window-wont-fix-what-memory-fixes No, because the two solve different problems. A larger window raises how much text an assistant can hold at once. It does not say which of that text is still in force, who approved it, or what has since replaced it. Put a team's whole history in front of a model and you have handed it the decision that was reversed in March alongside the one that replaced it, with nothing marking which is which. Arroway holds a much smaller set — the rules and decisions a person on the team approved, each carrying the name of who approved it and the condition that ends it — and an assistant reads that set before it acts. Capacity was never the missing piece. A statement of what currently counts was. ## Isn't out-of-date AI memory worse than having no memory at all? https://www.arroway.app/en/answers/stale-memory-is-worse-than-no-memory The risk is real and it is the right thing to ask about: an assistant that states a dead rule with confidence does more damage than one that asks. What decides it is whether anything ends a memory other than someone remembering to delete it. Here every rule and decision is written together with the condition that ends it — the revocation, the date, the event that makes it false. When that condition is met the memory is retired and stops being served, and a decision that replaces an earlier one names the one it replaced instead of sitting beside it. The failure you are describing belongs to stores that only accumulate. Expiry is part of the record, not a cleanup someone has to schedule. ## Why does the AI drop a rule we agreed on five messages ago? https://www.arroway.app/en/answers/rules-that-slip-five-messages-later Because the rule only ever existed inside the conversation. Anything agreed mid-session sits in the same window as everything said since — the code that was pasted, the errors that came back, the tangent about something else — and the model's own defaults are what it falls back to as that competition gets crowded. A rule that has to survive being told once is not stored anywhere; it is being remembered by a process nobody asked to remember it. Here a rule is written down once, outside any conversation, and every assistant reads the current set before it starts. It does not depend on the session recalling it, which is also why it survives the next session, the other tool, and the teammate who was not there. ## Whose memory is it when it lives on the AI vendor's server? https://www.arroway.app/en/answers/memory-that-lives-on-someone-elses-server It comes down to one test: can you take it out and read it without their software. A memory feature built into an assistant is part of that product — what it keeps, how long it keeps it, in what shape and under which policy are the vendor's decisions, and they can change without anyone asking you. Arroway is a separate record that belongs to your team. Its contents are text your people wrote, exportable in full at any time, read by whichever assistant is working rather than by one of them, and governed by rules the team writes. The question is not where the bytes physically sit — ours sit on a server too. It is who decides what the record contains, and whether it survives you changing your mind about the tool. ## Isn't AI memory without a write policy just a faster way to hallucinate? https://www.arroway.app/en/answers/memory-without-a-write-policy-is-just-faster-hallucination Yes, and it is the right objection to make about most of what is sold as agent memory. If anything an assistant produces can become a stored fact, the store turns into the place where one confident mistake is preserved and handed to the next run as settled. Better retrieval makes that worse rather than better, because it makes the wrong entry easier to find. What breaks the loop is a step between writing and governing: here an assistant can propose, and only a person on the project can make a proposal binding. Until someone approves it, it sits in a review queue as a suggestion, and no assistant reads it as a rule. ## Doesn't a knowledge graph solve this by linking the facts together? https://www.arroway.app/en/answers/the-graph-links-facts-it-doesnt-decide-which-is-current It solves a real part of it, and the part it solves is not this one. A graph is good at identity: it can work out that "the billing service", "billing-svc" and "the payments backend" are one thing, which a flat list of notes cannot. What it does not carry is authority. Link the facts about that service and the contradictory versions now arrive together — last year's retry policy beside this quarter's, connected, consistent and equally present, with no edge saying which one is in force. Arroway answers that question first: one entry is current, it names who approved it, and the one it replaced is retired with the reason attached. ## Our AI writes 400-line handoffs and the next agent reads half of one. What fixes that? https://www.arroway.app/en/answers/chatty-handoffs-bloat-every-agent-that-reads-them-next The fix is not a shorter prompt or a stricter style rule — it is separating what TRAVELS from what is kept. Length is what the reader pays, and what the next agent needs fits in one authored line. In Arroway every entry carries an essence written by hand: the operative state in a single sentence, never a copy of the body's opening. That line is what a read serves. The full body stays recoverable and comes back only when someone asks for that entry by name. So the record can be as thorough as the work deserves without the next twelve reads paying for it — and because the line is authored rather than truncated, it says the thing instead of the first 200 characters of the thing. ## There are already dozens of AI memory tools. Why would we evaluate another one? https://www.arroway.app/en/answers/a-crowded-memory-market-doesnt-mean-a-sanctioned-one Because the thing they are crowded on is not the thing that is missing. Almost every tool on that list answers the same two questions — how text gets stored, and how it comes back — and on those two they are genuinely hard to tell apart, which is exactly what makes the category feel saturated. The question none of them answers by default is who decided that a stored statement is what the team stands behind, and what happens to it when someone changes their mind. That is governance, not retrieval, and a crowded retrieval market says nothing about it. The honest version of the objection is that you cannot tell these tools apart on the axis you were comparing them on — which is true, and is a reason to change the axis rather than to stop looking. ## I don't want AI tools remembering me. I keep context per project. Isn't that enough? https://www.arroway.app/en/answers/ai-remembering-you-isnt-the-point-the-project-is Keeping context per project is the right instinct, and it is the one this is built on — what gets remembered here is the project, never the person. The gap is not in the scope you chose, it is in what holds it. Per-project context that lives in a file lets whatever lands in it — your line, an assistant's, last month's — govern every session with nobody seeing or approving it, and it gets worse the moment a second person, a second machine or a second assistant touches the same project, because nothing in the file says which version is in force or who decided. So this is not a personal-profile product with a project setting. The unit is the project's decision, a person sanctions it, and whoever opens that project next reads it — another teammate, another tool, or you in three weeks. ## Most AI memory is write-only — context goes in, retrieval comes out, and nothing is ever corrected. What closes that loop? https://www.arroway.app/en/answers/memory-that-only-writes-never-corrects A correction path that belongs to the record rather than sitting beside it. When something stored here stops being true, three things happen in order and all three can be inspected afterwards. Whoever opened the source and saw the divergence writes down what the source actually says, so nobody has to go and look again. The correction is then proposed as a replacement that names the memory it contradicts — not a newer row sitting next to the old one. And a person accepts or refuses it; on acceptance the replaced statement is retired in the same act, with the reason and the author on its archived line. Until that acceptance, the earlier statement is still what gets served. The delay is deliberate: a record where an assistant retires the team's decisions on its own judgement is a log of what the last model believed. ## If every session has to read the team's decisions before acting, doesn't that cost tokens on every single call? https://www.arroway.app/en/answers/cheaper-reads-when-nothing-changed It costs them once per session, and after that only what changed. A read of a project ends with a checkpoint. Present that checkpoint on a later call and the standing rules are referenced instead of written out again, and the space they would have taken goes to the material this particular task needs. Measured in production on a second read: 4,826 tokens referenced rather than reprinted. What is never skipped is the part that moves — work in flight, what landed since, and what ranks as relevant to what you are doing now. So checking what the team has decided before you act stops getting more expensive the more often you check, which is the property that decides whether anyone keeps doing it. ## A shared knowledge graph for all our agents feels like the wrong default — anything can write to it, and one project's facts end up in another's work. Is that avoidable? https://www.arroway.app/en/answers/a-shared-graph-with-no-authority-leaks-stale-facts It is, and the two halves of the objection need two different answers, because they are two different failures. Writability is answered by authority: writing something here does not make it a norm. What an assistant writes on its own initiative arrives as a proposal, or as context that is labelled as unsanctioned, and it stays that way until a person accepts it — at which point it becomes what the team stands behind, with their name on it. Leakage is answered by scope: the project is the boundary, it is chosen when the memory is written rather than filtered when it is read, and one project's material is not served into another. Neither answer is a property of the graph shape. A graph can carry both, or neither, which is why "shared graph" describes a storage choice and not a governance one. ## Our AI retrieves the right document and still answers with the outdated line from the top of it. Why does retrieval look fine when the answer is wrong? https://www.arroway.app/en/answers/retrieval-succeeds-but-assembly-uses-the-stale-part Because retrieval and assembly are two different steps, and a green number on the first says nothing about the second. What reaches the model here is not a document for some later layer to excerpt: it is a statement, delivered as one authored line that carries the operative point, with the full body coming back only when someone asks for that memory by name. There is no top of a file to truncate into and no paragraph to pick wrongly. A statement that was replaced is not a lower-ranked neighbour of its replacement — it is retired in the same act that accepts the replacement, with the reason and the author kept on its archived line. And a statement someone saw contradicting its source arrives marked as contradicted rather than arriving clean. Which version is current is settled once, by a person, in the record; it is not re-derived on every call by whatever gets the last word on the prompt. ## If every session has to read from a service before acting, what happens when that service has a bad second? https://www.arroway.app/en/answers/reads-that-recover-from-a-retryable-database-error The read is attempted again instead of failing. A database that scales to zero refuses the first call after an idle period while its compute wakes, and it says so: the refusal carries an explicit marker from the provider meaning the call never reached a running compute and can be repeated. That marker used to be ignored here, and the refusal travelled all the way to the caller as a failed read — which, for a session whose first act is to check what the team has already decided, means carrying on without it. Since September 2026 a refusal carrying that marker is retried, up to three attempts, costing on the order of three quarters of a second in the worst case. Two limits keep this from being a licence: only the provider's own declaration counts, never our reading of an error message, and only statements that are unambiguously reads are repeated. Anything that writes is attempted exactly once, as before. ## Shouldn't rules for AI agents be enforced in code instead of written down as memory? https://www.arroway.app/en/answers/guardrails-in-code-dont-expire-sanctioned-rules-do Some of them, yes — and those should never have been instructions in the first place. A rule that holds for as long as the system is built the way it is, like one deployment at a time, belongs in a lock the agent cannot skip. But a guardrail only knows how to enforce a rule while it holds; it has no way to say that the rule stopped holding, who decided that, or what replaced it. Most rules a team gives its agents are of that second kind: decisions someone made and someone will revisit — what may go to a client, which branch ships, what a price is. Arroway holds those. Each one carries the condition that ends it, a replacement points at the rule it retires, and only a person makes a rule binding. Put the invariant in code and the decision in memory; a rule that is both gets the lock and the record of why the lock exists. ## Arroway vs writing it in CLAUDE.md: what is the difference? https://www.arroway.app/en/answers/arroway-vs-claude-md CLAUDE.md is a file in a repository: someone writes it, someone keeps it up to date, and the coding assistant working in that repository loads it. Arroway is a shared memory that every AI tool connected to a project reads before it acts — Claude, ChatGPT, Codex and other tools that speak the same connection standard. It holds what the file cannot: which rules and decisions are in force right now, who decided each one, what would end it, and what has already been retired. Assistants write to it as proposals, and a person approves what becomes binding. It does not read your code, your repository or your data, and it does not run your agents. Arroway's recommendation is to leave CLAUDE.md empty: what holds goes to Arroway, where someone sees it and approves it, so that people and their AIs stay on the same page. ## How do I keep my AI agents from forgetting decisions? https://www.arroway.app/en/answers/how-to-keep-ai-agents-from-forgetting-decisions Stop asking the agent to remember, and make every session start by reading. An agent does not carry decisions between sessions: the conversation ends, the context is compacted, a different agent picks up the work, and what was settled on Tuesday is simply not in front of the model on Wednesday. The usual fixes — a decisions file, a vector store, a checkpoint — solve storage, and storage was never the hard part. What they leave open is whether the next session actually reads before acting, and whether it can tell a decision still in force from one that was overtaken. Arroway covers both with nothing to build: sessions open by reading the project, each decision carries who made it and what would end it, and a replacement retires the old one. It works the same with one agent and no team — the reader is simply the same agent, tomorrow. ## MCP memory server for teams: what should it give an agent before it acts? https://www.arroway.app/en/answers/mcp-memory-server-for-teams An MCP memory server is a server your AI tools call to read and write what a project knows. For a team, the test is what it hands an agent before the agent starts work: what is in force right now, who decided each thing, and what has already been retired — not just the stored text that looks most similar to the question. Arroway is a remote MCP server built around that read. A session opens by reading the project, ordered by the task the agent says it is about to do; every rule and decision carries its author and the condition that ends it; a replacement retires what it replaces; and what an assistant writes on its own arrives as a proposal until a person approves it. It connects to Claude from its connector directory, to ChatGPT and Codex, to Cursor through the plugin, and to any tool that accepts a remote MCP server. The install page shows the route for the tool you use. ## How do I see what my AI left for its next session — and can I trust it? https://www.arroway.app/en/answers/auditing-what-your-ai-hands-to-the-next-session You can trust it as far as you can inspect it, so the note has to be something you can inspect. When a session summarises itself for the next one, that summary is usually text the next session reads and nobody else sees: you find out what it said only when the work goes wrong. In Arroway a session that stops with work unfinished leaves a handoff with fixed parts — where it stopped, the one next step, what is already checked and must not be redone, the risk left open, and who it is for. It sits in the project's panel before anyone continues, with the name of whoever left it, whether someone has taken it, and whether an AI has already read it. Only a person can discard it, and the discard stays on the record. Arroway does not check that the note is true; it makes sure a person can. ## What is the best shared memory tool for AI agents and teams? https://www.arroway.app/en/answers/best-shared-memory-for-ai-agents-and-teams It depends on one question most comparisons skip: when your agents read the memory, do they need what was said, or what is decided? Lists of AI memory tools — Mem0, Zep, Letta, Cognee, Supermemory, Graphiti, LangMem and others — are usually compared on how well they store and retrieve, and on that axis they are hard to tell apart. For a team, the questions that separate them are different: who can make a statement binding, how a statement stops being true, and whether every agent and every person reads the same current version before acting. Arroway is built on those three: a person approves what becomes a rule, every rule carries the condition that ends it and a replacement retires the old one, and sessions in every connected tool open by reading the project, while one that has not read cannot propose a memory. This page does not rank anyone; it gives you the questions to ask each tool, and Arroway's answer to each. ## What does Article 26 of the EU AI Act require of teams on human oversight? https://www.arroway.app/en/answers/eu-ai-act-article-26-human-oversight-record Article 26 sets the duties of whoever uses a high-risk AI system in their own work — the deployer, as opposed to the vendor who built it. Two of those duties are about people and records: oversight has to be assigned to named people with the competence, training and authority to exercise it, and the logs the system generates have to be kept, as far as they are under your control, for at least six months. It is not due yet. The high-risk obligations were postponed to 2 December 2027 for the systems listed in Annex III — hiring, credit, education, access to essential services and the like — and to 2 August 2028 for AI built into products already covered by EU safety law; only the transparency duties have applied since 2 August 2026. So this is preparation, with more than a year of room. A human-oversight record should show who holds oversight and with what authority, which rules the AI worked under and since when, what changed and who changed it, and what each AI read before it acted. Arroway keeps that human side of the record; it does not replace the system's own logs, and it is not a compliance report. ## Does Claude Code read AGENTS.md? https://www.arroway.app/en/answers/does-claude-code-read-agents-md Yes, since version 2.1.277 (18 September 2026) — but by default only when the project has no CLAUDE.md. If a CLAUDE.md, .claude/CLAUDE.md or CLAUDE.local.md sits in your working directory or any directory above it, Claude Code reads those and leaves AGENTS.md out, with no error. The default can be changed under "Project instructions" in /config, for example to read both files, and a release on 24 September extended the support to Amazon Bedrock, Google Vertex AI, Microsoft Foundry, LLM gateways and sessions with telemetry disabled. Which file gets loaded decides which instructions apply, and nothing tells the team. Arroway's recommendation is to keep both files empty: whatever sits in them governs every session with nobody seeing or approving it, and it never reaches a chat assistant, another agent or a person outside the repository. What holds goes to Arroway, with who decided it and when it ends, and every connected tool reads it before acting, whichever file it loads. ## Arroway vs Mem0: what is the difference? https://www.arroway.app/en/answers/arroway-vs-mem0 Mem0 is a memory layer you build into your own AI app or agent: you send it the conversation, an LLM distills it into facts, and at query time it returns the memories most relevant to the request, organised by user, agent, app or run. It comes as a managed platform and as open source. Arroway is not built into anything: it is a shared memory for a project that every AI tool you already use — Claude, ChatGPT, Codex, Cursor or anything over MCP — reads before it acts. The difference is what each one is for. Mem0 remembers what was said, so an application can personalise for each of its users. Arroway holds what was decided: who decided it, what is in force, what ends it and what it replaced — with assistants writing proposals and a person approving what becomes binding. Use Arroway when your team's agents and people must act on the same current decisions across tools. The install page is the first step. ## Arroway vs Zep: what is the difference? https://www.arroway.app/en/answers/arroway-vs-zep Zep is a context layer for AI applications built on a temporal knowledge graph: it takes in conversations and business data, extracts facts and relationships, and when new data invalidates an earlier fact it stores the time that fact stopped being true. Its open-source engine, Graphiti, does the same for graphs you run yourself. Arroway is a shared memory for a project that every AI tool you already use reads before it acts. Both keep history instead of overwriting it. The difference is who decides that something changed. In Zep, the change is inferred from the data that arrives. In Arroway, a person approves what becomes a rule, every rule carries the condition that ends it, and a replacement names the rule it retires. Use Arroway when the team has to own the decision: a person approves it, and the next agent in any connected tool reads the one still in force. The install page is the first step. ## Arroway vs Settled: which decision is binding for the next agent? https://www.arroway.app/en/answers/arroway-vs-settled Both keep a person in the decision, and both let an agent ask what still holds. Settled is a Slack decision-ledger agent: its repository describes detecting decisions behind a confidence gate plus a human check, tracking each one from proposed through contested and settled to superseded, keeping the verbatim quote and a link back to the message, and exposing an MCP server so an agent can call is_binding before it acts. Arroway is the project memory every connected assistant reads before it acts — Claude, ChatGPT, Codex, Cursor or anything over MCP — and a decision becomes binding only when a person approves it, carries the condition that ends it, and leaves the next read when a later decision replaces it. Use Arroway when that decision has to arrive before the next agent acts, in any connected tool, including one that never saw the message. The install page is the first step. ## Arroway vs Basic Memory Teams: shared knowledge, or a decision in force? https://www.arroway.app/en/answers/arroway-vs-basic-memory Basic Memory Teams is one shared knowledge base for a team and every AI agent connected to it. Its documentation says a decision captured in one person's Claude session becomes context for another's Codex run, agents read a shared knowledge graph and write notes back, every change shows in an activity feed, and every save keeps a file history you can roll back. Arroway is the project memory those same tools read before they act, and a statement becomes a rule only when a person approves it. The difference shows up when an agent's note contradicts a decision a person already made. Basic Memory keeps both in the knowledge base, with a history of the file. Arroway keeps the approved decision in the read and holds the agent's note as a proposal until a person approves a replacement. Use Arroway when the next agent has to treat one statement as the decision in force. The install page is the first step. ## Arroway vs Snipara: context for the next code change, or a decision that also leaves the repository? https://www.arroway.app/en/answers/arroway-vs-snipara Snipara is shared project intelligence for coding agents. Its site says you change the agent and keep the project: reviewed decisions, sources and checks for Claude Code, Codex and Cursor. Its code-context page, last updated 24 September 2026, keeps repository files inside a code-scoped project and says business workflows — RFPs, proposal packs, client dossiers — now live in Helvabase, while Snipara stays on repository context, developer workflows, a hosted MCP server, memory and coding agents. Arroway is the project memory every connected tool reads before it acts, including a chat that never opened the repository. Use Arroway when that same rule also has to bind an agent that never opened the repository. The install page is the first step. ## Arroway vs Letta: what is the difference? https://www.arroway.app/en/answers/arroway-vs-letta Letta is a platform for building stateful agents: an agent you create there keeps its own memory between conversations, and part of that memory is a set of memory blocks that stay in the agent's context window and that the agent itself can read and rewrite with built-in tools. Several agents can attach to the same block, and a block can be marked read-only. It runs on Letta Cloud or on a server you host. Arroway is not a place to build an agent: it is a shared memory for a project that every AI tool you already use — Claude, ChatGPT, Codex, Cursor or anything over MCP — reads before it acts. The difference is where the memory lives and who edits it. In Letta it lives inside the agents you build there, and the agent edits it. In Arroway it lives outside every agent, assistants write proposals, and a person approves what becomes a rule, with the condition that ends it. Use Arroway when the agents and people doing the work are in tools you did not build and must act on the same current decisions. The install page is the first step. ## Who is accountable for what an AI agent does on a team? https://www.arroway.app/en/answers/who-is-accountable-for-an-ai-agent-on-a-team A named person, for each agent, and written down where the agent itself reads it. The question is common because the paper answer and the real one differ: an Ivanti survey of 1,500 IT professionals, reported by VentureBeat in June 2026, found 85% saying every AI agent has a named owner and only 42% saying ownership is actually clear. What works is the way a manager answers for a person's work. One human answers for the agent's results. A short list says what the agent does alone, what it hands over for approval and what it never touches. A record shows what it did. Those lines have to change when the team decides otherwise, and the agent has to read the current version before it acts. Arroway is where that lives: each decision carries who made it and what ends it, each log entry and handoff carries who wrote it, and every connected tool reads what is in force. The install page is the first step. ## How do you write a job description for an AI agent? https://www.arroway.app/en/answers/ai-agent-job-description-before-it-joins-the-team The same way you would for a new hire, on one page, before the agent starts. Harvard Business Review's March 2026 advice on onboarding AI agents says every agent should have a job description that spells out what it is responsible for, where its authority stops and when it must ask for human input. A usable version has seven lines: what the agent exists to do, the person who answers for it, what it does alone, what it hands over for approval, what it never touches, whom it tells when it is stuck, and where its record goes. The sheet only works if the agent reads it before it acts and if it changes when the team decides something else. Arroway is where the sheet can live as a set of rules every AI on the team reads at the start of a session, each with who decided it and when it ends. The install page is the first step. ## How do you onboard a new hire into a team that already works with AI agents? https://www.arroway.app/en/answers/onboarding-a-new-hire-into-a-team-that-works-with-ai-agents Give the new person, on day one, the four things they would otherwise learn by interrupting people: which agents the team uses and who answers for each, what has been decided and is in force today, what is half-done and with whom, and how to ask for a correction when an agent gets something wrong. Harvard Business Review's March 2026 advice treats agents as colleagues who need an onboarding plan of their own; the other side of that is that the human arriving beside them needs one too, and it should not be the full history of the project. The shortest version is a read, not a document: the new person's own assistant opens by reading what is in force on the project and tells them. Arroway is where that lives: decisions with who made them and when they end, handoffs with an owner, and the log of what each agent did, read by every connected tool before it acts. The install page is the first step. ## What are the alternatives to CLAUDE.md for sharing AI context across a team? https://www.arroway.app/en/answers/alternatives-to-claude-md-for-a-team Three of the answers are still files. AGENTS.md is a single file that several coding agents read; Cursor's documentation says it supports it in the project root and subdirectories, GitHub Copilot reads it too, and Claude Code reads it only when the project has no CLAUDE.md. Tool-specific rule files — Cursor's .cursor/rules, Copilot's .github/copilot-instructions.md, Gemini CLI's GEMINI.md — give each tool its own instructions. An import or a symlink makes several of those files one. All three change which file a tool reads, not what the file is: text the model loads every session and an assistant can add to, with nothing saying who approved a line or whether it still stands, out of sight of anyone who does not open the repository. The alternative that changes that is to take what holds out of the file and put it where someone sees it and approves it. Arroway is that place: rules and decisions per project, each with who approved it and when it ends, read before acting by every connected tool. The install page is the first step. ## How do you keep CLAUDE.md, AGENTS.md and GEMINI.md in sync? https://www.arroway.app/en/answers/one-team-three-instruction-files-and-they-drift Not by copying. Copies drift the first time a rule changes in one file and not in the others, and the tool that reads the stale one keeps following the dead rule with no error. Inside one repository the files can be made into one: CLAUDE.md can import AGENTS.md, and Gemini CLI's context.fileName setting can point it at AGENTS.md. That puts the coding agents on one text, and it is still a file: it does not say who decided a line, when it stops being true or whether an assistant added it in a session, and it does not reach the tool that does not read the repository. A rule stays in sync when it lives once, outside every file, where someone sees it and approves it, and every tool reads it from there. Arroway is that place: each rule with who approved it and when it ends, read by every connected assistant before it acts. The install page is the first step. ## Arroway vs LangMem: what is the difference? https://www.arroway.app/en/answers/arroway-vs-langmem LangMem is a library from LangChain that lets an agent built on LangGraph learn from its own conversations. Its documentation describes semantic memory (facts, kept as a searchable collection or as a profile), episodic memory (past interactions kept as examples) and procedural memory, where the agent's own instructions are refined from feedback by a prompt optimizer. The agent decides what to store through memory tools, and the memories sit in a LangGraph store you provide. Arroway is not a library inside an agent: it is a shared memory for a project that every AI tool you already use — Claude, ChatGPT, Codex, Cursor or anything over MCP — reads before it acts. The difference is who decides what is true. In LangMem the agent extracts and rewrites it, including its own instructions. In Arroway assistants write proposals, and a person approves what becomes a rule, with the condition that ends it. Use Arroway when the people and agents doing the work are in tools you did not build and must act on the same current decisions. The install page is the first step. ## How do you share a Claude Project with your team? https://www.arroway.app/en/answers/share-a-claude-project-with-your-team Claude's help center says sharing is available on the Team and Enterprise plans. A project is either public, so everyone in the organization can view and use it, or private, so only the people invited can; invited people get either view or edit access, and the chats inside a project are not shared unless someone shares each one. That solves one thing well: everyone who uses Claude on that plan opens the same instructions and the same project knowledge. It stops where the work does. A colleague who works in ChatGPT, Codex or Cursor does not read the project. A rule that changes is an edit someone has to make in the project, and nothing in it says who decided the line or when it stops being true. The way past that is to put what holds where every tool reads it and a person approves it. Arroway is that place: decisions per project, each with who approved it and when it ends, read before acting by every connected tool, Claude included. The install page is the first step. ## How do you share rules between Cursor and Claude Code? https://www.arroway.app/en/answers/cursor-rules-and-claude-md-in-the-same-team Each tool reads its own file. Cursor's documentation says its rules live in .cursor/rules as .mdc files with frontmatter, in four kinds: always applied, applied when the agent judges them relevant, applied to files matching a pattern, or only when mentioned by hand. It also supports AGENTS.md in the project root and in subdirectories, the more specific one taking precedence, and the page I read does not mention CLAUDE.md. Claude Code reads CLAUDE.md, and reads AGENTS.md only when the project has no CLAUDE.md. So the two share a file only through AGENTS.md, which a CLAUDE.md can import. That puts both tools on one text, and it is still a file: it does not say who decided a line, when it stops being true or whether an assistant added it, and it does not reach anyone who works outside the repository. A rule stays shared when it lives once, where someone sees it and approves it, and every tool reads it from there. Arroway is that place: each rule with who approved it and when it ends, read before acting by every connected tool. The install page is the first step. ## Trust https://www.arroway.app/en/trust Where Arroway keeps your data, how it is encrypted, which providers process it, how long it is kept and how to delete it.