Agent governance for GitHub organizations
One organization. Many repositories. Many agents. One source of truth.
Rness is the governance layer for AI-native engineering teams — connecting organizational context, rules, decisions and engineering knowledge to the agents your teams already use.
npm create rness
No new agent. No new workflow. No new configuration format.
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.
See Rness in action
A developer opens a repository and starts their agent — exactly as they do today.
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 | Core |
| ADR / architecture memory | Partial | Partial | Core |
| Decision traceability | Limited | — | Core |
| Context inheritance | Partial | Partial | Core |
| Configuration drift | Limited | Partial | Core |
| Agent auditability | Limited | — | 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.
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.
Know why an agent made a change.
Every change can be traced back through the rule, decision, specification and plan that shaped it. Organizational traceability — not surveillance of individual developers.
.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.
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 GitHub. 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 rness
Agents execute. Your organization governs.