Your team has spent years making decisions the AI has never been told about. Architecture rules. Team conventions. Lessons learned the hard way.
Tenure puts that knowledge in the room before the first message is sent.
Everyone focuses on the new hire. But there's a second person paying the cost: the senior engineer who got pulled out of a focused work block to answer questions that already have answers somewhere. That context exists. It just isn't accessible to the AI, so it gets re-explained by a human instead.
Not all knowledge belongs to everyone. Tenure's visibility model lets you be precise about what travels with the org, what stays within a team, and what is personal to an engineer.
The non-negotiables. Architecture decisions, security constraints, naming conventions, compliance rules, and anything else that applies to every engineer on every project. Set once by a principal or lead. Surfaces automatically for everyone.
How your squad actually works. Sprint rituals, patterns your team has adopted, known quirks in the codebase, decisions made in the last planning session. Visible to team members. Doesn't bleed into other squads.
Personal to each engineer. Domain expertise, preferred patterns, context about work in progress, and how they like the AI to respond. Travels with them across sessions and clients. Not visible to their team or org.
Beliefs at every layer are resolved at query time. When an engineer asks a question, the relevant org, team, and user beliefs all surface together, in the right priority order, without manual context-pasting.
An engineer opens VSCode. Tenure is already connected as their OpenAI-compatible provider. Before the first token is generated, the agent has the org standards, the team conventions, and that engineer's personal context in scope. What comes out looks like it was written by someone who has been on the team for months.
The generated code already follows your patterns. The reviewer isn't correcting style or re-explaining architecture. They're reviewing logic, which is the point.
The new engineer doesn't need a full architectural tour before they can be useful. The AI already has the tour. They can start contributing while they're still getting oriented.
The questions that get asked are the hard ones. Not "where does auth live" or "do we use tabs or spaces." That knowledge is already in the room.
Decisions get captured as beliefs when they're made, not documented six months later or not at all. The AI enforces them automatically until someone deliberately changes them.
You don't sit down and write a belief library from scratch. Beliefs accumulate from actual work. An engineer explains something to the AI, Tenure captures it. A lead adds an org-level rule in the dashboard. A team decision from today's planning session gets committed before the meeting ends.
The starting point for most teams is a short session where a principal or tech lead walks through the things they're tired of explaining. That usually takes an hour. It pays back immediately.
Deployment guide →Tenure doesn't replace your wiki, your ADRs, or your onboarding runbook. Those are reference artifacts people read deliberately. Beliefs are context the AI uses without being asked. The job is different.
A wiki page describing your auth architecture is something a new hire reads once. A belief that says "the session token is a signed JWT, validated by the gateway before the request reaches any service" is something the AI knows every time it touches anything near authentication. One is a document. The other is working memory.
Both are useful. They're not the same thing.
Deploy the Helm chart in your dev environment. Connect it to VSCode or any OpenAI-compatible client. Spend an hour capturing what your senior engineers are tired of explaining. The rest happens on its own.
MIT licensed · No call-home telemetry · Works with VSCode, Cursor, OpenWebUI, and any OpenAI-compatible client