Every engineering org racing to scale AI agents is about to hit the same wall: agents don’t know what they don’t know about your architecture. They generate code that compiles, passes lint, passes tests — and still quietly violates a boundary someone drew three sprints ago. Nobody catches it until it’s in production.
The fix isn’t a smarter agent. It’s a missing primitive: Change Intention (CHI).
What is a Change Intention?
A CHI is the single controlled path through which your Architecture Ledger is allowed to change. A developer — or an agent — declares what they intend to do. rkito captures that declaration as a CHI and proposes exactly how the Ledger (the living record of your systems, components, interfaces, and boundaries) should update as a result.
Every CHI then goes through Design Review — a human-only gate, structurally similar to a pull request, but evaluated against architectural intent rather than code correctness. Once approved, it merges into what rkito calls the “main branch of design.” No architectural change enters your system without first passing through this gate.
This is the detail most teams miss: intent has to be captured before code exists, not reverse-engineered from a diff after the fact.
The formal definition
rkito names this precisely: a Change Intention is a formal state transition of system design.
The current, approved state of every system, component, interface, and boundary.
The set of atomic, binary evaluation predicates that define what a valid Ledger state looks like.
A proposed transition, declared by an actor (human or agent). CHI is a candidate, not a mutation — L does not change on declaration alone.
The human-only function with sole authority to authorize a state transition.
The new Ledger baseline, realized only on human approval — never before it.
Checks a code diff d against the approved transition and the current baseline L′.
Every state the Ledger has ever held is traceable to exactly one authorized, human-reviewed transition. The architecture's entire evolution is a chain of authorized state transitions — never a silent mutation.
What this actually feels like for a developer
Here’s the part that matters: none of the formalism above changes how a developer works day to day. It maps almost exactly onto the Git branching workflow every engineer already knows — just with a design-intent gate layered in.
Ledger @ L
(current approved architecture)
│
│ branch out
▼
┌────────────────────────────────────────────┐
│ CHI drafted │
│ declare intent + diff (δ = L′ − L) │
└────────────────────────────────────────────┘
│
▼
┌────────────────────────────────────────────┐ human-only
│ Design Review │
│ (human-only gate) │
└────────────────────────────────────────────┘
│
├─ revisions requested
│ └─ CHI revised → back to Design Review (loop)
│
└─ approved
│
▼
┌────────────────────────────────────────────┐
│ CHI merged — Ledger updated to L′ │
│ ("main branch of design") │
└────────────────────────────────────────────┘
│
▼
┌────────────────────────────────────────────┐ fully automated
│ Continuous Design Audit │
│ (automatic, every PR — no human trigger) │
└────────────────────────────────────────────┘
│
├─ conformant
│ └─ ✓ Pass → merges normally, no human touches it
│
└─ violates L′
│
▼
✕ Block the PR
+ auto-draft a new CHI describing the deviation
│
▼
Human reviews ONLY the deviation
(routes back into Design Review, above)The workflow is the same shape as a normal branch → PR → review → merge cycle — but it’s important not to conflate the two things happening in it, because they’re evaluated differently and by different actors.
The CHI → Design Review loop is not a conformance check in the CDA sense. There’s no existing Ledger baseline to check a CHI against, because a CHI is the proposal to change that baseline. But rkito isn’t a passive form during this loop — as the repository of institutional design knowledge, it’s AI-assisted throughout: surfacing where the proposal diverges from existing Steering artifacts, where it converges with established precedent, and which specific Lenses the proposal now puts in tension. The AI does the work of finding the divergence and framing the trade-off; the architect still makes the call.
Design Review resolves that judgment call: should this proposed change become part of the approved design corpus at all? Review comments and revisions happen exactly like they do in a GitHub PR — a human can push back, the CHI gets revised, and it goes back through Design Review until it’s approved. A human decides every time the design corpus itself is allowed to evolve.
And it isn’t only the Architecture Ledger that evolves this way. Steering artifacts themselves — the Concepts, Policies, Best Practices, and Patterns that make up the Steering Ledger — change through the exact same branch-out, propose, human-only Design Review, merge cycle as the system Ledger does. Nothing enters either ledger without passing through a human-approved CHI.
Once approved, L′ becomes the new baseline. From that point on, Continuous Design Audit is a completely separate, fully automatic process that runs against ordinary code PRs — not against CHIs. No human triggers it, no human has to remember to run it — it checks every PR the moment it’s opened.
That’s the scaling mechanism: human review effort scales with the number of design deviations — not with the number of pull requests. A team can ship hundreds of AI-generated PRs a week and an architect’s attention is only ever spent on the ones that actually deviated from approved intent.
How rkito unifies three things that are usually three separate tools
Most orgs today are stitching together docs/wikis for design intent, a change-management process bolted onto GitHub, and a code-quality tool that checks syntax, not intent. rkito collapses this into one continuous system:
Where design intent is authored, as Concepts, Policies, Best Practices, and Patterns, resolving into Lenses: atomic, binary evaluation units.
The current, approved state of every system, component, and interface. Not aspirational documentation. The verified baseline every future change is measured against.
The only path by which either Ledger evolves, gated by human Design Review.
Triggered on every pull request, returning Pass, Record, or Block before merge, in minutes, without an architect in the loop for every PR.
The Steering Ledger defines the rules. The Architecture Ledger defines reality. CHI is how either is allowed to change. CDA is the gate that enforces all three, automatically, on every single PR.
Why rkito’s solution beats what’s out there
Widen the lens past code-quality tools and the landscape splits into distinct categories — each solving a real, adjacent problem, and each missing the same thing:
Confluence, Notion, Document360. Manually written, passively maintained, zero connection to the PR pipeline.
Structurizr, Backstage, Swimm. Describe the system after the fact; don't gate what merges into it.
Tools like Bito AI Architect. Feed context into agents at generation time; nothing checks the output afterward.
CodeRabbit and peers. General-purpose code review against the diff, not design-intent conformance against an approved baseline.
Mintlify, ReadMe, GitBook, Documentation.AI, Redocly, Stoplight, Fern, Bump.sh. Optimized for making documentation easy to read; none stop an agent from writing code that breaks the architecture underneath it.
StackHawk, Salt Security, Levo.ai. Reactive by design — surface what already shipped, not what's about to.
Catio, LeanIX, Ardoq. Strategic and decision-grade, positioned above the Git workflow, not inside the PR loop.
SonarQube, ArchUnit, OPA. Catch syntax and structural violations — a different class of error than design-intent violations.
None of them answer the question agentic engineering has made urgent: does this specific change, about to merge, conform to the architecture already approved? That’s the gate none of the adjacent categories own — and it’s the one rkito was built for.
Why you should start with the Ledger now
An agent-capable system ledger is step one for any org trying to adopt or scale agentic engineering safely. Without it, you have no baseline to audit against and no way to detect drift.
But the Ledger alone doesn’t save you — a Ledger that exists but nobody actually reviews is just data sitting there. This is why Design Review is restricted to humans, and not agents. Authority to commit a change to the Ledger is scoped entirely to the Design Review function R, and R is defined as human-only. An agent can act as the actor in a CHI — it can declare intent and generate the proposed diff δ — but it cannot execute R. Only a human can move a CHI to approved.
This restriction is independent of how capable the agent is at generating code. The question being managed is not code quality; it is whether a change to the design corpus was properly authorized. Authorization to change what the organization has approved as its architecture is reserved for a human, in every case, by design.
What’s actually happening right now
Agent task-completion time horizons on real software engineering work have been doubling roughly every eight months — agents are shipping more, faster, with less human review per unit of output.
Governance maturity hasn't kept pace: most enterprises deploying agentic AI have not redesigned roles or oversight models around it.
Multiple agents now modify interdependent parts of the same codebase concurrently, with no shared visibility into what the others are doing.
Human oversight requirements under emerging regulation get harder to demonstrate when the "author" of a change is an agent acting on a prompt, not a person.
Architectural drift compounds silently because testing, linting, and code review were built to catch behavior and syntax errors — not the class of error only visible at the architectural level.
rkito onboards your org onto a complete, evolving Architecture Ledger and Steering Ledger from day one — pulling from your existing repos, Terraform, Helm, Kubernetes manifests, and OpenAPI specs, and soon directly from your Confluence pages, Word docs, and ADR folders. You start with a verified baseline, not a blank page, and you’re auditing real PRs against it the same day.