Four steps to your first design audit on a real PR.
The velocity gains are real. So is the governance gap.
Maintainers face agent-written contributions at volume. What keeps a project coherent?
Put your standards and your current architecture into two ledgers your AI assistants can read. Explore designs in rkito, or let Claude, Copilot and Cursor sessions design within your rules from the first prompt. When you're ready, connect GitHub and rkito audits every pull request against the same record.
| Seq | Entry | State |
|---|---|---|
| Steering Ledger | ||
| 0412 | POL-018 · Services own their data stores | approved |
| 0413 | LENS-018.2 · No cross-service table reads | yes / no |
| Architecture Ledger | ||
| 0414 | SYS payments-api · 14 interfaces · PCI | baseline |
| 0415 | API POST /v2/refunds · OpenAPI 3.1 | mapped |
| Design session · shift left | ||
| 0416 | claude · scope payments-api · 3 downstream | in scope |
| Code Ledger · shift right | ||
| 0417 | PR #2291 · CDA · 12 lenses checked | pass |
Agents write code faster than any review process was built to handle. Before you can hand them more autonomy, they need to know how you build and what already exists.
READMEs, ADRs, CLAUDE.md files, wikis and design docs. Every extra source inflates an agent's context and your token bill, and the agent still has to guess which one is current.
API specs sit in one repo, data models in another, dependencies in someone's head. An agent changing one service has no idea which consumers it just broke.
Every AI-generated PR needs a senior engineer to check it by hand. Quality drops as volume rises, and architectural drift compounds with every merge.
You don't need to rewire your delivery pipeline to begin. Start by writing down how you build and mapping what you run. That groundwork is what every agentic engineering program needs, and it pays off in every design session from day one, in rkito and in the IDE.
With Steering and Architecture in place you are 99% of the way to a governed PR gate. The last step is one GitHub App install.
How you build
Agents that know your rules.
What you actually run
Agents that know the blast radius.
Enforcement at the PR gate
Drift caught before it ships.
This is where design intent is written down. Policies, best practices, guidelines and patterns are drafted with AI help so thinking moves fast, and every change still goes through a human-only review before it is approved.
Each artifact resolves into Lenses: small, yes-or-no checks that an agent or an audit can evaluate without interpretation. When a design exploration starts, in rkito or in a Claude, Copilot or Cursor session, it pulls the Lenses that apply and works inside them.
you › Let's explore adding partial refunds to checkout. # The assistant asks rkito what applies before proposing a design rkito.get_skills(entity: "payments-api") POL-018 Services own their data stores BP-API-07 Version breaking changes behind /v{n} PAT-004 Outbox for cross-service events → 4 lenses loaded · 0 conflicts claude › Here are two options that stay within POL-018 and PAT-004. Option B avoids a breaking change to /v2.
Illustrative mocks with sample data. Not actual product screens.
The living, approved record of what exists: every system, component, interface and boundary, with API specs and data models kept alongside them. Point rkito at your repos and it drafts the baseline from your code, Terraform, Helm, Kubernetes manifests and OpenAPI specs. Your architects review it and commit it.
Once systems are in the ledger, you can map steering controls to system categories. A PCI system gets PCI lenses. A public API gets versioning lenses. In a design exploration, in rkito or in the IDE, the session declares which systems it plans to modify and sees what that will affect before anyone writes a line.
Illustrative mock with sample systems. Not an actual product screen.
Explore designs in rkito’s design workspace on rkito.com, or from Claude Code in your IDE (Copilot and Cursor are coming; plugins and extensions live in the marketplace). Either way, rkito brings in the ADRs, policies, patterns and best practices you have already approved, along with the current state of every system you plan to touch. Explore options freely. Each one is checked against what's already been decided, so you converge on a design that fits before any code exists.
Fastest to build. Breaks two approved decisions.
Respects ownership, but changes a response shape three systems depend on.
Add partial_amount to /v2 without breaking it, and publish refund.partial through the outbox for finance-reporting.
Illustrative mock with sample decisions. Not an actual product screen.
Explore bold options. rkito shows which decisions each one respects or breaks, so you weigh trade-offs with facts, not memory.
Findings name the ADR, policy or pattern and the systems affected, so a design discussion starts from what's already been agreed.
The chosen design goes to human review. Once approved, it is the scope the agent implements and the PR gate checks.
Ready to enforce steering and change control at the PR gate? You have already done the hard part. Install the GitHub App and rkito runs a Continuous Design Audit on every pull request, against the same Steering and Architecture Ledgers your design sessions use, in rkito and in the IDE.
Each finding cites the lens it checked and the ledger entry it relates to, so reviewers see the reason behind it. Approved changes pass with a record. Unplanned drift is blocked, and rkito drafts the Change Intention that would make it legitimate.
POL-018, BP-API-07, PAT-004 and PCI-DSS 3.4 checks pass for the declared scope.
New field refunds.partial_amount matches approved intention CHI-0142. Architecture Ledger updated on merge.
finance-reporting reads the refunds table directly. payments-api owns that store; use the export API. Draft CHI-0143 opened for review.
Illustrative mock with a sample pull request. Not an actual product screen.
Most pipelines can only catch design problems after code exists. rkito reads the same ledgers at both ends, so what the agent planned against is exactly what the audit checks.
Conceptual diagram.
Iterate on designs in rkito, or with Claude, Copilot or Cursor in the IDE, against approved ADRs, policies and patterns and the current architecture. Once a design is approved, the session implements it within that scope and checks each write. Violations are prevented while the design is still cheap to change.
The Continuous Design Audit runs between tests and human review. Reviewers see annotated findings with the reason behind each one, and architects stop spending time on conformant PRs.
Steps one to three give your design sessions, in rkito and in the IDE, a real source of design intent. Step four turns on enforcement. There's no onboarding engagement and no bespoke tooling.
AWS Well-Architected, OWASP Top 10, ISO 27001 and more are pre-built. Adopt them in one click, then add your own policies.
rkito reads code, Terraform, Helm, Kubernetes manifests and OpenAPI specs, then drafts your Architecture Ledger.
The scan arrives as a Change Intention. Architects correct what needs correcting and merge it. Start exploring designs in rkito, or connect Claude, Copilot or Cursor over MCP.
One install configures the PR webhook. The next pull request gets a full design audit before it reaches code review.
Already have decisions written down? Import Confluence pages, Word documents, ADR folders and policy PDFs. rkito converts them into Steering artifacts and Lenses, so your architectural history is in the ledger from day one.
Regulated and air-gapped organisations get the same governance model, on their own terms.
A single workflow step. No new infrastructure and no agents to manage.
Fully managed on AWS. Choose your region and your data stays there.
A Docker container that runs air-gapped. No data leaves your network.
Essays, concepts, metrics and guides for each role.
Starter is free for five members and includes Steering, the Architecture Ledger, design reviews, ADRs and GitHub integration. No credit card.
Open source project? Qualifying projects get the full platform free for life. Apply to the OSS program.
