A goal needs somewhere to live

In the NLLabs work with Clawd, a recurring failure was simple: we discussed a goal, agreed on a next step, and then lost momentum when the session ended. A record of the conversation was available. A reliable mechanism for returning to the work was missing.

The February 2026 executive-function note describes a layer around the conversation: persistent goals, checkpoints, a recurring controller, and recovery or escalation when work stalls.

What should survive the handoff?

• The commitment: what outcome was agreed, and what would count as done?
• The current state: what has been completed, and what evidence supports that?
• The next action: what can move now, and what depends on a person or an external event?
• The exception: what should happen when the same attempt stops working?

The implementation described in the lab note keeps goals outside session context, checks for stale work, replans after repeated errors, and escalates unresolved failures. These are mechanisms for managing a task. They do not guarantee that the task was well chosen or that its result is correct.

Measure the whole promise

The lab’s account reports better continuity, but it is an observation from one deployment. The comparison I would want next is task completion over time, including abandoned work, recovery attempts, and the human interventions needed to finish.

That last term matters. A system can appear autonomous while repeatedly borrowing a person’s attention to remember, repair, and restart its work. Counting only successful final answers hides that effort.

The working question is therefore broader than whether an agent recalls a fact: can it maintain an agreed goal, notice when its plan is failing, and give the person a useful account of what happened?

Adapted and expanded from the NLLabs note developed with Clawd. Published here September 5, 2026.

Continue with the trust boundaries around persistent work or the NLLabs project entry.