AI writes the code.
Who governs the design?
AI coding tools have multiplied engineering velocity. They have not multiplied architectural judgment. Every line an agent writes carries your codebase further — and further from any context about where it must not go.
What agentic
engineering is
The developer is no longer writing every line. They are orchestrating. Reviewing. Merging. The agent writes. Sprint velocity has changed. The architectural surface area grows faster than review capacity ever could.
Copilot. Cursor. Claude Code. Cline. Devin. AI tools that write production code are standard-issue in 2026. Not experimental. Deployed.
A senior engineer now reviews 4x more PRs than they write. The generation rate has decoupled from the review rate. That gap is structural.
The developer is an orchestrator. They define the intent, accept the output, and approve the merge. The agent fills the space between.
The architectural surface area grows faster than any review capacity. Every agent-generated PR is a design decision made without design context.
ADRs. Banned patterns. Compliance constraints. None of this is in the agent's context window.
Pillars. Service contracts. Domain ownership. The agent cannot see the lines it is crossing.
Lenses. Active audit prompts. The conformance criteria that should govern every merge decision.
The agent is not the risk.
The missing context is.
How rkito fills the gap
rkito MCP loads Lenses, Pillars, and Architecture Ledger context into the agent before code generation. The agent knows the rules before writing a single line.
The Continuous Design Audit evaluates every PR against active Lenses. PASS or BLOCKED. No manual review required. No architect as the bottleneck.
Every approved structural change is recorded in the Architecture Ledger. Every decision is traceable. Every drift event is auditable.
Continuous Design Audit
CDA is the enforcement layer. Every PR triggers a full design audit — diff fetched, entities mapped, Lenses evaluated. The result is a GitHub check status: PASS or BLOCKED. No architect needed for clean PRs.
CDA does not block every PR. It evaluates every PR and raises a finding only when code deviates from design intent. A conformant PR proceeds with zero ceremony.
When a deviation is detected, the first question is: is there an approved Change Intention for this work? CHI governs whether the direction is approved. Lenses govern whether the implementation is correct. These are separate concerns.
The diff — not the full codebase — is what CDA evaluates. For regulated environments, a customer-side GitHub Action model keeps the diff inside the customer's perimeter entirely.
The rkito Session Protocol
The rkito Session Protocol is the mechanism by which agents precisely implement design intent. It is not a set of guardrails that prevent violations. It is the ordered process by which an agent receives the approved design decision, loads the architectural context for the entities it will modify, and implements exactly what was decided.
Nothing less. Nothing more. This is how the “implement the design” marching order is realized in the agentic era. The CHI is the approved intent. The session protocol delivers it to the agent before the first write.
An approved Change Intention defines what is to be built, in which scope, with what architectural decisions. Phase 4 delivers that CHI to the agent before any code is written. The agent implements exactly that scope — no more, no less. This is the 'implement the design' instruction, machine-delivered.
Phase 5 loads three things in parallel: current Architecture Ledger state for the target entities, all applicable Lenses, and Steering context. The agent's working context is bounded by the same record CDA will evaluate. What the agent implements is what will be assessed — no gap, no surprise.
At each write in Phase 6, validate_diff() evaluates the current diff against the loaded Lenses. BLOCKER findings halt generation and the agent corrects before continuing. The implementation stays aligned with the approved design as it is being written — not after.
OAuth PKCE for IDE agents. Service account API key for autonomous agents.
register_sessionget_skills() returns a conformance bundle: entity binding, applicable Lenses, Steering refs, CHI requirements.
get_skillsIf the target entity is not in the Architecture Ledger, the agent drafts a CHI for entity introduction and waits for architect approval.
draft_chiNo code before an approved Change Intention exists. The agent waits in 'CHI pending' state. This is the IFR-driving phase.
get_approved_chiThree parallel MCP calls: Architecture Ledger state, all applicable Lenses, Steering context. Full governed context loaded.
get_ledger_state · get_applicable_lenses · get_steering_contextAgent generates within CHI scope. validate_diff() called at each write. BLOCKER findings halt generation immediately — agent self-corrects.
validate_diffPR opened → CDA runs automatically → GitHub check result. Session record immutably closed in Agent Shepherd.
automatic on PR openAuto-injected at session start. Zero developer friction. Requires IDE host support.
One-time snippet committed to repo. Works with all MCP-compatible IDE agents.
Claude Code PreToolUse hook. rkito-mcp-check fires before first tool use.
RKITO_API_KEY + system prompt injection. Works with any agent accepting a system prompt.
The Skills Registry
A Skill is a governed, versioned instruction payload bound to one or more entities in the Architecture Ledger. It tells an agent precisely how to interact with a specific system, component, interface, or behavioural contract — without the agent needing to infer that context from the codebase.
Skills are not documentation. They are operational instruction sets subject to CHI-gated versioning, carrying Provenance, and bundled with the Lens criteria applicable to the entities they describe.
Lenses are binary conformance rules — pass/fail evaluation criteria. Skills are interaction instructions — how to work with an entity. An entity in the Architecture Ledger may have both. A Lens tells the CDA what to check. A Skill tells the agent how to act.
When an agent retrieves a Skill via get_skills(), it receives the instructions plus the complete Lens set applicable to the bound entities. The agent's instruction space is bounded by the same criteria CDA will evaluate. It cannot be instructed to violate a Lens — the Lens criteria are co-delivered with the instructions.
An org authors Skills for their own systems and components. They can also publish Skills to the rkito network — making their interaction patterns available for other orgs to adopt, pin, and fork. Provenance is preserved through adoption and fork chains.
skill::auth-service::oauth-flowv2 · CHI-0089Authored and consumed within one organisation
Discoverable by other orgs in the rkito network
Locally owned derivative — Provenance link preserved
rkito is the shared memory
in parallel agent flows
When multiple agents work concurrently on the same codebase — one modifying Service A, another modifying Service B which depends on Service A — each agent has its own context window. But the architectural state is shared and authoritative: the Architecture Ledger.
No agent can approve a structural change that another agent has already claimed scope over. No two agents can produce conflicting approved changes to the same entity simultaneously. The CHI system enforces this automatically.
Each agent session operates within a CHI scope. An approved CHI claims specific entities and a specific structural change. If a second agent targets the same entities, the protocol surfaces the conflict — the architect sees both CHIs and adjudicates before either agent proceeds.
Agent Shepherd shows every active agent session, what Ledger entities each is modifying, which Skills were loaded, and the status of each session's CHI gate. For an engineering organisation running parallel agentic flows, this is the real-time architectural risk surface — not theoretical, observable.
Multi-Agent CHI Collision Rate is the metric for this. A non-zero MACCR means concurrent agent sessions had overlapping CHI scope — a signal that agents are not coordinating through the shared Ledger as intended. Structurally zero is the target.
Agent A and Agent B each have their own context window. The Architecture Ledger has one state. When Agent B loads context for Notification Service, it sees that Payment Service has an active CHI scope. The governed context includes that dependency — the agent cannot inadvertently collide.
The governed
agentic engineering
loop
Not a diagram. Not a gate that blocks blindly. An infrastructure that governs every step — from intent to merge to record.
An infrastructure that governs.
The metrics that measure it
Four signals that make agentic governance visible. None exist in any other platform.
The proportion of merged agent-generated PRs that introduced confirmed architectural drift. The headline agentic risk metric.
How frequently agents are loading design context from the rkito MCP server before writing code. The prevention signal.
Compares the CDA pass rate for agent-generated PRs against human-authored ones. The comparative signal.
The rate at which agent-generated PRs merge without a CDA evaluation. The zero-tolerance metric.
What this means
for your team
Agentic velocity is a competitive advantage — but only if it does not accumulate governance debt. rkito gives you the infrastructure to move fast and maintain design integrity simultaneously. Adoption without anxiety.
You author the Lenses once. Every PR is evaluated against them — automatically, continuously. You are not the bottleneck. You are the author of the rules that govern at scale. Review the exceptions. Not every PR.
rkito MCP loads your architecture context before the session starts. You do not discover a constraint violation at PR review. You and your agent both know the boundaries before the first line is written.
Govern your agentic
engineering practice.
Connect your repos, activate Lenses, and let rkito's MCP server load your design context into every agent session. Every PR governed. Every drift event caught. Every architectural decision traceable.
What agentic engineering silently produces at scale — and why existing tools cannot detect it.
The CDA pipeline that evaluates every PR against active Lenses. The gate in the governed loop.
How security governance must evolve when agents are generating your production code.
The three-layer system — Rails, Change Control, Conformance — that rkito implements.