Two confirmation numbers sit in your inbox. You asked for one room.
Return to the hotel booking from our earlier example. This time, the assistant submitted the request but did not receive a clear response. It tried again. Both requests were accepted. You now have two nonrefundable reservations for the same stay.
The assistant says it is sorry. An apology may be welcome. It does not tell the hotel which reservation to keep.
The immediate task is to establish what happened and see what can be repaired. The larger question is how a service that promised to remove work from your life should behave when its own action creates more of it.
This is where the quality of a personal assistant becomes visible in a different way. The charming part of the relationship has reached a difficult counter. There is a record to find, a consequence to explain and a remedy that may not be available merely because everyone would prefer it.
The record before the explanation
The first useful move is to stop making the situation harder to understand. An assistant should not cancel one of the reservations merely because there are two. It needs to know what each record represents, whether either action is still pending, and what canceling would do. In our example, both were accepted, but the fact that a page failed to respond did not establish that at the moment the assistant retried. The error grew out of treating uncertainty as failure.
Before deciding who should bear the cost, we need to preserve that distinction. The original request concerned one room for specified dates. The approval covered that purchase. The two confirmation records show that the outside system accepted two bookings. These facts belong beside one another. A screenshot of the user’s yes does not, by itself, show authorization for the second reservation.
A chat message can also differ from the action that reached the seller. The assistant may describe a request accurately and then submit it incorrectly. A tool may return an unclear result. A merchant may process a request differently from what was expected. The record should help locate the difference rather than allowing each party to point to a different fragment and declare its own part complete. This requires more than a fluent account of what probably happened. The service should distinguish verified events from its interpretation of them. If it has confirmation numbers and timestamps, it can report them. If it cannot establish whether a payment was collected, it should leave that question open and identify the next appropriate check.
A system should not fill a gap in the evidence with the same confidence that helped create the gap. For the traveler, a compact chronology would be more useful than a long apology: one room requested; one purchase approved; two booking submissions made; two confirmations received. The explanation can then address why there were two submissions. It should not disguise the second attempt as a new user request merely because the assistant was still working toward the same broad goal.
The same discipline applies when the user has made a mistake. Perhaps the instruction actually asked for two rooms. Perhaps the approval clearly showed the wrong date, and the person accepted it. Those facts belong in the record too. Fairness does not require inventing fault in the provider. It requires an account that can withstand inspection whichever way the facts point. The purpose of a record is to make correction possible, not to secure a rhetorical victory.
The FTC’s shopping guidance advises keeping the seller’s identity, the order details, terms, payment records and relevant communications.[1] Assistance can make that practice easier. The service can gather the records needed for the task and put them somewhere the person can retrieve. It should not leave the only useful evidence scattered across a conversation that is difficult to search or export. There is a practical timing issue as well. An uncertain booking needs attention while there may still be a chance to resolve it. A record delivered after the relevant opportunity has passed is less useful, even if it is perfectly accurate. We should judge the evidence system partly by whether it gives people enough time to act.
The traveler does not need every technical event. They need enough to identify the accepted bookings, distinguish the intended purchase from the duplicate, and explain the situation to whoever can address it. The service may need a more detailed internal record to diagnose its own failure. The consumer’s need and the provider’s need overlap without being identical.
A careful design can preserve that difference. It can retain the information needed to establish the action without handing every support agent the whole history of the person’s private conversations. Evidence should be sufficient for its purpose, and access to it should have a purpose too.
Repair belongs to the work
Once the duplicate is established, what can the assistant actually do? It can help locate the relevant policy and the correct support route. With appropriate authority, it may help prepare or send a request explaining the duplicate. It can keep track of what response is received and whether the issue has really been resolved. It should be candid if a step needs the person’s direct involvement.
What it cannot honestly do is promise that the hotel will waive the nonrefundable condition merely because the error is inconvenient.
A request for a remedy and a right to receive that remedy are different. The available outcome depends on the transaction, the applicable terms and law, and the conduct of the parties. This book cannot turn those differences into one rule for every reader. It can insist that the service explain which route it is pursuing and what evidence supports its report.
Suppose the hotel agrees to release one reservation without charge. The assistant should establish which one remains valid and confirm the financial outcome, rather than end the task at the moment someone says they will look into it. If a refund is promised but not yet received, the state is still pending. If the hotel declines, that is a different state again, and the user needs to know what options remain. Words such as requested, accepted and completed carry different amounts of certainty. A reliable assistant should use them carefully.
Repair also has a cost. The traveler may spend time contacting support, forwarding records or waiting for a response. They may have money temporarily unavailable. They may need a backup plan before the original dispute is settled. These burdens can arise even when the final financial outcome is satisfactory.
This matters when providers describe the benefits of delegation. A service that saves twenty minutes when things go well and creates several hours of work when they go wrong should account for both. The consumer experiences the whole distribution of outcomes, not only the successful demonstration.
We do not need a universal numerical threshold to recognize the issue. The relevant frequency and consequences will differ by task. A typo in a private list and a duplicate travel charge should not receive the same treatment simply because both are counted as errors.
A provider should be able to learn from serious failures without requiring every affected person to become a persistent investigator. That is partly a question of support capacity. Can someone examine the records? Can they recognize a recurring problem? Can they correct the system rather than merely issue another reassuring message?
It is also a question of responsibility for the handoffs. The merchant may be the right party to reverse a charge, while the assistant’s provider may be the right party to address the duplicate submission. One practical remedy can require cooperation among parties whose roles differ.
The user should not have to prove that one company controlled everything before any company will help. A sensible first response can begin with what each party is able to establish and repair. The merchant can identify the accepted orders. The payment service can clarify a payment state. The assistant’s operator can inspect how its system acted under the user’s instruction. These capacities should support an investigation rather than become reasons to send the person in a circle.
There will be limits. A provider may not have access to another firm’s records. A support worker may need the user’s authorization to obtain them. Those limits should be explained plainly, with a specific next step. “Contact the other company” is much more useful when accompanied by the correct record and a clear question than when used as a way to end the conversation.
An assistant that has made a mistake should not become mysteriously less capable at the moment the work turns into repair.
That is an earned expectation of the service, not a claim that software can force a remedy. The same tools that help organize a purchase can often help organize the evidence afterward. Where they cannot, the provider should explain what is missing.
A repair process should also avoid creating a second harm. Sending an entire inbox to support in order to document one transaction may disclose unrelated information. Canceling the wrong reservation may leave the traveler with no room. Repeatedly resubmitting a complaint can create confusion instead of urgency. The task needs the same respect for scope that the original booking needed. Good intentions do not enlarge the user’s authorization.
Who had the power to prevent it?
After the urgent problem is addressed, another question remains. What should change so that the next person is less likely to face the same failure?
A useful review starts with control. Who could have prevented the second submission? What information was available? Was there a way to check the first booking’s state? Did the interface make the uncertainty clear? Was the user asked to approve a second purchase, or did the service treat the retry as covered by the first approval? These questions are more precise than asking whether “AI” is responsible. Software does not design its own commercial terms, choose every boundary of its authority or determine what evidence the customer receives. People and institutions make those choices. An account of responsibility should not end by pointing at the most human-sounding part of the product.
Nor should it end automatically at the user. The fact that a person gave an instruction does not tell us which errors they were able to foresee or prevent. The fact that they clicked an approval does not establish that every important consequence was made visible. The person may have contributed to the failure. The provider may have designed the conditions that made that contribution likely. Both deserve examination. We should be especially cautious when a service invites trust through claims of personal understanding, then treats that trust as the user’s mistake after something goes wrong. The invitation and the disclaimer belong in the same account of the relationship.
Legal scholar Jack Balkin’s work on information fiduciaries offers a way to think about that relationship. He argues that trust and vulnerability in dealings with digital services can justify particular duties concerning information. He also distinguishes these proposed duties from the full obligations of traditional professionals such as lawyers and doctors.[2] The concept is useful because it asks what follows from the role a business invites itself to occupy. It does not establish that every assistant currently owes the same legal duties in every jurisdiction. The policy question remains: if a company asks to become a trusted helper, what forms of care and loyalty should accompany the request?
Here is my answer at the level of ordinary service design. The company should avoid using the user’s dependence as a reason to obscure a conflict, withhold useful evidence or make a reasonable complaint impractical. It should take responsibility for the parts of the arrangement it controls. Where several businesses share the work, the user should be able to understand the relevant roles without becoming an expert in their contracts.
This is not a demand for a flawless product. It is a demand for a fair relationship with an imperfect one.
An error can be consistent with a provider having taken reasonable care. A pattern of preventable errors, ignored after clear reports, presents a different question. So does a system that gives users no practical way to discover what happened. The quality of the response matters alongside the original performance.
NIST’s generative-AI risk profile includes attention to oversight, user feedback, recourse and incident response.[3] These are useful categories for evaluating a service after deployment. They do not certify a particular product or settle a legal dispute, but they help move the discussion beyond whether an impressive demonstration succeeded.
A meaningful evaluation should include the difficult cases: interrupted tasks, ambiguous results, changed instructions, attempts to stop work and failures involving more than one service. It should ask whether the customer received accurate status information and whether a problem was contained before it spread.
There is a further point that consumer advice can easily miss. Some defects can only be seen across many users. A person may experience one duplicate booking. The provider may see a pattern connected to a particular response or tool. It has a view the individual lacks, and that view creates a practical responsibility to investigate. Telling each person to be more careful will not fix a repeated fault in the arrangement.
A remedy that leaves the person stronger
A completed remedy can have several parts. The immediate harm may be corrected. The user may receive a clearer account of what happened. A permission may be narrowed or an unreliable route removed. The provider may change how it checks uncertain transactions. These outcomes can make future delegation more dependable.
But a remedy should not require the person to surrender the benefit they sought. If the only response to a duplicate booking is “watch every click from now on,” the service has returned much of its work to the user. It has solved its own problem of responsibility by weakening the promise of assistance.
A better response should identify what can safely remain delegated and what needs to change. For our traveler, that could mean continuing to use research and comparison while withholding booking authority until the failure is understood. It could mean leaving the final purchase to the person. It could mean choosing another service. The decision should follow the seriousness of the problem and the credibility of the response, not embarrassment about having trusted the assistant.
People are allowed to revise trust. The revision need not be absolute. One failure does not tell us that every feature is useless, just as one excellent result does not establish that every future action should be authorized. Trust can be specific to a task, a boundary and a record of performance.
The provider should make that specificity possible. It should let the user narrow a permission without destroying unrelated work. It should make a useful record available if the person decides to leave. It should explain the consequences of that decision without making departure unnecessarily difficult.
This brings us to a broader meaning of repair. The objective is to restore the person’s ability to act, rather than merely close a support ticket.
In the hotel case, the traveler needs one valid reservation, an accurate account of the money and a decision about future use of the assistant. A support system can mark an issue closed while one of those needs remains unresolved. The customer should not have to adopt the company’s definition of completion when their own problem is still open.
The ordinary receipt contains a date, an amount and a seller. A useful record of delegated action needs a little more: what was requested, what was authorized, what actually happened and what remains to be done. That record gives the person something firmer than a memory of a pleasant conversation.
Eventually, the duplicate is resolved, or the available remedy is exhausted and the remaining choices are made clear. The assistant’s apology can then take its proper place. It accompanies an account of events and a response to them.
The person is no longer being asked to trust the tone.
Sources
[1] Federal Trade Commission, “Online Shopping,” May 2023, accessed September 30, 2026, especially “Keep Records” and “Report Problems.” The duplicate booking is a constructed case. No particular refund entitlement or legal deadline is asserted.
[2] Jack M. Balkin, “Information Fiduciaries and the First Amendment,” UC Davis Law Review 49, 1183–1234 (2016), especially Parts V–VI. The discussion uses a scholarly argument about trust, vulnerability and information duties; it does not treat the proposal as a universal statement of current law.
[3] NIST, Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile, AI 600-1, July 26, 2024, GOVERN 3.2 and the incident-response and management sections. This voluntary guidance identifies practices to consider, not an assurance that any named provider has implemented them successfully.