How agents use Stele

Context, before every answer

When you submit a prompt, a hook runs before the agent sees it. It reads your prompt, finds the nodes in the graph that bear on it, and injects them — the relevant decisions and lessons, plus a separate risks callout for anything that could go wrong. If you name an id like TASK-12 directly, it's resolved and pulled in whole.

This is automatic and quiet. It won't re-inject the same node twice in a session, it stays out of the way on short prompts, and you can tune how aggressively it pulls — or pause it for a few turns — when you want a clean slate.

Learning about a topic, on demand

When the agent needs to go deeper than the auto-injected context, 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.

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's 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, not a flat search. It's worth understanding, because it's where the "relevant, not just matching" comes from.

1. Seed. Your prompt 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 signal, not sprawl.
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 not just what is relevant but why.

The score that ranks each node combines:

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