How agents use Stele

Context on every turn

A hook runs before each of your messages. It searches the graph twice: once with your message, and once with your message plus the end of the agent's last reply, because a short follow-up like "ok, do it" only makes sense next to what came before. A judge model then reads the candidates and keeps only the ones that would change what the agent does next. Those reach the agent: the relevant decisions and lessons, plus a separate risks callout for anything that could go wrong.

If the judge doesn't answer in time, nothing from the search is added that turn. Stele would rather show the agent nothing than a pile of things that are merely nearby.

Two things skip the judge. 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.

Your agent can also state a topic: a sentence about the work plus the terms that distinguish it. That is optional. A topic sharpens the search, and the judge reads it as the agent's earlier focus, which may be out of date. The same node won't be shown twice in a session unless it has changed since. You can tune how aggressively recall pulls, and the agent can pause it for a few turns.

What this looks like from your side

You don't do any of it. What you notice is that answers arrive with history attached.

Because recall follows the conversation, it moves on when you do. If it pulls in the wrong history, the fix is just to say so, the same way you would redirect a colleague.

The agent can mute recall for a few turns while it works through something it already has the context for. Compaction does not break recall either: when your tool summarises a long conversation to make room, the next turn searches as before.

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 the conversation: what you and the agent say 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.