What Stele changes, day to day
The model is abstract until you see what it does to ordinary moments. Here are four that happen in every project with more than one contributor — human or agent — and how each goes differently once the reasoning lives in the record.
A watchdog on risky changes
The most expensive bugs are the ones you already fixed once. A change that looks harmless reintroduces a problem the project paid for months ago — and a fresh agent has no way to know. With the risk linked in the record, it surfaces while the change is being made, not after it ships.
The agent didn't get smarter — it got the context. It cited the task that added the lock and the risk that justified it, then offered a safer path. The graph is a check on the work, not just a log of it.
Onboarding that starts full, not empty
A new contributor — or their agent — usually spends the first week reconstructing context that someone already had. With Stele, the history is already at hand: why the API is shaped this way, the refactors it went through, the decisions still in force, what's planned next. The agent they bring reads the record before it touches a line of code, and they can ask the assistant directly.
I'm new to this codebase. Before I start on the billing work, catch me up from Stele: the key decisions still in force, anything that's been tried and rejected, and the open tasks.
They're productive on day one, and the agent gate-keeps as much as it helps — a change that contradicts a standing decision gets flagged before it lands.
Team memory that outlives the session
Context normally dies at the edges of a chat — when you hit a token limit, switch tools, or come back weeks later. Stele keeps it attached to the project instead of the conversation, so it survives all three. Switch from one agent to another and tell the new one to continue; it reads the task and picks up the thread.
"The next person" is often just you, weeks later, having forgotten the details. The record answers your own question — why did I build it this way? — as readily as a teammate's.
A project manager for agentic work
Stele also runs the work. The loop has two halves you'll use constantly: a planner that turns intent into a task graph, and an operator that executes it.
- /stele:planner takes an evolving idea — your docs, decisions, and constraints — and turns it into a prioritized, linked, implementation-ready set of tasks. Because it has full project context, it pushes back when a new idea conflicts with a decision already made.
- /stele:operator runs the implementation loop: it reads the open tasks, picks a coherent bundle, parallelizes what it can, records the lessons and risks it hits, completes the tasks, and writes a handoff so the next run continues cleanly.
The thread that ties it together is the record: planner writes the tasks with their rationale, operator works them with that rationale in hand, and every lesson learned along the way is waiting for the next related change.
/stele:planner — turn the notes in DOC-3 into a prioritized task graph for the export feature, flag anything that conflicts with decisions we've already made.