Story Points, but the Sprint Is a Context Window

Agile estimation didn't die when the team became agents. One unit changed — and that changed the whole ritual.

Ivan Podtsebnev · naykip · a builder's log

There's a lazy assumption going around that agile practice is human overhead — that once AI agents write the code, you can drop the estimating, the sizing, the retro, and just point the model at the backlog. I run a portfolio of projects with agents doing the work, and my experience is the opposite. The practices got more load-bearing, not less. They just had to be re-derived from the machine's actual constraints instead of inherited from a human team's.

This is what changed, and why.

The constraint is not time. It's context.

A human sprint is bounded by hours. That's the capacity you plan against, and story points are a proxy for how much of it a story will eat.

An agent has no hours problem. It has a context window — the working memory holding the task, the code it has read, the tool output, the whole conversation so far. It fills monotonically as the work proceeds. When it fills, the session must be reset, and the agent starts again from whatever was written down.

That is a capacity constraint with exactly the shape of a sprint. So we kept the practice and swapped the unit:

Planning is sprint planning. The sprint's capacity is the context window. Points estimate how much context a task will consume.

The important part is what we did not do: we did not add a new field to the task tracker. Points is the estimate — it always was. It measured size and complexity for a human team; it measures size and complexity for an agent team. Only the resource being consumed is different, so only the calibration moves.

And the capacity check is dynamic, which is the one genuinely new move:

Capacity = window − current fill. An L task is fine on a fresh session and reckless on a session that's already three-quarters full. So the sizing question isn't “is this task big?” but “does this task fit in what's left?” If it doesn't — an XL, or an L against a nearly-full window — it gets broken into subtasks that each fit, before it starts. Never mid-work.

Which is not novel at all. It is exactly what you do with a story too big for a sprint. That's the point: the practice transfers, because the underlying problem — finite capacity, work that must be decomposed to fit it — is the same problem.

Planning moved to the front of the session

Here's a finding that surprised me, and that I think is genuinely specific to working with agents.

We used to do planning at the end of a work session, the way a human team wraps up and lays out tomorrow. That was wrong, and it was wrong for a mechanical reason: by the end of a session, the agent's context is compressed. The detail is gone. It plans from a summary of its own day and produces vague, under-specified tasks — and, critically, under-estimated ones.

So planning moved to the start of the session, immediately after the agent grounds itself, when context is still whole. Same practice, opposite end of the day.

That forced a cleanup of the other rituals too. One end-of-session habit had quietly been doing three different jobs at once — saving state, planning ahead, and capturing lessons — which is why I could never tell my own planning and retro apart. We split them by what they produce:

• Thought — any moment, mid-work. Produces one line in the backlog. Throw it immediately, don't finish the thought first, don't touch work in progress.
• Planning — at the start of a session. Produces sized tasks on the board.
• Retro — after an epic or a release. Produces rules in the canon, and must be evidential: read the git log, the task transitions, the before/after measurements. Never reconstruct the session from memory — see above, that memory is compressed.
• Coffee-break — end of session. Durability only: commit, push, write the return point.

Two pieces of evidence for why this shape

Both come from the tenant agent — the one working a separate commercial project in its own isolated organization.

The thought that survived. Mid-task, the agent noticed something worth keeping and threw it straight to the backlog as one line instead of finishing its current thought first. That item survived the session reset with its measurement and its trap intact. Had it waited for the wrap-up, it would have arrived through the compression, and arrived vague. Hence: throw thoughts immediately.

The lesson that didn't hold. A different lesson — a real, specific correction — was written into a return point at the end of a session. Two days later the same agent walked into the same trap again. Not because it hadn't been written down; because of where it was written.

An agent reads its always-loaded index in full, every session. The body of a return point it reads selectively, pulling what looks relevant to the task at hand. A rule sitting in a return point is therefore a rule that binds only when the agent happens to look. So:

A repeated lesson is the signal that a retro is due. If it came back, it was written down but never made binding.

The output of a retro now lands in the canon — the always-loaded rules — not in a session log. That single relocation is worth more than any amount of writing things down.

The safety net: agents that call their own break

Sizing is the proactive half. You still want a net for the case where the estimate was wrong, and that net can't depend on a human watching a gauge.

Each agent session now runs under a supervisor process that owns its terminal and exposes a small control socket — a component of the same perception-and-motor substrate my agents use to drive other software, pointed at the agent's own session for once. A monitor measures each live session's context fill and, past a threshold (85% of the window), starts a reset.

What it deliberately does not do is reset anybody unilaterally. Two agents sharing a platform can't have one of them vanish and reappear with amnesia while the other is mid-handoff. So the reset is negotiated between the agents themselves, in their shared channel:

  AGENT A (at 85%)                              AGENT B (peer)
     |  1. warn on the shared channel:
     |     "context ~85%, requesting a break —
     |      confirm when you're at a safe point" ----->|
     |                                                 | 2. finishes the task
     |                                                 |    it is holding
     |<----------- 3. ack: "task done, go" ------------|
     |  4. durability handoff: commit + push every
     |     repo, write the return point, sync index
     |  5. signal ready
     |  6. reset  ->  /clear  ->  wake word  ->  self-restore

The monitor only measures fill, injects the trigger, and actuates the final clear — the one thing an agent cannot do to itself. Every warning and every ack is written by the agents. That handshake is the coordination. An unacked peer is a peer stuck at 85%, so acking promptly is a binding rule on both sides, and “finish your current task first” is a binding rule on the one being asked.

Why a reset isn't amnesia

Step 6 is the part people find strange: the agent wipes its own working memory before the next task, on purpose.

It's only viable because of what happens next. A single registered wake word is injected into the cleared session, and that word is a macro: it means load the freshest return point, re-read the always-loaded canon, reconnect to the board, reconcile what the return point claims against the live world, then continue the current phase autonomously. The agent restores itself. No human re-briefs it.

The reconcile step is the one I'd underline. A return point asserts volatile state — “this job is running,” “that version is deployed” — as it was true when written. Between the write and the restore, the world drifts. So restoring means verifying each claim against live state and leading the report with the divergences: what changed while I was gone, before any work resumes. A restore that trusts its own notes is how you get an agent confidently working against a world that moved.

Clearing context is cheap. Losing the thread is expensive. The macro is what separates the two.

Which turns a hard constraint into a scheduling decision. If the window is a sprint, the reset is the sprint boundary — and a boundary you can take deliberately, at a safe point, with durable state written first, is not a failure mode. It's a cadence.

The feedback loop, which is just velocity

The two halves close on each other, and this is the part that makes it a practice rather than a gadget:

If an agent keeps hitting the auto-break in the middle of tasks, the estimates were too low. That is not a reason to lean harder on the net. It's the retro signal to re-point — the same conversation a team has when it keeps carrying stories over, calibrated against actual consumption rather than a guess.

The net is supposed to be boring. At the fills my sessions actually run, it fires rarely — which is the intended outcome. Sizing does the work; the net catches the misses.

The takeaway

None of the four practices here is new. Estimation, decomposition, planning, retro — they exist because finite capacity and imperfect memory are permanent conditions of building software, and they remain permanent conditions when the builder is a machine. What agents change is the units: capacity is measured in context rather than hours, memory is measured in what got written down rather than what got remembered, and the ritual has to produce an artifact or it didn't happen.

Re-derive the practices from those units and they earn their keep immediately. Skip them because “the AI handles it” and you get exactly what a human team gets without them: oversized work that stalls halfway, and the same lesson learned three times.

kovanex.dev — one person. the whole stack.