How agents use Stele

Context, once the agent says what it's doing

Your agent starts a session with nothing pulled in. When it understands the task, it points recall at it: a sentence about the work plus the terms that distinguish it. It gets the first results immediately, and from then on a hook runs before each of your messages, finds the nodes that bear on that topic, and puts them in front of the agent: the relevant decisions and lessons, plus a separate risks callout for anything that could go wrong.

Two things don't wait for a topic. Naming an id like TASK-12 resolves it and pulls it in whole. And a note attached to a file surfaces the moment you edit that file, by an exact match, whether or not a topic is set.

The rest is quiet. Your agent replaces the topic when the work moves on, and can turn it off entirely. The same node won't be shown twice in a session unless it has changed since. You can tune how aggressively it pulls, and the agent can pause it for a few turns without losing its topic.

What this looks like from your side

You don't do any of it. The agent is told, on each of your messages, that recall is waiting for a topic; it decides when it knows enough to name one. What you notice is the moment the answers start arriving with history attached.

When the work moves on, the agent replaces the topic rather than adding to it, so the context follows the conversation instead of accumulating every subject you have touched. If it gets the topic wrong, the fix is just to say so , the same way you would redirect a colleague.

A periodic reminder shows the agent what it is currently focused on, so a topic that has quietly gone stale gets noticed rather than silently returning less and less. The agent can also mute recall for a few turns while it works through something it already has the context for; the topic survives the pause.

Compaction does not break this either. When your tool summarises a long conversation to make room, the topic keeps running and the agent is handed back what it needs to change it, so recall does not quietly get stuck on a subject you finished an hour ago.

Learning about a topic, on demand

When the agent needs to go deeper than what recall surfaces, it dispatches a read-only search subagent. That subagent interrogates the graph in its own context. It can read and search, but never write , and returns a short, cited briefing. The heavy searching stays off your main thread, so the agent gets the answer without filling its window with raw results.

Tracking the work

When the agent starts something real, it creates a task and claims it atomically , so if you've got more than one agent running, no two grab the same work. The task is the unit of continuity: anyone, human or agent, can see what's in flight and pick it up later.

Nudges that keep the record honest

Stele prompts the agent at the moments that matter, without ever blocking it:

• Before the first code change of a session, a one-time nudge to search the record first , so the agent doesn't re-decide something already settled or regress a fix already made.
• When a task closes, a reminder to update the decisions it touched, write down anything learned, and link it up , so the knowledge lands while it's fresh.

Risks at the moment you change the code

Recall works off a stated topic: what the agent says the work is. But the riskiest moment is often a change nobody thought to mention. So Stele also watches the boundary where work actually lands, and matches what you're doing against the record right there.

• You edit a file. If a risk, lesson, or decision is anchored to that exact file, it surfaces: "a note the team wrote names the file you're editing." A literal match, so it's precise: no guessing, no noise.
• A command fails. On a genuine failure, Stele reads the error and surfaces a lesson only when one stands out unusually strongly for this project. The team already wrote up this failure; here it is, before you debug it again.
• You commit a change. The committed diff is matched against the record, and a risk is raised when the change looks close to one: a fix you might be undoing, surfaced before you push. And if you commit while still holding an open task, a gentle reminder to close it out if the work is done , so finished work doesn't linger claimed into your next session.

All three are soft: a one-time line to the agent, never a block, surfaced once per session and only when the match is strong. The aim is silence by default. A nudge has to earn its place before it interrupts you.

Closing the loop

When the work is done, the agent completes the task with a note of what shipped, records the decisions and lessons worth keeping, links them to the code and tasks they belong to, and opens follow-up tasks for anything left. None of that is busywork you do afterward. It is part of finishing. The next prompt, the next session, the next agent all start from a richer record than the last.

Under the hood: the graph walk

The part that decides what to surface is a graph walk over the record. It's worth understanding, because it's where relevance comes from: a node can match your words and still bear on nothing.

1. Seed. The topic finds starting nodes two ways at once: full-text search and semantic (embedding) search , and any ids you named explicitly are added in whole.
2. Walk the deliberate edges. From each seed, the walk follows only the edges that carry meaning: blocks, supersedes, caused-by, contradicts, fulfills , and skips the noisy ones (a passing mention, a loose "relates-to") so the context stays tight.
3. Score every node it reaches on several axes at once (below).
4. Surface risks separately. Risk nodes within a hop or two are lifted out into their own callout, so a warning never gets buried under general context.
5. No arbitrary cutoff. There's no fixed "top 5". The walk returns what's strongly relevant within a token budget, and shows every node with the edge that pulled it in, so the agent sees what is relevant and why.

The score that ranks each node combines:

Finished and dropped tasks used to be left off this list entirely, on the thinking that closed work is exhaust. But a task's completion note is often the only place anyone wrote down how something actually works, and you're most likely to ask about it in the hours right after it closes. So a task's status now changes how it ranks and how it's labeled, and never whether the walk can find it. A closed task comes back clearly marked: COMPLETED, or CANCELLED — decided not to do for work you deliberately dropped, so your agent reads it as history instead of mistaking it for something still open , or, worse, going and building the thing you already decided against. It still ranks well below live work, and a task closed months ago ranks lower than one closed this morning.

Retrieval also respects workspaces: a walk sees the shared trunk plus whatever overlays you have active, and nothing from branches you're not on.

The one way to make something invisible

Status changes how a node ranks, never whether it exists to the walk, with exactly one exception, and it's the one you control directly. Mark a node hidden from its page in the dashboard and it drops out of search, recall, every list, and the duplicate finder: the surfaces that summarize or rank across your whole project. It isn't deleted: the node still exists, still reachable if you already have its id, and clearly marked so nobody mistakes it for something live.

It's for the handful of things you'd rather the record stopped volunteering: a note that was only ever true for a moment and has expired, something pasted in by mistake, a genuine error you don't want surfacing by default.