background
What is an AI-native team?
An AI-native team is a team where people and AI agents work from one shared context layer: a repo-owned record of how the team thinks, versioned and changed through review.
The context layer holds the team's domain language, the constraints that must hold, the decisions behind the system, the conventions it follows, and the guardrails its agents run under. People and agents read it on every task, and every change to it passes the same review gate. Leji is the open specification for the context layer.
Beyond prompts and tool adoption
AI tools speed up tasks, but scattered prompts, per-tool instructions, and knowledge held in individual memory do not change how a team operates. An AI-native team instead shares, versions, and governs one context layer.
Intent over instructions
Shared context captures durable intent: what things mean, what must hold, and why. People and agents derive actions from that intent and the task, while meaning and constraints outlive any vendor. The rationale explains why.
A circle, not a tier
Context flows in a circle across human-to-human, human-to-AI, and human-to-AI-to-human work. Everyone with access reads it, anyone can propose changes, and people approve. Version control grants access; restricted context belongs in a permissioned context layer.
Mechanism over goodwill
Shared context decays as reality changes. Review gates, mechanical drift checks, and freshness horizons keep maintenance from depending on discipline alone. The governance rules make these forcing functions mechanical and flag context that has aged.
An AI-native workflow
An engineer and an agent load the context layer for a task, starting from the same language, constraints, and decisions. The agent proposes code and context changes where needed; a person reviews both through the same gate, making context maintenance part of the work.
How Leji makes it checkable
AI-native is easy to claim and hard to verify. Leji makes the context layer checkable: a leji.json manifest declares conformance, and the reference CLI adopts the repo, validates the artifacts against published schemas, and scores conformance.
The four conformance levels (core, indexed, governed, and federated) each name a cumulative set of requirements a context layer either has in place or does not. They are not a maturity score: most teams should reach governed and stop.
The federated level exists for organizations where more than one team already owns a context layer worth keeping whole; siblings stay distinct, independently owned sources that a host mounts by pin.
The CLI checks what a machine can check and reports the rest, which the team attests to, so a claim is grounded rather than merely asserted.
Frequently asked questions
Is being AI-native just using AI coding tools?
No. Using AI tools speeds up individual tasks. Being AI-native changes how the team operates: the operating context is shared, versioned, and governed, so people and agents work from the same source. Tool adoption is a step on the way, not the destination.
Does being AI-native require a specific vendor or tool?
No. The context layer is tool-agnostic. Leji standardizes the shape and the governance, not the contents, and conformance never requires a particular commercial product or service. Vendor entrypoints are redirects into the one context layer.
What is the difference between Leji and the context layer?
Leji is the open specification. The context layer is what a team builds and owns by following it. Leji standardizes the shape and the governance, not the contents.
How does an AI-native team keep the context layer from going stale?
Changes to the context layer pass the same review gate as code, freshness horizons flag context that has aged, and tooling never silently treats stale context as current. An AI-native team updates the context layer as part of doing the work, so staleness surfaces early rather than accumulating unseen.