"My Coding Agent Finished the Task. Why Did the Thread Die?"

The most annoying follow-up bug in a coding agent is not a crash.

It is when the first task succeeds, and the next message still feels like amnesia.

I would ask Claude Code or Codex to do something through my local assistant, wait for it to finish, and then send the most normal follow-up in the world:

make the button green

From the user's side, that is obviously part of the same thread.

From the system side, it was too easy to treat completed as "this session is over, start from scratch next time."

That was the bug.

The real problem was mixing up three different things

While building CliGate, I realized I had let three layers blur together:

• the chat conversation
• the runtime session
• the current execution turn

Those are not the same object.

A conversation is the long-lived place where the user keeps talking.

A runtime session is the working thread attached to that conversation.

A turn is just one run inside that session.

Once I wrote it down that way, the mistake became obvious. completed should mean the current turn is done. It should not mean the whole thread has to be detached.

Why the old behavior felt wrong so quickly

The broken flow looked like this:

user asks for task
-> runtime session starts
-> task completes
-> conversation clears active session
-> next follow-up starts a brand-new session

That does not sound terrible until you use it from a phone or a busy web chat.

Real follow-ups are short. People say things like:

• retry that
• do the same for this file
• make the button green
• explain the error
• continue

Those messages only work if the agent still knows what thread they belong to.

If the system detaches the session the second one task finishes, the user is forced back into full restatement mode. The agent technically works, but the thread feels fake.

The fix was not more prompting

My first instinct was to improve follow-up classification.

That helped a little, but it was not the core fix.

The real fix was to make the binding model explicit:

• conversation is persistent
• runtime session is sticky by default
• completed/failed only close the current turn
• a new session should be explicit, or caused by a real compatibility change

In other words, I stopped treating task completion as session death.

That tiny semantic change affects the whole product feel.

When should a new session actually start?

Not every follow-up should reuse the old session forever.

But the boundary needs to be meaningful.

In CliGate, the cases that justify a new session are things like:

• there is no bound session yet
• the user explicitly asks for a new one
• the provider or model changed in a way that makes reuse incompatible

That is very different from saying the last turn completed, so the thread should be thrown away.

The first rule matches how people think.

The second rule matches how brittle plumbing thinks.

This mattered on both web chat and mobile channels

The nice part is that the same model applies in more than one place.

In a web chat window, the user expects one tab to behave like one ongoing thread.

In Telegram, Feishu, or DingTalk, the expectation is even stronger. A conversation on the phone is already compressed. The user is relying on the system to preserve context across tiny, vague follow-ups.

So the product behavior I wanted was simple:

• first message creates a runtime session
• later messages keep using that session by default
• completed or failed do not silently drop the thread
• /new or a real config drift can start a fresh session

That makes the agent feel much closer to a real working thread instead of a command launcher.

The subtle UX win was explaining the boundary clearly

Once you separate conversation, session, and turn, the UI gets easier to reason about too.

The user can understand:

• this conversation is still attached to a session
• the last turn is done
• I can keep asking follow-ups
• if I want a clean start, I should explicitly ask for a new session

That is a much better mental model than making the user guess whether the tool still remembers anything.

It also makes debugging easier. If a new session appears, it should be because the user asked for one or because something important changed, not because the state machine quietly treated success as disposal.

The rule I am keeping

If you are building a coding agent, do not let one successful task kill the thread.

The durable unit is the conversation.

The reusable worker is the runtime session.

The thing that ends on success or failure is the turn.

Once I separated those three layers, follow-ups stopped feeling random and started feeling conversational.

That is now part of how I am shaping CliGate, the local control plane I use for Claude Code, Codex CLI, Gemini CLI, channels, and a resident assistant layer on top.

If you are building agent workflows, are you treating completion as the end of a turn, or the end of the whole thread?