10x faster code generation0 architecture context in agents100% of PRs still need design conformance
Definition
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 Shift
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.
The tools
Copilot. Cursor. Claude Code. Cline. Devin. AI tools that write production code are standard-issue in 2026. Not experimental. Deployed.
The velocity shift
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 role change
The developer is an orchestrator. They define the intent, accept the output, and approve the merge. The agent fills the space between.
The problem
The architectural surface area grows faster than any review capacity. Every agent-generated PR is a design decision made without design context.
The governance gap
The Governance Gap
✕
What the system must NOT do
ADRs. Banned patterns. Compliance constraints. None of this is in the agent's context window.
This is not a training problem. This is a context problem.
✕
Where the architectural boundaries are
Pillars. Service contracts. Domain ownership. The agent cannot see the lines it is crossing.
This is not a training problem. This is a context problem.
✕
Whether this PR violates a design rule
Lenses. Active audit prompts. The conformance criteria that should govern every merge decision.
This is not a training problem. This is a context problem.
The agent is not the risk. The missing context is.
How rkito fills the gap
The Infrastructure · rkito governs
Before the agent writesAMCP Server
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.
It is not a prompt. It is a context layer.
When the PR opensBCDA Pipeline
The Continuous Design Audit evaluates every PR against active Lenses. PASS or BLOCKED. No manual review required. No architect as the bottleneck.
Automated conformance at CI speed.
After it shipsCArchitecture Ledger
Every approved structural change is recorded in the Architecture Ledger. Every decision is traceable. Every drift event is auditable.
Not a snapshot. A living record.
Continuous Design Audit
Shift Right · CDA enforces at PR time — after code is written
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.
Deviation is the only triggerCDA 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.
The CHI gate is primaryWhen 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.
Code privacy by designThe 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.
Entity Mappingchanged files mapped to Architecture Ledger entities
auto
04
CHI Gateis there an approved Change Intention for this scope?
gate
05
Lens Evaluationevery applicable Lens evaluated against the diff
gate
06
PASS or BLOCKEDresult posted as GitHub check — binding, non-optional
binding
< 5 minper PR, automated
0architect time on clean PRs
100%violations caught before merge
The rkito Session Protocol
Shift Left · MCP context loads before the agent writes
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.
The CHI is the marching orderAn 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.
Context loads precisely for the entities being modifiedPhase 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.
validate_diff keeps implementation aligned during generationAt 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.
AuthenticationOAuth PKCE for IDE agents. Service account API key for autonomous agents.register_session
gate
02
Skill Discoveryget_skills() returns a conformance bundle: entity binding, applicable Lenses, Steering refs, CHI requirements.get_skills
03
Precondition ResolutionIf the target entity is not in the Architecture Ledger, the agent drafts a CHI for entity introduction and waits for architect approval.draft_chi
if needed
04
CHI GateNo code before an approved Change Intention exists. The agent waits in 'CHI pending' state. This is the IFR-driving phase.get_approved_chi
Governed Code GenerationAgent generates within CHI scope. validate_diff() called at each write. BLOCKER findings halt generation immediately — agent self-corrects.validate_diff
07
CDA Evaluation + Session ClosePR opened → CDA runs automatically → GitHub check result. Session record immutably closed in Agent Shepherd.automatic on PR open
Protocol invariants — non-negotiable
✓
No code before an approved CHI
✓
BLOCKER findings must resolve before PR is opened
✓
CDA is binding — not advisory
How agents discover the protocol
A1PreferredMCP Prompts
Auto-injected at session start. Zero developer friction. Requires IDE host support.
A2UniversalCLAUDE.md / AGENTS.md
One-time snippet committed to repo. Works with all MCP-compatible IDE agents.
A4Hardest enforcementSession Hook
Claude Code PreToolUse hook. rkito-mcp-check fires before first tool use.
B1Autonomous agentsOrchestrator env vars
RKITO_API_KEY + system prompt injection. Works with any agent accepting a system prompt.
The Skills Registry
Skills Registry · A separate feature. Not Lenses. Not the session protocol.
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 and Skills are different thingsLenses 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.
Skills carry conformance bundlesWhen 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.
Skills are org-private or published to the networkAn 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.
What an agent receives when it calls get_skills()
skill::auth-service::oauth-flowv2 · CHI-0089
Instructions
How to interact with Auth Service — permitted OAuth patterns, interface contracts, what is prohibited
Lens bundle
Lens[A12] Service Authentication Posture · Lens[A15] External Service Data Access — co-delivered, non-suppressible
Steering refs
Pillar: Security · Policy: API Gateway Routing · ADR-0041: Auth Service Isolation
Bound entity
Auth Service @ Ledger state v7 · approved via CHI-0089 by J. Smith
Org-privateOrg-private
Authored and consumed within one organisation
PublishedPublished
Discoverable by other orgs in the rkito network
ForkedForked
Locally owned derivative — Provenance link preserved
rkito is the shared memory in parallel agent flows
Multi-Agent · rkito as shared memory across 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.
CHI scope prevents collisionsEach 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 is the live operational viewAgent 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.
MACCR measures coordination healthMulti-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 BNotification ServiceCHI-0113Phase 4 — awaiting CHI
both read from the same Ledger
Architecture Ledger — shared statePayment Service @ v7 — CHI-0112 scope: settlement interface refactorNotification Service @ v4 — CHI-0113 scope: event subscription modelAPI Gateway @ v12 — no active CHI scope
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.
INTENTManifesto · Pillars · Lenses
↓
AGENT GENERATESWith rkito MCP context loaded
↓
[ CDA GATE ]Design intent enforced at PR time
↓
GOVERNED MERGEConformant · Auditable · Traceable
↓
INTENT UPDATEDArchitecture Ledger records the change
What this means for your team
⊞ Engineering LeadersYou can scale AI tool adoption without scaling architectural risk.
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.
⌬ ArchitectsYour design intent is enforced even when you are not in the loop.
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.
▸ DevelopersYou know what you cannot do before you write the code. The agent knows too.
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.
The metrics that measure it
Four signals that make agentic governance visible. None exist in any other platform.
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.
