Conversation is a transport-independent problem. The same intent arrives by phone, in a web widget or in a message thread, and the differences between those are mostly about time and output affordances - not about language. Building four systems because there are four channels is the mistake this area exists to avoid.
Four generations, one trajectory
| Generation | Author writes | System decides |
|---|---|---|
| Decision tree / IVR | Every path and reply | Nothing |
| Intent classifier | A reply per intent | Which intent this is |
| LLM chatbot | Instructions and knowledge | The wording of every reply |
| Agent | Tools, guardrails, goals | Which actions to take, in what order |
Each step bought coverage and cost inspectability. A decision tree can be audited exhaustively; an agent has a combinatorial action space and cannot be exhaustively anything. That trade explains why the engineering emphasis in agent products sits on constraining consequences rather than on improving answers.
Dialogue state
The state that matters is not the transcript. It is the constraint set the conversation has established: what the customer wants, what has been ruled out and why, what has been decided, what is still open. Summarising toward a narrative loses the negatives, which is why an agent twenty turns in will re-offer an option the customer already rejected.
Synchronous and asynchronous are different problems
Phone, web voice and web chat are variations on one problem with different clock speeds. A message thread that resumes after three weeks is a different problem wearing the same clothes: the context may be stale, one message may contain several questions, and there is no interruption - a wrong answer is fully delivered before anyone can react.
The absence of interruption changes the risk profile enough that we treat email as a channel requiring review rather than autonomy. In bitpull.ai, the production system built on this research, it currently appears as summaries and notifications rather than as an agent-operated channel - and we would rather say that than describe a roadmap as a product.
Handover
A handover at the right moment with context attached is the system working, not failing. Two things make it a failure: it happens late, after the customer has asked for a person more than once, or it arrives cold, so the human starts from nothing and the customer explains the problem twice.
That second failure is structural. If the conversation state was never organised for handover - established facts, attempts made, believed goal - it cannot be handed over, whatever the escalation logic does.
Grounding and refusal
The most valuable behaviour a customer-facing agent has is a clean "I do not know that, let me get someone who does". It is also the behaviour most easily eroded by prompt drift in long conversations and by optimisation pressure toward containment metrics - which reward an agent for not escalating, exactly backwards.
Open questions
- What is the right representation of dialogue state such that it survives compaction, channel changes and a three-week gap?
- How do you evaluate refusal quality, given that both over- and under-refusal are failures with no shared unit?
- Can conversation design be expressed as testable artefacts rather than as prose in a prompt?