Evolution threads are the spine of long-running product work in Evonx. They exist because of a failure mode anyone who has worked with an AI assistant will recognise: the conversation goes well, you close the tab, and everything the model understood about your product evaporates.
A chat log is a poor container for engineering work. It is ordered by time rather than by dependency, it mixes decisions with small talk, and nothing in it distinguishes "we tried this and rejected it" from "we are doing this". Threads are our attempt at a container that fits the shape of the work instead.
What a thread holds
Intent is the outcome the thread is chasing, stated once. Not a task list — the reason the task list exists. When a later step contradicts the intent, that is a signal worth surfacing rather than a detail to smooth over.
Decisions are the choices already made, with the reasoning attached. This is the part chat loses most expensively. Six steps into a thread, "we are using the existing invoice table rather than a new one" needs to still be true, and it needs to still be explicable.
Steps are the ordered units of work. Each one is small enough to run, review, and undo on its own. That granularity is deliberate: a step you cannot review is a step you have to trust blindly.
State is where the thread actually is — which step is next, what ran, what is waiting on a human. It is the answer to "what was I doing?" without re-reading anything.
Threads move one step at a time
The most common thing people expect from an agent is one-shot execution: describe the feature, get the feature. We deliberately do not default to that for substantial work.
One-shot generation is fine when the change is genuinely small and well-specified. Beyond that it produces a large output that is expensive to verify, and when something is wrong you are debugging the whole thing at once. Stepwise execution costs slightly more wall-clock time and gives you something reviewable at every stage — with a working preview to check it against.
It also fails better. A wrong step is a wrong step; you correct it and continue. A wrong one-shot build is often easier to throw away than to fix.
Why structure beats a bigger context window
A reasonable objection: why not just put the whole history in the prompt and let the model sort it out? Context windows keep growing.
Because relevance does not scale with volume. A model given fifty pages of conversation has to infer which parts still bind, and it will sometimes infer wrong — resurrecting a rejected approach or treating an aside as a requirement. Structure removes the guesswork: a decision that is recorded as a decision does not need to be recognised as one. This is the same reason grounding beats improvisation for the agent itself.
It also makes the work legible to humans. A teammate opening a thread sees intent, decisions, and next step immediately, rather than scrolling a transcript to reconstruct what was agreed.
The practical effect
The effect on day-to-day work is unglamorous and significant: you can stop. You can leave a thread mid-flight, come back after a weekend, and continue without a re-briefing. Work spanning weeks stays coherent because coherence lives in the structure rather than in whoever happens to remember the discussion.
That is the whole point. Software work is long-running; the tools around it should be too.