Shared Context & Standards

Two developers, two chats, one codebase. Without shared rules an AI produces two different architectures in the same repository. XAIO applies standards on two levels, and both reach the agent on every turn — not once at setup.

Organisation rules

On the Platform Builder plan an organisation defines one set of rules that applies to all of its projects: architecture principles, naming conventions, required technologies, coding standards, and patterns that are not allowed.

The rules live on the organisation, not in the project's files. They are read from the server at the start of every chat turn and placed in the agent's instructions under a heading that marks them authoritative for the organisation. A project cannot quietly opt out of them, and no one can override them by editing a file in the repository.

Allowed models. An organisation can also restrict which AI models its projects may use. If a project is pinned to a model outside that list, the model is not used — the turn runs on the default model instead and the attempt is logged.

Project rules — AGENTS.md

Each project can add its own instructions in AGENTS.md, a normal file at the root of the project's sources.

Because the file is tracked in Git, a change to the rules is a change to the repository. It shows up in diffs, goes through the same review as any other change, and is versioned with the release it belongs to. Months later the history still shows which rules were in force when a feature was built.

Use the organisation level for what must never differ between projects, and AGENTS.md for what is specific to one product — its domain language, the external systems it talks to, the conventions its own team agreed on.

Shared project context

Chat history belongs to the project, not to the person who typed it. It is stored with the project's files, so the reasoning behind a decision does not disappear into a private session when someone is on holiday or leaves the team.

One architecture, by default

Every web app XAIO generates has the same shape: a React frontend, a Python/FastAPI backend and its own PostgreSQL database. The generator also works to fixed correctness rules — money as Decimal and never a float, timestamps as TIMESTAMPTZ in UTC, foreign keys with explicit delete behaviour, unique and check constraints, soft deletes, and a versioned migration for every schema change.

The practical effect for a team: two developers who never spoke to each other produce code that reads as if it came from the same person.