# Rness - One source of truth for every AI coding agent

Agent governance for engineering organizations.

**One organization. Many repositories. Many agents. One source of truth.**

Your organization's standards, decisions, specs and plans, written into every repository's AGENTS.md. Claude Code, Codex, Cursor and GitHub Copilot already read it.

```sh
npm create rness    # or: pnpm create rness, yarn create rness, bun create rness
```

No new agent. No new workflow. No new configuration format.

Your organization on GitHub. GitLab and Bitbucket: not shipped yet.

- [Documentation](https://rness.dev/docs)
- [View on GitHub](https://github.com/rness-dev/rness)

This page is the landing page of rness.dev as Markdown. What it shows that the published command does not do yet is marked "not shipped yet": specified, not built, not in `@rness/cli` today.

## Your AI agents shouldn't each have their own understanding of your organization.

Rness gives your organization one source of truth for agent context, rules, decisions and engineering knowledge.

- **Principle.** Centralized governance. Decentralized development.
- **Adoption.** Keep using the agents you already use. Rness makes them understand your organization.

## 01 - The problem

### AI development is becoming distributed. Organizational knowledge shouldn't be.

```
acme/
├── app1
│   ├── CLAUDE.md
│   ├── AGENTS.md
│   └── .cursor/rules
├── app2
│   ├── CLAUDE.md
│   └── AGENTS.md
└── app3
    └── .github/copilot-instructions.md

3 repositories · 4 formats · 0 shared source of truth
```

- **Fragmented context.** Different agents and repositories contain different pieces of organizational knowledge.
- **Cross-project drift.** Rules and standards get copied between repositories and become inconsistent.
- **Lost decisions.** Architecture decisions, plans and specifications become disconnected from the agents implementing them.
- **No organizational visibility.** Engineering leaders cannot easily see what governance applies to which repository, or how AI-assisted development is evolving across the organization.

## 02 - Introducing Rness

### A governance layer above your agents.

Rness does not replace your agents or redefine their configuration systems. It provides the organizational layer that connects them.

| Layer | Members | Role |
| --- | --- | --- |
| AI models | Claude · GPT · Gemini · … | Provide intelligence |
| AI agents | Claude Code · Codex · Cursor · Copilot · … | Execute development tasks |
| **Agent governance** | **Rness** | Governs the organizational context and policies agents operate in |
| Engineering system | GitHub · GitLab · Bitbucket · CI/CD · Cloud · … | System of record for code and development |

- **Context:** Standards, Architecture, Product
- **Rules:** Security, Testing, Git
- **Decisions:** ADRs, Plans, Specs

Agents execute. Rness governs.

## 03 - Cross-repository governance

### One organization. Every repository.

Define shared context and governance once. Apply it across every repository in the organization. The repositories remain independent. Rness provides the organizational context around them.

```
github.com/acme/
.rness          organization source of truth
app1
app2
sdk
contracts
infrastructure
…

$ rness context --scope app1
$ rness context --scope app2
Same organizational context. Different repository.
```

## 04 - Cross-agent governance

### Define once. Govern every agent.

Claude Code remains Claude Code. Codex remains Codex. Cursor remains Cursor. Rness provides the shared organizational layer around them.

- No new agent
- No new workflow
- No new configuration format

## 05 - Organization-wide context

### Give every agent the context it needs - without duplicating it everywhere.

Organization-level context is inherited by every repository. Each repository adds only what is specific to it.

```
Organization
├── Product context              inherited
├── Engineering principles       inherited
├── Security policies            inherited
├── Architecture principles      inherited
│
├── app1
│   └── repository-specific context   local
├── app2
│   └── repository-specific context   local
└── app3
    └── repository-specific context   local
```

## 06 - Policy enforcement (not shipped yet)

### Turn engineering standards into organizational policy.

Policies carry a scope - organization, repository, directory or file pattern - so the right rule applies at the right level. Native agent configuration files stay where they are. Rness does not ask developers to replace them.

```
Organization
├── Security
│   ├── secrets policy
│   ├── dependency policy
│   └── smart contract policy
├── Engineering
│   ├── testing
│   ├── TypeScript
│   └── Git
└── Architecture
    ├── API standards
    └── data standards

Scope: Organization → Repository → Directory → File / pattern
```

## 07 - Architecture memory

### Your agents should understand not only what to do - but why.

Architecture decisions become organizational memory instead of isolated documents - and reach the agents implementing them.

| Decision | Title | Status | Scope |
| --- | --- | --- | --- |
| adr/0001 | PostgreSQL is the primary database | Accepted | Organization |
| adr/0014 | GraphQL is the public API | Accepted | app1 |
| adr/0021 | Use viem for EVM interaction | Accepted | contracts |

## 08 - Plans and specifications

### Connect what you're building to why you're building it.

Specs, plans and decisions are linked - so an agent implementing a plan knows the spec behind it and the decisions that constrain it. Rness connects the knowledge agents need before and during implementation.

Product → Spec → Plan → Implementation → Agent

- specs/0012: Unified lending API
- plans/0027: Implement Morpho adapter
- adr/0031: Standardize market identifiers

## 09 - Product in action

### Your agent works. Your board keeps up.

A developer writes a specification with Claude Code, approves it and ships it. Agent Pulse - the GitHub Project Rness keeps in step with `.rness` - moves the card as it happens. (A screencast on the page.)

Claude remains Claude. The developer remains in the same workflow. Rness provides the organizational governance around it.

## 10 - Before / after

**Before.** app1 has `CLAUDE.md`, `AGENTS.md` and `.cursor/rules`; app2 has `CLAUDE.md` and `AGENTS.md`; app3 has `.github/copilot-instructions.md`. Context is fragmented across repositories and agents.

**With Rness.** `.rness` feeds Claude, Codex, Cursor and Copilot, which feed app1, app2 and app3. Governance is centralized. Workflows remain decentralized.

### Centralized governance. Decentralized development.

## 11 - A new layer in the stack

### A new layer in the AI development stack.

Coding agents are not what Rness competes with - they are what it governs. The relevant comparison is between the layers that address organization-wide AI governance.

| Layer / capability | Coding agents (Claude Code · Codex · Cursor · Copilot) | Project rules (CLAUDE.md · AGENTS.md · .cursor/rules) | Agent governance (Rness) |
| --- | --- | --- | --- |
| Execute coding tasks | yes | - | - |
| Repository instructions | yes | yes | yes |
| Cross-repository governance | Limited | Limited | Core |
| Cross-agent governance | Limited | Limited | Core |
| Organization-wide context | Limited | Limited | Core |
| Policy enforcement | Limited | Partial | Core (not shipped yet) |
| ADR / architecture memory | Partial | Partial | Core |
| Context inheritance | Partial | Partial | Core |
| Configuration drift | Limited | Partial | Core |

Categories, not vendors. Coding agents execute tasks. Project rules instruct a single repository. Agent governance spans the organization - every repository, every agent.

## 12 - Context inheritance

### The right context, at the right scope.

Organizational knowledge can be inherited and specialized as work moves closer to the code: Organization → Repository → Directory.

- Organization: Rules, Security, Architecture
- Repository (inherits, specializes): app/, api/, contracts/
- Directory (inherits, specializes): contracts/src/

A monorepo works the same way: each package is a scope that inherits the repository's rules.

```sh
rness add platform --scopes apps/web,packages/ui
```

## 13 - Configuration drift

### Know when your repositories drift from organizational policy.

Rness compares each repository against the organization's governance and surfaces what has drifted - before it reaches an agent.

On your machine today: `rness sync --check` finds the repository whose governance drifted, and `rness status` shows where every decision, specification and plan stands. The organization-wide view comes later, with rness Cloud (not shipped yet).

```
rness / acme                      Organization (not shipped yet)
24 Repositories · 4 Agents · 18 Policies

Governance status
app1    ✓ compliant
app2    ✓ compliant
app3    drift detected
app4    ✓ compliant

Drift
app3    security policy
app7    outdated architecture rule
app12   missing testing standard
```

## 14 - Product architecture

### `.rness` - the organization-level source of truth.

`.rness` is not another agent configuration format. It is the organizational knowledge and governance layer that connects to the agent-specific configuration systems you already have.

```
github.com/acme/
.rness/
app1/
app2/
app3/
sdk/
contracts/
…
```

| `.rness/` | |
| --- | --- |
| `standards/` | Rules and standards, by scope |
| `adr/` | Architecture decisions |
| `specs/` | Specifications |
| `plans/` | Plans |
| `skills/` | Reusable agent skills |

## 15 - Developer workflow

### Nothing changes for developers.

1. **Connect.** Connect your GitHub organization. GitLab and Bitbucket come next (not shipped yet).
2. **Govern.** Define organizational context, standards, policies, decisions, specs and plans.
3. **Keep coding.** Developers continue using Claude Code, Codex, Cursor, GitHub Copilot or other agents exactly as before.

Rness works around your workflow, not against it.

## 16 - CLI

### Governance you can run from the terminal.

Inspect, resolve and sync organizational governance without leaving the shell.

| Command | What it does |
| --- | --- |
| `rness create` | Create or join an organization, or start blank |
| `rness add` | Add a repository to the workspace |
| `rness sync` | Sync organizational governance |
| `rness context` | Resolved context |
| `rness status` | Where every decision, spec and plan stands |
| `rness validate` | Check the context and its blocks |
| `rness upgrade` | Move to a new CLI version |
| `rness login` | Reach private repositories |

```
$ rness sync --check
unchanged AGENTS.md
unchanged org/app1/AGENTS.md
unchanged org/app2/AGENTS.md
stale     org/app3/AGENTS.md
1 block(s) out of date - run rness sync

$ rness sync -y
unchanged AGENTS.md
unchanged org/app1/AGENTS.md
unchanged org/app2/AGENTS.md
updated   org/app3/AGENTS.md
```

## 17 - Trust & architecture

### Your repositories remain the source of code. Rness becomes the source of organizational agent knowledge.

- **Your Git provider:** code, history, pull requests
- **rness:** agent context, governance, organizational knowledge, decisions, policies

Rness does not replace your Git provider. It sits beside it - and points your agents at what your organization has decided.

## Give every AI agent the same understanding of your organization.

One source of truth. Every repository. Every agent.

```sh
npm create rness
```

No GitHub organization yet? Choose "Blank local workspace" at the first question.

- [Get started](https://rness.dev/docs)
- [View on GitHub](https://github.com/rness-dev/rness)

Agents execute. Your organization governs.

---

Rness · [Documentation](https://rness.dev/docs) · [GitHub](https://github.com/rness-dev/rness) · [npm](https://www.npmjs.com/package/@rness/cli) · [Security](https://github.com/rness-dev/.github/blob/main/SECURITY.md) · [About](https://rness.dev/about.md) · [Contact](https://rness.dev/contact.md) · [Privacy](https://rness.dev/privacy.md) · Analytics without cookies, by PostHog · [llms.txt](https://rness.dev/llms.txt)