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 it's one graph, 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. You never claim one of those directly — they close themselves once every task under them is finished, and reopen if new work turns up underneath.
- 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, kept alongside the work
Once your agent knows what it is working on, it points recall at that topic: a sentence about the work plus the terms that distinguish it. From then on Stele walks the graph alongside the conversation and pulls in the decisions, lessons, and risks that bear on it. Reachable risks ride along on the trail, so a past incident gets named while a change is being made, in time to act on it.
It waits to be pointed rather than guessing from each message. A single prompt is a sentence about the work, not a description of it, and searching on the sentence matched a lot of things that were merely nearby. Your agent replaces the topic when the work moves on, and turns it off entirely if it would rather look things up itself.
The agent does one of three things with what it finds:
- Explains. Cites the decision that already settled something.
- 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.
The topic isn't the only trigger, and this one needs no setup at all. A note about specific code can carry anchors: the files and symbols it concerns. Edit one of those files and the note surfaces by an exact match, the moment you touch it, whether or not a topic is set. How agents use Stele walks through this recall at the action boundary.
How much gets surfaced, and how far Stele walks to find it, is set per project. It works out of the box; power users can tune it in 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. Some of it is automatic: facts expire, resolved risks retire, superseded decisions step aside , and the rest your agents run for you. The self-repairing graph covers the whole mechanism: the two clocks, what retires on its own, and the verification sweep that catches what's quietly drifted.