cd /news/ai-agents/im-not-a-developer-i-used-ai-to-make… · home › topics › ai-agents › article
[ARTICLE · art-168283] src=dev.to ↗ pub= topic=ai-agents verified=true sentiment=· neutral

I’m not a developer. I used AI to make my small boxing shop easier for agents to read

A non-developer co-owner of Paragon Elite Fight Group, a 24-product boxing and jiu-jitsu shop in Athens, used Claude and Shopify's Sidekick to build agent-facing infrastructure on Cloudflare Workers, including a public did:web identity document, a signed publisher credential with a separate evidence file, a product knowledge graph, an llms.txt file, and a read-only MCP service exposing guide-reference and product-comparison tools. The shop owner stresses that signatures identify who made a claim rather than proving it true, and that the supplementary tools cannot access customer accounts, create orders, or process payments, with Shopify remaining the commerce platform.

by read10 min views3 publishedNov 12, 2026

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.

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.

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.

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.

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.

On 12 November 2026, I added several discovery resources through the existing services:

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.

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. 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.

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 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.

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 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 it rather than weaken protection just to obtain a successful test.

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.

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.

I would welcome feedback from people who build or operate agents:

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.

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.

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](https://paragonelitefight.com/.well-known/did.json).

`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. 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. 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](https://paragonelitefight.com/pages/verification).

`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](https://paragonelitefight.com/__canary/reference).

`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.

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.

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.

The project also includes:

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.

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

── more in #ai-agents 4 stories · sorted by recency
── more on @paragon elite fight group 3 stories trending now
sponsored brought to you by zahid.host 4,200+ EU-deployed projects
reading about agents? ship yours in a single git push.

Run your AI side-project on zahid.host

EU-based hosting, git-push deploys, automatic HTTPS, no cold starts. Free tier with a custom domain — perfect for shipping the agent you just read about.

$git push zahid main
→ Live at https://your-agent.zahid.host ✓
Get free account → Pricing
from €0/mo · no card required
LIVE [news/im-not-a-developer-i…] indexed:0 read:10min 2026-11-12 · —