This week, an Agent technical series on Juejin (掘金, Chinese developer community) walked through a concrete scenario: group-meal customer service shift handover. When the AI took over, it compressed the conversation into a single line — "Group meal order short two servings due to page cache; backend already verified the modification record." Sounds smooth — but three states got rewritten simultaneously: a guess was promoted to a reason; an old report was treated as current fact; and "I'll check" turned into "checked." We think enterprise IT should note this: most Agent projects stall at deployment not because the model lacks capability, but because state management isn't done right.
What this is
The author is writing a series titled "Starting from Tickets, Build an AI Agent." This installment's core idea: split chat information into three categories — reported (what humans reported), hypothesis (unverified assumptions), and todo (claimed ≠ completed). Every entry must carry a "source message ID" and a "parent issue"; conclusions with no source get rejected.
State changes run through SQLite atomic transactions: old items get marked superseded, downstream items that depend on them get marked stale, new items get inserted. Single-write-lock conflicts bounce straight back to the caller — no faking high-concurrency support. Two version numbers are also introduced — topic version (where the original messages were updated) and investigation-view version (how many changes have been confirmed). Operations submitted against an old version get explicitly rejected; old operations cannot overwrite new state.
This design is called the Investigation Board. The core judgment: conversations cannot be compressed into natural-language summaries; traceable structured state must be preserved.
Industry view
Supporters say this hits the most real blocker in Agent deployment. In "shift-based" businesses — customer service, outsourcing, project management — cross-shift state loss is pervasive. Conversations are logged, but traceable state isn't, so when an AI takes over, it can only re-guess from a summary.
There is pushback, though. First, the example classifies only two issue dimensions — "quantity" and "flavor" — a demo-grade simplification; real business issue dimensions often run into the dozens, and manual labeling isn't realistic. Second, the author themselves admits this design is not true Event Sourcing (the pattern of recording every state change) and doesn't solve high concurrency either; enterprises treating it as a silver bullet will be disappointed. The broader skepticism: state management is a necessary condition, not a sufficient one — even if an Agent remembers the facts, if it can't or isn't allowed to use them, business problems remain unsolved. This is also what Gartner and other analysts keep reminding us: the main cause of AI project failure has never been model capability, but governance and value demonstration.
Impact on regular people
For enterprise IT: companies planning to buy or build AI customer service should ask one question at acceptance — "How does state hand over across shifts and across agents?" If the answer is "we have context memory," you can basically conclude they haven't truly deployed yet.
For individual careers: AI won't "replace" operations, customer service, or project management roles in the near term — but it will amplify roles that already have clear handover processes; roles with fuzzy processes will get more chaotic under AI than before.
For the consumer market: consumers won't suddenly feel AI customer service getting better in the near term. Most companies' Agents are still at the "can answer" stage; "can remember accurately" is the entry ticket for the next stage.