# Stele — stop reintroducing problems your team already solved > When an agent picks up a change, it reads what the project already learned — > and pushes back when the change would reintroduce a problem. Stele is a knowledge graph and agent memory for teams that ship with AI coding agents — Claude Code, Cursor, Codex, and any MCP-compatible client. A task system, a knowledge graph, and an agent operator — as one shared record. - **Live site:** https://stele-ai.dev - **App:** https://app.stele-ai.dev - **Status:** v1 in beta. Free during beta. Sign in with GitHub. --- ## In practice — every answer starts with what the project remembers 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. The agent uses what it finds: to explain, to push back, or to act on knowledge the team already had. This isn't a separate "ask the knowledge base" surface. It happens on every prompt, before the agent answers. Two patterns dominate: 1. **Ask why.** "Why do we do X this way?" The agent walks back through the decision that set X, the task that surfaced the question, the lesson that shaped the decision, and the original design doc — and cites them by id. 2. **Pushback.** When the change would contradict prior learning, the agent declines and cites the specific knowledge it conflicts with — instead of silently doing the change and recreating the problem. --- ## A real moment — one task, kept safe by everything else {#proof} A real moment from this project, replayed. The agent is about to drop a cross-process refresh-lock as part of cleaning up the auth layer. The lock is no longer needed in most flows — but there's a recorded risk that says it's only safe to remove while Supabase refresh-token rotation is off. The agent picks up the task, walks the graph, hits the linked risk node, and pauses to ask the human instead of guessing. The chain: - **TASK-211** — *delete the cross-process refresh-lock* - **KNOW-370** (risk, caused-by TASK-211) — *cross-process refresh-lock only safe to drop while Supabase refresh-token rotation is off* - **DOC-208** — *Auth v2 design* (the document that introduced the lock) Parallel agents, recall, a linked risk, and an agent that paused to ask — not refusing on its own, but checking before it ships. --- ## One record {#concept} The point isn't any one part. It's that they share a single ledger — so each part makes the others sharper. A task is not just an item in a list; it's a node connected to the decisions that motivated it, the risks it might trip, the design doc it implements, and the lessons that came out of it. A decision is not a Slack message lost to scroll; it's a node connected to the task that surfaced the question, the risk it mitigates, and the design doc that records the alternatives considered. The graph is the integration. It's why pushback works: the agent doesn't need to be told "check the wiki" — the relevant knowledge is already on the path it walks for every prompt. --- ## The reasoning behind your code, kept with it Six capabilities, all reading and writing the same record. ### Risks surfaced 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. ### Doctor keeps the ledger curated `stele doctor` audits the graph as it grows — near-duplicates surfaced for dedupe, broken edges caught, orphaned components flagged. Active curation, not just append-only writes. ### 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. ### Fewer repeated mistakes An agent checks a change against what the project already learned, and stops before repeating a problem — citing the specific prior knowledge. ### Kept honest Entries carry provenance and age. Stale knowledge is flagged and revised, not trusted forever — the ledger ages with the code. --- ## What your ledger looks like, in use Decisions, tasks, and lessons accumulate as you and your agents work — each one linked to what caused it, ready for the next agent (or your future self) to walk. A real snapshot from the Stele project itself, today: - **30** decisions recorded - **58** lessons captured - **189** tasks (open and closed) - **8** components (the scaffolding the graph hangs off) - **1,343** edges between nodes Each node has a stable shareable id (`TASK-211`, `KNOW-370`, `DOC-208`, `COMP-5`) so it can be cited in prose, in commit messages, or by another agent — and the citation resolves to the canonical node forever. --- ## Where you actually use it — one backend, four surfaces {#surfaces} Supabase holds the record; row-level security carries access end-to-end. Two surfaces for agents, two for humans — all reading and writing the same graph. ### For agents **Claude Code plugin (primary).** The production-supported path: an MCP server (32 tools) plus hooks and slash commands. How agents read the record before they act and write back what they learned mid-task. **MCP-compatible clients (in principle).** The same MCP server connects in principle to any MCP-capable client — Cursor, Codex, Gemini, others. Daily- driver testing today is Claude Code; the rest is unverified. ### For humans **Web (dashboard).** Where humans read the record — tasks, knowledge, docs, and the links between them. Includes an embedded assistant for asking the graph questions. Lives at https://app.stele-ai.dev. **CLI (setup).** `stele` handles auth, admin, and the local web server. One binary, wired into your shell. --- ## Today, you can see a task is taken. Next, the whole project as it's built. Right now the visibility into others' work is simple: a task shows as picked up, so two people don't start the same thing. The direction is for Stele to become where agentic work starts — following tasks as they move, watching the knowledge your team and its agents build in realtime, and seeing the project take shape alongside the code rather than buried inside it. --- ## Get started The decisions, the tasks, and the lessons behind them — in one place your future self and your agents can both read. - **Open the app:** https://app.stele-ai.dev - Free during beta. Sign in with GitHub. --- ## About the technology - **Backend:** Supabase (Postgres + Auth + Realtime). Row-level security carries authorization end-to-end. No custom server. - **Agent integration:** Claude Code plugin shipping an MCP server (32 tools), UserPromptSubmit / PreToolUse / PostToolUse / Stop hooks, and slash commands. - **Identifiers:** Linear-style stable shareable ids per node type — `TASK-N`, `KNOW-N`, `DOC-N`, `COMP-N` — usable in prose and by other agents. - **Graph walk:** typed edges (`caused-by`, `mentions`, `fulfills`, `supersedes`, etc.); the same code path used by the deliberate `build_context` MCP tool and the per-prompt auto-RAG hook. - **Knowledge categories:** decision, architecture, goal, risk, gap, fyi, opportunity, priority, lesson, commitment. --- *Stele — a shared record for your project. Free during beta · sign in with GitHub.*