BlogHow an agent session uses Stele
In practice

How an agent session uses Stele

Stele
  • how-to
  • agent loop

You keep talking to your agent the way you already do. Stele changes what happens around each turn: context in, work tracked, knowledge out.

Abstract illustration of a prompt flowing through context, a task, and a written lesson.

Before the answer

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

This is automatic and quiet. It will not re-inject the same node twice in a session. It stays out of the way on short prompts. You can tune how aggressively it pulls, or pause it for a few turns, when you want a clean slate. It is best-effort software sitting in a hook path, not a guarantee that every relevant fact will always appear.

When the agent needs to go deeper

Auto-injected context is a starting set, not a full investigation. When the agent needs more, it can dispatch a read-only search subagent. That subagent interrogates the graph in its own context: it can read and search, but not write. It returns a short, cited briefing so the main thread is not filled with raw search hits.

Tracking the work

When the agent starts something real, it creates a task and claims it atomically. If more than one agent is running, no two grab the same work. The task is the unit of continuity: a human or another agent can see what is in flight and pick it up later, with linked decisions and risks attached.

Nudges, not blockers

Stele prompts the agent at moments that matter without blocking the session. Examples from the shipped loop: a one-time nudge before the first code change of a session to search the record first, so the agent does not re-decide something already settled; nudges around writing lessons and risks as work completes. The agent can still proceed. The point is to make the honest update the easy path.

Writing back

As the session learns something worth keeping, the agent writes it into the graph: a decision with a reason, a lesson that includes the concrete trigger (the error string, the failing path), a risk bound to the task that should retire it. Anchors to files and symbols help the fact resurface when that code is touched again. Lifecycle fields (expiry, task binding, due dates) are chosen at write time so retirement is not left as homework for later.

What this is not
This post describes the day-to-day agent loop around the shared record. It is not a claim about autonomous “loop engineering” oracles, unpaid background gardeners, or benchmark lift. Those are separate topics with their own shipping status.

Further reading