What is an AI-native team?
An AI-native team is a team where people and AI agents work from one shared context layer: one versioned, repo-owned, governed record of how the team thinks.
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 both read it on every task, and every change to it passes the same review gate. Leji is the open specification for the context layer; the context layer itself is what a team builds with it.
Beyond prompts and tool adoption
Adopting AI coding tools is not the same as being AI-native. Most teams start by writing per-tool instruction files and ad hoc prompts: a rules file for one assistant, a different one for the next, conventions that live in one engineer's head. That makes individual tasks faster without changing how the team operates. An AI-native team moves the operating context out of scattered files and individual memory into one context layer that people and agents share, version, and govern together.
Intent over instructions
An AI-native context captures durable intent, what things mean, what must hold, and why, rather than imperative instructions re-encoded for each tool. Intent outlives any one vendor: when the tools change, the meaning and the constraints stay. People and agents derive the right action from declared intent plus the task in front of them. The rationale explains why durable intent outlasts per-tool instructions.
A circle, not a tier
Context flows in a circle, not down a tier. Human-to-human, human-to-AI, and human-to-AI-to-human are all first-class flows around one context layer. Everyone with access reads all of it, anyone can propose a change, and people approve. Access is the version control system's to grant; restricted context lives in its own permissioned context layer.
An AI-native workflow
An engineer and an agent pick up a task and both load the context layer at the start, so both begin from the same domain language, constraints, and recent decisions. The agent proposes a change to the code and, where the work reveals new intent, a change to the context layer. A person reviews both through the same gate. The context layer stays current because updating it is part of the work, not a separate chore.
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, the reference CLI validates the artifacts against published
schemas, and four conformance levels (core, indexed, governed, and federated) describe
how far a context layer has matured. A team can show where it stands rather than assert it.
Frequently Asked Questions (FAQs)
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 governance of the context layer, not its contents, and conformance never requires a particular commercial product. 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; the contents are the team's own.
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, and freshness horizons flag context that has aged. Updating the context layer is part of doing the work, so it stays current rather than drifting.