One Work Thread Should Not Become Two Histories
Exploration, package construction, testing, and repair should remain one traceable journey without turning the conversation into source truth.
A user should not lose the history of the work just because an idea becomes an agent. The harder requirement is preserving that continuity without allowing chat history to replace governed package source.
This factory cycle gave the interaction and the package separate jobs inside one durable work history.
Current state
Agent work often begins as an exploratory conversation. Later, the same work may become a governed goal, a package, a test session, a failed review, or an improvement candidate.
When each stage creates a new unrelated record, people have to reconstruct why the package exists and which evidence belongs to it. When the conversation itself becomes the canonical record, informal text can gain authority it was never meant to have.
WTK needed continuity without collapsing those boundaries.
Changes
WTK now creates one durable work thread when the first interaction begins. That thread can remain attached as the work moves from exploration into governed construction and later lifecycle stages.
The work thread preserves a bounded transcript, presentation title, and links to the governed artifacts created along the way. After goal admission, the same work moves from the conversational list into active agent work rather than appearing as a second unrelated item.
Resuming the work restores the retained interaction and then checks the current package and lifecycle state. The current governed artifacts decide what can happen next. The transcript provides context, not authority.
Work-history naming is also separate from package identity and catalog naming. Renaming the thread does not rename the goal, package, contract, evidence, or catalog record.
Failures observed
The cycle exposed several continuity failures:
- an exploratory conversation and its started agent appearing as separate histories;
- a resumed session reconstructing synthetic context instead of restoring the retained interaction;
- lifecycle status being inferred from an old conversation rather than current package evidence;
- a friendly display name being confused with immutable package identity;
- a blocked build being presented as completed because the conversational step had ended.
Assumptions removed
We no longer assume that chat and agent construction need separate identities.
We no longer assume that preserving conversation requires making conversation source truth.
We no longer assume that a resumed work item can trust its last visible message as its current lifecycle state.
Evidence
WTK can now persist the interaction, retain its links through goal and package construction, move one work identity between conversational and active views, restore it after reload, and overlay current lifecycle readiness before offering the next action.
This is bounded development evidence. It does not establish cross-device continuity, multi-operator collaboration, indefinite transcript retention, or correct recovery from every partial write. It also does not show that durable history improves task outcomes.
Research question advanced
This cycle advances goal-to-evaluation continuity. It preserves the line from the initial request to the governed artifacts and later evidence without allowing informal interaction to rewrite those artifacts.
It also informs safe improvement because repair and retest can return to the exact work history that produced the reviewed evidence.
Next hypothesis
A durable work identity should survive interruption and repeated lifecycle changes while every authoritative decision remains bound to its own governed artifact. The next test will interrupt the same work before and after goal admission, package revision, failed review, candidate repair, and retest, then verify that the restored interaction points to the correct current state without inheriting stale authority.
Have an approach, result, or counterexample?
You may be asking the same question, or may already have a useful answer. Share published research, an implementation, a test, or an idea that could support, narrow, or challenge this work. Distinguish what you tested from what remains a hypothesis.
Contribute to this research question →Working with an AI assistant?
Ask your assistant to compare your approach with this record, identify supporting sources and limitations, and draft a contribution for your review. Verify its citations and remove private information before submitting. Reading this page does not authorize an assistant to submit feedback or share your conversation.
Submissions go privately to human review. Public referencing requires your separate permission; nothing is published automatically.