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.
Activating a workspace widens what your agent reads. It doesn't redirect writes: new entries go to the shared record unless the agent names the workspace, or you're on a branch the workspace is tied to.
Private workspaces and personal memory
A regular workspace keeps experimental notes out of the way, but everyone in the project can still read it. A private workspace is readable only by the people you add to it. Other members of the project can't see its notes, its name, or what's inside. If something in the shared record links to a private note, they see a locked marker in place of the link, and opening it tells them the note is private.
Personal memory is a private workspace with one member: you. It holds what you want your agent to know about this project that your teammates shouldn't see:
- Your own ideas and goals on a team project. Half-formed ideas, your goals for the quarter, a direction you want to try before you pitch it. Your agent uses them when it works with you.
- Feedback or a goal from your manager. “Own the migration work,” or “write tighter design docs.” Your agent connects it to the project: it points you at the migration tasks and holds your design docs to a higher bar.
Facts about the code and decisions the team made still belong in the shared record, because your teammates need them.
Nothing becomes private by default. Your agent saves to a private workspace or your personal memory only when you ask for it, or when it offers and you agree, and it tells you where each private note went. Turning a private workspace into a shared one, or moving its notes into the shared record, also waits for your yes.
Context, kept alongside the work
On every turn, 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 searches with your message and the end of the agent's last reply, then a judge model keeps only what would change what the agent does next. Things that are merely nearby never arrive. Your agent can state a topic to sharpen the search, but it doesn't have to.
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 conversation 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.