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.
npm create rnessNo new agent. No new workflow. No new configuration format.
- Claude Code
- Codex
- Cursor
or any agent that reads AGENTS.md
- app1
- app2
- app3
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.
Centralized governance. Decentralized development.
Keep using the agents you already use. Rness makes them understand your organization.
AI development is becoming distributed. Organizational knowledge shouldn't be.
Different agents and repositories contain different pieces of organizational knowledge.
Rules and standards get copied between repositories and become inconsistent.
Architecture decisions, plans and specifications become disconnected from the agents implementing them.
Engineering leaders cannot easily see what governance applies to which repository, or how AI-assisted development is evolving across the organization.
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.
Agents execute. Rness governs.
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.
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
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.
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.
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.
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.
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.
- In app1, a developer starts Claude Code; rness reports the scope and its standards and decisions.
- They run /rness:spec. Claude reads the security standard and an ADR, writes specification 0012 as Draft, and its card appears on Agent Pulse, marked working.
- They run /rness:plan from 0012: that approves it, the card moves to Approved, and Claude writes the plan and builds it; tests pass. /rness:plan check 0034 checks every task and the card moves to Implemented.
- The session ends: the working mark is cleared and the session stays in the card's history.
Claude remains Claude. The developer remains in the same workflow. Rness provides the organizational governance around it.
Context is fragmented across repositories and agents.
Governance is centralized. Workflows remain decentralized.
Centralized governance. Decentralized development.
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 | ✓ | - | - |
| Repository instructions | ✓ | ✓ | ✓ |
| Cross-repository governance | Limited | Limited | Core |
| Cross-agent governance | Limited | Limited | Core |
| Organization-wide context | Limited | Limited | Core |
| Policy enforcement | Limited | Partial | Corenot 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.
The right context, at the right scope.
Organizational knowledge can be inherited and specialized as work moves closer to the code.
A monorepo works the same way: each package is a scope that inherits the repository's rules. rness add platform --scopes apps/web,packages/ui
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.
.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.
Nothing changes for developers.
Connect your GitHub organization. GitLab and Bitbucket come next not shipped yet
Define organizational context, standards, policies, decisions, specs and plans.
Developers continue using Claude Code, Codex, Cursor, GitHub Copilot or other agents exactly as before.
Rness works around your workflow, not against it.
Governance you can run from the terminal.
Inspect, resolve and sync organizational governance without leaving the shell.
Your repositories remain the source of code. Rness becomes the source of organizational agent knowledge.
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.
npm create rnessNo GitHub organization yet? Choose “Blank local workspace” at the first question.
Agents execute. Your organization governs.