{"slug": "my-coding-agent-remembered-sessions-not-work-that-was-the-bug", "title": "\"My Coding Agent Remembered Sessions, Not Work. That Was the Bug\"", "summary": "A common bug in their coding agent where the system remembered the conversation session but not the actual work task, causing failures when users switched channels or followed up on previous jobs. To solve this, they redesigned the architecture to separate the concepts of a \"Task\" (the user's actual goal), an \"Execution\" (a specific attempt to advance the task), and a \"RuntimeSession\" (the underlying process), allowing the agent to maintain work continuity even when the runtime session changes. This distinction improved follow-up handling, failure recovery, and the ability to present different levels of detail across mobile and web interfaces.", "body_md": "The first version of my coding agent had a very common bug: it remembered the conversation, but not the work.\nThat sounds fine until the agent has to do something real.\nI would start a task from the web UI, continue it from a mobile channel, approve one command, ask for progress later, and then discover that the system was mostly guessing from the last few messages. It knew there was a session. It did not really know what job that session belonged to.\nThat is the difference between a chatbot and a working assistant.\nMost agent systems begin with a simple shape:\nconversation -> runtime session -> messages\nThat works for demos because the user does one thing at a time.\nIt breaks when the user behaves normally:\nNone of those are really about a chat session. They are about work.\nA runtime session can crash. A user can switch from web to Telegram or Feishu. Two agents can work on the same issue from different roles. If the system treats the runtime session as the main identity, every one of those cases becomes fragile.\nIn CliGate, I started moving the design toward a different model:\nPerson\n-> Project\n-> Task\n-> Execution\n-> RuntimeSession\nThe important part is not the diagram. It is the boundary.\nA Task is the thing the user thinks they are doing: \"fix routing\", \"review the auth change\", \"write release notes\", \"check why the build failed\".\nAn Execution is one concrete attempt to move that task forward. It may be Codex acting as the editor, Claude Code acting as a reviewer, or another provider doing a focused job.\nA RuntimeSession is just the current process or provider session underneath that execution.\nThat means the assistant can say: this is still the same task, even if the runtime process has changed.\nThe most annoying bugs came from follow-ups.\nWhen I typed:\nmake the button green\nI did not mean \"start an unrelated new job.\" I meant \"continue the last task with the same context.\"\nWhen I typed:\nuse cc to review it too\nI did not mean \"replace the current agent.\" I meant \"spawn a second execution under the same task, with a reviewer role.\"\nThose two messages look similar if all you have is chat history. They are very different if the system has a task model.\nOnce the assistant can distinguish task identity from execution identity, a few things become much easier:\nThat last point surprised me. On mobile, I want a short answer: \"Codex is waiting for approval.\" In the web UI, I may want the full timeline: user message, assistant decision, runtime event, command output, file changes, approval, result.\nSame task. Different presentation.\nIf the user can reasonably ask \"what happened with that thing?\", that thing deserves an identity outside the chat transcript.\nFor my project, that identity became Task\n.\nThe runtime session is still useful. It preserves provider context and lets the agent resume efficiently. But it should not be the thing the product uses to understand the user's work.\nSessions are implementation details. Work is the product surface.\nI am still iterating on the architecture, but the direction already cleaned up several design decisions:\nThis also made failure handling less awkward. If a runtime dies, the assistant does not need to tell the user \"your session is gone, please start over.\" It can start a new runtime under the same execution or create a fresh execution under the same task, depending on what actually failed.\nThat is a small implementation detail with a large UX effect.\nI used to think agent memory meant better summaries of previous messages.\nNow I think the more important question is: what are you summarizing into?\nIf everything collapses back into a conversation, the assistant will eventually lose the shape of the work. If the product has explicit projects, tasks, executions, and runtime sessions, the agent has somewhere stable to put its memory.\nThat has become one of the design principles behind CliGate.\nIf you are building coding agents, how are you modeling the difference between a conversation, a task, and a runtime session?", "url": "https://wpnews.pro/news/my-coding-agent-remembered-sessions-not-work-that-was-the-bug", "canonical_source": "https://dev.to/codekingai/my-coding-agent-remembered-sessions-not-work-that-was-the-bug-1n3e", "published_at": "2026-05-21 03:46:07+00:00", "updated_at": "2026-05-21 04:02:47.467929+00:00", "lang": "en", "topics": ["developer-tools", "artificial-intelligence", "large-language-models", "products", "startups"], "entities": ["CliGate", "Codex", "Claude Code", "Telegram", "Feishu"], "alternates": {"html": "https://wpnews.pro/news/my-coding-agent-remembered-sessions-not-work-that-was-the-bug", "markdown": "https://wpnews.pro/news/my-coding-agent-remembered-sessions-not-work-that-was-the-bug.md", "text": "https://wpnews.pro/news/my-coding-agent-remembered-sessions-not-work-that-was-the-bug.txt", "jsonld": "https://wpnews.pro/news/my-coding-agent-remembered-sessions-not-work-that-was-the-bug.jsonld"}}