You know what sucks? Coming back 2 months later to a project you started with a burning sense of purpose, and realizing you have no idea what the next step was, or even whether its still a good idea. (narratives are important!) A similar need: capturing context, relevant links, and the "why" for enabling code-authoring agents to go solve a problem for you with high autonomy.
Well, recently I’ve been reading Accelerando (surprisingly relevant these days...) and it has an interseting through line: characters can fork instances of themselves to go do research, tasks, etc. It’s a bit magical in the book, but very similar to typing claude in your terminal and firing off …
You know what sucks? Coming back 2 months later to a project you started with a burning sense of purpose, and realizing you have no idea what the next step was, or even whether its still a good idea. (narratives are important!) A similar need: capturing context, relevant links, and the "why" for enabling code-authoring agents to go solve a problem for you with high autonomy.
Well, recently I’ve been reading Accelerando (surprisingly relevant these days...) and it has an interseting through line: characters can fork instances of themselves to go do research, tasks, etc. It’s a bit magical in the book, but very similar to typing claude in your terminal and firing off a request. claude is different from you in extremely important ways, but the analogy is good enough to be useful.
They say that effective vibe coding/engineering is an exercise in context management. What I’ve found to be useful is using a document to manage this forking process, enabling re-entrance, and clear exit conditions - I call them threads. Inside, you put the core bet (what’s the hypothesis, the insight, inspiration, etc), relevant links, immediate next steps, the definition of done (to close the thread), and a log of significant decisions/actions. See the example template below. I’ve found this is enough information to solve both needs from paragraph 1:
- I can cycle back onto this later and get the blurb that inspired 2-months-ago me, see what immediate next steps are, and regain momentum. (see It’s all about momentum, innit?)
- I can essentially say "Hey, take a look at @threads/dev-box.md - what solutions for declarative package installs should I consider?" to an LLM and get useful output.
This process/convention has proven useful in many situations:
- Peeling off threads when you’re deep in another task, have discovered an important related task, and want to capture context you can come back to later without totally dumping your mental state.
- Asking an LLM to capture significant decisions you’ve discussed (and their motivations) in its thread file during the agentic code authoring process.
- As a place to accrue requirements for a soon-to-be-task to ensure you don’t forget them later.
- A place to refer to when you wonder why you made the decision you did.
In the code agent arena, this is a layer above the agent-generated plan. When done well, these should be high value density and be worth checking into your monorepo, allowing humans and code agents to utilize the narratives and decisions within as context. They seem to have a similar value to architectural decision records, though I am admittedly no expert in those.
Like all good things, the idea is simple and flexible: it’s just a file containing the most important information regarding a task. And the information within is (mostly) all you need to know to close said thread. And it doesn’t have to be coding related, I even have one for refactoring my physical desk to make it more modular!
Appendix
Example Template
---
title: Thread Template
created: 2025-12-15
---
# Bet
REPLACE ME! See [motivating note](https://blog.sao.dev/2025-threads/). Establishes a format for encoding bets into threads that can be easily spawned and re-entered. This file acts as a template, with some self-reference for context.
# Context
REPLACE ME!
- [Narratives and Better Bets](https://blog.sao.dev/zt-2025-06-22-narrative-and-better-bets/)
- Tokens are expensive, keep this succinct
# Next Steps
REPLACE ME! This section is technically optional, but should exist as it contains the distillation of how to "get started" again.
# Definition of Done
REPLACE ME! This is more optional, but also important to add description of specific outcomes that represent payoff. Can be descriptions of test or use cases, or outcomes in the real world, etc.
# Log
## 2025-12-29
- Drafted [motivating note](../dev/sao/notes/zt_2025-12-15_external-threads.md).
- Implemented this template.