Brand intelligence for agentic commerce

An authorized voice for your brand.

Trakt shows what AI says about your business, then gives your organization a structured voice: establish its root identity, assign people and agents scoped roles, and publish approved brand terms with a verifiable authority path.

A claim is a statement from your business. Authority is permission to speak or act on its behalf.

INTELLIGENCE TO PUBLISHINGIllustrative workflow

ObserveRecord AI answers and cited sources.
ApproveCheck the business source and approve an exact correction.
PublishMake the approved statement and permission evidence available.
QueryAnother agent or service fetches the record and checks it.

Agentic commerce

Many systems shape one buying answer.

AI shopping brings together brand information, product catalogs, commerce tools, payments and fulfillment. Trakt’s role is to connect brand intelligence with approved statements and evidence another service can check.

Role	Examples	How Trakt fits
AI shopping	ChatGPT, Gemini, Copilot, Perplexity, Amazon Rufus	Consumers can fetch statements and check their evidence independently.
Sources and catalogs	Shopify, Google Merchant Center, Akeneo, Salsify	Source product facts can support a specific approved statement.
Commerce platforms	Salesforce, commercetools, Constructor	Trakt can complement these tools with source and permission evidence.
Checkout and payments	Stripe, PayPal, Coinbase Business	Payment rails are separate from authority to publish merchant terms.
AI visibility	Profound, Scrunch, Peec, BrandCapsule	Answer gaps can guide which correction a business reviews.
Access and payment trust	Cloudflare, Visa, Mastercard	Access or payment trust is separate from claim authority.
Fulfillment	Merchants, warehouses, carriers	Stock and delivery status still come from commerce operations.
Trakt focus	Trakt	Connect AI answer observations with statements consumers can check.

Examples describe roles in the market. They are not Trakt partnerships or available integrations, and functions can overlap.

When agents act for a business

Let buyers know who speaks for the brand.

When an agent can buy or sell, a changed price or unauthorized promise can become a real order. The signed statement and its permission path show whether the business authorized those exact terms.

Some commerce protocols sign buyer payment instructions or agent requests. Trakt’s focus here is the merchant side: a signature ties exact record contents to a signing key, a scoped grant limits what that key may authorize, and a public commitment lets a reader compare a published version and its history while the full terms stay off-chain.

Your organization defines authority

A valid signature can still come from the wrong business.

An impostor can sign “Brand X offers this price” with a key they control. That proves the key signed the words; it does not show Brand X authorized that key.

Trakt structures people and agents under the organization’s enrolled root identity. Each role gets scoped permission to publish or change particular brand terms; consumers can check that path and its time limits.

No path to a recognized root? Treat authority as untrusted or unknown. Do not attribute the claim to the business or act on its behalf.

Brand root identityorganization enrollment binds the rootOrganization rolespeople and agents get scoped permissionsAuthorized publisherpublishes approved termsBusiness statement

Unrelated keyno verified delegation path“Brand X says…”Signature may be valid. Business authority is not established.

Illustrative organization path; team controls vary. A DID string or chain anchor alone does not prove brand ownership, and an authorized publisher can still make a false claim—check the underlying source.

Stop a price swap

Approved: SKU-41 · USD 120.00
Agent receives: SKU-41 · USD 12.00

Check: The received terms do not match the signed record. The agent stops and fetches the approved offer again.

Business consequence: It avoids buying or selling at an altered price.

Reject authority used too broadly

Granted: Agent · change SKU-41 price · until expiry
Attempted: Rewrite manufacturer warranty

Check: The action falls outside the grant, so the authority check rejects it before signing or publication.

Business consequence: A price editor cannot silently change a product promise.

Do not treat old stock as current

Signed demo snapshot: demo-shop-001 · demo-sku-001 · 7 each
Consumer request: 5 each · current status unknown

Check: The signed quantity is a planning candidate only. Current stock has not been established, so the consumer must check live availability.

Business consequence: A past statement is not mistaken for current stock, a reservation, or fulfillment.

Illustrative checks, not live external-agent or payment integrations. A signature identifies which key signed which contents; it does not prove a business fact is true or force another agent to obey.

From an AI answer to an accountable correction.

For example, an AI answer says a manufacturer’s warranty lasts one year. The approved warranty says three. The brand team checks the source, approves an exact correction, then publishes it for another service to query.

The team can compare later answers and evidence of use. The full feedback loop requires a connected consumer; publishing does not make a model use the correction.

FOLLOW THE CORRECTIONExample

Observe an answerKeep the AI response with the sources it cited.
Find the gapCompare its answer with the business source.
Approve a correctionReview the exact statement before it is shared.
Publish for queriesMake the statement and permission evidence available.
Measure laterCompare later answers and evidence of use.

Set who can speak for each part of the brand.

Your organization builds its structure in Trakt. Assign people and agents roles, then scope who may publish or change a price, product detail, warranty or other commercial term.

A delegate may change SKU-41’s price until expiry, but cannot rewrite its warranty. The permission path lets a consumer check whether that exact change speaks for the business.

See what a reader can check

PRICE PERMISSIONExample

Who: A person chosen by the business
Can change: One product’s price
Cannot change: The product’s name
Until: The permission expires

Allowedchange that product’s price
Outside scopechange its name

THREE DIFFERENT STATESNamed checks

AvailableA published proof record can be fetched.
CheckedNamed checks have run on the statement and its authority.
UsedEvidence shows a connected consumer used it in an answer or action.

An agent asks. The record can be checked.

A service can fetch a published record and named check results through the Trakt API. It can also verify the exported evidence itself and compare its fingerprint with a public blockchain receipt.

Trakt’s results report checks Trakt ran; independent checks are separate. Platform acknowledgements and records of model use are a next step.

For agent builders

Statement and evidence: GET /api/public/proofs/{proofID}
Exported proof material: GET /api/public/proofs/{proofID}/export
Named check results: GET /api/public/proofs/{proofID}/verification

A public receipt for an exact version.

For an on-chain publication, a public blockchain holds a short digital fingerprint that covers the exact approved record. The full statement and supporting documents stay off-chain.

A reader can compare the record and its evidence with the public commitment. A changed record has a different fingerprint. A confirmed ledger entry shows the commitment existed by the time it was recorded.

Trakt manages the initial signing keys; the public chain record can still be checked independently. A fingerprint or signature does not prove stock or business facts.

WHY KEEP THE RECEIPTFor each role

MerchantKeep evidence of the terms you approved.
BuyerCheck the version an agent presents.
PartnerCompare a disputed change with the retained record.

A real local test-chain transaction

The chain stores a commitment, not the offer.

This historical Hardhat transaction on chain 31337 called publishOperation(bytes32,bytes32). The operation ID identifies the publication; the root fingerprints a batch of off-chain records that a reader can compare with an inclusion proof. It is local test-chain evidence, not a Base, production, or customer transaction.

Operation ID: 0x1856bdd9c8a6af7a5669232b85ad57fb345ad0590cba5942d6d1d105f0102d11
Committed root: 0xa4241e74ec23ed12ae93c242583c2f2f83374598f78315f8d77653a596e8dc25
Transaction · block: 0x65b190f39548d03c3f139b00023cab85a88c966fd9290cfdc7faa77ae633f9bfBlock 3 · contract 0x5fbdb2315678afecb367f032d93f642f64180aa3

Show exact call data

0x7015906d1856bdd9c8a6af7a5669232b85ad57fb345ad0590cba5942d6d1d105f0102d11a4241e74ec23ed12ae93c242583c2f2f83374598f78315f8d77653a596e8dc25

The full signed record, source documents, signatures and authority path stay off-chain in the export and require separate verification. The publisher allowlist only permits submitting an anchor; it does not grant authority to speak for a business. Anchoring a false or unauthorized record does not make it true or authorized.

Know the answer. Check the source.

Give brand teams a way to investigate AI answers, merchants a way to publish approved terms, and connected services evidence they can check. The demonstration uses sample inventory. Checking a record does not reserve stock or complete a purchase.

Enter the workspace Create account