Check both the service’s capability and the customer’s permission
Some integrations can support buying or booking, but actual capability, eligibility, terms, and user authorization must be checked for the specific service. A system’s ability to take an action and a customer’s permission to take it are separate facts. I would want both established before a commitment. I would also want the result to distinguish a proposal, a submission and a confirmed booking or purchase.
“It includes choices a person makes with help, and choices a person hands off, within limits, to a machine acting on their behalf.”
— Curtiss Witt, The Decision Economy, Chapter 4.
When can an AI integration actually buy or book?
Certain AI integrations can support purchases or bookings, but availability depends on the specific service and conditions. Do not assume that an assistant capable of recommending an offer can also complete the transaction. Check the supported operation and the user’s authority before treating advice as executable action.
OpenAI’s shopping guidance describes checkout for some eligible products and merchants. That is not a claim that every product or service can be purchased through every ChatGPT experience. Verify the current supported route for the intended task rather than generalizing from one documented integration. OpenAI: Shopping with ChatGPT Search; accessed September 2026
Different tasks can involve different requirements, confirmations, and consequences. A request for a booking may remain subject to provider confirmation, while another operation may create a commitment. Read the specific process instead of assuming that all action-capable tools share one transaction model.
A capability called “book” or “buy” still needs documentation explaining inputs, effects, and result states. The caller should know what happens when it succeeds and what conditions remain unresolved. A convenient label does not remove the need to understand the operation before using it.
A supported integration may have eligibility, account, location, or other conditions that need current confirmation. Record the relevant constraints when planning the task. A historical demonstration or announcement should not be treated as proof that the same route is available to this user now.
The comparison below describes two approaches to the work. It is a practical design contrast, not a measured claim that one approach always produces a better commercial outcome.
| Information and activity approach | Decision-support approach |
|---|---|
| Infer permission from a connected account. | Establish the authorized action and constraints. |
| Treat submission as fulfillment. | Report the actual state of the transaction. |
| Retry an uncertain action blindly. | Check the outcome before risking duplication. |
What exactly must the customer authorize?
The user’s request should distinguish researching options from submitting a request or committing to an offer. These are different permissions. A system should not infer the broader action merely because completing it would seem convenient after the research stage has produced a promising option.
Where relevant, state the permitted scope, price limits, timing, and other conditions that determine whether an action is acceptable. The purpose is to avoid having the agent invent the customer’s trade-offs. A constraint should be clear enough that the system can recognize when it needs further instruction.
A confirmation should identify what is being approved, including material terms and unresolved conditions. A generic “yes” without context can leave the scope unclear. Preserve the user’s opportunity to understand the proposed action rather than reducing approval to a ceremonial step in an automated process.
An agent may be signed in or technically able to reach a service without being authorized to perform every available action. The user’s task defines the permitted scope. Account access and tool discovery are enabling conditions, not blanket permission to make commitments on the customer’s behalf.
Specify conditions that require a pause, such as a material difference from the approved terms or uncertainty about the supported operation. The system should return the decision to the user rather than improvise a substitute commitment simply to report that the task is finished.
What should be verified before commitment?
Confirm that the destination and offer match what the customer intended to select. A summarized recommendation can be incomplete or ambiguous. The action should target the verified offer, not merely the first link or similarly named item returned during the research stage.
The conditions used for comparison may differ from those presented when action is possible. Check material terms before proceeding. If they change the basis of approval, obtain the appropriate decision rather than assuming earlier interest authorizes a materially different offer.
An estimated price or availability statement may require confirmation. Label it accurately throughout the task. A system should not transform a preliminary figure into a committed term merely because it is easier to summarize the process as a completed purchase or booking.
Some tasks require information or conditions that were not part of the initial recommendation. Make those gaps explicit. If they cannot be resolved within the authorized scope, the correct result may be an incomplete task with a clear next question rather than a guessed answer.
The action may require specific details, but it does not justify sharing every piece of information available about the customer. Limit disclosure to what the operation needs and consider the destination. The task’s convenience does not remove responsibility for appropriate data handling.
The working rule I return to is this: “It includes choices a person makes with help, and choices a person hands off, within limits, to a machine acting on their behalf.” It is a way to judge the next piece of work, while keeping its evidence and limitations visible.
How should I interpret an action’s result?
An agent can prepare an action without actually sending it to the provider. Report that state clearly. A prepared booking request or purchase plan is useful work, but it should not be described as a completed external action when no such action has occurred.
A provider may receive a request without accepting or fulfilling it. The user needs to know whether the result is pending or confirmed. Preserve the service’s actual state rather than turning every successful submission into a statement that the customer now has the requested outcome.
A confirmed arrangement can still require later delivery or service. Distinguish the transaction state from the eventual experience. This keeps the record useful and avoids treating a successful technical action as proof that every part of the customer’s goal has already been achieved.
If the outcome is uncertain, inspect the service’s state before retrying a consequential operation. Repeating an action blindly can create unintended effects. The response should explain what is known, what is uncertain, and what check is needed rather than assume failure or success without evidence.
The customer should receive a concise account of the action, provider response, material conditions, and any remaining task. Avoid including unnecessary sensitive information. The purpose is to make the result inspectable and allow the person to recognize whether further action is required.
Does the Institute’s assessment buy or book anything?
A tool can be useful without buying or booking anything. Do not judge its value solely by whether it can commit an action. Helping the customer understand options or identify the next check can be the complete intended contribution of the capability.
The Institute’s assessment returns owner-reported readiness information and three starting actions. Its manifest explicitly excludes bookings and payments from assessment invocation. The presence of REST and MCP routes does not expand that operation into a transaction service. Decision Economy Institute: live capability manifest; accessed September 2026
Emailing a completed plan is not part of the assessment’s decision calculation. It requires a separate explicit request through the appropriate path. An agent or user should not infer that assessment completion automatically authorizes email or enrollment in research updates. Decision Economy Institute: live capability manifest; accessed September 2026
A result can identify a need for work without requiring a purchase of assistance. The owner can choose self-help or an appropriate support path. This preserves the tool’s decision-support role and avoids turning every assessment outcome into an implied authorization for commercial engagement.
Before an AI-assisted action, answer both questions separately. The service must support the operation, and the user must authorize it within the relevant conditions. When either is missing, provide the information or next question needed to proceed instead of claiming a capability or permission that is not established.
What can I do with this today?
Start with one offer and write down the next decision this article helps you examine. Give the work a defined scope before adding a new page, tool or integration.
1. Check what will happen before authorizing a transaction.
2. Identify the consequential fact or condition that remains uncertain. Name who can check it and what would establish completion.
3. If you need help ordering the business work, complete the free Decision Economy Readiness Assessment. Read its reasons and three starting actions, then choose the first task you can inspect.
Our own example is deliberately bounded. The Institute’s Method explains the owner-reported result; its capability manifest declares what the tool can do; and its assessment schema makes the question bank and data contract inspectable. These September 2026 publisher documents describe the assessment. They do not independently establish better customer or business outcomes.
Check both the service’s capability and the customer’s permission
Before the next customer faces the same unresolved choice, identify the improvement that would make the answer more useful. Use the readiness assessment to turn your reported conditions into three starting actions, and keep the next evidence check in view.
Disclaimer
Based on your answers, this assessment suggests improvement priorities; it does not independently verify your business or predict AI recommendations, sales, or business quality.
FAQ
What is the scope of shopping documentation?
OpenAI’s shopping guidance describes checkout for some eligible products and merchants. That is not a claim that every product or service can be purchased through every ChatGPT experience. Verify the current supported route for the intended task rather than generalizing from one documented integration.
What makes confirmation meaningful?
A confirmation should identify what is being approved, including material terms and unresolved conditions. A generic “yes” without context can leave the scope unclear. Preserve the user’s opportunity to understand the proposed action rather than reducing approval to a ceremonial step in an automated process.
When should current terms be reviewed?
The conditions used for comparison may differ from those presented when action is possible. Check material terms before proceeding. If they change the basis of approval, obtain the appropriate decision rather than assuming earlier interest authorizes a materially different offer.
What should happen after an uncertain failure?
If the outcome is uncertain, inspect the service’s state before retrying a consequential operation. Repeating an action blindly can create unintended effects. The response should explain what is known, what is uncertain, and what check is needed rather than assume failure or success without evidence.
Must a user accept implementation help?
A result can identify a need for work without requiring a purchase of assistance. The owner can choose self-help or an appropriate support path. This preserves the tool’s decision-support role and avoids turning every assessment outcome into an implied authorization for commercial engagement.
Do I need to share contact details before seeing the assessment result?
No. The complete result is available before an optional email request. If a contact commitment has held you back, try the free readiness assessment and read the plan first. Emailing it and consenting to future updates are separate choices. The result remains BY YOUR ACCOUNT.
References
Curtiss Witt. The Decision Economy, updated author-supplied manuscript, Chapter 4 for the quoted decision rule; the supplied manuscript also grounds the framework. Supplied September 2026; unpublished manuscript, so no public URL is asserted.
OpenAI: Shopping with ChatGPT Search. First-party product guidance, retrieved September 10, 2026. Documents selection context, metadata, review and price limitations, and eligible checkout. Its shopping behavior is not a universal business-recommendation algorithm.
Decision Economy Institute: live capability manifest. Publisher’s capability declaration, accessed September 10, 2026. Describes the available routes and their limits; not an independent test of every operation.
Decision Economy Institute: How this assessment works. Publisher’s own Method; ruleset de-readiness-1.0.0, accessed September 10, 2026. Not an independent outcomes study.
Decision Economy Institute: Assessment schema and question bank. Publisher’s technical contract; accessed September 10, 2026. Data shape and published question bank, not proof of real-world decision quality.
Continue exploring
What changes when AI joins the customer—or is sent ahead?
What permissions and limits should an AI agent have?
Can anyone guarantee that AI will recommend my business?
Tags: AI agent buying and booking; Decision Economy; Decision Economy Institute; Curtiss Witt; customer decisions; decision support; business readiness; DERA; Better Choices; Agent participation.