What Happens When the Traffic Stops Being Human?
From Magento to AI agents: Ievgenii Gryshkun on AI Engine Optimization, agentic commerce, and the future of ecommerce.
For more than a decade, Ievgenii Gryshkun has been working with Magento 2 and Adobe Commerce.
But recently, his focus has shifted from building ecommerce experiences primarily for human shoppers to asking a very different question:
What happens when the buyer is software?
That question led him to build an open-source suite of Magento modules focused on AI Engine Optimization (AEO) and agentic commerce through angeo.dev.
In this Developer Story, Ievgenii explains what changes when AI assistants become an ecommerce discovery and purchasing channel, why traditional ecommerce assumptions begin to break down, what developers are missing about AI-driven commerce, and what the future of the ecommerce developer might look like.
From Magento to AI Agents
You've spent more than 10 years working with Magento 2 / Adobe Commerce. What led you from traditional ecommerce engineering to building tools for AI Engine Optimization and agentic commerce?
It started with a spec, not with a strategy.
About a year ago, OpenAI announced agentic checkout — the idea that an assistant could complete a purchase without the shopper ever landing on the store.
My reaction was the ordinary engineer reaction:
Is this implementable on Magento 2, and what breaks when you try?
So I tried.
The prototype became a module, and the module became a suite.
The reason I kept going is simpler than it sounds. People are already asking assistants what to buy instead of typing keywords into a search box.
If part of the demand now lives there, it is another acquisition channel — and building for channels is what ecommerce developers have always been paid to do.
The difference was that nobody had written down what "being visible" means in this one.
After ten years of Magento work, most of my problems had known shapes: indexers, performance, checkout edge cases, integrations.
This one had no shape.
There was no checklist for "is this store readable by an AI assistant," so I started measuring it myself — first on client stores, then across live Magento stores pulled from a public domain ranking.
That order matters, and it is the part I did not plan.
I started building because there was nothing to measure with. The implementations then gave me something to measure, and the measurements turned out to be more interesting than the modules.
For ten years I built ecommerce systems for humans.
Then I started asking what happens when the buyer is software.
When the Traffic Stops Being Human
You described your story as "what happens when the traffic stops being human." What does that actually mean for an ecommerce developer?
It means the assumptions your storefront rests on stop being safe to rely on.
You build for a visitor who runs your JavaScript, holds a session, accepts cookies, sees your layout, works through a three-step checkout, and can tell from a photo that something is out of stock.
With an agent, you cannot count on any of that.
It works from what you declare, and what you do not declare effectively does not exist.
A traditional crawler sits in between, but the goal is different in a way that matters.
Google indexes you so a person can click through.
An assistant retrieves you so it can answer — sometimes without producing a click at all, and increasingly so it can act.
There are three consequences for a developer:
- Your machine-readable layer becomes a product surface rather than a garnish on one.
- You lose most of your feedback loop: no click, no session, usually no analytics event. So the traffic you are losing is invisible to you.
- Silence is the default failure mode.
Nothing errors. Nothing returns a 500.
The store simply is not in the answer.
Making Stores Readable to AI
What are the biggest problems preventing ecommerce stores from being properly understood by AI systems today?
The failures are boring, which is exactly why they survive.
The most common one is access.
Magento's default robots.txt reflects a crawler world that predates today's AI crawlers: a wildcard User-agent: * group with restrictive Disallow rules.
Any crawler without its own matching user-agent group falls back to that wildcard group and inherits it.
The part almost everyone gets wrong is how the file is actually evaluated.
Per RFC 9309, a crawler first picks the group whose user-agent line matches it most specifically.
The moment you add a named group for GPTBot, the wildcard group stops applying to it entirely, including any Disallow you assumed was still in force.
Within the applicable group, the most specific rule wins, not the first one.
That cuts both ways.
I have found stores that blocked AI crawlers without intending to, and stores that were certain they had blocked them and had not.
The second failure is that structured data is decorative.
Product schema is present, but offers.availability is missing, or price is rendered client-side, or the JSON-LD nodes carry no @id.
So Product, Organization and BreadcrumbList never reference each other and a machine reads three unrelated fragments instead of one entity.
The third is that none of this is tested.
There is a test for checkout and a test for the cart price rule, and no test for whether the store is still legible to a machine after the last deploy.
What the numbers show
The numbers are why I trust this rather than assume it.
I scanned a frame of live Magento stores drawn from the top of a public domain ranking — 462 in July and 762 in August.
About 11% of the frame served an llms.txt.
About 10% published Product JSON-LD.
Across client audits, the average score is roughly 25%, and it does not correlate with SEO maturity, because these signals did not exist when those stores were built.
Of those, 376 were measurable in both scans, a month apart.
94% had changed nothing.
Not one store had added product markup.
The stores that did touch their AI-crawler rules tended to change several at once, which reads like a single deliberate decision rather than gradual drift.
That second scan told me more than the first one did:
This is not a market slowly adopting something. It is a market that has not started.
From Discoverable to Transactable
Your work isn't only about helping AI discover products — it's also about making stores transactable for AI agents. What needs to change technically for an AI agent to actually complete an ecommerce journey?
Discovery is a reading problem.
Transaction is a contract problem, and contracts are much harder.
Three things have to exist.
The store has to declare what it can do somewhere an agent looks — a product feed, or a signed profile at a well-known path, depending on which protocol you are implementing.
It has to expose real operations:
- create cart
- add item
- get shipping methods
- set shipping information
- place order
These operations need server-side guardrails, because you are now taking instructions from software rather than from a form you rendered yourself.
And it has to handle identity and payment without a browser session, which today means either a pay-by-link handoff or a protocol-level payment flow.
I built that path on my demo store as MCP tools and placed real orders through it from an AI assistant.
It works, and it is on video.
Two things surprised me.
The first is how much friction comes from ordinary security defaults.
My own agentic feed endpoint returned 401 to anonymous callers, which is correct for a REST API and fatal for an agent that has no account with you.
The second is more uncomfortable, and I went and measured it rather than leaving it as a feeling.
Being transactable does not make you chosen.
Even with a working connector, a cold request like "find me a grey backpack" often never reaches my store — the assistant answers from its own tooling instead.
So I ran a pre-registered study on it, with the analysis plan sealed and hashed before I saw any data.
Working from a partner's corpus of businesses that ChatGPT, Gemini and Perplexity actually named in buying answers, 458 unique domains went into the analysis.
I asked whether four observable signals — crawler blocking, llms.txt, Product JSON-LD, and offers.availability — separated the businesses named repeatedly from those named exactly once.
None of them did.
One, llms.txt, was actually more common among the businesses named once, in every cut I ran.
I do not have a causal explanation for that, and the obvious reading — that publishing the file hurts you — is not supported by the data.
The scope matters: every business in that sample had already been named at least once, so it says nothing about what gets you into an answer in the first place.
But within its limits it is a null result on my own product category, and I published it as one.
Being reachable is table stakes. Being selected is the unsolved problem, and I do not think anyone has solved it — including me.
AI Engine Optimization vs SEO
How do you see AI Engine Optimization differing from traditional SEO?
Most SEO fundamentals survive.
Crawl access, clean architecture, canonical handling, a valid sitemap, fast and stable responses, accurate product data — a machine needs all of it, sometimes more than a person does, because it has less tolerance for ambiguity.
What changes is the objective.
SEO asks whether a page can earn a position and a click.
AEO asks whether a system can extract, verify and use the right information from that page, sometimes without sending a click at all.
So the unit of optimization moves from the page to the passage and the entity:
Can a machine take a self-contained, correct statement about your product without parsing your whole template?
There are three things I would rethink.
1. Answer-shaped content
Keyword-shaped landing pages matter less than answer-shaped content — the answer in the first paragraph, real specifications, and an FAQ that responds to the question as it is actually asked.
2. Structured data
Structured data stops being an add-on for rich snippets and becomes the primary payload.
3. Measurement
Measurement has to be rebuilt, because rankings and CTR do not describe a channel without clicks.
You end up measuring whether an assistant knows you exist, describes you correctly, and mentions you against your competitors.
The overlap is large enough that I would never tell anyone to drop SEO.
This is a layer on top of a well-built store, not a replacement for one.
Building an Open-Source Solution
You're building an open-source suite of Magento modules around AI Engine Optimization and agentic commerce. What made you choose open source?
Two reasons, one principled and one practical.
The principled one: this is a standards layer.
Crawler policy, llms.txt, JSON-LD, feed formats, protocol profiles — plumbing that makes ecommerce legible to machines.
Plumbing behind a paywall gets adopted slowly and fragments into a dozen incompatible half-implementations.
Everything in the suite is MIT for that reason.
The practical one:
I am one person.
Open source is how a solo developer gets distribution and feedback at a scale that would otherwise need a sales team.
Installs tell me which problems are real.
The first external tester ran my feed module against about 1,900 configurable products and found a bug I would never have reproduced locally, filed it, and I shipped the fix.
That exchange cost nothing and improved the module for everyone.
What I want people to do with it is simple:
Install one command, get an honest score of where their store stands, fix what it finds — and read the code and disagree with me.
Every signal definition is an opinion expressed as a check.
Those should be argued with in public, not accepted because a vendor said so.
That is also why I maintain a public list of AEO-related Magento projects, currently 43 of them, most of which are not mine, and why the research goes out with the sealed plan, the exclusion lists and the per-row data attached.
The Packagist numbers are honest about how this actually goes.
module-llms-txt has passed 3,000 installs, the audit module is in the hundreds, and several modules sit in the low dozens.
Not every package gets meaningful adoption.
With thirteen published, that is a normal open-source outcome, not a failure.
What Developers Are Missing
What do you think ecommerce developers are currently underestimating about the transition from human-driven traffic to AI-driven discovery and purchasing?
Mostly the assumption that this is a marketing problem arriving later.
The first thing underestimated is that the machine-readable layer is a deploy-time regression surface like any other.
A theme change, a cache rule, or a new CDN config can silently strip your JSON-LD or cut off a crawler, and nothing in your pipeline will complain.
I run the audit as a CLI with a --fail-on-severity flag for exactly that reason:
Treat it like phpstan, not like a quarterly report.
The second is that "we allow AI bots" is usually an untested belief.
Group-matching semantics, staging rules left in production, robots.txt served as a static file that bypasses the module you configured — I have found all three on live stores.
The third is treating a signal as a checkbox rather than as communication.
While investigating that study, I fetched every llms.txt file my scanner had flagged and read the first line of each.
71% matched one generated template, differing only in the brand name — 113 files that represent a platform default rather than 113 decisions to describe a catalogue.
The file was present.
It was not saying anything.
A signal that is technically valid and semantically empty is not visibility.
It is compliance.
The fourth, and the one I keep returning to, is that discovery is the easy half.
Everyone is thinking about being found.
Very few are thinking about what happens when something machine-shaped actually tries to buy:
- no session
- no cookie consent
- a price rendered client-side
- an API requiring a token the agent will never have
- a checkout expecting a human to pick a shipping method
That gap is engineering work, and no content team is going to close it.
The Future of Ecommerce
Imagine an ecommerce ecosystem five years from now where AI agents are responsible for a significant part of product discovery and purchasing. What does the role of the developer look like in that world?
The storefront doesn't disappear.
It stops being the only interface.
If a meaningful share of discovery and purchase runs through agents, the store becomes an API with a UI attached rather than a UI with an API attached.
The developer's job shifts toward defining and defending contracts:
- what the store declares it sells
- what it promises about price and availability
- which operations it exposes
- what an agent is allowed to do with them
Three things I expect to become ordinary parts of the role are:
Observability of non-human traffic
Knowing which agents arrived, what they read, and what they concluded, measured at the edge rather than guessed.
Trust and identity
Verifying that a request claiming to be a given agent actually is one, and constraining what it may do.
Correctness
Correctness becomes a first-class concern, because when a machine misquotes your price it does not simply lose a sale.
It makes a promise on your behalf.
What does not go away is the store itself.
Someone still has to model the catalog, get tax and shipping right, and keep the checkout from losing orders.
That work survives the buyer becoming software.
It just acquires a second consumer, far less forgiving than the first.
Building Solo
You're developing angeo.dev and the open-source projects alongside client work. What have you learned about building and maintaining a serious technical project with limited time and resources?
I probably spend 30–40 hours a week on it alongside client work, and the real constraint turned out not to be time but the number of open fronts.
What changed things was learning to say no.
I decided not to build vector or semantic search into the suite, even though it was the obvious "AI" feature to add, because several companies do it better on infrastructure built for it.
I stopped adding modules and moved to stabilizing what exists.
Every feature I don't ship is maintenance I don't owe anyone for the next five years — and with a dozen published packages, maintenance compounds fast.
AI tooling is genuinely part of how I work, and I would rather be specific than mystical about it.
I use it for routine work, for testing a hypothesis quickly before committing to a direction, and for collecting scattered material that I then have to systematize myself.
The systematizing is still the job.
What it buys me is exploring three approaches in an evening instead of one.
The other lesson is that publishing enforces quality.
A package with strangers' production stores behind it gets written differently than a script in a private repo.
Public releases are the deadline mechanism when nobody else sets deadlines for you.
Advice for Developers
For developers who want to work at the intersection of ecommerce and AI, what should they learn or start experimenting with today?
You don't need to become an ML engineer.
You need to understand how your ecommerce system exposes information and capabilities to machines.
You don't need to train models.
Learn how your systems become inputs to models and agents.
Start with primary sources rather than commentary.
Nearly all the real answers sit in specifications you can read in an afternoon:
- RFC 9309 for crawler policy
- schema.org for product data
- the
llms.txt standard
- MCP and the agentic commerce protocols forming around it
Once you have read them, most vendor claims become easy to evaluate.
Then measure something real on a store you already work on.
Check what your robots.txt actually resolves to and which group a named crawler lands in.
Check whether your Product JSON-LD carries availability and price.
Then ask an assistant about that store and see what comes back.
The gap between what you assumed and what you find is the entire lesson.
Then build the smallest possible thing.
A minimal MCP server exposing catalog search over your own store teaches more about agentic commerce in a weekend than months of reading, because you hit the real problems immediately:
- authentication
- rate limiting
- what to expose
- what an agent does with a bad response
And do it in public.
Ship it, write about what broke, let people correct you.
That is how I learned most of this, and the field is new enough that a careful post from a working developer still counts as a contribution.
About Ievgenii Gryshkun
Ievgenii Gryshkun is a Magento 2 / Adobe Commerce engineer with more than 10 years of experience in ecommerce engineering.
He is the creator of angeo.dev, where he is building open-source tools for AI Engine Optimization and agentic commerce, helping ecommerce stores become more readable and actionable for AI systems.
You can explore his work and research at angeo.dev and through his open-source Magento projects.
A Note from CoderLegion
AI-driven ecommerce is still a rapidly developing area, and many of the practices discussed here are emerging rather than settled standards.
Ievgenii's work offers an interesting perspective from the engineering side.
Instead of asking only how ecommerce businesses can market themselves to AI systems, it asks a more fundamental technical question:
Can an AI agent actually understand, trust, and transact with your store?
That may become one of the most important engineering questions in ecommerce over the next few years.
