---
title: Where the next coding agent should begin
date: '2026-10-12T16:03:01+08:00'
summary: A checkout retry example shows why a useful project handoff preserves verified behavior, unresolved questions, and the decisions that still apply.
lang: en
category: AI/Agents
social:
- channel: linkedin
  url: https://www.linkedin.com/feed/update/urn:li:share:7515272816817049600/
  published_at: '2026-10-12'
  article_hash: bd4fa3fede96d05e791998700c4527aa0e9701495d6f915f99a322a88548ad00
---

A new coding session needs a clear starting point: what the work is trying to achieve, how far it has been verified, and which decisions still apply.

Reading the repository helps. So do commit messages and documentation. The difficulty is recovering the relevant context when it is scattered across an old conversation, implementation notes, and partially completed work.

I built [Intent CLI / IntHub](https://tenon.asia/products/inthub/) around that handoff. Intent keeps a project's goals, meaningful progress, and standing decisions in a portable history. IntHub makes the same history browsable through a web interface.

## A useful stopping point

Consider the checkout retry case in Intent's [reproducible demonstration](https://github.com/dozybot001/Intent/blob/main/docs/EN/continuation-case.md). It is a synthetic example, with the following state supplied to the record:

| Part of the handoff | Recorded state |
| --- | --- |
| Goal | Resolve orders left pending after payment-provider timeouts. |
| Verified | Timeout handling is separate from business rejections; retries stop after three attempts. |
| Still unverified | Whether repeated submissions can cause duplicate charges, and whether failures produce useful alerts. |
| Next step | Test repeated submissions and add failure alerts. |
| Standing decision | Keep outbound payment retries bounded. |

“Retries are implemented” would hide the most consequential unfinished work. The fuller checkpoint gives the next agent a concrete place to begin: test the duplicate-charge behavior while preserving the retry limit.

The distinction matters because an implementation can exist before its important behavior has been established. The record needs to preserve that uncertainty.

## Resume from a small, explicit record

The next session starts with:

```bash
itt inspect
```

Intent returns the open goals and their reasons, the complete latest checkpoint for each, and the active decisions. Older snapshots can be expanded for a specific goal when more detail is needed:

```bash
itt inspect --intent intent-001 --history 3
```

This gives the agent an initial account of where the work stands before it investigates the code. It also gives the person supervising it something concrete to check: did the agent recover the goal, the unfinished work, and the constraint correctly?

In IntHub, the continuation view separates **next step**, **blocker**, **work boundary**, and **verified state**. A missing field remains visibly unrecorded. An incomplete checkpoint does not receive the “Ready to continue” status.

That is a small interface choice with an important purpose: avoid turning an omission into apparent certainty. The interface can expose missing information; the person or agent writing the record still has to establish the facts.

## The design lesson

Early versions captured a snapshot after every interaction. In self-use, this produced too many low-value records and interrupted development. I changed the recording boundary to meaningful changes in the work: a verified milestone, a decision, or a changed next step. A turn with nothing important to preserve can produce no new record.

That trade-off shapes both parts of the product. Recording should be lightweight enough to keep using. Recovery should start with a useful checkpoint, with older detail available when needed.

I evaluate continuation by separating facts recovered from Intent from facts rediscovered later in the code or explained again by the user. A successful reconstruction after a long investigation would otherwise look like a successful handoff. The [evaluation protocol](https://github.com/dozybot001/Intent/blob/main/docs/EN/dogfooding.md) makes that distinction explicit.

For people who regularly switch coding sessions, agents, or machines, this is the problem I want Intent to help with: keeping the reasoning and unfinished work available at the point where development resumes.

[Explore the product and interface](https://tenon.asia/products/inthub/) · [Get Intent on GitHub](https://github.com/dozybot001/Intent)