The Agentic Commerce Protocol, or ACP, gives businesses and AI agents a shared way to coordinate a purchase. It does not make customer authorization, fulfillment, or support someone else’s problem.
That distinction is useful when planning an implementation. Your checkout team needs a compatible commerce flow. Your support team needs the order, the relevant policy, and a way to handle exceptions. eesel CLI helps with the second job by letting people and coding agents operate an eesel support teammate from the terminal.
What is the Agentic Commerce Protocol?
ACP is an open standard developed by Stripe and OpenAI for commerce between buyers, agents, and businesses. It is available under Apache 2.0. Merchants keep responsibility for their customer relationships and order fulfillment.
Instead of making every agent invent its own checkout integration, the specification defines a common approach. Compatible implementations can work with a merchant’s existing commerce backend and payment provider.
Implementing ACP does not automatically list your products in an AI shopping platform. Platform participation has its own requirements. It also does not require every merchant to replace its payment processor with Stripe; compatibility must be checked for the intended integration.
What a purchase flow needs to establish
At a practical level, your implementation should be able to answer:
- Which item and variant is being purchased?
- What are the final price, delivery terms, and available fulfillment options?
- What has the customer authorized?
- Did payment and order creation succeed?
- Which records will a support agent need if something goes wrong?
These are implementation checks, not a claim that a protocol resolves every dispute automatically. A support summary is not proof of consent, and a successful API response is not proof that a parcel arrived.
ACP, AP2, and TACP are separate projects
“Agentic commerce protocol” sometimes gets used as a category label. Here, ACP means the specific Stripe/OpenAI project. Google’s AP2 and Forter’s TACP are not alternative versions of it.
| Project | Main concern | Question for a merchant |
|---|---|---|
| ACP | Coordinating agent-to-business commerce | Can the intended agent use our checkout implementation? |
| AP2 | Evidence of payment authorization | What did the customer authorize, and how is that recorded? |
| TACP | Trusted context for merchant risk decisions | What information accompanies the agent’s request? |
Google’s AP2 announcement describes signed mandates that record a customer’s instructions. It distinguishes a buyer approving a cart in real time from a buyer delegating a task under conditions agreed in advance.
Forter’s TACP proposal focuses on passing trusted context between an agent and a merchant for risk assessment. Read the project’s implementation requirements rather than treating that goal as a guarantee against fraud.
These concerns overlap, but the projects do not have to be understood as a winner-takes-all contest. Evaluate the requirements of the actual shopping channel, processor, and merchant system you intend to use.
What changes for customer support?
An agent-led purchase can introduce a gap between what the customer remembers asking for and what the merchant received. Consider a buyer who says, “I asked for a medium jacket, but this order is a large.”
Your team needs to establish the order’s recorded variant, the applicable exchange policy, and any relevant transaction evidence available to the merchant. It cannot assume access to the buyer’s private conversation with their shopping agent.
Three preparations are useful:
- Keep the order record identifiable. Support needs the order reference and the right customer verification process.
- Make policy answers consistent. Return windows and exceptions should come from approved, current sources.
- Define escalation for missing evidence. A teammate should not invent an authorization history or promise a refund it cannot approve.
This is where a support teammate can help without pretending to be part of the checkout protocol.
Inspect post-purchase support through eesel CLI
The eesel CLI operates the same eesel agent and workspace as the dashboard. It gives a support engineer terminal access to the teammate’s configuration and work. Scripts and coding agents such as Claude Code, Cursor, and Codex can read its JSON output too.
For this article’s example, the goal is specific: check whether the teammate can explain the store’s exchange policy and hand off a disputed purchase appropriately. It is not to build ACP endpoints or validate a payment mandate.
Start with the intended workspace
With Node.js 18.17 or newer, run:
npx @eesel/cli login
npx @eesel/cli whoami
npx @eesel/cli agents
Use the intended teammate’s ID in place of AGENT_ID:
npx @eesel/cli integrations --agent AGENT_ID
npx @eesel/cli instructions --agent AGENT_ID
npx @eesel/cli automations --agent AGENT_ID
These checks establish which systems the teammate can access, what rules it follows, and what starts its work. Review existing enabled automations and permitted actions before adding another connection. Expanded access may become available to work that is already configured.
Check the difference between policy and transaction data
An approved exchange-policy document can be added as knowledge:
npx @eesel/cli files upload ./exchange-policy.pdf --agent AGENT_ID
npx @eesel/cli status --agent AGENT_ID
Replace the example file path with your own document. Uploading knowledge does not change the teammate’s standing instructions or grant permission to refund an order.
Status shows connection and content-download information, not whether an answer is correct. Review the policy version and test the relevant questions separately.
If the store uses Shopify, the Shopify integration distinguishes synced policies and catalog knowledge from live order lookups. Public-storefront crawling alone does not provide private order access; the full connection requires an authorized person’s approval in Shopify admin.
Nor does connecting Shopify import the buyer’s shopping-agent conversation. If a dispute needs evidence outside connected sources, the workflow should ask for it through an appropriate process or escalate.
Test the explanation before enabling order changes
Use a fictional case with no real order identifier first. Review action permissions before using chat, because chat can invoke actions:
npx @eesel/cli new --name "exchange-policy-review" --agent AGENT_ID
npx @eesel/cli chat "Using our approved exchange policy, explain what information a human reviewer needs when a shopper says an agent ordered the wrong size. Do not change orders or send messages." --agent AGENT_ID
The wording states the intended task; it is not a technical barrier against actions. Keep order-changing permissions off or subject to approval while testing.
Check whether the answer cites the available policy, identifies missing information, and avoids asserting what the buyer authorized. A good answer may need a human decision rather than an automatic resolution.
Review what actually happened
npx @eesel/cli activity --agent AGENT_ID
npx @eesel/cli approvals --agent AGENT_ID
Read the activity alongside the support conversation and merchant records. The approvals list shows teammate actions waiting for approval. It does not show customer checkout authorization or AP2 payment mandates.
For scripts, select the agent explicitly and protect EESEL_API_URL and EESEL_API_TOKEN. Use --help for command options. For a write command, --dry-run prints the server request without sending it; it does not simulate a conversation or verify a transaction.
Give a coding agent a bounded inspection task
For example:
Inspect this eesel teammate’s connected sources, instructions, and automations. Check whether its rules explain how to handle a disputed agent-led purchase. Report gaps and ask before editing anything.
JSON output lets the coding agent inspect the setup and report what it finds. The support team can review the same configuration in the dashboard. Asking the coding agent to seek permission is separate from configuring eesel’s held-action approvals.
Prepare checkout and support as separate pieces of work
An ACP implementation can make a checkout accessible to compatible agents. Dependable post-purchase service still requires policy knowledge, order access, action limits, and human escalation.
Start with one dispute scenario and make sure your team can explain what is known, what is missing, and who decides the next step. Do not promise access to information the merchant does not have.
Try eesel and use eesel CLI to inspect that support workflow. Keep checkout integration and payment authorization with the systems responsible for them, while your eesel teammate helps with the support work you have actually connected and permitted.
Frequently asked questions
What is the Agentic Commerce Protocol?
ACP is an open standard developed by Stripe and OpenAI for programmatic commerce between buyers, AI agents, and businesses. It describes how compatible systems coordinate checkout and payment information. It is not a general name for every agent-payment protocol.
Are ACP and Google’s AP2 the same protocol?
No. ACP addresses commerce flows, while AP2 focuses on evidence of a user’s authority to transact through signed mandates. They are separate projects, not versions of a single protocol.
Does implementing ACP automatically list a store in shopping agents?
No. Implementing a checkout standard and being accepted into a shopping platform are different steps. Each platform controls its own merchant participation process.
Where does eesel CLI fit?
eesel CLI lets a person, script, or coding agent operate the same support teammate available in the eesel dashboard. It can inspect connections, knowledge, instructions, automations, and activity. It does not implement ACP checkout or retrieve a buyer’s private shopping conversation automatically.
How should support teams prepare for an agent-led purchase?
Make sure they can identify the order, check the relevant policy, and find the evidence available to the merchant. Use approved sources and a clear escalation process when authorization or payment evidence is missing. Do not infer a buyer’s consent from a support summary.
Can a coding agent use eesel CLI safely?
It can help with a bounded inspection task because commands return JSON. Select the intended agent, protect credentials, and review changes. CLI chat can invoke actions. Telling a coding agent to ask first does not enforce approval; configure eesel’s action-approval settings.
