Core concepts
Everything in Stele is a node in one graph — knowledge and tasks alike, held together by the edges between them. Understand that model and the rest of the product follows from it. This page is the map.
One graph, not two tools
Most setups keep a task tracker in one place and notes in another, and the link between them lives in your head. Stele keeps both in a single graph: a decision, a lesson, a risk, and the task it belongs to are all nodes, joined by typed edges. Because they share one record, the connection is queryable — you can walk from a task to the risk it carries, or from a decision to everything it shaped.
Node types
A handful of node types carry the project's memory and its work.
- Knowledge
- The reasoning behind the code — decisions, lessons, risks, goals, and gaps. Each is a short, addressable fact written as the work happens, so it can be cited later instead of re-derived.
- Tasks
- Work the project tracks for itself, claimed atomically. Tasks come in sub-types for the larger shapes — epics, objectives, and milestones — so a roadmap and its day-to-day work live in one place.
- Documents
- Longer narratives — a design spec, an audit, an architecture overview — that don't fit in a one-line fact but still belong in the record, linked to the tasks and decisions they explain.
- Diagrams
- Visual nodes rendered from a text description — an architecture sketch, a sequence flow — versioned and linked like everything else, so a picture lives in the record next to the words.
- Components
- The structural skeleton: the parts of the system, nested into a tree. Every other node lives under a component, which is what keeps the record organized instead of a flat pile.
Every node has a stable, shareable id — TASK-12, KNOW-5, DOC-8 — so any piece of context can be named in a sentence and opened in one click.
Components & topics
Nothing floats free. Every task and every fact lives under a component — a part of the system, like auth or billing — and components nest into a tree that mirrors how you think about the project. That structure is what lets the record answer "what do we know about billing?" instead of returning a flat pile of notes.
Topics cut across that tree. They're lightweight tags that group related nodes wherever they sit, so a theme like performance can span components without breaking the hierarchy.
The task lifecycle
A task moves through a small, deliberate set of states. The important step is the claim: it's atomic, so when an agent or a teammate picks a task up, everyone else sees it's taken and no two start the same work. Closing it records what happened, which becomes context for whoever touches that area next.
You rarely drive these transitions by hand. You describe the work; the agent claims, completes, and writes the closing note as part of doing it.
Workspaces
A workspace is a scoped overlay on the graph — a place to accumulate knowledge for a branch or an experiment without disturbing the shared record. When the work proves out, you merge the workspace back and its findings join the main graph. When it doesn't, you drop it and the trunk was never touched.
Context, served automatically
This is the part you feel without doing anything. When you prompt your agent, Stele walks the graph first and pulls in the decisions, lessons, and risks that bear on your question — before the agent answers. Reachable risks ride along on the trail, so a past incident gets named while a change is being made, not after it ships.
The agent does one of three things with what it finds:
- Explains — cites the decision that already settled something, instead of guessing.
- Pushes back — declines a change that contradicts what the project learned, and points at the prior knowledge.
- Acts — uses knowledge the team already had to do the work correctly the first time.
What gets surfaced is controlled by Auto-RAG, Stele's retrieval layer. It works out of the box; power users can tune how aggressively it pulls context from the project settings.
Provenance you can follow
Because every node is linked, every change leaves a trail you can walk. A design document leads to the task that implemented it, to the risk that surfaced during the work, to the decision that resolved it — and to the person who made the call. You can reconstruct exactly why something is the way it is, rather than guessing from the diff.
A record that keeps itself honest
A graph that confidently serves wrong facts is worse than no memory at all. So Stele tracks each fact on two axes — how recently its content changed, and when it was last verified against reality — and uses both to decide what to trust. Stale entries are flagged for review, ephemeral notes expire, resolved risks retire with their task, near-duplicates are surfaced to merge, and a reversed decision is superseded so it stops being served as truth.
You don't garden this by hand. The doctor command audits the graph as it grows — surfacing near-duplicates, catching broken links, and flagging what's drifted — and the agents you already use act on what it finds.