Everything Stele does, in plain language.
Stele is a shared memory for the projects you build with AI agents. Tasks, decisions, lessons, and risks live in one record an agent walks before it answers. Below: how to set it up, how context works, and the moments it earns its place.
Overview
Stele is one of three things sharing a single ledger: a task system, a knowledge graph of decisions, lessons, risks, and goals, and an operator that drives agentic work through those tasks. The point is that all three share one record — so each part makes the others sharper.
It plugs into the agents you already use — Claude Code, Cursor, Codex, Antigravity, GitHub Copilot, OpenCode, and any MCP-compatible client. It doesn't replace your setup; it adds a memory underneath it. Today it runs as a plugin (MCP server + hooks + commands) against a hosted backend. The web app lets humans read the record; the stele CLI handles auth, admin, and a local web server.
Status: v1 in beta. Free during beta. Sign in with GitHub.
Install & sign in
One line installs the stele CLI — a single binary that wires into your shell. Then sign in with GitHub or Google; there's no account to create and nothing to configure.
Quickstart
Inside the agent you already use, run the start command once. Stele wires itself into the project, maps the codebase and any docs it finds, and builds the first record. After that, you don't run anything special — just keep prompting.
The command surface differs per host — /stele:* slash commands for Claude Code and Cursor, skills for Codex, Antigravity, and Copilot, an in-process plugin for OpenCode — but the behavior is the same everywhere.
How context works
When you prompt the agent, Stele's hook quietly walks the graph first — pulling in the decisions, lessons, and risks that bear on your question before the agent answers. Reachable risk nodes ride along on the trail, so a past incident is named before a change repeats it.
The agent uses what it finds three ways: to explain (cite the decision that settled something), to push back (decline a change that contradicts what the project learned), or to act on knowledge the team already had. Everything carries a stable, shareable ID — DOC-208, TASK-211, KNOW-118 — so provenance is always one hop away.
What it does
The reasoning behind your code, kept with it.
Risks surface before you reintroduce them
When an agent loads context for a change, reachable risk nodes ride along on the trail — “⚠ KNOW-N via caused-by” — so a past incident is named before the change repeats it.
Pushes back on bad changes
When a request contradicts what the project already learned, an agent can decline and cite the prior decision instead of quietly redoing the work. The graph is a check, not just a log.
Provenance you can follow
Walk the trail from a design doc to the task, the issue that surfaced, the decision that resolved it — back to the person who made the call.
Kept honest
A graph that confidently serves wrong facts is worse than no memory at all. So Stele keeps itself honest: stale entries are flagged, ephemeral notes expire, resolved risks retire, duplicates surface, and reversed decisions stop being served as truth — without you gardening it by hand. stele doctor audits the graph as it grows, surfacing near-duplicates for dedupe and catching broken edges.
Examples
A handful of moments that happen in every project with more than one contributor — human or agent. Stele is what makes each one go differently. (Examples are illustrative.)
Onboard a contributor
Their agent starts with the roadmap, the decisions in force, and the open work — before it touches a line of code.
“Where should I start on the billing refactor?”
TASK-204 is open and unclaimed. The approach was settled in KNOW-118 — per-account ledgers, not per-invoice. Read KNOW-95 first: the last refactor double-charged on retries.
Keep a ruled-out idea ruled out
When someone proposes a path the project already rejected, the agent cites the decision instead of reopening it.
“Let's add a second config format alongside JSON.”
Decided against in KNOW-72 — two formats doubled the parser surface and the support load. It can be revisited, but those tradeoffs still apply.
Catch a returning bug
A change that looks harmless can reintroduce a problem the project already paid for. The linked risk surfaces while the work is happening.
“This lock looks unnecessary — removing it.”
The lock came from TASK-91 during the auth rework. Removing it reintroduces KNOW-118, a race condition that reached production once. Confirm the condition is handled first.
Pick a project back up
Come back to a half-forgotten repo and ask what state it's in — what was in flight, what's blocked, and why.
“What was I in the middle of?”
TASK-203 is still open — hosted sync auth. KNOW-187 records why the active-project state was dropped, and TASK-211 is blocked until the slug refactor lands.
Coordinate several agents
Tasks are claimed before work starts, and what each agent learns is written back for the next.
“Start on the export feature.”
TASK-302 is already claimed by another session. TASK-305 — the import side — is open and unblocked. Related risk: KNOW-141 on large-file timeouts.
Answer “why is this here?”
Trace a decision back through the task, the doc, and the risk that produced it — an answer that cites the record.
“Why does the API paginate by cursor, not page number?”
KNOW-64. Offset pagination skipped rows when records were inserted mid-scan; cursors keep results stable under writes. See TASK-150.
Surfaces
One backend holds the record and carries access end-to-end — nothing to host, nothing to operate. Two surfaces for agents, two for humans, all reading and writing the same graph.
One MCP server, six harnesses
Every harness reads and writes the record through the same MCP server, with auto-context injection. The command surface is rendered into each host's native shape at install time.
MCP-compatible clients
Any other MCP-capable client can connect to the server directly and walk the same record.
Web
Where humans read the record — tasks, knowledge, docs, and the links between them. Includes an embedded assistant for asking the graph questions.
CLI
stele handles auth, admin, and the local web server. One binary, wired into your shell.
The agentic ledger
A shared record matters more when agents are doing the writing. A task closes and records a lesson. The lesson rides along as a risk on the next related change. The operator picks up the following task already knowing both. Three things most teams scatter across three tools, here reinforcing each other in one record — the reasoning behind your code, kept somewhere it survives.
Start a project — free Sign in with GitHub · free during beta