{ "version": "2.0", "lastUpdated": "2026-09-24T00:00:00.000Z", "collection": { "name": "Resources", "description": "Guides, templates, and checklists — how to build, ship, and measure for the agent-mediated web. Organized by what you're working on.", "url": "https://www.neuralpartners.ai/resources/", "count": 10 }, "taxonomy": { "types": [ "guide", "template", "checklist", "research-report" ], "categories": [ "websites-agentic-commerce", "neural-intelligence", "neural-core", "neural-labs", "ai-digital-experiences", "growth-marketing", "paid-media", "performance-marketing" ] }, "feeds": { "json": "https://www.neuralpartners.ai/feeds/resources.json", "jsonFull": "https://www.neuralpartners.ai/feeds/resources-full.json", "rss": "https://www.neuralpartners.ai/resources/rss.xml" }, "items": [ { "id": "meet-neural-bot-giving-an-agent-a-body", "slug": "meet-neural-bot-giving-an-agent-a-body", "url": "https://www.neuralpartners.ai/resources/meet-neural-bot-giving-an-agent-a-body/", "title": "Meet Neural Bot: what we learned giving an AI agent a body", "type": "guide", "category": "neural-labs", "excerpt": "Neural Bot is our Reachy Mini robot powered by Claude, ElevenLabs, and local speech-to-text. Here’s what connecting an agent to a camera and motors taught us about AI in the physical world.", "topics": [ "robotics", "physical-ai", "ai-agents", "neural-labs" ], "author": "Neural Partners", "updated": "2026-09-24T00:00:00.000Z", "readingTime": "6 min read", "featured": false, "trending": false, "image": "https://www.neuralpartners.ai/resources/meet-neural-bot-giving-an-agent-a-body/images/hero.webp", "bodyFormat": "markdown", "body": "Neural Bot sits on a desk in our lab. It's a Reachy Mini, the open-source desktop robot from Pollen Robotics, now part of Hugging Face. It has a head that moves on six axes, a body that rotates, two antennas, a wide-angle camera, a microphone array, and a speaker. It has no arms and no legs. It can't pick anything up.\n\nThat's the point. We didn't buy a robot to get into robotics. We bought one to answer a question that matters to everything else we build: what happens when an agent stops living in a browser tab and starts living in a room?\n\nMost of our work is agentic systems that read, decide, and act through software. Neural Bot is the same loop with a physical surface bolted on. The lessons carry straight back to the screen.\n\n
\n \"Neural\n
Neural Bot on the workbench. The cover art is a conceptual illustration, not a photo.
\n
\n\n## Why Reachy Mini\n\nIt's cheap enough to experiment with (the Lite version starts around $299, wireless around $449), open enough to take apart, and small enough to live on a desk. The SDK is Python, there's a simulator for development without the hardware, and it ships with libraries of recorded dances and emotional gestures. We forked the SDK and built our own layer on top.\n\nOpen hardware mattered more than we expected. When something broke, we could read the daemon, the kinematics, and the media pipeline instead of filing a support ticket.\n\n## The loop\n\nEvery interaction runs the same cycle:\n\n1. **Listen.** A microphone records until it hears a second of silence, then a local speech-to-text model transcribes it.\n2. **Look.** The camera grabs a frame, cleaned up for backlighting, and sends it with the words.\n3. **Think.** Claude gets the transcript, the current camera image, recent conversation, and a short list of remembered facts.\n4. **Act.** Claude returns words to speak through ElevenLabs and instructions for the body: an emotion to play while talking, a dance, a song.\n5. **Remember.** In the background, a second pass pulls out anything worth keeping.\n\nNothing about that loop is robot-specific. It's perceive, reason, act, remember. The body just makes every weakness in it impossible to ignore.\n\n## Lesson 1: The body is just another tool surface\n\nThe model never touches a motor. It writes plain text with small tags at the end, like `[EMOTION:curious]` or `[DANCE:side_to_side_sway]`. Our code strips the tags out, speaks the rest, and hands the tag to the motion system.\n\nTwo design choices made this safe and fast.\n\n**Allowlists, not freedom.** The model can only pick from named moves we loaded. If it invents one, nothing happens. For physical actions, that's the right default: the agent chooses from a menu, it doesn't write the recipe.\n\n**Tags over full tool calls.** One pass, no round trip. The model decides what to say and how to move in the same breath, which keeps speech and gesture in sync.\n\nThe same pattern works for any agent that touches the real world, physical or not. Charging a card, sending an email, and nodding a robot head all benefit from a short, validated list of allowed actions.\n\n## Lesson 2: Latency is the whole experience\n\nIn a chat window, three seconds feels fine. Standing in front of a robot, three seconds of silence feels broken.\n\nSo we budgeted every step. A small local speech-to-text model. Responses capped at one or two sentences because they’re spoken aloud. Raw audio from ElevenLabs text-to-speech to skip decoding. Camera frames sent for the current turn only, never stored in history, so context stays lean.\n\nThe best trick wasn't technical. While the model thinks, Neural Bot tilts its head up and to the side with a bouncy, cartoonish motion. People read it as \"it's thinking\" and wait patiently. A physical cue buys time that a spinner never could.\n\nNext on the list: streaming the response sentence by sentence into speech so it starts talking before it's finished thinking.\n\n## Lesson 3: The real world is mostly noise\n\nConversation is turn-based. The world isn't.\n\nA lot of the engineering is deciding what not to react to. When music is playing, the bar for \"that was speech\" goes up. If a recording runs 15 seconds without a pause, it's a song, not a person, so we drop it. Music pauses only after we've confirmed real speech, and resumes afterward.\n\nWhen known-face photos are configured, presence detection runs on its own thread, checking a couple of times per second for a face. If it recognizes someone walking up, Neural Bot greets them, then waits a full minute before it’ll greet again. Without that cooldown, it’d say hi every time you leaned out of frame.\n\nSoftware agents face the same problem with inboxes, webhooks, and event streams. Filtering is the job.\n\n## Lesson 4: Memory changes the relationship\n\nAfter each exchange, a background pass extracts concrete facts: names, preferences, running jokes. Neural Bot keeps a small, capped list and skips duplicates. Those facts quietly shape how it talks next time.\n\nThe difference is immediate. A robot that remembers your name and what you asked for yesterday feels like a presence. One that doesn't feels like a demo.\n\nIt also raises the stakes, which brings us to the next one.\n\n## Lesson 5: Privacy gets physical\n\nA camera and memory in a shared space are not just product features. They are privacy decisions.\n\nThe current setup recognizes faces only when photos have been configured for known people; it has no enrollment or consent flow of its own. Camera frames go to Claude for the current turn but aren’t kept in conversation history. Speech is transcribed locally, while the transcript goes to Claude and response text goes to ElevenLabs. Remembered facts live in a small local file that the operator can inspect or delete. Those boundaries matter, but they don’t make this an offline or private-by-default robot.\n\nAny agent that watches and remembers, in a store, an office, or a home, needs the same thinking before launch, not after.\n\n## Why the brain is in the cloud\n\nNeural Bot uses a local speech-to-text model to turn microphone audio into words. Claude handles the reasoning and the current camera image; ElevenLabs turns its reply into speech. That split let us build the interaction loop without running the reasoning model on the robot.\n\nIt also sets real limits. Each turn needs network calls, so latency matters. The current camera frame and the transcript leave the machine for Claude, and the reply text goes to ElevenLabs. Local transcription does not mean the whole conversation stays in the room. We design around those boundaries rather than claiming an on-device brain we do not run.\n\n## What we're watching\n\nThe part we find most interesting isn't the code. It's how people change around it.\n\nDo people talk to Neural Bot differently than they talk to a chat box? Do they forgive mistakes more when there's a face attached? Does the room itself change when something in it is paying attention? We don't have clean answers yet. We have a robot on a desk and a growing list of observations.\n\nFor the businesses we work with, especially experience-driven retail, that question isn't abstract. Agents are about to show up in showrooms, kiosks, and counters, not just websites. How people respond to an AI with presence is worth understanding before it's standard.\n\n## What's next\n\n- **Turn toward the speaker.** The mic array can estimate direction of sound. It should look at whoever's talking.\n- **Real-time gaze.** Feed face position into head control so it tracks you as you move.\n- **React to touch.** An accelerometer can tell when it's picked up or bumped.\n- **Stream everything.** Sub-two-second response time is the target.\n\n## Try it yourself\n\nIf you want to run the same experiment:\n\n1. Start in the Reachy Mini simulator. You can build the whole loop before the hardware arrives.\n2. Get the listen, think, speak cycle working with no movement at all.\n3. Add one physical action from an allowlist. A nod is plenty.\n4. Measure time from end of speech to first sound. Fix that before adding features.\n5. Decide what the robot remembers, and who can see it, before you turn memory on.\n\nNeural Bot says hi." }, { "id": "agent-payment-rails-explained", "slug": "agent-payment-rails-explained", "url": "https://www.neuralpartners.ai/resources/agent-payment-rails-explained/", "title": "Agent payment rails, explained", "type": "guide", "category": "websites-agentic-commerce", "excerpt": "Before an AI agent can spend money for a customer, someone has to prove it's allowed to. How AP2, Visa TAP, Mastercard Agent Pay, and x402 answer that — and what merchants actually need to do.", "topics": [ "agentic-commerce", "payments", "protocols" ], "author": "Neural Partners", "updated": "2026-09-18T00:00:00.000Z", "readingTime": "8 min read", "featured": false, "trending": false, "image": "https://www.neuralpartners.ai/resources/agent-payment-rails-explained/images/hero.webp", "bodyFormat": "markdown", "body": "Last verified: 9 August 2026\n\n## The question nobody had to answer before\n\nCard networks are built on a chain of accountability. A cardholder authorizes a purchase. A merchant presents evidence of that authorization. A network arbitrates when the two disagree. Every fraud rule, chargeback right, and liability shift in the system assumes a human made a decision at a knowable moment.\n\nAn agent breaks that assumption. When an assistant buys a lamp, who authorized it? The customer authorized _something_ — but what, exactly, and how far does it extend? Did they approve this specific purchase, or a budget, or a category? If it goes wrong, who eats it?\n\nThat's the problem this entire layer exists to solve. It's not really a payments problem. It's an evidence problem — proving, after the fact and to a skeptical party, that an agent acted within authority a human actually granted.\n\nEverything below is a different answer to that question. This guide is the settlement half of the story; the discovery-and-cart half lives in [Agentic commerce protocols, explained](/resources/agentic-commerce-protocols-explained/).\n\n## What changed in 2026: a neutral venue appeared\n\nFor most of 2025, every major player had its own approach. Google had one. Visa had one. Mastercard had one. OpenAI and Stripe had one. Each was credible, and none of them interoperated.\n\n**On 28 April 2026, Google donated the Agent Payments Protocol to the FIDO Alliance.** That's the single most consequential thing that happened in this layer, and it happened quietly.\n\nFIDO immediately stood up two technical working groups:\n\n- **Agentic Authentication**, chaired by CVS Health, Google, and OpenAI, with vice-chairs from Amazon, Google, and Okta.\n- **Payments**, chaired by **Mastercard and Visa**.\n\nThe card networks now co-chair the payments group. OpenAI chairs the authentication group. Mastercard contributed its Verifiable Intent work into the same venue. FIDO — the organization that standardized passkeys and spent a decade making authentication work across companies that compete — became the neutral ground.\n\nIf you were waiting for the agentic payments space to stop being a land grab before you invested, that's the signal. It happened in April.\n\n## The pieces\n\n### AP2 — Agent Payments Protocol\n\nGoogle announced AP2 in September 2025 and donated it to FIDO in April 2026. Currently at v0.2, Apache 2.0, with 60+ supporting organizations.\n\nAP2 is built as an extension of A2A, the agent-to-agent communication standard, which means it inherits A2A's identity and messaging model rather than inventing one. It integrates with UCP for commerce flows and supports x402 as an alternative settlement path.\n\nIts core idea is the **mandate** — a cryptographically verifiable record of what a human actually authorized, which the agent carries and the merchant can check. Not \"trust me, the user said yes,\" but a signed artifact that survives a dispute.\n\n### Visa Trusted Agent Protocol (TAP)\n\nIntroduced 14 October 2025. Built on **HTTP Message Signatures (RFC 9421)** and aligned with **Web Bot Auth**, developed in collaboration with Cloudflare.\n\nTAP uses three signatures that answer three different questions:\n\n- **Agent Recognition** — is this a known, registered agent, or an anonymous bot?\n- **Consumer Identity** — is there a real, identifiable customer behind it?\n- **Payment Container** — is the payment instrument valid and authorized for this use?\n\nLaunch partners included Adyen, Ant International, Checkout.com, Coinbase, Cybersource, Elavon, Fiserv, Microsoft, Nuvei, Shopify, Stripe, and Worldpay. Closed-beta pilots ran through late 2025 in the US, with APAC and Europe following, and a live deployment in the UAE.\n\nOne thing to be careful about: **Visa has not donated TAP to a standards body.** It's published on GitHub and Visa's developer platform, and Visa co-chairs the FIDO Payments working group — but TAP itself remains Visa's. Anyone telling you otherwise is guessing.\n\n### Mastercard Agent Pay\n\nUnveiled in **April 2025** — earlier than most coverage suggests. It became usable on OpenAI's ACP in late September 2025, starting with Citi and US Bank cardholders, then broadening. Latin America and the Caribbean followed in December 2025.\n\nIn **June 2026** Mastercard launched **Agent Pay for Machines**, aimed at a different problem: very high-frequency, low-value transactions between machines. Multi-rail — cards, bank accounts, stablecoins — with 30+ partners including Adyen, Ant International, Checkout.com, Cloudflare, Coinbase, Global Payments, Stripe, and Tempo.\n\n### x402 and the machine-payments category\n\nCoinbase originally contributed x402, a protocol that revives HTTP's long-dormant `402 Payment Required` status code for machine-to-machine payment.\n\nOn **14 July 2026 the x402 Foundation launched under the Linux Foundation** with forty member organizations. The premier members are the tell: Adyen, AWS, American Express, Circle, Cloudflare, Coinbase, Fiserv, Google, Mastercard, Monad Foundation, MoonPay, Ripple, Shopify, Solana Foundation, Stellar Development Foundation, Stripe, and Visa.\n\nSeparately, Stripe and Tempo shipped the **Machine Payments Protocol (MPP)** in March 2026. Stripe supports both MPP and x402 through PaymentIntents.\n\nThis is a genuinely distinct category from consumer agentic commerce. It's about agents paying for API calls, compute, inference, and data — thousands of tiny transactions where card rails don't economically work. If your business sells anything an agent might consume programmatically, this layer matters to you sooner than the shopping one does.\n\n### EMVCo\n\nWorth knowing what _hasn't_ happened. EMVCo — which owns EMV 3-D Secure, payment tokenization, and Secure Remote Commerce — has published **no agentic specification.** Its stated 2026 plan is to evolve the existing specs to support card-based agentic payments, with a Digital Payment Credentials schema as a priority.\n\nThat's meaningful because EMVCo is where card-based standards eventually become mandatory rather than optional. Nothing there yet means the current landscape is still voluntary.\n\n## How to think about the layers\n\nThese aren't competing for the same slot. Stacked, they look like this:\n\n- **Identity and intent** — who is the agent, and what did the human actually authorize? _AP2 mandates, Visa TAP's three signatures, Mastercard Verifiable Intent, FIDO's working groups._\n- **Instrument** — what payment method, tokenized how, with what liability terms? _Mastercard Agent Pay, Visa's payment container, existing network tokenization._\n- **Settlement** — how does value actually move? _Card rails for consumer purchases. x402 and MPP for machine-to-machine._\n\nA complete consumer transaction touches all three. A machine-to-machine API payment might skip the middle entirely.\n\n## What merchants actually need to do\n\n**Almost nothing, urgently — and that's the point.** Most of this layer is being built to work without merchants re-platforming. Visa TAP rides on HTTP signatures your infrastructure already speaks. Mastercard Agent Pay works through existing acquirer relationships. AP2 hands off to payment methods you already accept.\n\nThe real work is in three places:\n\n**Decide your agent policy before someone decides it for you.** Do you accept agent-initiated orders? All of them, or only from recognized agents with verified consumer identity? What's your position when an agent-originated order goes into dispute? These are answerable now, and the answers get harder once volume arrives.\n\n**Ask your payment provider what they support.** Adyen, Stripe, Checkout.com, Worldpay, Fiserv, and Global Payments all appear across the partner lists above. Your provider probably has an agentic roadmap. Most merchants haven't asked.\n\n**Watch the fraud and dispute picture, not the protocol picture.** The protocols will settle. What won't settle quickly is how liability allocates when an agent buys the wrong thing, or the right thing at the wrong time, or something the customer says they never approved. That's where the cost lands, and it's under-discussed relative to the technical layer. It's also why we treat verification and trust as its own layer of the stack rather than a checkout detail.\n\n## What we're watching\n\n**Whether FIDO holds.** A neutral venue only works if the participants keep using it. Visa keeping TAP proprietary while co-chairing the FIDO payments group is a thing to watch, not a criticism.\n\n**Whether EMVCo moves.** When card-based agentic payments get an EMVCo specification, the voluntary phase ends and the compliance phase starts. Nothing published yet.\n\n**Whether machine payments outgrow consumer payments.** The x402 Foundation's member list is more impressive than anything on the consumer side. Agents buying compute and data may end up the larger volume story, and it's getting a fraction of the attention.\n\n**Whether anyone solves evidence.** There are early efforts at standardizing tamper-evident audit trails across an agentic transaction — discovery through fulfillment. None are mature. But when an agent-originated dispute reaches a real arbitration process, evidence is what the argument will be about.\n\n## Common questions\n\nHow does a merchant know an AI agent is allowed to spend?\n\nThat is the question the whole layer exists to answer, and it splits into three parts. Identity and intent — who is the agent and what did the human actually authorize — is handled by AP2 mandates, Visa TAP’s three signatures, and Mastercard Verifiable Intent. Instrument — what payment method, tokenized how, with what liability terms — is handled by Mastercard Agent Pay and existing network tokenization. Settlement is card rails for consumer purchases and x402 or MPP for machine-to-machine. A complete consumer transaction touches all three.\n\nWhat do merchants actually need to do right now?\n\nAlmost nothing urgently, and that is the point — most of this layer is being built to work without merchants re-platforming. Visa TAP rides on HTTP signatures your infrastructure already speaks, Mastercard Agent Pay works through existing acquirer relationships, and AP2 hands off to payment methods you already accept. The real work is deciding your agent policy before someone decides it for you, asking your payment provider what they support, and watching the fraud and dispute picture rather than the protocol picture.\n\nIs Visa TAP an open standard?\n\nNo. Visa has not donated TAP to a standards body. It is published on GitHub and Visa’s developer platform, and Visa co-chairs the FIDO Payments working group, but TAP itself remains Visa’s. Anyone telling you otherwise is guessing.\n\nWhat is x402 and does it apply to my business?\n\nx402 revives HTTP’s long-dormant 402 Payment Required status code for machine-to-machine payment. The x402 Foundation launched under the Linux Foundation on 14 July 2026 with forty member organizations. It is a genuinely distinct category from consumer agentic commerce — it is about agents paying for API calls, compute, inference, and data. If your business sells anything an agent might consume programmatically, this layer matters to you sooner than the shopping one does.\n\nHas EMVCo published an agentic payments specification?\n\nNot yet, and that is worth knowing. EMVCo — which owns EMV 3-D Secure, payment tokenization, and Secure Remote Commerce — has published no agentic specification. Its stated 2026 plan is to evolve the existing specs for card-based agentic payments. That matters because EMVCo is where card-based standards eventually become mandatory rather than optional, so nothing there yet means the current landscape is still voluntary.\n\n## Sources\n\n[Google donates AP2 to the FIDO Alliance](https://blog.google/products-and-platforms/platforms/google-pay/agent-payments-protocol-fido-alliance/) · [FIDO Alliance: standards for trusted AI agent interactions](https://fidoalliance.org/fido-alliance-to-develop-standards-for-trusted-ai-agent-interactions/) · [ap2-protocol.org](https://ap2-protocol.org/) · [Visa introduces the Trusted Agent Protocol](https://usa.visa.com/about-visa/newsroom/press-releases.releaseId.21716.html) · [Visa TAP specifications](https://developer.visa.com/capabilities/trusted-agent-protocol/trusted-agent-protocol-specifications) · [Mastercard unveils Agent Pay](https://www.mastercard.com/us/en/news-and-trends/press/2025/april/mastercard-unveils-agent-pay-pioneering-agentic-payments-technology-to-power-commerce-in-the-age-of-ai.html) · [Mastercard Agent Pay for Machines](https://investor.mastercard.com/investor-news/investor-news-details/2026/Mastercard-Launches-Agent-Pay-for-Machines-to-Unlock-Super-Fast-Always-On-Payments/default.aspx) · [Linux Foundation launches the x402 Foundation](https://www.linuxfoundation.org/press/linux-foundation-announces-operational-launch-of-x402-foundation-to-standardize-internet-native-payments-for-ai-agents-and-applications) · [Stripe: Machine Payments Protocol](https://stripe.com/blog/machine-payments-protocol) · [EMVCo on agentic payments](https://www.emvco.com/knowledge-hub/enabling-seamless-and-secure-payments-in-2026/)\n\n### Need an agent policy before the volume arrives?\n\nDeciding which agents you accept, and what evidence you keep when one buys, is a business decision with a technical implementation — it lands in the same place as the rest of [your agentic commerce surface](/ecommerce/agentic-commerce/). We help merchants make both halves deliberately.\n\n[Talk to us](/contact-us/) [More resources](/resources/)" }, { "id": "agentic-readiness-index-home-services", "slug": "agentic-readiness-index-home-services", "url": "https://www.neuralpartners.ai/resources/agentic-readiness-index-home-services/", "title": "The Agentic Readiness Index: Home Services Edition", "type": "research-report", "category": "ai-digital-experiences", "excerpt": "We scanned 623 plumbing, HVAC and electrical contractors three times over. One in three is reachable only by phone as far as an AI agent is concerned, and not one has built an agent interface.", "topics": [ "agentic-commerce", "ai-strategy" ], "author": "Neural Partners", "updated": "2026-08-14T00:00:00.000Z", "readingTime": "11 min read", "featured": false, "trending": true, "image": "https://www.neuralpartners.ai/resources/agentic-readiness-index-home-services/images/hero.webp", "bodyFormat": "markdown", "body": "An AI agent can read almost every home services website in America. It can tell you what the company does, where it works, and roughly what it charges. What it cannot do — for one contractor in three — is book them.\n\nWe scanned **623 US home services contractors** — plumbing, HVAC, electrical, mechanical and multi-trade — on 14 August 2026, checking whether an AI agent can read a site, understand what it offers, and act on it. Every company was scanned **three separate times**, and a site is only recorded as unreadable if it failed in at least two of those three passes. That gate matters more than it sounds; the section on what we got wrong explains why.\n\n> Before you read this\n> \n> Neural Partners sells websites and agent-readiness work to home services businesses, and this data comes from a free readiness scan we offer as part of that business. The sample is our own first-party contact list for this industry — not a neutral census or a stratified sample (full caveats in the Methodology section below). An earlier cut of this study reached different conclusions; we found the defect ourselves, re-ran everything, and the section “What we got wrong” below lists what we retracted and why. Weigh the source before the rest of the report.\n\n## Executive summary\n\nFour numbers carry the story:\n\n33%\n\n**Phone-only to an agent.** No form, no followable booking link — just a phone number, which an AI agent cannot dial.\n\n16%\n\n**A booking button that cannot be pressed.** An agent can see it and cannot use it, because it is a JavaScript modal rather than a link.\n\n1%\n\n**Publish a machine-readable booking action.** Five sites out of 545. This is the number that decides whether an agent can hire you.\n\n100%\n\n**Zero agentic protocols.** Every scored company. Not a low score — a flat zero, across the entire cohort.\n\n**Readability is not the problem here.** 89% of these sites can be read by an agent and discovery averages 82 out of 100. By the usual measures this industry looks fine.\n\nIt is not fine, because reading is not the job. A home services business exists to be booked, and when an agent finishes reading a contractor’s site there is almost nothing it can act on: no machine-readable way to book, and in a third of cases no contact route at all except a telephone number.\n\n> The one-line version\n> \n> **The industry spent a decade optimising its booking path for a human with a mouse.** That is precisely the layer an agent cannot traverse.\n\n## The shape of the industry: states, not one score\n\nA company an agent cannot see is not a low score — it is a different state, and averaging the two together hides the thing you want to know. _\\[Denominator: all 623 companies\\]_\n\nState\n\nn\n\nShare\n\nWhat it means\n\nReadable, and scored\n\n**556**\n\n**89%**\n\nAn agent can read the site\n\nAgent-blind\n\n58\n\n9%\n\nReturns nothing an agent can use\n\nUnreachable\n\n7\n\n1%\n\nNo response across three passes\n\nOpted out via robots.txt\n\n2\n\n0.3%\n\nDeclined deliberately, the polite way\n\nAmong the 556 scored, the average is **60**, the median 63, the range 20–76. **Not one company in this cohort scored above 80.** The agent-blind causes split three ways: an empty page shell (31), an active bot wall (24), and a JavaScript-only shell (3). Only two companies opted out deliberately through robots.txt. Invisibility in this industry is overwhelmingly unintentional.\n\n## Five findings\n\n### Finding 1 — Readable, and completely unable to transact\n\n_\\[Denominator: 556 scored\\]_ All four agentic protocols we check for — the standards that would let an agent negotiate directly with a business’s systems — return **exactly 0%**. Not a low number. Zero, across every company an agent could read.\n\nProtocol\n\nWhat it would let an agent do\n\nAdoption\n\nUniversal Commerce Protocol (UCP)\n\nComplete a transaction\n\n**0%**\n\nModel Context Protocol (MCP)\n\nCall your systems as tools\n\n**0%**\n\nWebMCP\n\nUse tools the page hands it in-browser\n\n**0%**\n\nAgent2Agent (A2A)\n\nNegotiate with your agent directly\n\n**0%**\n\nThis one is as solid as anything in the study: the readable subset _grew by 45 companies_ when we re-ran it, and the number did not move a point. [The agentic protocol landscape](/resources/agentic-protocol-landscape/) explains what each standard does and which are worth building on today.\n\n### Finding 2 — The booking button is right there, and an agent cannot press it\n\n_\\[Denominator: 545 sites the booking overlay could probe\\]_ **This is the report.** Of the sites an agent can read:\n\nCan an agent book you?\n\nn\n\nShare\n\nHas some booking affordance\n\n235\n\n43%\n\n…that an agent can actually follow (a real URL)\n\n185\n\n34%\n\n…that is JavaScript-only (a modal, not a link)\n\n86\n\n**16%**\n\n**Phone-only to an agent** — no form, no followable booking\n\n**179**\n\n**33%**\n\nZero forms in the server HTML\n\n289\n\n53%\n\nPublishes a machine-readable booking action\n\n**5**\n\n**1%**\n\nOne in three home services businesses is reachable only by telephone as far as an AI agent is concerned. Another one in six has built a booking button that an agent can see on the page and cannot use, because pressing it runs JavaScript rather than following a link.\n\nForms do not rescue it. We found 423 forms across the cohort, and only **189 of them (45%)** carry enough labelling for an agent to know what to type. Spot-checking the largest operators showed why the raw count flatters the picture: at one national brand, the only two forms on the homepage are the site search box. At another, a newsletter field and a zip-code field. A third serves 224KB of HTML containing no structured data, no forms and no links at all.\n\n> Why we trust this one most\n> \n> Every figure in this table moved by a point or two between our first cut and our re-run — while the denominator _grew by 38 sites_. A number that stays put when its sample changes underneath it is measuring something real. The findings we retracted did not behave that way.\n\n### Finding 3 — Private equity buys legibility. It does not buy readiness.\n\nWe expected consolidation to make no difference. It makes a large one, on every dimension except the one that matters.\n\nOwnership\n\nCompanies\n\nInvisible\n\nProbed\n\nBookability\n\nLocalBusiness schema\n\nFollowable booking\n\nPlatform / PE-backed\n\n194\n\n**2%**\n\n187\n\n**41**\n\n**62%**\n\n**45%**\n\nIndependent\n\n429\n\n14%\n\n358\n\n31\n\n42%\n\n28%\n\nBacked operators are **seven times less likely to be invisible** to an agent, and materially more legible on every other measure. The reason is unglamorous: they buy a field-service management suite, and that suite ships structured data and a booking URL. Inherited, not built.\n\nBut the ceiling is identical. Both groups sit at **0% on all four agentic protocols**. Capital bought a better website. It did not buy anyone an agent interface, because nobody is selling one yet.\n\n### Finding 4 — Electricians are the least agent-ready trade, at the worst possible moment\n\n_\\[Denominator: 545 probed\\]_\n\nTrade\n\nProbed\n\nBookability\n\nFollowable booking\n\nPhone-only\n\nHVAC\n\n104\n\n41\n\n46%\n\n35%\n\nMulti-trade\n\n100\n\n38\n\n37%\n\n29%\n\nMechanical\n\n135\n\n37\n\n39%\n\n30%\n\nPlumbing\n\n90\n\n34\n\n34%\n\n29%\n\n**Electrical**\n\n**116**\n\n**22**\n\n**14%**\n\n**41%**\n\nAn electrical contractor is **less than half as likely** to have a booking endpoint an agent can follow as any other trade — 14% against 34–46% — and the most likely to be reachable only by phone.\n\nThe timing is unfortunate. The trade facing the largest incoming demand shock — EV chargers, panel upgrades, heat-pump electrification, all of it researched online before anyone picks up a phone — is the least prepared to be found and booked by the software doing the researching.\n\n_An earlier cut of this study made the same claim using invisibility rather than bookability. That version was wrong, and we explain why below. This one rests on the booking data, which is measured only on sites an agent could read and was unaffected by the defect._\n\n### Finding 5 — Scale helps, and then it stops\n\nRead the sample sizes on this one before the percentages.\n\nTier\n\nCompanies\n\nInvisible\n\nScored\n\nAvg score\n\nBookability\n\nLocalBusiness schema\n\nEnterprise / national platform\n\n**21**\n\n0%\n\n21\n\n60\n\n**18**\n\n**10%**\n\nMulti-location group\n\n245\n\n4%\n\n234\n\n**63**\n\n**42**\n\n65%\n\nIndependent\n\n357\n\n15%\n\n301\n\n58\n\n29\n\n39%\n\nMulti-location groups are the sweet spot — big enough to buy good tooling, small enough to still look like a local business to a machine. The national brands have the worst bookability in the entire study and publish `LocalBusiness` structured data on 10% of sites; they publish `Organization` instead, which is correct for a franchisor and useless to an agent asked to find a plumber in Burlington tonight.\n\n_The enterprise tier is n=21 — the smallest cell in the study. Treat it as a hypothesis worth testing, not a finding._\n\n## Two industries, two different ways to be invisible\n\nWe ran the same three-pass test over our July lighting cohort, so these two figures were produced by identical logic and can be read side by side.\n\nLighting (July, re-tested)\n\nHome services (August)\n\nCompanies\n\n219\n\n623\n\nReadable by an agent\n\n149 (68%)\n\n**556 (89%)**\n\nInvisible to agents\n\n**70 (32%)**\n\n65 (10%)\n\nDominant cause of blindness\n\nBot wall (53)\n\nEmpty page (31)\n\nA lighting company that an agent cannot see has usually _decided_ that — 53 of its 64 agent-blind sites sit behind a captcha or challenge page that refuses automated clients by design. A home services company that an agent cannot see is usually just misconfigured: a page shell that renders nothing without JavaScript.\n\nThat difference matters more than the gap between 32% and 10%. Lighting has a door with a lock on it. Home services has an open door and nothing behind it. The second is easier to fix and, on the evidence in this report, much less likely to be fixed on purpose.\n\n_We are comparing observability only. The two volumes’ 0–100 scores were produced by different versions of the scoring code and are not comparable; presenting a movement between them would imply an industry change we cannot evidence._\n\n## What we got wrong\n\nWe published research limitations as a matter of course. This time there is something larger to report: our first cut of this study was wrong in three specific ways, we caught it before publication, and we re-ran the entire cohort.\n\n**The defect.** Our scanner treated any failed request as a permanent verdict. If a single fetch failed for any reason — a momentary network blip, a slow DNS response — the company was recorded as unreachable, with no second attempt. Run hundreds of scans concurrently and a certain number of transient failures are guaranteed. Every one of them became a finding.\n\n**How we found it.** Re-scanning a sample by hand, sites recorded as dead answered immediately with full pages. One company returned two different verdicts minutes apart. That is not a site changing; that is a measurement that does not hold still.\n\n**The fix.** Every company in this report was scanned three separate times, spaced apart. A company is only recorded as unreadable if it failed in at least two of the three. **34 companies (5.5%) changed state between runs** — so any single pass, including our first one, was going to be wrong somewhere.\n\nThree claims from the earlier cut are withdrawn:\n\n- **“17% of the industry is invisible to agents.”** The real figure is **10%**. The earlier number counted first-attempt failures as fact.\n- **“One website vendor blocks agents on every site it builds.”** Verified over three spaced rounds, it is 3 of 12 — a normal rate, not a policy. The original figure came from a single request racing another. _We had this in a draft of this report. It was wrong, and it would have been unfair to a named vendor._\n- **“Your website vendor determines whether you are visible to AI.”** This held strongly in our July lighting study. In home services the spread across vendor types collapsed to 2–7%, resting on four invisible sites out of 55 — too thin to carry a finding. **Ownership separates this industry, not vendor** (Finding 3).\n\nOne more, in our favour and equally worth stating: we had reported that 3.9% of these businesses publish DNS in a way that made them look offline. On re-check, **zero** of the 623 do. That claim came from the same class of error, in our own DNS code, and we withdraw it too.\n\n## Methodology & what this data can — and can’t — support\n\n- **Sample frame.** 623 real companies drawn from Neural Partners’ own first-party contact list for this industry — our prospect list, not a neutral census or a stratified sample. Every figure describes this cohort, not a certified industry rate.\n- **Reproduction gate.** Three spaced passes per company; a non-readable state is only recorded when it reproduces in at least two of three. Hard blocks — sites that serve a browser and refuse an agent — were verified across three rounds with both user agents, sequentially. **16 companies (2.6%)** do this consistently.\n- **Denominators.** Four populations appear here and mixing them would flatter the numbers, so every table states which it uses. _Companies_ is all 623. _Scored_ is the 556 an agent could read. _Probed_ is the 545 the booking overlay could assess. Vendor analysis uses the 487 companies whose website vendor we could identify.\n- **Why we don’t lead with our own Completion score.** Our standard scan produces a Completion score alongside Discovery. In this industry it does not tell you much: two of its inputs pass on almost every site (99% and 97%), one measures product data that a service business structurally does not have, and the agentic-protocol inputs are at zero across the entire cohort. A score where nearly everyone lands in the same place cannot rank anyone. So for home services we report **bookability**, which does separate the field. If you run our free scan you will still see a Completion score; treat it as a checklist, not a ranking.\n- **Small subgroups.** The enterprise tier is n=21 and the vendor-type breakdown rests on as few as four invisible sites in a bucket. Both are reported with their sample size attached and neither carries a headline.\n- **No per-vendor rates.** We measured hard-blocking by vendor. No individual vendor’s sample is large enough to publish a rate against, so we publish the 2.6% cohort figure and nothing more granular.\n- **Anonymised by design.** No company and no vendor is named anywhere in this report. The patterns are the point; naming individual businesses that did not choose their situation is not.\n- **What we compare across volumes, and what we don’t.** Our July lighting volume has now been re-scanned under this same three-pass gate, so the two volumes’ _observability_ figures — whether an agent can see a site — are measured identically and are comparable. Their _0–100 scores_ are not: the scanner’s scoring code changed between the two runs, so any movement would mix instrument change with real change. We compare the first and not the second.\n- **Point-in-time.** Scanned 14 August 2026. Bot-facing behaviour changes. Read a snapshot as a photo, not a trend.\n\n## What this means for you\n\nIf you run a home services business, three things follow directly from this data:\n\n- **Give an agent a URL it can follow.** The single highest-leverage change in this entire report is turning a JavaScript booking modal into something with a real link behind it. 16% of this industry is one attribute away from being bookable by an agent.\n- **Check which state you are in.** Readable, agent-blind and unreachable are three different problems with three different fixes. If you are agent-blind, it is almost certainly a platform default you did not choose, and it is usually fixable without touching your website.\n- **Nobody has done the deliberate work yet.** Zero percent, across 623 companies, on every agentic protocol. That is not a gap you are behind on — it is one nobody has closed. The window where this is a differentiator rather than table stakes is open right now.\n\n> As disclosed at the start of this report\n> \n> Neural Partners builds websites and agent-readiness infrastructure for home services businesses, and offers the free scan this data comes from. Full methodology and sample caveats are in the Methodology section above.\n\n**Want your own score?** Run the free [Agentic Readiness Check](/#readiness) to see exactly where your site lands — it is the same scan behind this report.\n\n## What to read next\n\nThis report measures the gap. These cover what closes it:\n\n- [The agentic protocol landscape](/resources/agentic-protocol-landscape/) — every standard on one page, with a plain verdict on whether it is safe to build on. Re-verified quarterly.\n- [MCP, A2A, and the agent interoperability stack](/resources/mcp-a2a-agent-interoperability/) — the protocols sitting at 0% in this study, and what implementing them actually involves.\n- [The Agentic Readiness Index: Lighting Industry Edition](/resources/agentic-readiness-index-lighting-industry/) — our July volume, covering a different industry. Re-tested in August under the same three-pass gate described above — its findings held.\n- [AI marketing for home services](/industries/home-services/) — what we build for contractors, including the booking layer this report says almost nobody has.\n\n### Want to be the first bookable contractor in your market?\n\nZero percent of 623 contractors have done deliberate agent-interoperability work, and 16% are a single attribute away from a booking link an agent could follow. Being early here is cheap and it does not stay available.\n\n[Talk to us](/contact-us/) [More resources](/resources/)" }, { "id": "agentic-readiness-index-lighting-industry", "slug": "agentic-readiness-index-lighting-industry", "url": "https://www.neuralpartners.ai/resources/agentic-readiness-index-lighting-industry/", "title": "The Agentic Readiness Index: Lighting Industry Edition", "type": "research-report", "category": "ai-digital-experiences", "excerpt": "We scanned 219 lighting companies for whether AI agents can find, read, and buy from them. A third are invisible to agents entirely — and almost no one built their readiness on purpose. Re-tested in August 2026 under a stricter reproduction standard; the findings hold.", "topics": [ "agentic-commerce", "ai-strategy" ], "author": "Neural Partners", "updated": "2026-08-14T00:00:00.000Z", "readingTime": "12 min read", "featured": true, "trending": true, "image": "https://www.neuralpartners.ai/resources/agentic-readiness-index-lighting-industry/images/hero.webp", "bodyFormat": "markdown", "body": "> Update — 14 August 2026: we re-tested this report’s own numbers\n> \n> While producing Volume 2 of this index, our web team found a defect in the scanner that produced this report. Any network error — a timeout, a momentary DNS failure, a dropped connection — was recorded as a permanent verdict of “unreachable,” with no retry. Run against hundreds of sites at once, a blip lasting a second could be filed as a dead website.\n> \n> That is a real flaw in an instrument whose entire job is to classify what an AI agent can and cannot see. So rather than quietly patch it, we re-ran this report against itself: **all 219 companies, three separate passes, spaced apart**, under a stricter rule than the one we published under. A company is now only counted as invisible if that result **reproduces on at least two of three attempts**. A single bad result is no longer allowed to become a finding.\n\n## The findings hold\n\nAs published (July)\n\nRe-tested (August)\n\nReadable by an agent\n\n144 (66%)\n\n149 (68%)\n\nAgent-blind\n\n60 (27%)\n\n64 (29%)\n\nUnreachable\n\n15 (7%)\n\n**6 (3%)**\n\n**Invisible to AI agents**\n\n**75 (34%)**\n\n**70 (32%)**\n\n**One number was wrong.** We reported that 7% of the industry was simply unreachable. It is 3%. Those companies were not offline; our scanner had a bad moment and recorded them as dead.\n\n**The headline is unchanged.** Roughly a third of the lighting industry is invisible to AI agents, and the composition of that third barely moved. Only 7 companies out of 219 — 3% — landed in a different state on different attempts.\n\n### Why it held\n\nBecause in lighting, invisibility is mostly _deliberate_. **53 of the 64 agent-blind companies sit behind a bot wall** — a captcha or challenge page that refuses automated clients by design. A deterministic block returns the same refusal every time you ask. It reproduces, because someone configured it to.\n\nThat is the difference between a finding and an artifact, and it is why this report survived a test it could have failed. The flaky bucket — sites that time out sometimes — was always the small one here. It got smaller. The wall was always the story, and the wall is still there.\n\nWe can say that because we ran the same test on [Volume 2, the home services edition](/resources/agentic-readiness-index-home-services/), and **that** report did not hold as well: its invisibility figure fell from 17% to 10% under the identical protocol, because its non-readable sites were dominated by transient failures rather than deliberate walls. Same instrument, same correction, two different verdicts. That is what a real methodology check looks like.\n\n### What we are _not_ restating\n\n**The 0–100 readiness scores.** The scanner’s scoring code changed between the July run and this one, so the two sets of scores are not comparable and it would be misleading to present a movement as though the industry had changed. Everything above concerns **observability** — whether an agent can see a site at all — which is measured by logic that did not change. The scores as published stand as a point-in-time measurement taken with the July instrument.\n\n### What changes going forward\n\nEvery volume of this index, including this one retroactively, now runs under the reproduction gate: **three passes, and no negative finding survives unless it reproduces at least twice.** We think that should be table stakes for anyone publishing measurements of the open web. We are also shipping a retry-with-backoff fix to the scanner itself, including the free readiness check on this site.\n\n_If you scanned your own site here before 14 August 2026 and were told it was unreachable, it is worth running again._\n\nAI agents are starting to browse, compare, and buy on behalf of people — not someday, now. Mainstream browsers now ship agentic-browsing audits, and checkout protocols built for AI agents are already live inside mainstream ecommerce platforms. The question for any consumer-facing business isn’t “should we care about this?” anymore. It’s “can an agent actually use our site today?”\n\nWe ran that question against a real cohort: 219 lighting companies — 147 independent showrooms and 72 brands — using a scanner that checks whether an AI agent can read a site, find what it sells, and complete a purchase. This is what that cohort looks like — not a certified claim about the entire industry. Read the note below before the findings.\n\n> Before you read this\n> \n> Neural Partners builds and migrates websites for lighting companies, and this data comes from a free readiness scan we offer as part of that business. The sample is our own first-party contact list for this industry — not a neutral census or a stratified sample (full caveats in the Methodology section below). We are publishing the findings that cut against platforms we compete with alongside the ones that do not, because we think that is more useful to you than a comfortable summary — but weigh the source before the rest of the report.\n\n## Executive summary\n\nFour numbers carry the story:\n\n27%\n\n**Invisible to agents.** These companies return nothing an AI agent can read — most sit behind an active bot wall.\n\n57/100\n\n**Average score** among the companies agents can actually see. Mid, not hopeless.\n\n74%\n\n**Zero way to transact.** No commerce or interoperability protocol of any kind.\n\n100%\n\n**Inherited, not built.** Every agent-buyable company got there via its platform, not its own work.\n\nThis isn’t one score. It’s two groups. Roughly a third of the companies we scanned can’t be read by an agent at all — usually because their website platform blocks automated visitors before an agent ever gets a look. The other two-thirds average a respectable 57, but that readiness is almost entirely inherited: every top-scoring company we found runs the same class of modern commerce platform, and every company capable of completing an agent-driven purchase got there by default, not by design. (This describes our scanned cohort, not a certified industry census — see the disclosure above and the Methodology section below.)\n\nNobody in this cohort has done intentional agent-interoperability work — the technical layer that would let an agent negotiate directly with a company’s own systems sits at zero across the board. The category is wide open. **Agent-readiness in this industry, today, is rented, not built.** Whoever helps a company own it — or unknowingly locks it into a platform that caps it — sets that company’s ceiling.\n\n## The shape of the industry: three segments, not one score\n\nThe single biggest correction we made before publishing this report: a company that’s invisible to AI agents isn’t a low score. It’s a different state entirely, and folding it into an average distorts everything downstream. Separate it out, and the real shape of the industry appears.\n\nSegment\n\nn\n\nScored (agents can read it)\n\nAgent-blind\n\nUnreachable\n\nInvisible share\n\nShowrooms\n\n147\n\n89\n\n49\n\n9\n\n39%\n\nBrands / OEM\n\n72\n\n55\n\n11\n\n6\n\n24%\n\n**Combined**\n\n219\n\n144\n\n60\n\n15\n\n34%\n\nOf the 60 agent-blind companies, 46 are actively walling out automated visitors with a bot-detection page — the kind that serves a CAPTCHA instead of content — 11 return no meaningful content without JavaScript, and 3 serve an empty page shell. Not one of the 219 companies opted out deliberately through the standard, polite mechanism (robots.txt). This invisibility is unintentional. That’s exactly the point.\n\n> The segment finding, corrected\n> \n> Showrooms and brands score almost identically once you isolate the companies agents can actually see — **58 versus 57**. The real difference isn’t the quality of the work; it’s that **39% of showrooms are invisible to agents versus 24% of brands**, and the large majority of bot walls in this cohort sit on showroom sites. Showrooms aren’t building worse websites — they’re more likely to be running on platforms that wall out automated visitors by default.\n\n## Five findings\n\nThe publishable core of this study — five findings, each anonymized at the platform-tier level, each carrying its sample size, each checked against raw per-check evidence.\n\n### Finding 1 — More than a quarter of the industry is invisible to AI agents, and it’s inherited, not chosen\n\n60 of 219 companies (27%) return nothing an agent can read — 34% counting domains that were unreachable outright. The dominant cause isn’t neglect. It’s active bot walls (46 companies) that the business itself almost certainly doesn’t know it has. And invisibility tracks the website platform, sharply:\n\nPlatform tier\n\nn\n\nShare invisible to agents\n\nGeneral modern commerce platforms\n\n83\n\n4%\n\nCustom-built sites\n\n17\n\n24%\n\nUnknown / no detected platform\n\n49\n\n45%\n\nVertical-specific industry platforms\n\n70\n\n66%\n\n_On a general modern commerce platform, roughly 1 company in 25 is invisible to agents. On a vertical, industry-specific platform, it’s 2 in 3. Custom-built (n=17) and unknown-platform (n=49) tiers are modest samples — read their percentages as directional, not precise._\n\n### Finding 2 — Of the companies agents can read, nearly three in four expose zero way to transact\n\n106 of 144 scored companies pass none of the four completion protocols we checked for. And the split by platform tier is stark: zero-completion runs 52% on general modern commerce platforms — and 100% on every other tier. Not one custom-built, unknown-platform, or vertical-platform site in our scored set can complete an agent-driven transaction.\n\n### Finding 3 — The industry can be found, but not bought from\n\nDiscovery — whether an agent can locate and read a company — averages 70 out of 100. Completion — whether an agent can act on what it found — averages just 39. 27% of scored companies sit in what we call the “found but not buyable” quadrant: an agent can locate them, read them, summarize them, and then hits a dead end at the exact moment intent becomes a transaction. The loss concentrates precisely where it’s most expensive.\n\n### Finding 4 — Every agent-buyable company got there by accident\n\n38 companies (26% of scored) publish a commerce profile that lets an agent complete a purchase (the protocol is called UCP) — the only agent-commerce protocol with real adoption in this cohort. Every single one of those 38 runs a general modern commerce platform whose vendor ships that capability by default. The profiles are real and functional — most are payment-capable — but none were built by the company itself.\n\nWorth being precise about what this does and doesn’t prove: since UCP is the only completion protocol we found in the wild, and one platform ships it automatically, “100% inherited” partly reflects that construction — it’s close to true by definition, not just by observation. What it does show cleanly: no company in this cohort has done intentional agent-interoperability work. The deeper layer that would let an agent negotiate directly with a company’s own systems (A2A) sits at 0 of 144, and a browser-native equivalent (WebMCP) shows up exactly once, unverified. The leaders lead because of a platform choice, not because they built something the others didn’t.\n\n### Finding 5 — The gap between mid-pack and leader is a weekend of work, not a rebuild\n\n18 scored companies (13%) already clear 80 out of 100 — proof the ceiling is reachable with tooling that exists today. What separates the middle of the pack from them is mostly missing signals of intent, not missing infrastructure: 67% of scored companies have no llms.txt file, 49% lack basic meta and social tags, 47% have no structured data markup, and 31% fail all three at once.\n\nThese are files and markup, not replatforming projects — which is also why “wait and see” is the most expensive strategy on the table. The fixes are cheap for you, and just as cheap for whoever competes with you.\n\n## The good news: where the industry already wins\n\nThe same data, read as opportunity. Nothing here is spin — each point is the honest upside of a verified number.\n\n### Discovery is mostly a solved problem\n\nScored companies average 70/100 on Discovery. 98% permit AI crawlers, 100% serve identical content to bots and browsers, and 70% have a working sitemap. If a site is observable at all, agents can probably find and read it today.\n\n### The leaders are ordinary businesses\n\nThe 18 companies that scored 80+ are lamp stores and fixture brands — not technology companies. All of them run detected, mainstream commerce platforms whose vendor ships agent-readiness by default. The ceiling is commercially available right now, to anyone.\n\n### The biggest fixes are the cheapest\n\nThe most common failures — no llms.txt (67%), missing meta tags (49%), no structured data (47%) — are files and markup, not infrastructure. A focused week of work can move a mid-pack company into the top quartile.\n\n### Nobody has won yet\n\nIntentional agent-interoperability adoption sits at 0% across the cohort. Every company reading this is, at worst, one platform decision and one sprint behind the leader — and at best, first.\n\n### What the industry is already doing right\n\nMost of what this study measures pays off today, for humans, regardless of when agents arrive in force. Read through that lens, the scored companies are quietly better than the readiness framing alone suggests:\n\nHuman-web fundamental\n\nShare of scored companies\n\nOpen to crawlers, no cloaking (trust basics)\n\n98–100%\n\nAccessible, usable forms (assistive tech works)\n\n68%\n\n3 of 4 human-web fundamentals present (a11y, meta, structured data, sitemap)\n\n51%\n\nSEO-ready today (structured data + meta together)\n\n36%\n\nPerfect Discovery score\n\n17%\n\n> The underdog finding\n> \n> Independent showrooms out-fundamental the national brands. Showrooms beat brands on accessibility (72% vs. 62%), match them on overall score (58 vs. 57), and hold the majority of the top-quartile spots. Where their sites are observable at all, small lighting retailers are punching at — and above — national-brand level. The industry’s problem isn’t craft. It’s that a third of that craft sits behind platforms agents simply can’t see.\n\n### The ladder: where agent-readiness fits, and what comes first\n\nAgent-readiness isn’t a separate discipline that arrives someday. It’s the top rungs of a ladder this industry is already climbing — and every rung pays for itself before the next one matters.\n\nRung\n\nWhat it means\n\nPays off today via\n\nCohort today\n\n**1 · Work for humans**\n\nAccessible markup, labeled forms, stable layout\n\nConversion, usability, accessibility exposure\n\nForms 98% · a11y 68%\n\n**2 · Be findable**\n\nSitemap, meta / social tags, structured data\n\nSearch rankings and rich results, social sharing\n\nSitemap 70% · meta 51% · structured data 53%\n\n**3 · Be machine-readable**\n\nllms.txt, machine-readable product data\n\nAI search citations, arriving now\n\nllms.txt 33%\n\n**4 · Be transactable**\n\nCommerce & interoperability protocols — agents can act and buy\n\nAgentic commerce, the frontier\n\n26% commerce profile · 0% deep interoperability\n\nThe cohort’s shape: solid on rung one, halfway up rung two, a cliff at rungs three and four. That’s the honest pitch to a company that isn’t ready to think about “agentic strategy” yet — climb the next rung. It pays for itself now, and it happens to be the same ladder.\n\n## The hard truths\n\nThe same data, read without comfort. This is what makes the optimistic view credible.\n\n- **Dozens of businesses are unknowingly paying a vendor to make them invisible.** Bot walls aren’t a decision a company makes — they ship with the platform. Most affected businesses have no idea an AI agent, or the crawler behind any AI search index, sees a CAPTCHA page where their storefront should be.\n- **The vertical-platform trap is structural.** A company on a vertical, industry-specific platform can’t fix its agent-readiness with effort alone: two-thirds invisibility and total zero-completion are properties of the platform, not the tenant. The honest advice to those companies is to migrate or push their vendor — the data doesn’t support a third option.\n- **Readiness in this industry is dangerously concentrated.** Nearly all of the agent-readiness we found — the top scorers, every agent-buyable profile, most machine-readable product data — traces back to one commerce-platform ecosystem. This industry hasn’t broadly adopted agentic commerce; one vendor shipped it to a large share of its customers at once. That’s a finding and a fragility: readiness this concentrated is one platform decision away from disappearing.\n- **This section and the one before it point the same direction, on purpose.** Both halves of this report — the optimistic read and this one — end up supporting the same conclusion: the ceiling is reachable and undefended. That’s not neutral academic framing so much as this cohort’s actual shape, but you should know both sections are built toward that conclusion rather than presented as detached analysis.\n- **Completion is worse than the 39 average suggests.** Two of its inputs — agent-fillable forms and followable actions, both around 98% — are saturated and no longer discriminate well; they quietly inflate the blended score. Strip them out and the real “can an agent act here” picture, running through commerce and interoperability protocols alone, is bleaker.\n- **Agent traffic is arriving before the industry is ready.** Mainstream browsers now ship agentic-browsing audits; agentic checkout protocols are already live in mainstream commerce platforms. The gap this report measures is being monetized right now by whoever is ready — and more than a quarter of this industry isn’t even visible for the race.\n\n## Methodology & what this data can — and can’t — support\n\nWe believe in publishing limitations alongside findings. Here is what this study supports, and where it should be read with care.\n\n- **Sample frame.** 219 real companies drawn from Neural Partners’ own first-party contact list for this industry — our prospect list, not a neutral census or a stratified industry sample. Every figure in this report describes this specific cohort, not a certified industry rate. We plan to sample from a neutral frame (an industry association directory, for example) for future editions.\n- **Scanner design.** A robots-honoring scanner made roughly a dozen read-only requests per company. We rechecked every aggregate in this report against the underlying per-check evidence before publishing, to catch aggregation errors — that is an internal QA pass, not third-party verification, and we are naming it as such rather than letting the phrase imply more than it does.\n- **Saturated signals.** Two of the Completion inputs (agent-fillable forms, followable actions) sit near 98% and no longer discriminate well; they mechanically inflate the blended Completion average of 39. We have not recomputed Completion with these signals removed — that recomputation would produce a stronger, more honest number, and we are flagging it as unfinished rather than letting 39 quietly stand in for it. Treat 39 as a soft upper bound on transactability, not a precise estimate.\n- **Small subgroups.** Several platform-tier breakdowns (Finding 1) rest on samples as small as n=17. We report them because the pattern is large and consistent, but treat the exact percentages in these cells as directional, not precise.\n- **Platform-dependent checks.** Our machine-readable product-data check can currently only find product pages on platforms that expose them in a standard way. Its 57% pass rate describes “of the stores we could sample,” never the industry as a whole.\n- **Static proxies.** Our accessibility and layout-stability checks are static heuristics aligned with — but not identical to — tools like Chrome Lighthouse. We label them as estimates, not lab results.\n- **Low-confidence result.** Our single WebMCP detection (roughly 1% of the cohort) is unverified and low-confidence. We treat it as effectively zero until independently confirmed.\n- **Point-in-time.** This is a single-day scan. A company’s bot-facing behavior can and does change day to day — we recommend reading any one snapshot as a photo, not a trend, and we plan to re-scan quarterly.\n- **Survivorship note.** Our 100% “no cloaking” pass rate, by definition, excludes the companies most likely to treat automated visitors differently — the ones we couldn’t observe at all.\n\n## What this means for you\n\nIf you sell lighting — as a showroom or a brand — three things follow directly from this data:\n\n- **Find out which industry you’re in.** If your site is agent-blind, that’s almost certainly a platform default you didn’t choose, not a reflection of your business. It’s fixable, and usually faster than it sounds.\n- **The ceiling is closer than it looks.** Companies already at 80+ are ordinary lighting businesses on commercially available platforms. Most of the gap between mid-pack and leader is markup and files, not a rebuild.\n- **Nobody has built readiness on purpose yet.** Intentional agent-interoperability work is at zero across this entire cohort — not because it’s hard, but because nobody’s tried. That’s an open question, not a settled one.\n\n> As disclosed at the start of this report\n> \n> Neural Partners builds and migrates lighting-industry websites and offers the free scan this data comes from. Full methodology and sample caveats are in the Methodology section above.\n\n**Want your own score?** Run the free [Agentic Readiness Check](/#readiness) to see exactly where your site lands — it’s the same scan behind this report.\n\n## What to read next\n\n**Volume two is out.** [The Agentic Readiness Index: Home Services Edition](/resources/agentic-readiness-index-home-services/) — 623 plumbing, HVAC and electrical contractors, scanned August 2026. One in three is reachable only by phone as far as an agent is concerned, and zero percent expose any agentic protocol at all.\n\n_A note on this lighting volume: it was scanned in a single pass. While preparing volume two we found that a single pass can misreport a working site as unreachable, so volume two scans every company three times and only trusts a result that reproduces. We are re-running this lighting cohort under the same gate, and until then the two volumes should not be compared directly. The lighting figures most likely to move are the agent-blind and unreachable shares._\n\nThis report measures the gap. These guides cover what closes it — the standards a site has to speak before an agent can find, read, and buy from it:\n\n- [The agentic protocol landscape](/resources/agentic-protocol-landscape/) — every standard on one page, with a plain verdict on whether it’s safe to build on. Re-verified quarterly.\n- [Agentic commerce protocols, explained](/resources/agentic-commerce-protocols-explained/) — UCP and ACP, and what agentic commerce actually demands of your product data.\n- [Agent payment rails, explained](/resources/agent-payment-rails-explained/) — how a merchant knows an agent is authorized to spend, and what to decide before the volume arrives.\n- [AI-ready websites](/ecommerce/websites/) — the metadata layer that moves a site out of the agent-blind half of this cohort." }, { "id": "agentic-commerce-protocols-explained", "slug": "agentic-commerce-protocols-explained", "url": "https://www.neuralpartners.ai/resources/agentic-commerce-protocols-explained/", "title": "Agentic commerce protocols, explained", "type": "guide", "category": "websites-agentic-commerce", "excerpt": "UCP and ACP took different paths in 2026. What each one does, where the transaction layer actually consolidated, and what agentic commerce demands of your product data.", "topics": [ "agentic-commerce", "protocols", "e-commerce" ], "author": "Neural Partners", "updated": "2026-08-09T00:00:00.000Z", "readingTime": "8 min read", "featured": false, "trending": true, "image": "https://www.neuralpartners.ai/resources/agentic-commerce-protocols-explained/images/hero.webp", "bodyFormat": "markdown", "body": "Last verified: 9 August 2026\n\n## The problem these protocols solve\n\nA customer tells an assistant to buy a specific lamp in brushed brass, ship it to the office, use the corporate card. For that to complete without a human touching a browser, six things have to happen:\n\nThe agent has to **find** your catalog. It has to **understand** the product — variants, stock, price, shipping. It has to **build** a cart and get an accurate total including tax and freight. You have to **verify** the agent is legitimate and acting for a real customer with real authority. Money has to **move**. And you need a **record** of what was agreed, in case it goes wrong.\n\nBefore 2025 there was no standard way to do any of this. Agents scraped pages, guessed at prices, and failed at checkout. The protocols below exist because scraping doesn't scale and merchants hated it.\n\nThis guide covers discovery through cart. The verification and money-movement half has its own guide — see [Agent payment rails, explained](/resources/agent-payment-rails-explained/). For the whole field at a glance, start with [the agentic protocol landscape](/resources/agentic-protocol-landscape/).\n\n## Two protocols, and they took different paths\n\n### Agentic Commerce Protocol (ACP)\n\nOpenAI and Stripe launched ACP on 29 September 2025, the same day ChatGPT got Instant Checkout. Apache 2.0, date-versioned, currently at 2026-04-17.\n\nThe original pitch was complete: an agent inside ChatGPT could search products, build a cart, and pay — without the customer leaving the conversation. Etsy went live at launch with a million-plus US sellers. Walmart signed a partnership two weeks later.\n\n**Then in March 2026, OpenAI pulled native checkout out of ChatGPT.** Their own explanation: \"the initial version of Instant Checkout did not offer the level of flexibility that we aspire to provide.\"\n\nWhat replaced it is a discovery model. Agents surface your products inside ChatGPT; you run your own checkout. The named discovery partners after the revamp — Target, Sephora, Nordstrom, Lowe's, Best Buy, The Home Depot, Wayfair — are all sending customers to their own storefronts. Walmart went further and built a dedicated ChatGPT app with account linking, loyalty, and Walmart's own payments.\n\nThat's not a failure. Discovery inside a surface with hundreds of millions of users is worth a great deal. But it is a materially different product than the one announced, and any strategy deck written before March 2026 has this wrong.\n\n### Universal Commerce Protocol (UCP)\n\nGoogle announced UCP on 11 January 2026, co-developed with Shopify, Etsy, Wayfair, Target, and Walmart. Apache 2.0, currently at v2026-04-08.\n\nUCP kept the full checkout scope that ACP retreated from, and it grew fast. On 24 April 2026 the Tech Council expanded to include **Amazon, Meta, Microsoft, Salesforce, and Stripe** — joining Google, Shopify, Etsy, Target, and Wayfair.\n\nRead that list again. Amazon and Google on the same technical council. Microsoft too. And Stripe, which is a founding maintainer of ACP.\n\nBeyond the Council, the endorser list runs through Adyen, American Express, Best Buy, Flipkart, Klarna, Macy's, Mastercard, PayPal, The Home Depot, Visa, and Zalando. UCP has also started extending into lodging — Marriott, Hilton, Booking.com, Expedia, Amadeus — and food ordering with DoorDash, Uber Eats, Square, and Toast.\n\n## Where this actually landed\n\nNo one announced a merger. But the pattern is hard to miss.\n\nACP moved away from checkout in March. UCP consolidated checkout backing in April. The one company with a foot in both camps — Stripe — joined the UCP council while remaining an ACP maintainer. Meta did the same thing.\n\nOur read, and we'll say the confidence level plainly: **we think UCP is where the transaction layer settles, at maybe 70% confidence.** The remaining 30% is that ChatGPT's distribution is large enough that a discovery-only ACP still shapes how a lot of commerce starts, and that OpenAI takes another run at checkout with a different design.\n\nWhat that means practically: these aren't an either/or. They now do different jobs. ACP is a demand channel. UCP is transaction infrastructure. A merchant with both is not hedging — they're covering two parts of the same funnel.\n\n## How UCP works, concretely\n\n**Discovery is a well-known file.** You publish a manifest at `/.well-known/ucp` on your domain. An agent fetches it and learns what you support. If you've implemented `robots.txt` or `llms.txt`, the mental model is the same — a machine-readable statement of capability at a predictable path.\n\n**Capabilities are negotiated, not assumed.** You declare what you can do — catalog browsing, cart operations, checkout, order status. An agent that needs something you don't offer knows before it tries. This is the part most merchants underestimate: you can adopt UCP for discovery and catalog only, and add checkout later, without breaking anything.\n\n**Extensions are namespaced by reverse domain.** Vertical-specific or merchant-specific behavior doesn't pollute the core spec.\n\n**Transport is your choice.** REST, or over A2A, or over MCP. If you've already built [MCP infrastructure](/resources/mcp-a2a-agent-interoperability/), that's not wasted work.\n\n**Payments hand off to AP2.** UCP doesn't reinvent money movement. It's designed to work with the Agent Payments Protocol, which now lives at the FIDO Alliance.\n\n## What this asks of your product data\n\nHere's the part that gets skipped, and it's the part that actually determines whether any of this works for you.\n\nAgentic commerce is unforgiving about product data in a way that human browsing never was. A human sees \"Brushed Brass — 3 left\" and understands. An agent needs the finish as a structured attribute with a controlled value, the inventory as a number with a freshness guarantee, and the price as an amount with a currency and a validity window.\n\nThe failure modes we see most:\n\n- **Variants encoded in the title.** \"Modern Sconce - Brass - Large\" is one product to an agent unless the variant axes are structured. It cannot filter on a substring it doesn't know is a filter.\n- **Inventory that's directionally true.** Human shoppers tolerate a stale stock count. An agent that builds a cart against stale inventory produces a failed order and a customer who blames you, not the agent.\n- **Pricing that depends on context the agent can't see.** Logged-in pricing, regional pricing, and cart-level promotions all need to be expressible in the protocol or the total will be wrong at the last step.\n- **Shipping estimated at checkout only.** If freight isn't computable until the final step, the agent can't compare you against alternatives, and it will drop you earlier in the process than you'd like.\n\nNone of this is new advice. It's the same data hygiene that made feeds work for paid shopping. What's new is that the penalty moved from _lower ad performance_ to _the transaction does not complete._\n\n## What we'd do, in order\n\n- **1\\. Fix the catalog before touching a protocol.** Structured variants, controlled attribute values, real-time inventory, computable shipping. Every protocol on this page is a transport for this data. Bad data transported perfectly is still bad data.\n- **2\\. Publish the UCP manifest.** Discovery and catalog capability only. This is a small piece of work and it makes you visible to the layer that's consolidating.\n- **3\\. Get into ACP discovery.** Different audience, different surface, low incremental cost once the catalog is clean.\n- **4\\. Decide on checkout deliberately.** Whether an agent completes a purchase without touching your storefront is a business decision about margin, attribution, and customer relationship — not a technical one. Walmart looked at it and built their own app instead. That was a strategy call, and it was probably right for them.\n- **5\\. Put a re-check on the calendar.** Ninety days. This layer moved three times in the last twelve months.\n\n## Questions worth asking a vendor\n\nIf someone is selling you agentic commerce readiness, these separate the real from the deck:\n\n- Which spec version have you implemented, and when did you last update it?\n- Does our UCP manifest declare checkout capability, or only discovery? Which do you recommend and why?\n- How does inventory freshness get guaranteed between our system and the manifest?\n- What happens to attribution when the purchase originates in an agent?\n- If ACP changes again, what breaks?\n\nThe last one matters most. Anything built as a one-time integration against a moving standard is a liability with a delivery date.\n\n## Common questions\n\nWhat is the difference between UCP and ACP?\n\nThey now do different jobs. ACP, launched by OpenAI and Stripe in September 2025, moved away from native checkout in March 2026 and is effectively a discovery channel — agents surface your products inside ChatGPT and you run your own checkout. UCP, announced by Google in January 2026, kept the full checkout scope and is transaction infrastructure. A merchant running both is not hedging; they are covering two parts of the same funnel.\n\nWhich agentic commerce protocol won?\n\nNo one announced a merger, but the pattern is hard to miss. ACP moved away from checkout in March 2026 and UCP consolidated checkout backing in April, when its Tech Council expanded to include Amazon, Meta, Microsoft, Salesforce, and Stripe. Our read, with the confidence level stated plainly: we think UCP is where the transaction layer settles, at roughly 70% confidence. The remaining 30% is that ChatGPT distribution is large enough that a discovery-only ACP still shapes where a lot of commerce starts.\n\nHow does an AI agent discover that my store supports UCP?\n\nYou publish a manifest at /.well-known/ucp on your domain. An agent fetches it and learns which capabilities you support. If you have implemented robots.txt or llms.txt, the mental model is identical — a machine-readable statement of capability at a predictable path.\n\nDo I have to support checkout to adopt UCP?\n\nNo. Capabilities are negotiated, not assumed. You declare what you can do — catalog browsing, cart operations, checkout, order status — and an agent that needs something you do not offer knows before it tries. You can adopt UCP for discovery and catalog only, and add checkout later, without breaking anything.\n\n## Sources\n\n[ucp.dev](https://ucp.dev/) · [Universal Commerce Protocol on GitHub](https://github.com/Universal-Commerce-Protocol/ucp) · [Google: agentic commerce and UCP](https://blog.google/products/ads-commerce/agentic-commerce-ai-tools-protocol-retailers-platforms/) · [Shopify Engineering: Building UCP](https://shopify.engineering/UCP) · [Agentic Commerce Protocol](https://agenticcommerce.dev/) · [ACP on GitHub](https://github.com/agentic-commerce-protocol/agentic-commerce-protocol) · [OpenAI: Buy it in ChatGPT](https://openai.com/index/buy-it-in-chatgpt/) · [Forrester on the ACP pullback](https://www.forrester.com/blogs/what-it-means-that-the-leader-in-agentic-commerce-just-pulled-back/) · [UCP Tech Council expansion](https://www.newsfilecorp.com/release/294133/Amazon-Meta-Microsoft-Salesforce-and-Stripe-Join-the-Universal-Commerce-Protocol-Tech-Council)\n\n### Want your catalog ready for this?\n\nStructured product data, a UCP manifest, and agent-legible inventory are exactly what we build for catalog-driven brands — see [agentic commerce](/ecommerce/agentic-commerce/) and [digital storefronts](/ecommerce/websites/). If you're weighing what to do first, we'll give you a straight answer.\n\n[Talk to us](/contact-us/) [More resources](/resources/)" }, { "id": "agentic-protocol-landscape", "slug": "agentic-protocol-landscape", "url": "https://www.neuralpartners.ai/resources/agentic-protocol-landscape/", "title": "The agentic protocol landscape", "type": "guide", "category": "websites-agentic-commerce", "excerpt": "A working map of the standards that let AI agents browse, transact, and talk to each other — what each does, who controls it, and whether it's safe to build on yet. Re-verified quarterly.", "topics": [ "agentic-commerce", "protocols", "ai-strategy" ], "author": "Neural Partners", "updated": "2026-08-09T00:00:00.000Z", "readingTime": "11 min read", "featured": false, "trending": false, "image": "https://www.neuralpartners.ai/resources/agentic-protocol-landscape/images/hero.webp", "bodyFormat": "markdown", "body": "Last verified: 9 August 2026\n\nEighteen months ago this was a field of experiments. It isn't anymore. Money moves across these rails. Enterprises run production workloads on them. Three of the protocols below changed governance in the last eight months, and two of them changed hands entirely.\n\n## Read this first\n\nThat's the reason this page exists, and the reason it carries a date at the top. Anything written about agentic protocols has roughly a ninety-day shelf life. We re-verify this table every quarter against primary sources — spec repositories, foundation announcements, and vendor documentation — and we tell you when we last did it.\n\nIf you take one thing away: **the protocols are consolidating faster than they are competing.** The Linux Foundation and the FIDO Alliance now steward most of what matters. That's a good sign for anyone deciding whether to build. It means the odds of your integration work being stranded went down sharply in 2026.\n\n## The map\n\nFour layers, and they stack. An agent needs to find you, talk to your systems, agree on a transaction, and settle it. Each layer has its own standard, and they mostly don't overlap.\n\n- **Interoperability** — how an agent connects to tools and data. _MCP._\n- **Coordination** — how agents talk to each other across company boundaries. _A2A, AGNTCY._\n- **Commerce** — how an agent discovers products and completes a purchase. _UCP, ACP._\n- **Trust and settlement** — how a merchant knows an agent is legitimate, and how money moves. _AP2, Visa TAP, Mastercard Agent Pay, x402, MPP._\n\nPlus one that sits outside the stack: **the browser layer**, where the page itself hands tools to an AI running in the visitor's tab. That's WebMCP, and it's the newest thing here by a wide margin.\n\n## Model Context Protocol (MCP)\n\n**What it does:** Connects an AI agent to your tools and data. If you've built an integration that lets Claude, ChatGPT, or Copilot read from your systems, you almost certainly built it on MCP.\n\n**Who controls it:** The Agentic AI Foundation, a directed fund under the Linux Foundation. Anthropic created MCP and donated it in December 2025, co-founding AAIF alongside Block and OpenAI. Governance runs through individual maintainers, not company seats — there is no vendor with a controlling stake.\n\n**Should you build on it:** Yes. This is the most settled standard on this page. But check which spec revision your existing servers target, because the July 2026 release broke things. We go deeper on that in [MCP, A2A, and the agent interoperability stack](/resources/mcp-a2a-agent-interoperability/).\n\nTechnical detail\n\n- **Current spec:** `2026-07-28`. Previous revision `2025-11-25`.\n- **License:** Apache 2.0 (code and spec), CC-BY-4.0 (docs).\n- **Breaking changes in 2026-07-28:** the `initialize` handshake is gone — the core is now stateless, with version and capability negotiation carried per-request in `_meta` plus the `MCP-Protocol-Version` header. Protocol-level sessions and `Mcp-Session-Id` were removed from Streamable HTTP. Server-initiated requests were replaced by Multi Round-Trip Requests. Sampling, Roots, and Logging are deprecated on a twelve-month window. Tasks moved out of core into an extension. Dynamic Client Registration is deprecated in favor of Client ID Metadata Documents.\n- **Extensions framework:** official extensions cover OAuth Client Credentials, Enterprise-Managed Authorization, MCP Apps, and MCP Tasks. Extensions are off by default.\n- **Registry:** still in preview. The API froze at v0.1 in October 2025 and has not reached general availability. Don't build a dependency on registry stability yet.\n- **Scale:** the TypeScript and Python SDKs have each passed a billion cumulative downloads. AWS shipped a general-availability MCP server in May 2026; Google has more than fifty managed MCP servers.\n- **Source:** [modelcontextprotocol.io](https://modelcontextprotocol.io/specification/2026-07-28/changelog)\n\n## Agent2Agent (A2A)\n\n**What it does:** Lets autonomous agents from different organizations discover each other, negotiate, and hand off work. Where MCP connects an agent to _your_ tools, A2A connects your agent to _someone else's_ agent.\n\n**Who controls it:** The Linux Foundation, as a standalone project. Google donated it in June 2025 with AWS, Cisco, Microsoft, Salesforce, SAP, and ServiceNow as founding partners.\n\n**Should you build on it:** Yes, and the reason changed this year. A2A hit version 1.0 in March 2026 — its first stable release. The wait-and-see position that made sense in 2025 doesn't anymore.\n\nTechnical detail\n\n- **Current spec:** v1.0.1 (May 2026). v1.0.0 shipped 12 March 2026 and carried breaking interaction-protocol changes, multi-tenancy, and signed Agent Cards.\n- **Bindings:** JSON over HTTP, gRPC, JSON-RPC.\n- **SDKs:** Python, JavaScript, Java, Go, .NET.\n- **Adoption:** 150+ supporting organizations at the one-year mark. Live in Azure AI Foundry, Microsoft Copilot Studio, and Amazon Bedrock AgentCore Runtime.\n- **Related:** Google now groups A2A with AP2 (payments), A2UI (interface), and UCP (commerce) as the \"A2Family.\" AP2 is built as an extension of A2A.\n- **Relationship to MCP:** complementary, not competing. A2A handles agent-to-agent across organizational boundaries; MCP handles agent-to-tool inside them.\n- **Source:** [a2a-protocol.org](https://a2a-protocol.org/latest/specification/)\n\n## Universal Commerce Protocol (UCP)\n\n**What it does:** Lets an AI agent browse a merchant's catalog, build a cart, and complete a purchase — with the merchant keeping control of pricing, inventory, and the customer relationship.\n\n**Who controls it:** A Tech Council originally formed by Google, Shopify, Etsy, Target, and Wayfair. In April 2026 it expanded to include Amazon, Meta, Microsoft, Salesforce, and Stripe.\n\n**Should you build on it:** This is where the commerce layer consolidated. If you sell things and you're picking one commerce standard, pick this one. The full treatment is in [Agentic commerce protocols, explained](/resources/agentic-commerce-protocols-explained/).\n\nTechnical detail\n\n- **Announced:** 11 January 2026. **Current spec:** v2026-04-08. **License:** Apache 2.0.\n- **Discovery:** a `/.well-known/ucp` manifest at your domain, with capability negotiation and reverse-domain extension namespacing.\n- **Transports:** REST, plus A2A and MCP.\n- **Payments:** compatible with AP2.\n- **Verticals:** beyond retail, UCP is extending into lodging (Marriott, Hilton, Booking.com, Expedia, Amadeus) and food ordering (DoorDash, Uber Eats, Square, Toast).\n- **Endorsers beyond the Council:** Adyen, American Express, Best Buy, Flipkart, Macy's, Mastercard, PayPal, Klarna, The Home Depot, Visa, Zalando.\n- **Source:** [ucp.dev](https://ucp.dev/)\n\n## Agentic Commerce Protocol (ACP)\n\n**What it does:** Originally, agent-mediated checkout inside ChatGPT. As of 2026, primarily product discovery — with the merchant running their own checkout.\n\n**Who controls it:** OpenAI and Stripe as founding maintainers, with Meta on a three-of-seven Technical Steering Committee. No foundation donation. Neutral stewardship is described as a long-term aspiration, not a plan.\n\n**Should you build on it:** Yes for discovery — being findable inside ChatGPT has obvious value. Be careful about building checkout on it. That's the part OpenAI pulled back.\n\nTechnical detail\n\n- **Launched:** 29 September 2025, alongside ChatGPT Instant Checkout. **License:** Apache 2.0. **Current spec:** 2026-04-17.\n- **The pullback:** in March 2026 OpenAI eliminated native checkout in ChatGPT. Its own framing — \"the initial version of Instant Checkout did not offer the level of flexibility that we aspire to provide.\" ACP was repositioned toward discovery, with retailers running checkout themselves.\n- **Post-revamp discovery partners:** Target, Sephora, Nordstrom, Lowe's, Best Buy, The Home Depot, Wayfair. Walmart moved to a dedicated in-ChatGPT app with account linking and its own payments.\n- **Governance signal worth noting:** Stripe is a founding ACP maintainer _and_ joined the UCP Tech Council in April 2026. Meta sits on both. There is no announced merger, but the overlap is not accidental.\n- **Source:** [agenticcommerce.dev](https://agenticcommerce.dev/)\n\n## The payment and trust layer\n\nFour things happened here in 2026, and together they're the biggest structural shift on this page. Each one gets unpacked in [Agent payment rails, explained](/resources/agent-payment-rails-explained/).\n\n**AP2 went to the FIDO Alliance.** Google donated the Agent Payments Protocol in April 2026. FIDO stood up two working groups: Agentic Authentication (chaired by CVS Health, Google, and OpenAI) and Payments (chaired by Mastercard and Visa). Mastercard contributed its Verifiable Intent work at the same time. FIDO is now the neutral ground where the card networks and the AI labs are in the same room.\n\n**Visa's Trusted Agent Protocol** launched in October 2025, built on HTTP Message Signatures (RFC 9421) and aligned with Web Bot Auth, developed with Cloudflare. It uses a three-signature model — agent recognition, consumer identity, payment container. Pilots ran through late 2025 and 2026. Visa has not donated TAP to a standards body.\n\n**Mastercard Agent Pay** launched in April 2025 — earlier than most write-ups suggest — and became usable on ACP in late September 2025. In June 2026 Mastercard added Agent Pay for Machines, aimed at high-frequency machine-to-machine transactions across cards, accounts, and stablecoins.\n\n**Machine payments became a category.** The x402 Foundation launched under the Linux Foundation in July 2026 with forty member organizations, including Visa, Mastercard, Stripe, AWS, Google, Cloudflare, Coinbase, and Amex. Separately, Stripe and Tempo shipped the Machine Payments Protocol in March 2026. If your roadmap includes agents paying for things autonomously — API calls, compute, data — this is the layer to watch.\n\n## The advertising layer\n\nTwo competing standards, and anyone telling you there's only one hasn't looked recently.\n\n**Ad Context Protocol (AdCP)** is stewarded by AgenticAdvertising.org, a 501(c)(6) still completing its formation. Current version 3.1.4 as of July 2026, with 123+ members including Yahoo, PubMatic, Scope3, Samba TV, and LG Ads. The first agent-to-agent media buy with real money ran in October 2025.\n\n**AAMP** — the IAB Tech Lab's Agentic Advertising Management Protocols — shipped v1.0 in January 2026 and v2.3 in July 2026. It takes the opposite approach: rather than a new protocol, it extends the standards the industry already runs on (OpenRTB, AdCOM, OpenDirect, VAST, Deals API, GPP) with an agentic layer.\n\nThey are not aligned. The IAB's published materials don't mention AdCP, MCP, or A2A. If you're planning agentic media buying, this is an unresolved bet, not a settled standard.\n\n## The browser layer: WebMCP\n\n**What it does:** Flips MCP around. Instead of a server exposing tools to a remote agent, the page itself registers tools that an AI running in the visitor's browser can call — using their live session, their cookies, their authenticated state. No API keys, no auth handoff.\n\n**Status:** Early. It's a Draft Community Group Report from the W3C Web Machine Learning Community Group — not on the standards track and not in a Working Group. Chrome is running an Origin Trial across versions 149 through 156. Microsoft co-authors the spec. WebKit has an open request with logged concerns about privacy, security, and API design. Mozilla has published no position.\n\n**Should you build on it:** Only if you can absorb churn. The API changed in 2026 — `navigator.modelContext` was deprecated in Chrome 150 in favor of `document.modelContext`, and the earlier `provideContext()` method no longer exists. Anyone who shipped against the old surface has broken tools. That's the shape of this standard right now. We run WebMCP on this site and document exactly what that cost in [WebMCP: when your website hands tools to the agent](/resources/webmcp-explained/).\n\nTechnical detail\n\n- **Current API:** `document.modelContext.registerTool(tool, options)`, `getTools(options)`, and an `ontoolchange` event.\n- **Requirements:** secure context, origin-isolated documents, gated by a `\"tools\"` permissions policy defaulting to `['self']`.\n- **Two flavors:** an imperative JavaScript API and a declarative one using HTML form annotations.\n- **Tooling:** WebMCP inspection is built into Chrome DevTools under the Application panel — it shows registered tools, invocations, and schema violations. You don't need an extension.\n- **Local testing:** `chrome://flags/#enable-webmcp-testing`.\n- **Source:** [webmachinelearning.github.io/webmcp](https://webmachinelearning.github.io/webmcp/)\n\n## AGNTCY\n\n**What it does:** Infrastructure underneath multi-agent systems — a federated agent directory, identity and verifiable credentials, secure messaging (SLIM), a schema framework (OASF), and observability.\n\n**Who controls it:** A Linux Foundation project since July 2025. Formative members: Cisco, Dell, Google Cloud, Oracle, and Red Hat. It is not part of the Agentic AI Foundation.\n\n**Should you build on it:** Watch it. The code is actively maintained, and A2A agents and MCP servers are discoverable through AGNTCY directories — it's a layer beneath them, not a competitor. But we found no 2026 milestone announcements, version releases, or named production deployments. Technically alive, publicly quiet.\n\n## What we'd actually do about this\n\n**If you sell products online:** UCP is the priority. A `/.well-known/ucp` manifest and clean structured product data is the highest-leverage work available right now. ACP for discovery, separately and second. Our [agentic commerce practice](/ecommerce/agentic-commerce/) exists for exactly this.\n\n**If you're building agent-facing infrastructure:** MCP, and audit which spec revision you're on. The 2026-07-28 release deprecates enough that \"we shipped MCP servers\" doesn't tell you whether they'll work in a year.\n\n**If you're evaluating agent-to-agent workflows:** A2A cleared the stability bar in March. The reason to wait is gone.\n\n**If you're planning agentic media:** Don't pick yet. AdCP and AAMP are genuinely unresolved, and picking early here has real switching costs.\n\n**If someone is selling you a full-stack agentic solution:** ask which of these they've implemented, which spec version, and when they last checked. The honest answer involves dates.\n\nWe re-verify this page quarterly against primary sources. If something here has gone stale, [tell us](/contact-us/) — we'd rather fix it than defend it.\n\n## Common questions\n\nWhich agentic protocols actually matter right now?\n\nFour layers, and they stack. MCP connects an agent to your tools and data. A2A lets agents from different organizations talk to each other. UCP handles product discovery and checkout. AP2, Visa TAP, Mastercard Agent Pay, and x402 handle trust and settlement. WebMCP sits outside that stack, in the browser.\n\nWhich of these are safe to build on today?\n\nMCP is the most settled standard on the page — build on it, but check which spec revision your servers target, because the July 2026 release carried breaking changes. A2A reached its first stable release in March 2026, so the wait-and-see position from 2025 no longer applies. UCP is where the commerce layer consolidated; if you sell things and you are picking one commerce standard, pick that one. WebMCP and AGNTCY are worth tracking rather than depending on.\n\nWho controls these standards?\n\nMost of what matters is now under neutral stewardship. MCP sits with the Agentic AI Foundation, a directed fund under the Linux Foundation, after Anthropic donated it in December 2025. A2A is a standalone Linux Foundation project, donated by Google in June 2025. AP2 went to the FIDO Alliance. UCP is governed by a Tech Council that grew in April 2026 to include Amazon, Meta, Microsoft, Salesforce, and Stripe alongside Google, Shopify, Etsy, Target, and Wayfair. Visa TAP is the notable exception — Visa has not donated it to a standards body.\n\nHow current is this guide?\n\nAnything written about agentic protocols has roughly a ninety-day shelf life. We re-verify this page every quarter against primary sources — spec repositories, foundation announcements, and vendor documentation — and the last-verified date is stated at the top of the page.\n\n### Want a read on where you actually stand?\n\nWe build on these rails for a living — UCP manifests, MCP servers, structured product data, and the verification layer underneath. That work ships as [our agentic commerce practice](/ecommerce/agentic-commerce/). If you want to know which of this matters for your business this quarter, let's talk.\n\n[Talk to us](/contact-us/) [More resources](/resources/)" }, { "id": "mcp-a2a-agent-interoperability", "slug": "mcp-a2a-agent-interoperability", "url": "https://www.neuralpartners.ai/resources/mcp-a2a-agent-interoperability/", "title": "MCP, A2A, and the agent interoperability stack", "type": "guide", "category": "neural-core", "excerpt": "MCP connects agents to your tools. A2A connects agents to each other. Both changed hands in the last year, and MCP's July 2026 spec broke things on purpose. What to audit before it costs you.", "topics": [ "mcp", "protocols", "ai-strategy" ], "author": "Neural Partners", "updated": "2026-08-09T00:00:00.000Z", "readingTime": "8 min read", "featured": false, "trending": false, "image": "https://www.neuralpartners.ai/resources/mcp-a2a-agent-interoperability/images/hero.webp", "bodyFormat": "markdown", "body": "Last verified: 9 August 2026\n\n## The distinction that clears up most confusion\n\n**MCP connects an agent to tools and data.** Your CRM, your product catalog, your internal search, your ticketing system. One agent, many capabilities. Inside your walls.\n\n**A2A connects an agent to another agent.** Your procurement agent talking to a supplier's fulfillment agent. Two autonomous systems, different owners, negotiating and handing off work. Across organizational boundaries.\n\nIf you're wiring Claude into your data warehouse, that's MCP. If you're letting your logistics agent coordinate with a carrier's agent, that's A2A. Most organizations need the first one long before they need the second.\n\nThey're designed to compose. A2A carries the conversation between agents; each agent uses MCP to reach its own tools. Nobody has to choose. For where these sit relative to commerce and payments, see [the agentic protocol landscape](/resources/agentic-protocol-landscape/).\n\n## Model Context Protocol\n\n### It's not Anthropic's anymore\n\nAnthropic created MCP and released it in late 2024. On **9 December 2025 it donated the protocol to the Agentic AI Foundation**, a directed fund under the Linux Foundation that Anthropic co-founded with **Block and OpenAI**, with support from Google, Microsoft, AWS, Cloudflare, and Bloomberg.\n\nThe founding projects were MCP, Block's goose, and OpenAI's AGENTS.md. Agentgateway joined in June 2026.\n\nGovernance is worth understanding because of how it's structured. Authority runs through **individuals**, not company seats — Lead Maintainers, then Core Maintainers, then Maintainers. No organization holds a bloc. The current Core Maintainer roster spans Anthropic, Microsoft, Google Cloud, and AWS, and every one of them holds their seat personally.\n\nSpecification changes go through a proposal process (SEPs) that moved to a pull-request workflow in late 2025. There's a published feature lifecycle with a twelve-month minimum deprecation window. This is normal open-source governance, and its arrival is the strongest signal that MCP is infrastructure rather than a vendor feature.\n\n### The July 2026 release broke things on purpose\n\nThe current specification is **2026-07-28**. The previous revision was 2025-11-25. The gap between them is large, and if you have MCP servers in production you need to know what's in it.\n\n**The core went stateless.** The `initialize` handshake is gone. Protocol version, client capabilities, and client info now travel per-request in `_meta` alongside an `MCP-Protocol-Version` header. A new `server/discover` RPC handles up-front negotiation when you want it.\n\n**Sessions were removed.** `Mcp-Session-Id` is out of Streamable HTTP. Cross-call state now moves through explicit server-minted handles passed as tool arguments.\n\n**Server-initiated requests were replaced.** Instead of a server calling back to the client, a server returns an `input_required` result carrying its requests, and the client retries with responses attached. This is called Multi Round-Trip Requests.\n\n**Sampling, Roots, and Logging are deprecated.** Twelve-month window. Migration paths: tool parameters instead of Roots, direct LLM provider APIs instead of Sampling, stderr or OpenTelemetry instead of Logging.\n\n**Tasks moved out of core** into an official extension.\n\n**Authorization tightened.** RFC 9207 issuer validation is now required, credentials are bound to their issuer, and Dynamic Client Registration is deprecated in favor of Client ID Metadata Documents.\n\nThe through-line is that MCP is being rebuilt to scale like ordinary web infrastructure. Stateless requests survive load balancers, retries, and cold starts in a way stateful sessions never did. It's the right call, and it costs work.\n\n### What to do about it\n\nIf you shipped MCP servers before mid-2026, you're on a spec revision with deprecated features. Nothing breaks tomorrow — the twelve-month window is real — but \"we've deployed MCP servers\" is no longer a statement about whether they'll work next year.\n\nThree questions worth answering internally:\n\n- **Which spec revision does each server target?** If nobody knows, that's the finding.\n- **Do any of them depend on Sampling, Roots, or Logging?** Those are on the clock.\n- **Do any depend on session state?** That's the migration with real work in it.\n\n### Where MCP actually is\n\nThe TypeScript and Python SDKs have each passed a billion cumulative downloads, with roughly half a billion a month across the four Tier 1 SDKs (TypeScript, Python, Go, C#; Rust in beta). AWS shipped a generally available MCP server for all AWS services in May 2026. Google announced more than fifty managed MCP servers in April.\n\nOne thing that has _not_ happened: **the MCP Registry has not reached general availability.** It launched in preview in September 2025 and its API froze at v0.1 in October. The documentation still warns about breaking changes and data resets. Don't build a hard dependency on it yet.\n\n## Agent2Agent\n\n### The stability milestone most people missed\n\nGoogle announced A2A in April 2025 and **donated it to the Linux Foundation on 23 June 2025** as a standalone project — not under LF AI & Data, and not under the Agentic AI Foundation. Founding partners were AWS, Cisco, Google, Microsoft, Salesforce, SAP, and ServiceNow.\n\nThrough 2025 it moved fast and broke things across 0.x releases. The reasonable position then was to watch it.\n\n**That position expired on 12 March 2026, when A2A shipped v1.0.0** — its first stable release. It carried breaking changes to the interaction protocol, added multi-tenancy and signed Agent Cards, and moved to a stateless, layered, web-aligned architecture with three bindings: JSON over HTTP, gRPC, and JSON-RPC. Version 1.0.1 followed in May with bug fixes.\n\nAt the one-year mark A2A had **150+ supporting organizations**, 22,000+ GitHub stars, and five SDKs. It's live in Azure AI Foundry, Microsoft Copilot Studio, and Amazon Bedrock AgentCore Runtime, with reported production use in supply chain, financial services, insurance, and IT operations.\n\n### The A2Family\n\nGoogle now groups four things together, and the grouping is useful even if you're skeptical of the branding:\n\n- **A2A** — agents talking to agents.\n- **AP2** — agents paying (an extension of A2A, now donated to the FIDO Alliance).\n- **A2UI** — agents rendering interfaces to humans.\n- **UCP** — agents transacting commerce (which can run over A2A or MCP).\n\nThat's a coherent stack. It's also mostly Google-originated, which is worth naming — though AP2 went to FIDO and A2A went to the Linux Foundation, so the parts that matter most are now stewarded elsewhere. The commerce corner of it is covered in [Agentic commerce protocols, explained](/resources/agentic-commerce-protocols-explained/), and the payments corner in [Agent payment rails, explained](/resources/agent-payment-rails-explained/).\n\n## AGNTCY: the layer underneath\n\nAGNTCY handles the infrastructure problems that show up once you have more than a handful of agents. A federated **Agent Directory** for discovery. **Identity** with verifiable credentials and policy-based access. **SLIM** for secure low-latency messaging. **OASF**, a schema framework. Plus observability and evaluation tooling.\n\nCisco open-sourced it in March 2025 and it became a Linux Foundation project on 29 July 2025, with formative members **Cisco, Dell Technologies, Google Cloud, Oracle, and Red Hat** and 65+ supporting companies.\n\nIt's explicitly complementary: A2A agents and MCP servers are discoverable through AGNTCY directories, and AGNTCY's identity work covers MCP servers directly. It sits beneath both rather than alongside them.\n\nWe'll be straight about the current picture. The code is actively maintained — repositories updated through mid-2026, and the directory added automated security scanning for MCP servers and agent skills. But we found no 2026 milestone announcements, no published component versions, and no named production deployments. That's consistent with a technically healthy project going through a quiet stretch. It's also consistent with a project losing momentum. We can't tell from outside, and we'd rather say that than guess.\n\nNote also that AGNTCY is **not** part of the Agentic AI Foundation, despite the similar-sounding \"AGNTCon\" event name. Cisco and Oracle participate in AAIF separately as Gold members.\n\n## The governance map, because it explains a lot\n\nWhere these standards live now tells you more about their future than their feature lists do.\n\n- **Linux Foundation — Agentic AI Foundation:** MCP, goose, AGENTS.md, agentgateway.\n- **Linux Foundation — standalone projects:** A2A, AGNTCY, x402 Foundation.\n- **FIDO Alliance:** AP2, plus the Agentic Authentication and Payments working groups.\n- **W3C Web Machine Learning Community Group:** [WebMCP](/resources/webmcp-explained/) (incubation, not standards track).\n- **Vendor-controlled:** ACP (OpenAI, Stripe, Meta on a TSC — no foundation), Visa TAP (Visa).\n- **Industry consortium:** UCP (a Tech Council of Google, Shopify, Etsy, Target, Wayfair, Amazon, Meta, Microsoft, Salesforce, Stripe).\n\nTwo useful reads from that list. First, the foundation column got long in 2026 — that's the market voting for neutrality. Second, the vendor-controlled column still contains real, widely-deployed protocols, and there's nothing wrong with that as long as you price the risk consciously.\n\n## What we'd actually do\n\n**Start with MCP, and audit what you already have.** It's the most settled standard in agentic AI and the one most likely to already be in your stack. The July 2026 spec change is the more urgent item than any new adoption.\n\n**Treat A2A as ready.** Stability shipped in March. If agent-to-agent workflows are on your roadmap, the technical reason to wait is gone. The remaining reasons are organizational — do you actually have a counterparty ready to talk to?\n\n**Watch AGNTCY, don't bet on it.** The problems it solves are real and arrive later. Nothing about waiting costs you.\n\n**Don't build a house on the MCP Registry.** Still preview, still v0.1.\n\n**Ask vendors for dates, not names.** \"We support MCP\" means nothing on its own. \"We support MCP 2026-07-28, and here's our deprecation plan for Sampling\" means something.\n\n## Common questions\n\nWhat is the difference between MCP and A2A?\n\nMCP connects an agent to your tools and data. A2A connects your agent to someone else’s agent. They are complementary rather than competing — A2A handles agent-to-agent across organizational boundaries, MCP handles agent-to-tool inside them. That distinction clears up most of the confusion about the two.\n\nIs MCP still controlled by Anthropic?\n\nNo. Anthropic created MCP and donated it in December 2025, co-founding the Agentic AI Foundation — a directed fund under the Linux Foundation — alongside Block and OpenAI. Governance runs through individual maintainers rather than company seats, so no vendor holds a controlling stake.\n\nWhat did the July 2026 MCP spec change?\n\nIt broke things on purpose. The initialize handshake is gone and the core is now stateless, with version and capability negotiation carried per-request in \\_meta plus the MCP-Protocol-Version header. Protocol-level sessions and Mcp-Session-Id were removed from Streamable HTTP. Server-initiated requests were replaced by Multi Round-Trip Requests. Sampling, Roots, and Logging are deprecated on a twelve-month window, Tasks moved out of core into an extension, and Dynamic Client Registration is deprecated in favour of Client ID Metadata Documents.\n\nShould I build on A2A yet?\n\nYes, and the reason changed this year. A2A reached version 1.0 in March 2026, its first stable release, with v1.0.1 following in May. The wait-and-see position that made sense in 2025 does not anymore. It has 150+ supporting organizations and runs in Azure AI Foundry, Microsoft Copilot Studio, and Amazon Bedrock AgentCore Runtime.\n\nCan I rely on the MCP registry?\n\nNot yet. The registry is still in preview — the API froze at v0.1 in October 2025 and has not reached general availability. Do not build a dependency on registry stability.\n\n## Sources\n\n[MCP specification 2026-07-28 changelog](https://modelcontextprotocol.io/specification/2026-07-28/changelog) · [MCP governance](https://modelcontextprotocol.io/community/governance) · [Anthropic donates MCP, AAIF formed](https://www.anthropic.com/news/donating-the-model-context-protocol-and-establishing-of-the-agentic-ai-foundation) · [Agentic AI Foundation](https://aaif.io/) · [MCP Registry](https://modelcontextprotocol.io/registry/about) · [Google donates A2A to the Linux Foundation](https://developers.googleblog.com/en/google-cloud-donates-a2a-to-linux-foundation/) · [A2A releases](https://github.com/a2aproject/A2A/releases) · [A2A passes 150 organizations](https://www.linuxfoundation.org/press/a2a-protocol-surpasses-150-organizations-lands-in-major-cloud-platforms-and-sees-enterprise-production-use-in-first-year) · [Meet the A2Family](https://opensource.googleblog.com/2026/04/meet-the-a2family.html) · [Linux Foundation welcomes AGNTCY](https://www.linuxfoundation.org/press/linux-foundation-welcomes-the-agntcy-project-to-standardize-open-multi-agent-system-infrastructure-and-break-down-ai-agent-silos) · [AGNTCY docs](https://docs.agntcy.org/)\n\n### Want your MCP surface audited?\n\nWe run MCP and A2A in production on our own platform — including the spec migration this guide describes — on top of [Neural Core](/neural-core/) and the [marketing infrastructure](/neural-core/) underneath it. If you need to know which of your servers survive the next twelve months, that's a conversation worth having.\n\n[Talk to us](/contact-us/) [More resources](/resources/)" }, { "id": "webmcp-explained", "slug": "webmcp-explained", "url": "https://www.neuralpartners.ai/resources/webmcp-explained/", "title": "WebMCP: when your website hands tools to the agent", "type": "guide", "category": "websites-agentic-commerce", "excerpt": "WebMCP lets a page expose tools directly to an AI in the visitor's browser — live session, no API key, no auth handoff. How it works, where the standard really stands, and what we run on this site.", "topics": [ "mcp", "protocols", "agentic-commerce" ], "author": "Neural Partners", "updated": "2026-08-09T00:00:00.000Z", "readingTime": "7 min read", "featured": false, "trending": true, "image": "https://www.neuralpartners.ai/resources/webmcp-explained/images/hero.webp", "bodyFormat": "markdown", "body": "Last verified: 9 August 2026\n\n## The model it replaces\n\nThe standard way to make a website usable by an AI agent is to build a second website for machines. You stand up an [MCP server](/resources/mcp-a2a-agent-interoperability/). You define tools. You issue API keys. You build an auth flow so the agent can act on a user's behalf. Then you maintain two systems that have to stay in sync.\n\nThat works, and most serious integrations still do it. But look at what it costs: the agent operates on a _copy_ of your application's capability, reached through credentials the user had to provision, against state that may not match what they're looking at.\n\nWebMCP inverts it. The page registers its tools directly into the browser. An AI assistant running in that tab — a browser-native assistant, an extension, a sidebar — calls them using the visitor's **live session, their existing cookies, and the DOM they're already looking at.**\n\nNo server. No API key. No auth handoff, because there's nothing to hand off — the user is already logged in.\n\n## Why that matters more than it sounds\n\nThe authentication point is the whole thing.\n\nConsider what it takes today for an agent to check a customer's order status on your site. You need an API, an authenticated endpoint, a token exchange, a consent flow, and a way for the agent to prove it's acting for that specific customer. That's weeks of work and a permanent security surface.\n\nWith WebMCP, the customer is logged into your site in their browser. The agent runs in that context. When it calls your `get_order_status` tool, it's the customer's session making the call — same as if they'd clicked the button themselves. The authorization question was answered when they logged in.\n\nThe second-order effect is that **anything a user can do on your site becomes a candidate tool**, without a parallel API. Long tail functionality that would never justify an API endpoint becomes agent-accessible for the cost of a tool registration.\n\n## How it actually works\n\nThe API lives on the document:\n\n```\ndocument.modelContext.registerTool({\n name: 'get_pricing',\n description: 'Returns current pricing for all plans.',\n inputSchema: { /* JSON Schema */ },\n execute: async (params) => {\n // your logic — runs in the page, with the user's session\n return { content: [{ type: 'text', text: '...' }] }\n }\n})\n```\n\nThree things on the current surface: `registerTool(tool, options)` to register, `getTools(options)` to enumerate, and an `ontoolchange` event for when the available set changes.\n\nChrome also offers a **declarative** flavor where you annotate HTML forms directly, which covers a lot of common cases without writing JavaScript at all.\n\nRequirements are what you'd expect for something this powerful: a secure context, origin-isolated documents, and a `\"tools\"` permissions policy that defaults to `['self']`.\n\n**A note on churn, because it's the most important practical thing here.** This API changed in 2026. It used to live at `navigator.modelContext` and included a `provideContext()` method. `navigator.modelContext` was deprecated in Chrome 150; `provideContext()` no longer exists in the specification. If you shipped against the earlier surface and never revisited it, your tools are not registering in current Chrome — and nothing errors loudly to tell you. That's the shape of building on an incubating standard: not a reason to avoid it, but a reason to own the maintenance.\n\n## Where the standard actually stands\n\nLet's be precise, because a lot of coverage overstates this.\n\nWebMCP is a **Draft Community Group Report** from the **W3C Web Machine Learning Community Group.** A Community Group is where ideas incubate. It is _not_ the standards track, and WebMCP has _not_ graduated to a Working Group.\n\n**Chrome** is running an Origin Trial spanning versions **149 through 156**. Chrome stable is currently 151, so the trial is mid-window. It is not shipped to stable.\n\n**Microsoft** co-authors the specification and the Edge team has publicly committed to collaborating.\n\n**WebKit** has an open request on its standards-positions repository, filed in May 2026, tagged with concerns about API design, privacy, security, venue, and meaningful user consent. Those are substantive objections, not procedural ones. Safari has not taken a position.\n\n**Mozilla** has published no position at all.\n\nSo: one browser shipping an experiment, one co-authoring, one with logged concerns, one silent. That's genuinely early. Anyone describing WebMCP as an emerging web standard is being generous.\n\n## Debugging it\n\nChrome DevTools has WebMCP inspection built in, under the **Application** panel. It shows the tools a page has registered, the tools that have been invoked, lets you invoke them manually, and flags schema violations.\n\nYou do not need an extension for this. Older guidance — including our own, earlier — pointed at a separate DevTools extension. The functionality moved into the browser.\n\nFor local development before the origin trial token is in place, enable `chrome://flags/#enable-webmcp-testing`.\n\n## What we run on this site\n\nWe registered WebMCP tools on neuralpartners.ai the week Chrome's documentation went live. Seven tools are registered from a single script in our site footer:\n\n- `get_pricing` — current pricing across our Neural Core plans\n- `list_offerings` — services tracks, bundles, and platform tiers\n- `search_intelligence` — search our Intelligence articles by topic\n- `get_company_info` — company details and contact information\n- `navigate_to` — navigation to a requested section\n- `contact` — pre-fills our contact form\n- `start_quote` — pre-fills a quote request\n\n**We resolved the API migration on 9 August 2026, and we'd rather tell you why than quietly fix it.** Our implementation read `navigator.modelContext` only — the original surface. When Chrome deprecated it in favor of `document.modelContext`, our registration guard simply returned early and no tools registered at all on newer Chrome. Nothing threw. Nothing logged. The site looked exactly the same. We caught it while fact-checking this very guide, and the fix reads both surfaces, preferring the current one:\n\n```\nvar mc = document.modelContext || navigator.modelContext;\nif (!mc || typeof mc.registerTool !== 'function') return;\n```\n\nThat is the failure mode of an incubating standard in one paragraph: a silent regression, invisible to everyone including the people who shipped it, caught only by going back and checking. If you have WebMCP tools in production and haven't looked since Chrome 150, go look now.\n\nTwo design decisions worth stealing.\n\n**The form tools never submit.** `contact` and `start_quote` write a handoff payload to `sessionStorage` and pre-fill the matching form when the visitor lands on it. The human still clicks the button. An agent that can complete a lead form on someone's behalf without their attention is a spam vector, not a feature — and the first serious abuse of WebMCP will almost certainly be exactly that.\n\n**Every tool is read-mostly.** Nothing we've registered changes state. That's a deliberate ceiling on blast radius while the security model is still being argued about in public.\n\nYou can verify all of this yourself: open this site in Chrome 149 or later and check the Application panel in DevTools.\n\n## Should you build on it\n\n**Yes, if** you can absorb API churn, your use case is read-heavy, and being early has strategic value for you. The work is small — registering a handful of tools is an afternoon, not a quarter.\n\n**No, if** you need stability, you're planning write operations, or you'd have to justify the maintenance to someone who'll ask why the tools broke. Chrome 150 already broke one generation of implementations — ours included. It will happen again before this reaches a Working Group.\n\n**Either way**, don't let WebMCP substitute for the work that actually matters. Structured data, a clean `llms.txt`, a [UCP manifest](/resources/agentic-commerce-protocols-explained/), and a real MCP server serve far more agent traffic than a browser API in origin trial. WebMCP is a strong signal and a genuine capability. It is not the foundation.\n\n## What we're watching\n\nWhether it moves from the Community Group to a Working Group — that's the graduation that would make this a real standard rather than an experiment.\n\nWhether WebKit's concerns get addressed. The privacy and consent objections are the substantive ones, and if they don't resolve, WebMCP stays a Chrome feature.\n\nWhat happens at the end of the Chrome 156 origin trial. That's the decision point.\n\nWhether a permission and consent model emerges that survives contact with adversaries. Right now the security story rests on the origin boundary and a permissions policy. That's a reasonable start and it is not sufficient for write operations at scale.\n\n## Common questions\n\nWhat is WebMCP?\n\nWebMCP lets a page expose tools directly to an AI running in the visitor’s own browser, on the visitor’s live session. Every agent integration before it required a server, an API key, and an auth handoff. WebMCP removes all three.\n\nShould I build on WebMCP today?\n\nYes if you can absorb API churn, your use case is read-heavy, and being early has strategic value — the work is small, registering a handful of tools is an afternoon rather than a quarter. No if you need stability, you are planning write operations, or you would have to justify the maintenance to someone who will ask why the tools broke. Chrome 150 already broke one generation of implementations, ours included, and it will happen again before this reaches a Working Group.\n\nIs WebMCP a substitute for structured data or an MCP server?\n\nNo, and this is the mistake worth avoiding. Structured data, a clean llms.txt, a UCP manifest, and a real MCP server serve far more agent traffic than a browser API in origin trial. WebMCP is a strong signal and a genuine capability. It is not the foundation.\n\n## Sources\n\n[WebMCP specification (W3C Web Machine Learning CG)](https://webmachinelearning.github.io/webmcp/) · [webmachinelearning/webmcp](https://github.com/webmachinelearning/webmcp) · [Chrome: WebMCP documentation](https://developer.chrome.com/docs/ai/webmcp) · [Chrome: WebMCP imperative API](https://developer.chrome.com/docs/ai/webmcp/imperative-api) · [Chrome DevTools: WebMCP panel](https://developer.chrome.com/docs/devtools/application/webmcp) · [Intent to Experiment: WebMCP](https://groups.google.com/a/chromium.org/g/blink-dev/c/gmYffo5WOE8/m/OJxuQRP3AAAJ) · [WebKit standards-positions #670](https://github.com/WebKit/standards-positions/issues/670)\n\n### Want tools on your site that actually register?\n\nWe build agent-facing surfaces — WebMCP tools, MCP servers, structured data, and the monitoring that catches a silent regression before a customer does. The foundation underneath is [an AI-ready website](/ecommerce/websites/). If you want that done properly, let's talk.\n\n[Talk to us](/contact-us/) [More resources](/resources/)" }, { "id": "semantic-search-for-showroom-catalogs", "slug": "semantic-search-for-showroom-catalogs", "url": "https://www.neuralpartners.ai/resources/semantic-search-for-showroom-catalogs/", "title": "Semantic search for showroom catalogs: what it is and why it matters", "type": "guide", "category": "neural-core", "excerpt": "How semantic and hybrid search help shoppers find in-stock furniture, rugs, and lighting they described but couldn't name — and why that's a revenue problem at catalog scale.", "topics": [ "semantic-search", "hybrid-search", "product-discovery", "catalog-search" ], "author": "Neural Partners", "updated": "2026-07-04T00:00:00.000Z", "readingTime": "5 min read", "featured": false, "trending": false, "image": "https://www.neuralpartners.ai/resources/semantic-search-for-showroom-catalogs/images/hero.webp", "bodyFormat": "markdown", "body": "## The short version — what semantic search actually is\n\nA shopper opens your online showroom and types \"a low, comfy sofa for a small apartment.\" They're not naming a product — they're describing a feeling and a constraint. Keyword search reads that literally and hunts for those exact words in your catalog. If the right piece is filed as \"compact 2-seat loveseat, 32-inch depth,\" it never surfaces. The sofa's in stock. The shopper leaves with nothing.\n\nSemantic search closes that gap. Instead of matching the words, it matches the meaning behind them. \"Low, comfy, small apartment\" and \"compact loveseat, shallow depth\" point at the same thing — so the shopper sees the sofa they pictured, not a blank results page.\n\nKeyword search finds what shoppers name. Semantic search finds what they mean.\n\n## The challenge — why good products stay hidden\n\nEvery showroom hits the same wall. Your catalog is tagged by the people and systems that built it — manufacturers, spec sheets, import feeds. Shoppers don't talk like spec sheets. So the words they use and the words in your data describe the same product and never meet:\n\n- \"warm brass sconce for a damp bathroom\" → antique gold wall light, IP44 rated\n- \"a soft rug that hides pet hair\" → high-pile stain-resistant polypropylene area rug\n- \"something midcentury for the entryway\" → walnut console table, tapered legs\n\nKeyword search only connects those columns if someone hand-tagged every synonym in advance. On a small catalog, you can brute-force that. Across dozens of manufacturers and 100,000+ SKUs, you can't tag your way out — the combinations outrun any team you could hire.\n\n## For your shoppers — they search the way they think\n\n### Describe it, don't decode it\n\nShoppers type the room, the vibe, or the use case — \"cozy reading nook lamp,\" \"sturdy table for a rental\" — and get real matches instead of a lesson in your tagging system.\n\n### Fewer dead ends\n\nThe \"0 results\" page is where sales quietly die. Semantic search fills it with the closest things you actually stock, so a described query still lands somewhere real.\n\n### The right piece, faster\n\nLess scrolling through 200 near-misses. The fixture, sofa, or rug they had in mind rises toward the top instead of sitting on page nine.\n\n### It just feels smarter\n\nSearch that understands intent reads as a showroom that knows its inventory — which is exactly the impression an experience-driven brand wants to leave.\n\n## For the business — what it does to the numbers\n\n### Recover sales you already own\n\nThe most expensive miss is the in-stock product a ready-to-buy shopper couldn't find. Semantic search catches those before they become a bounce.\n\n### Turn browse into buy\n\nBetter matching means fewer shoppers giving up and running the same query in a competitor's search box.\n\n### Onboard vendors without waiting\n\nNew manufacturer catalogs become discoverable the day they land — not after the next overnight job — so every vendor you add starts earning immediately.\n\n### Spend less on tagging\n\nStop paying down a synonym backlog that never ends. The model carries the meaning, so your team stops babysitting keyword lists.\n\n## Under the hood — how it works, and how we run it\n\nHere's the part that matters if you want to know we've actually built this, not just described it.\n\n### Embeddings, minus the math\n\nAn embedding model reads text — a product description, or a shopper's query — and turns it into a list of numbers that captures what it's about. Similar meanings land close together; unrelated ones land far apart. \"Warm brass sconce\" and \"antique gold wall light\" end up as neighbors. From there, search is a geometry problem: embed the query, find the nearest products.\n\n### One model, both sides\n\nThe catalog and the live query have to be embedded by the same model, or the two number-spaces don't line up and relevance quietly degrades. It's an easy thing to get wrong and a hard thing to notice later — so we verify it rather than assume it.\n\n### Hybrid, not either/or\n\nSemantic search doesn't replace keyword search — it completes it. Keyword matching (`BM25`) is unbeatable on exact hits: model numbers, SKUs, precise specs. Semantic catches intent and description. We run both and fuse the rankings, so the shopper who types a SKU gets the exact unit and the shopper who describes a room gets the right options. Precision and recall in a single result list.\n\n### Model size is a measured call, not a spec-sheet flex\n\nBigger embedding models capture finer shades of meaning but cost more to store and run at catalog scale. Smaller ones are cheaper and faster with less range. There's no universal right answer — so the right approach is to test candidate models against a labeled set of real queries and only adopt the leaner one when relevance holds where it matters. Efficiency counts only if quality survives it.\n\n### On-demand beats the nightly batch\n\nPlenty of systems re-embed on a schedule — you onboard a vendor, then wait for the overnight run. Ours embeds a manufacturer's catalog on demand, from a single admin action, searchable in minutes. For a showroom adding vendors continuously, that difference compounds every single week. It's the piece most search stacks skip, and the one an operator feels every day.\n\n## The bottom line\n\nGo back to that shopper looking for a low, comfy sofa for a small apartment. Whether she finds it or bounces isn't a coincidence — it's a direct result of whether your search understood what she meant, not just what she typed. That's the whole case for semantic and hybrid search: it turns \"0 results\" into a sale you already had sitting in the warehouse, on every product line in your showroom, not just the ones someone remembered to tag well.\n\n## Common questions\n\nWhat is semantic search, in plain terms?\n\nKeyword search finds what shoppers name. Semantic search finds what they mean. A shopper types \"a low, comfy sofa for a small apartment\" — they are describing a feeling and a constraint, not naming a product. If the right piece is filed as \"compact 2-seat loveseat, 32-inch depth,\" keyword search never surfaces it. Semantic search matches the meaning behind the words instead of the words themselves.\n\nWhy do good products stay hidden in a showroom catalog?\n\nYour catalog is tagged by the people and systems that built it — manufacturers, spec sheets, import feeds — and shoppers do not talk like spec sheets. \"Warm brass sconce for a damp bathroom\" and \"antique gold wall light, IP44 rated\" describe the same product and never meet. Keyword search only connects them if someone hand-tagged every synonym in advance. On a small catalog you can brute-force that; across dozens of manufacturers and 100,000+ SKUs the combinations outrun any team you could hire.\n\nDoes semantic search replace keyword search?\n\nNo — it completes it. Keyword matching with BM25 is unbeatable on exact hits: model numbers, SKUs, precise specs. Semantic search catches intent and description. We run both and fuse the rankings, so the shopper who types a SKU gets the exact unit and the shopper who describes a room gets the right options.\n\nHow long does a new manufacturer catalog take to become searchable?\n\nMinutes, from a single admin action. Plenty of systems re-embed on a nightly schedule, so you onboard a vendor and then wait for the overnight run. Ours embeds a manufacturer’s catalog on demand. For a showroom adding vendors continuously, that difference compounds every week.\n\nDoes the embedding model matter?\n\nYes, in two ways. The catalog and the live query have to be embedded by the same model, or the two number-spaces do not line up and relevance quietly degrades — an easy thing to get wrong and a hard thing to notice later, so we verify it rather than assume it. Model size is a measured call: bigger models capture finer shades of meaning at higher storage and compute cost, so we test candidates against a labeled set of real queries and only adopt the leaner one when relevance holds.\n\n## Where this fits\n\nSemantic and hybrid retrieval is one half of catalog discoverability. The other half is whether an AI agent can reach your catalog at all — see [how we run semantic search inside Neural Core](/technology/semantic-search/), and [what a storefront built for two audiences looks like](/ecommerce/websites/) once both halves are in place.\n\nIf the shopper doing the searching is an agent rather than a person, the discovery problem changes shape. [Agentic commerce protocols, explained](/resources/agentic-commerce-protocols-explained/) covers what agents need from your product data, and [the agentic protocol landscape](/resources/agentic-protocol-landscape/) maps the standards underneath.\n\n### Want this working on your showroom?\n\nSemantic and hybrid product discovery is core to what we build. If you're running a large multi-manufacturer catalog and keyword search is leaving sales on the table, let's talk.\n\n[Talk to us](/contact-us/) [More resources](/resources/)" }, { "id": "agent-teams-homepage-competition", "slug": "agent-teams-homepage-competition", "url": "https://www.neuralpartners.ai/resources/agent-teams-homepage-competition/", "title": "40 Minutes. 6 Agents. 3 Competing Homepages.", "type": "guide", "category": "neural-labs", "excerpt": "Neural Partners tested Claude's new Agent Teams feature by running a homepage design competition with 6 parallel AI agents. Three distinct creative directions, QA review cycles, and a clear winner — all in under an hour.", "topics": [ "experiments", "ai-strategy", "neural-labs" ], "author": "Neural Partners", "updated": "2026-02-06T00:00:00.000Z", "readingTime": "5 min read", "featured": false, "trending": false, "image": "https://www.neuralpartners.ai/resources/agent-teams-homepage-competition/images/hero.webp", "bodyFormat": "markdown", "body": "We ran an experiment this week. Claude shipped a new feature called Agent Teams — multiple AI instances that can coordinate, communicate, and work in parallel on a shared project. We wanted to see what it could actually produce on a real creative brief.\n\nSo we set up a competition. Six agents organized into three teams of two. Each team had a frontend developer and a dedicated UX/QA reviewer. The brief: build a new Neural Partners homepage. The primary constraint: it cannot look like AI made it. Best one wins.\n\nEvery team worked in an isolated directory with no shared dependencies. Each produced a single self-contained HTML file — no build step, no risk of teams stepping on each other's work.\n\n## What Makes Agent Teams Different\n\nAgent Teams is still an experimental Claude Code feature, but the architecture is compelling. One session acts as the team lead, coordinating work and assigning tasks. Teammates work independently in their own context windows with full tool access — they can write code, run dev servers, and inspect each other's output.\n\nThe key detail: these agents can see their work. The QA reviewers opened the pages in a real browser, visually inspected layouts, checked responsiveness, filed feedback, and sent it back for iteration. This isn't code review by reading markup — it's visual QA with real screenshots.\n\nEach team went through multiple revision cycles within the 40-minute window.\n\n## What Came Back\n\nThree genuinely different creative directions. Not three variations on a theme — three distinct points of view on what Neural Partners should look and feel like.\n\n**Team 1 — Editorial Elegance.** Clean, asymmetric hero layout with a floating \"94% Agent Readiness\" stat card. Scrolling marquee ticker. Numbered service cards. Light/dark section alternation for rhythm. Professional but played it safe — the editorial concept promised more personality than the execution delivered.\n\n**Team 2 — Bold Interactive.** The strongest first impression. Mixed-weight typography with a floating node network (Schema, Data, Growth, Agents, Creative) orbiting a gradient sphere. Custom cursor follower. SVG blog illustrations. Industry marquee with orange dot separators. The most visually dynamic entry — the kind of site that turns heads in a portfolio.\n\n**Team 3 — Dark Mode Reimagined.** A warm dark palette that avoids the cold, sterile AI aesthetic. Animated gradient orb with floating labels. But the real winner was the copy: \"Ready to build something that actually works?\" and \"Let's skip the pitch deck and have a real conversation about your brand, your customers, and where AI fits in.\" The glassmorphism CTA card at the bottom was the single best design moment across all three entries.\n\n## The Scoring\n\nThe team lead opened all three in Chrome, scrolled through each top to bottom, and scored them across four dimensions:\n\nCriterion\n\nTeam 1: Editorial Elegance\n\nTeam 2: Bold Interactive\n\nTeam 3: Dark Mode Reimagined\n\nVisual Design\n\n7.5\n\n8.5\n\n8.5\n\nUX Quality\n\n7.0\n\n8.0\n\n7.5\n\nCreativity\n\n7.0\n\n8.5\n\n8.0\n\nHuman Feel\n\n7.0\n\n7.5\n\n8.5\n\n**Total (/40)**\n\n**28.5**\n\n**32.5**\n\n**32.5**\n\nTeams 2 and 3 tied on total score, but Team 3 edged the win on the criterion that mattered most — human feel. When your primary constraint is \"don't look AI-generated,\" the team with the most human copy voice and warmth wins. Team 2 was the flashier entry, but flash is something AI does well by default. Team 3's warmth and conversational tone are harder to produce by accident.\n\nThe honest recommendation: the best homepage is probably Team 3's soul layered onto Team 2's visual energy. That's our actual next step.\n\n> The feature is experimental. The implications aren't.\n\n## What We Learned\n\n**The brief matters more than the tool.** The reason this experiment produced genuinely different creative directions is because the constraints were specific. \"Don't look AI-generated\" forced decisions that went beyond impressive CSS tricks and into actual design thinking — copy voice, color warmth, personality. A vague prompt would have produced three variations of the same generic SaaS template.\n\n**QA teammates changed the output quality significantly.** Having a dedicated reviewer who could visually inspect the work in a real browser — not just read the code — created a feedback loop that meaningfully improved each variation through iteration. The QA agents caught spacing issues, animation timing problems, and contrast concerns that a code-only review would have missed.\n\n**The competition format works.** Framing it as a competition rather than a single team doing three passes produced more creative divergence. Each team committed to a distinct direction rather than hedging toward a safe middle ground.\n\n**It's still early.** Agent Teams is experimental. Session resumption doesn't work yet, which limits long-running jobs. Token costs multiply with each agent. The coordination overhead means this isn't the right tool for every task — it shines when parallel, independent work on a well-scoped brief adds real value.\n\n## The Numbers\n\n- **6** agents working in parallel\n- **~40 minutes** total execution time\n- **~800,000** tokens consumed\n- **3** complete homepage variations with multiple QA iterations each\n- Run on **Claude Max** subscription\n\n## Bottom Line\n\nWe're going to keep running these. Different briefs, different team structures, different project types. The pattern of parallel creative exploration with built-in QA is too useful to leave as a one-off experiment.\n\nIf you want to try it yourself: [Claude Agent Teams documentation](https://code.claude.com/docs/en/agent-teams).\n\n### How Neural Partners Can Help\n\nOur [AI & Technology](/solutions/ai-technology/) team helps brands navigate tools like these — separating signal from noise and finding the workflows that actually move the needle.\n\n[Explore Our Services](/neural-labs/services/) [Start a Conversation](/contact-us/)\n\n## Continue Reading\n\n[\n\nJanuary 2026\n\n### The Infrastructure for Agentic Commerce Just Arrived\n\nGoogle, Shopify, Walmart, and Target just released UCP — the open standard defining how AI agents browse, checkout, and transact at scale.\n\nRead more →](/intelligence/the-infrastructure-for-agentic-commerce-just-arrived/)[\n\nOctober 2025\n\n### The Agentic Consumer Part 3: Building for What's Next\n\nThe final installment of our series on how AI agents are reshaping commerce, and what brands need to build now.\n\nRead more →](/intelligence/the-agentic-consumer-part-3-building-for-whats-next/)[\n\nJuly 2025\n\n### Cannes Lions 2025: Where AI Hype Finally Hit a Human Wall\n\nThe spotlight shifted from AI hype to human insight, marking a pivotal moment for marketing grounded in ethics, clarity, and creative truth.\n\nRead more →](/intelligence/cannes-lions-2025-review/)\n\n### Want to See What AI Can Build for You?\n\nWe're running experiments like this every week — testing new tools, new workflows, and new ways to move faster. Let's talk about what that looks like for your brand.\n\n[Start a Conversation](/contact-us/)" } ] }