Agents can accelerate customer-facing tasks, but speed is not continuity. The real design challenge is preserving a customer’s intent and definition of success from discovery through renewal.
Imagine a hypothetical software buyer who says during discovery that her main goal is not “better reporting.” It is cutting the time her operations team spends reconciling three systems every Friday. A sales agent records the call, an evaluation agent prepares a comparison, an onboarding agent configures a template, and a support agent later answers questions. Every task is completed quickly. Three months later, nobody can say whether Friday reconciliation became easier. This is the customer lifecycle problem that agents make more important, not less. A lifecycle is often drawn as a sequence of stages: discovery, evaluation, onboarding, adoption, support, renewal, and expansion. But the customer does not experience a sequence of departments. The customer experiences one continuing attempt to make progress. When agents do more of the work, teams can increase the pace of activity without preserving that continuity. The risk is a lifecycle full of efficient moments that do not add up to a successful relationship. The durable object is the customer’s intent Most lifecycle systems are built around events: a meeting happened, a trial started, a ticket closed, a renewal date arrived. Events are easy to count. They are not the same as intent. Intent has at least three parts: the problem the customer is trying to solve, the outcome they would recognize as useful, and the constraints that shape an acceptable solution. In the hypothetical example, the problem is repetitive reconciliation, the desired outcome is a calmer and shorter Friday process, and the constraints might include keeping the existing systems and preserving an approval step. An agent working at any stage should be able to distinguish the current task from that longer thread. “Configure this integration” is a task. “Help the operations team reduce Friday reconciliation without replacing its accounting system” is the reason for the task. Each stage should add context, not restart the story Continuity does not require placing every transcript in one enormous record. It requires carrying forward the small set of facts that changes the next decision. Discovery: What is the customer trying to change, why now, and what language do they use to describe it?Evaluation: Which criteria matter, what remains unproven, and what commitments have been made?Onboarding and adoption: What first useful outcome is expected, who needs to change behavior, and what evidence would show progress?Support: Is this an isolated issue, or is it blocking the outcome that justified the purchase?Renewal and expansion: Did the definition of success hold, and has the customer’s situation created a different job to do? The key is not merely transferring notes. The next stage has to interpret what those notes mean for its work. A support agent might resolve a permissions error correctly, for example, while missing that the error has prevented the customer’s first live workflow for two weeks. The technical answer can be right while the lifecycle response is wrong. Activity is not responsibility Agents are well suited to bounded work: summarizing a conversation, preparing a checklist, identifying an unanswered question, or drafting a follow-up. These actions can remove delay and make customer work more consistent. But sending the follow-up is not the same as making sure the customer reaches the intended outcome. Responsibility means someone can answer: Are we still solving the right problem? What has changed? What is blocking progress? Who has authority to make the next commitment? Some of those answers should remain explicitly human. Commercial exceptions, promises about future capabilities, sensitive escalations, and judgments about a strained relationship carry consequences beyond task completion. An agent can prepare context and options. A named person should own the decision and its communication. The counterargument: standardization can improve the experience There is a reasonable case that agents will make continuity easier. People forget notes, interpret stages differently, and leave companies. A well-designed process can prompt for missing criteria, retain decisions, and keep routine follow-up from slipping. Customers may prefer a fast, accurate answer from an agent to waiting for a person who has context but no time. I agree with that case. The mistake is assuming that consistency of process automatically creates continuity of purpose. A system can apply the same onboarding checklist to every account while steadily drifting away from what each customer needs. It can also preserve an outdated goal long after the customer’s priorities change. Continuity must allow revision, not just retention. The right balance is to let agents maintain the thread while people remain accountable for interpreting consequential changes. The customer should also be able to correct the record. If the stated success criterion no longer fits, the lifecycle should change with it. Start with one handoff...