I’m not a developer. I used AI to make my small boxing shop easier for agents to read
A field report from a 24-product store in Athens: structured data, signed identity, read-only tools, and the limits of building with AI. Originally published on Paragon Elite Fight Group. Disclosure: This article was d
A field report from a 24-product store in Athens: structured data, signed identity, read-only tools, and the limits of building with AI.
Originally published on Paragon Elite Fight Group.
Disclosure: This article was drafted with substantial AI assistance from the author's notes and project records, then reviewed and approved by the author. The author is responsible for the published claims.
I don't write code. Until recently, I could not have explained what a Cloudflare Worker or a decentralized identifier was.
My partner and I run Paragon Elite Fight Group, an online boxing and Brazilian jiu-jitsu equipment shop based in Athens, Greece. At the time of writing, we have 24 active products, a basic Shopify plan, and no paid advertising.
Thinkplus built the original store. The additional agent-facing infrastructure came later, through conversations with Claude and Shopify's Sidekick, repeated corrections, and more troubleshooting than I expected.
This is not a growth case study. I cannot show that a signed credential increased sales or that an AI assistant recommended us because it found a discovery file.
It is a practical account of a smaller question:
When software visits a shop, can it understand what the business sells, distinguish its claims from supporting evidence, and find useful information without guessing?
That seemed like a problem I could work on, even without being a developer.
This account describes the project as of 12 November 2026. Individual endpoints, tests and catalog details can change.
Starting with information, not autonomous checkout
Much of the discussion about shopping agents focuses on transactions: finding products, building carts, and completing purchases.
I started further back.
A shop contains information that is easy for a person to interpret but surprisingly easy for software to misunderstand. Is a sizing table a manufacturer's chart or the retailer's recommendation? Does a displayed price apply to every variant? Does a signature prove a claim, or only identify who signed it?
My aim was to make those distinctions explicit.
Shopify remains the commerce platform. I have not built an alternative checkout or given my supplementary tools permission to access customer accounts, create orders, or process payments.
What I built
The additional infrastructure consists of several separate pieces, mostly served through Cloudflare Workers.
I maintain a technical directory, but the important distinction is between identity, evidence, information and actions.
Identity and publisher-issued claims
A public did:web document exposes the business's identity information and public verification keys.
A publisher-issued credential records business assertions in a signed format. A separate evidence file links to supporting sources.
These are different things. Publishing a signature does not make every statement independently true. A retailer signing its own claim is not the same as a manufacturer endorsing that claim.
The Verification Record attempts to keep those distinctions visible, including the scope and limitations of recorded checks.
Structured information and read-only tools
There is also a product knowledge graph, structured product information, plain-text guidance, and discovery resources pointing software toward the available interfaces.
The supplementary MCP service at https://paragonelitefight.com/api/mcp exposes two read-only tools: guide references and product comparison.
The guide tool returns links, not the contents of the guides. Product descriptions and minimum prices are not a substitute for checking a particular variant's stock, price, fit or eligibility.
Those boundaries matter more to me than the number of endpoints.
Discovery is not adoption
On 12 November 2026, I added several discovery resources through the existing services:
- API Catalog
- MCP Server Card
- Agent Skills Index and its linked guidance skill
- A2A Agent Card
The homepage also advertises the plain-text guidance through a Link response header.
These resources help describe what is available. Their existence does not demonstrate that an external agent has discovered them, used them correctly, or recommended the shop.
What the limited tests established
A limited A2A adapter reuses the existing read-only tools. A guide request returned the expected references, and an invalid guide topic returned a tool-level error. Existing MCP initialization continued to work.
The A2A product-comparison test remains unconfirmed.
This is a structured-command interface, not an unrestricted conversational assistant. I am not presenting it as a fully tested implementation of every part of a protocol.
The dated discovery update records the checks and their limits.
The most useful correction was not technical
One of the clearest lessons came from a small boxing-glove dataset.
The original files contained six recommendation rows for Superare S40 and S50 gloves. They used body-weight and height ranges, grouped into the store's existing men's and women's charts.
The original name included the word “Standard.”
That was too strong.
We had not measured participants or experimentally validated the ranges. General glove-selection advice did not establish that these exact ranges were correct for these models.
The source material also contained inconsistent wording about 14 oz gloves, sparring and hand wraps.
Adding more structured data would have made those inconsistencies easier to distribute. It would not have made them true.
So we revised the content first.
What changed in the dataset
The new version calls itself a sizing guide. It preserves the six recommendation rows but identifies them as publisher guidance, explains that ranges overlap, and states that fit and sparring suitability cannot be determined from nominal glove weight alone.
The CSV and JSON now carry consistent usage notes. A README records provenance, variables and limitations.
The revised dataset is available on our Open Data page, alongside the source sizing guide.
We also published version 2.0.0 on Zenodo, with the persistent identifier 10.5281/zenodo.24159069.
The DOI provides an identifier for citation. It is not peer review or manufacturer certification.
A concrete discovery result, with a limit
A direct Google Dataset Search check on 12 November 2026 found the store's dataset.
At the time of that check, it still displayed the older July title and metadata, not the November revision.
That is a useful observation. It is not evidence of increased traffic or sales, and it does not establish that the new Zenodo record has been indexed.
Where building with AI gets difficult
AI made it possible for me to build things I could not have implemented alone. It also made it possible to create more moving parts than I could comfortably maintain.
A successful request is a narrow result
A successful response from an endpoint does not establish continuous availability, universal crawler access, or resistance to abuse.
During this work, some automated requests returned 403 or 429 responses. In one case, I could open an updated resource in my browser while the assistant's request received a 403.
That difference did not prove a global block, and it did not prove the problem was solved.
An experimental cache-warming project remains disabled after blocked requests. I chose to pause it rather than weaken protection just to obtain a successful test.
Documentation becomes another system to maintain
The same explanation can exist in HTML, Markdown, JSON and plain-text guidance. Updating one does not automatically update the others.
We have added dated updates to those formats, but I would not describe that as a complete audit of every historical statement.
It is easy to make another file. It is harder to keep every copy accurate.
What I would do differently
I would start with fewer components.
I would check source content before making it machine-readable.
I would distinguish “published,” “responded successfully,” “verified,” and “used by someone else” from the beginning.
I would also resist treating a scanner's green result as a business outcome.
The useful question is not how many protocols a small shop can advertise. It is whether each component gives a reader accurate information at a maintenance cost the business can afford.
What I still want to learn
I would welcome feedback from people who build or operate agents:
- Does a publisher-issued identity document help your system in practice? If so, what do you verify?
- What makes a retailer's evidence useful without confusing self-assertion with independent endorsement?
- How should a small shop balance crawler access, protection and operational simplicity?
- Which parts of this stack would you remove?
I am sharing this because small businesses are experimenting with these questions too, often without an engineering team.
AI helped me write the code and this article. I remain responsible for what I publish.
The lesson so far is simple: making information easier to retrieve is worthwhile, but making it accurate comes first.
Technical appendix: the documented stack
This appendix summarizes the store's maintained technical directory. It is a record-based inventory, not a fresh exhaustive listing of the Cloudflare account and not an independent security audit.
The directory contains 16 historical entries covering Workers and supporting components. That does not mean 16 currently active services. One component is retired, another is disabled, and individual tests retain their original dates.
Identity and time-bounded records
paragon-well-known
Publishes identity, publisher-issued credentials and discovery documents.
The directory records reverification of the canonical identity and signed credential on 23 September 2026. That dated result is not continuous verification or independent accreditation.
paragon-heartbeat
Produces short-lived signed publisher records. The directory records a successful public signature check on 1 October 2026.
A heartbeat signature is not a checkout transaction test, an alert service or proof of uninterrupted availability.
Public starting point: identity document.
Discovery, routing and product representations
llm-cache-headers
Coordinates LLMS publications, Verification formats, selected response handling, supplementary advice routing and limited missing-page recovery.
The November discovery updates extend this existing component. Its custom shared HTML cache remains disabled; I do not present it as proof of site-wide acceleration.
robots-txt-injector
Adds discovery references and content preferences to supported robots responses.
Declarations express publisher intent. They do not guarantee that every crawler follows them or indexes the site.
paragon-product-sync
Supports selected product representations in HTML, agent-oriented JSON and Markdown, with related-product and missing-product handling.
Recorded sample checks do not establish complete translated-URL coverage or universally current inventory.
Public starting points: LLMS guidance and AI Agent Gateway.
Supplementary guidance and custom compatibility
paragon-agent
Provides the two supplementary read-only guide/comparison tools. The limited A2A adapter reuses those tools.
MCP behavior and A2A behavior have separate test records. A successful MCP comparison does not establish that the corresponding A2A path has passed.
paragon-ucp-mcp-worker
Retains custom compatibility functions and a catalog backend used by supplementary advice.
It is distinct from native Shopify commerce interfaces. Its existence does not establish complete custom cart or payment support.
paragon-gear-advisor
Provides bounded shopper assistance with store links and a fallback.
Scoped tests observed real AI responses and the shopper panel. Accuracy, quota capacity, device coverage and live stock are not guaranteed.
Public documentation: Technology, Security & Trust.
Cornerman, quotations and OhYeah
paragon-cornerman and the initial OhYeah integration
Connect source snapshots, hashes, approval records and signed quotations with public evidence formats and selected product-page access.
The documented collection contained 20 published records by 15 October 2026: 17 IBJJF quotations and 3 WBC quotations. This is a dated publication count, not a promise that every rule or exception is covered.
The quotations are source material, not product endorsements or competition approvals.
Their application-specific signature format should not be confused with blanket W3C Data Integrity conformance.
The initial published service is not the complete planned Cornerman system. FightPulse, a full public hash-chain log and signed checkpoints, the public .plan diary, Cornerman-specific agent interfaces, broader interoperability, orchestration and full Shopify integration remain unfinished or require further work.
Public documentation: Verification Record.
Retrieval references and dated price records
pef-canary-stamp
Issues ten-minute retrieval references for controlled experiments.
A reference can identify an issuance window. It does not authenticate product facts, verify stock, identify visitors, or prove organic discovery or content reuse.
Public example: retrieval reference endpoint.
paragon-price-history-workerjs v2
Publishes custom-signed snapshots of base catalog variant prices.
The directory records an independently checked snapshot dated 7 October 2026 covering 24 products and 72 variants in EUR.
That snapshot is not a complete 30-day price history, market-specific checkout pricing, immutable archival storage or legal certification. A configured schedule is not evidence that every subsequent run succeeded.
Publication notifications and catalog exports
paragon-doorbell
Supports change detection and attempts publication notifications.
Historical IndexNow attempts returned 429 responses. Cooldown behavior was recorded, but later acceptance was not established by those checks. Notification attempts do not prove indexing.
paragon-openai-feed
Prepares structured catalog and trust exports.
Export preparation does not establish OpenAI acceptance, ingestion or display. Recorded checks also left stock/enrichment questions unresolved.
paragon-google-feed
Supplies supplemental product attributes alongside the primary source.
Historical processing results are recorded in the directory. Processing does not independently authenticate identifiers, guarantee product approval or establish visibility.
Retired and disabled components
paragon-google-indexing
Retired according to removal records dated 7 October 2026. It is included for lifecycle transparency, not counted as an active service.
pef-keeper-v2
A disabled regional cache-warming experiment.
Diagnostic requests encountered rate limits. Successful autonomous warming and a measurable performance benefit have not been established.
I am not attaching a customer-facing speed claim to this experiment.
Supporting publications outside the Worker inventory
The project also includes:
- Product knowledge-graph publications in linked-data formats.
- The versioned boxing-glove sizing dataset.
- Structured organization, product, offer and article information.
- Breadcrumbs, sizing and care resources.
- Product-passport and safety-information fields.
- Browser interaction experiments.
- Short letters to human and machine readers.
These are not all equivalent types of evidence.
A letter is editorial material, not automatically a signed credential. A product-passport component does not prove that every field is populated. Structured data does not independently validate the facts it contains.
This project does not establish universal crawler access, complete protocol conformance, legal compliance or complete store security.
Where to inspect the published documentation
- Technology directory
- Verification Record
- Verification JSON
- Verification Markdown
- AI Agent Gateway
- Open Data
- Versioned dataset on Zenodo
These references are published so that readers can examine the scope of individual claims, not as a substitute for independent review.
Evangelos Papadimas
Co-founder, Paragon Elite Fight Group
Athens, Greece
Originally published by Dev.to AI. Aggregated on AIWithGhost for educational purposes — full credit and traffic to the original publisher.