I see Profound’s MCP evolution as a meaningful shift for Marketing Engineers. It now connects agents to a knowledge graph and adds 15 new capabilities built around how marketing teams actually work.
For retailers, I believe this demands a serious reframe. Answer engines are already shortlisting products and shaping purchase decisions long before shoppers ever land on retail or ecommerce websites. That compresses the shopping funnel and makes traditional search less reliable as the primary channel for customer acquisition.
Instead of waiting for shoppers to arrive through search, I need to think about how retailers can be recommended throughout the entire shopping journey. That means understanding how people use answer engines for Christmas gifting, how brands earn mentions and citations in relevant AI responses, and how visibility can be maximized across AI search experiences.
I see this report as a practical edge for retailers preparing for the next holiday cycle. It uses real shopper behavior from Christmas 2025, analyzed through Profound’s AI visibility lens, to show how people are using AI to shop for the holidays.
Most importantly, it turns those insights into actionable takeaways. By understanding where answer engines influence discovery, comparison, and purchase decisions, I can see how ecommerce teams should optimize product visibility before the 2026 season ramps up and compete more effectively for the AI shelf this Christmas.
Making a brand machine-readable and improving its odds of being selected for AI-generated answers are important, but I see them as only part of the larger shift. Under the surface, a retrieval layer is changing how AI systems identify entities, connect facts, and decide which brands deserve to be cited.
That layer is GraphRAG. Once I understand how it works, “optimize for AI” stops feeling like a vague instruction and starts looking like a practical SEO strategy.
What is GraphRAG, actually?
GraphRAG extends traditional retrieval-augmented generation (RAG) by adding a knowledge graph. That graph helps AI understand entities and the relationships between them, instead of treating content as disconnected text fragments.
Microsoft Research introduced GraphRAG in 2024, and a broader ecosystem has formed around it since then. Instead of pulling from a flat sea of text chunks, GraphRAG builds a map.
In that map, nodes are the entities: a company, product, person, certification, location, or concept. Edges are the relationships between those entities, such as “offers,” “is certified by,” “authored,” or “operates in.”
I think of it as a system of things and the lines connecting them. When a model works from a map instead of a pile of scraps, it does not have to guess its way toward an answer. It can follow the relationships.
If the map says Entity A holds Certification B in Region C, the system can follow that path with confidence instead of inferring the connection and hoping it is right. That is why graph-based retrieval can produce more complete, better-grounded answers to complex questions with fewer hallucinations.
Microsoft described this failure mode in its GraphRAG patent, “Knowledge Graph Extraction” (US20250131289A1). The patent calls out a recall problem in naive RAG: a less prominent entity can disappear inside chunk embeddings, which means the system may retrieve nothing useful.
It also describes one of the fixes: entity resolution. When duplicate spellings or variations of the same thing are merged, the system can treat them as one entity instead of scattering their authority across several weak signals. That is one of the core building blocks behind graph-based retrieval.
Traditional RAG works by chopping content into fixed chunks, turning each chunk into a vector, and storing those vectors in a database. When I ask a question, the system retrieves the closest chunks in vector space and passes them to a language model to generate an answer.
That can work for simple questions like “What is the capital of France?” It struggles with the questions that usually matter most in business: the multi-step questions.
If I ask a system to find a provider that offers a specific service, holds a specific certification, and operates in a specific region, naive RAG may stitch together an answer from scraps that merely sound related. It does not truly understand how the facts connect, so it guesses across the gaps.
When a system has to guess, the safer move is often to leave a brand out rather than risk saying something inaccurate about it. That is the part I think many SEO teams need to sit with.
This explains a common frustration: “Our content is strong, but AI systems still do not cite us.” The issue may not be content quality. GraphRAG consistently outperforms naive RAG on complex, multi-hop questions where vector search falls apart. That is where the visibility leak often starts.
In many cases, the machine could not reliably tell what the brand is, how its facts fit together, or whether it could trust those relationships enough to cite the brand by name.
The three problems GraphRAG is built to fix
I see GraphRAG lining up with three SEO problems that show up again and again: disambiguation, attribution, and relationships.
Disambiguation matters when the same entity appears under different names and gets counted as several weaker signals instead of one strong one. If “the firm,” “the agency,” and the actual brand name never resolve to a single entity, authority gets split.
Attribution matters when the fact survives but the credit disappears. When content is blended into an AI answer, the brand behind the original insight can easily vanish.
Relationships matter when the connections that give expertise meaning stay buried in prose instead of being declared in a way a machine can read.
If I have ever watched AI repeat something a company wrote without naming it, or credit a competitor for a specialty the company actually owns, I have seen all three problems in action.
What ties them together is simple: this is not only a content problem. It is an identity problem.
Same sentence, more machine-readable context
I want to make the idea of an entity concrete, because it can become abstract quickly. I will use one real-world example and one fictional example.
Start with Wayne Gretzky. Search his name in almost any AI client and I expect to see a confident summary: facts, former teams, records, and related links. That confidence is not luck. It is what a well-established entity looks like. His identity is nailed down and agreed upon across the web, so the system does not have to guess who he is.
Now imagine the opposite. Picture a goaltending coach in Moncton. I will call her Marie Tremblay. Her About page says: “Our head coach, Marie ‘Lefty’ Tremblay, has run elite goaltending camps across the Maritimes for 20 years.”
That is a good sentence. A parent understands it immediately. I would not rewrite it into robotic prose just to satisfy a machine. Optimizing for AI does not mean abandoning human voice.
The better move is to keep the sentence and add context around it. I need to make explicit what a human reader infers automatically.
That means clarifying that “Lefty” and “Marie Tremblay” are the same person. It means connecting Marie to the academy, to goaltending as a discipline, and to the Maritimes as the region she serves. It also means making “20 years” and “elite” verifiable claims rather than loose adjectives.
A human gets all of that from one sentence. A machine may not. My job is to close the gap between what the reader understands and what the system can verify, so Marie becomes as legible to AI retrieval systems as a famous entity like The Great One already is.
Why a flat triple is no longer enough
Knowledge graphs are built on triples: subject, predicate, object. “Acme offers consulting” is clean and useful, but it is flat. A bare triple cannot easily carry the high-stakes details that matter, such as whether the relationship is true, where it applies, who says so, and what evidence supports it.
The standards community is working on that gap. The W3C is extending the model with Resource Description Framework (RDF)-star, which allows site owners to make statements about statements. In practice, that means source, date, confidence, and other metadata can attach directly to a relationship instead of floating around as a disconnected claim. It is moving through the RDF 1.2 standardization process, with the RDF 1.2 Primer serving as a plain-English introduction.
Microsoft’s GraphRAG patent points in a similar direction. It pulls claims into a subject-action-object structure and weights relationships by how often they appear, instead of treating every stated link as equally reliable.
The practical lesson is clear to me: the future is not just saying two things are related. It is saying they are related and showing the proof in a form a machine can verify. A richer triple beats a flatter page.
The publishing layer is starting to respond
I am also watching the publishing layer, because that is where the shift is becoming visible outside the models themselves.
On June 1, the new open standard EntityMap launched a 33-day public consultation ahead of its July 1 launch. It was started by Fred Laurent, CTO of InLinks and Waikay, with backing from Dixon Jones. For anyone following entity SEO and the move from “strings to things,” those names matter.
The concept is deliberately familiar. Where sitemap.xml tells search engines which pages exist, an entitymap.json file tells AI systems what an organization knows: which entities it covers, how they relate, and where the evidence lives.
EntityMap aims at the same three problems: disambiguation, attribution, and relationships. It also builds in the richer-triple idea by allowing declared relationships to carry receipts, including a source URL, publisher, and timestamp.
I would treat it as a signal, not a mandate. EntityMap is a proposal in consultation, not a requirement. No major engine has committed to reading files like these, so I would not turn it into another box-checking exercise yet. The important point is that credible people are building entity-first publishing standards, and that direction is worth watching.
The honest state of GraphRAG
I do not think GraphRAG belongs in hype territory, because two realities keep it grounded.
First, GraphRAG is expensive. Building the map requires a language model to extract entities and relationships, and that is the costly part. By Microsoft’s own estimate, graph extraction accounts for roughly 75% of indexing costs. That LLM cost is one reason web-scale, real-time graph retrieval has not taken over everything overnight.
Second, the cost curve is bending. Recent research is attacking the infrastructure problem directly, including TurboQuant, a vector compression method from Google Research and NYU, presented at ICLR 2026. It reduces the memory footprint of vectors these systems traverse while preserving quality well enough to make the economics more interesting.
That does not mean every engine is running GraphRAG across the open web today. It means the economics are improving, which helps explain why entity-first standards are emerging now. I am cautious about anything framed as inevitable, but this shift makes practical sense.
Structured data still matters. Schema.org markup, a clean Knowledge Panel, consistent NAP, and strong entity signals are not going away. Entity-first work extends that discipline. It does not replace it.
My entity-first action plan
Here is how I would make this practical without betting everything on one standard.
Inventory entities, not just keywords. I would go beyond the search terms that historically brought traffic and list the things the brand genuinely knows about: products, services, people, methods, concepts, locations, and credentials. That becomes an entity map, whether or not it ever gets published as a formal file.
Disambiguate, then connect to the graph. I would claim and confirm the brand’s Wikidata entity and Google Knowledge Panel where possible. I would standardize naming, resolve variants, and keep sameAs links consistent across structured data. This is how “Lefty” and “Marie Tremblay” become one clear identity instead of two weak signals.
Make relationships explicit. I would use Schema.org types and properties such as Organization, Person, Product, knowsAbout, sameAs, and author so expertise is declared rather than implied. I would also mirror those relationships in internal linking.
Attach evidence to every claim. I would connect important facts to verifiable sources: named authors, first-party data, citations, documentation, and dated references. Graph-based systems increasingly need proof behind a relationship, not just the assertion.
Front-load defining facts. Retrieval still works through narrow windows, so I would place the clearest, most verifiable statement of what the brand is and what it does near the top of important pages.
Watch the publishing layer without overcommitting. I would read the EntityMap spec, follow how it develops, and decide later whether an entity index belongs in the stack. Schema.org work should continue either way.
Tie the entity map to revenue. I would map entity coverage to the queries and answer surfaces that influence leads, sales, margin, and retention. That helps leadership see entity work as revenue protection, not an academic exercise.
Measure what AI systems can recognize
Rankings and clicks still matter, but they describe the old search-page model. I would add metrics that show whether AI systems can recognize, trust, and cite the brand.
AI citation share measures how often the brand is named or cited in AI answers compared with competitors. I would track it monthly with an AI visibility tool.
Entity recognition asks whether priority entities have confirmed Knowledge Panels, Wikidata entries, and consistent identity signals. It is simple, but foundational.
Relationship completeness looks at how many priority entities have explicit, marked-up relationships and consistent sameAs links.
Attribution rate tracks how many core claims are backed by linked, verifiable evidence.
Answer-equity proxies include branded-query lift, assisted conversions from AI referrals, and lead stability as raw click volume softens. These business signals help show whether authority is compounding even when CTR is harder to read.
Where graph-based retrieval is heading
I expect graph-based retrieval to keep moving toward multimodal graphs, where text connects to images, audio, video, and structured data. I also expect more streaming and incremental indexing for live data, plus domain-specific ontologies for areas like medicine, finance, and law.
The move from strings to things is gaining momentum. The brands that stay visible will not simply be the ones publishing the most content. They will be the ones machines can understand without guessing, with clear entities, explicit relationships, and claims backed by evidence.
I do not need to wait for a new standard to launch before preparing. I can make a brand more legible now to systems that do not just read pages, but read what the brand knows. In the answer economy, I see the real battleground as identity, not just content.
I see vibe coding as one of the most accessible ways to create small pieces of software with AI tools like ChatGPT, Cursor, Replit, and Gemini. Instead of writing code line by line, I describe what I want in plain language, receive working code in return, paste it into an environment like Google Colab, run it, and test the result.
In this guide, I’ll explain how I approach vibe coding, where I think it works well, where it breaks down, and which SEO examples can inspire practical projects of your own.
Vibe coding variations
I use “vibe coding” as a broad term, but it helps to separate it from nearby approaches:
Type
Description
Tools
AI-assisted coding
AI helps write, refactor, explain, or debug code. I usually associate this with developers or engineers who already understand the systems they are building.
GitHub Copilot, Cursor, Claude, Google AI Studio
Vibe coding
AI handles most of the work after I provide the idea or prompt.
ChatGPT, Replit, Gemini, Google AI Studio
No-code platforms
Platforms handle what I ask for through visual interfaces, drag-and-drop workflows, or background automation. Many now use AI, but they existed before AI became mainstream.
Notion, Zapier, Wix
For this guide, I’m focusing only on vibe coding.
The barrier to entry is low. In most cases, I only need a ChatGPT account, free or paid, and access to a Google account. Depending on the project, I may also need API access or subscriptions to SEO tools such as Semrush or Screaming Frog.
I also like to set expectations early: by the end of this kind of workflow, I’m usually aiming to run a small program in the cloud. If I want to build a SaaS product or software I plan to sell, I treat AI-assisted coding as the more realistic path because it usually requires more technical knowledge, more testing, and more budget.
Vibe coding use cases
I find vibe coding most useful when I’m working with clear buckets of data and need a helpful outcome, not a perfect one. That might mean finding related internal links, adding pre-selected tags to articles, comparing groups of URLs, or building something playful where the output does not need to be exact.
For example, I built an app that creates a daily drawing for my daughter. I type a short phrase about something she told me, such as “I had carrot cake at daycare.” The app uses examples of drawing styles I like and a few pictures of her, then generates a drawing as the final output.
When I ask for precise changes, the tool often gets worse. I once asked it to remove a mustache, and instead it recolored the image. That is exactly the kind of limitation I expect with this approach.
If my daughter were a client reviewing every detail, I would need someone with Photoshop or similar skills to make exact edits. For this use case, though, the result is good enough, and that is where vibe coding shines.
I would be cautious about building commercial applications solely through vibe coding. Some companies may even need vibe coding cleaners to clean up AI-generated work. But for demos, MVPs, internal tools, and quick experiments, I see vibe coding as a useful shortcut.
How I create SEO tools with vibe coding
When I create an SEO tool with vibe coding, I usually follow three steps:
I write a prompt describing the code I need.
I paste the code into a tool such as Google Colab.
I run the code and check whether the results match what I expected.
Here’s a real prompt example from a tool I built to map related links at scale. After crawling a website with Screaming Frog and extracting vector embeddings through the crawler’s OpenAI integration, I vibe coded a tool to compare topical distance between the vectors for each URL.
This is exactly what I wrote in ChatGPT:
I need a Google Colab code that will use OpenAI to:
Check the vector embeddings existing in column C. Use cosine similarity to match with two suggestions from each locale (locale identified in Column A).
The goal is to find which pages from each locale are the most similar to each other, so we can add hreflang between these pages.
I’ll upload a CSV with these columns and expect a CSV in return with the answers.
After ChatGPT generated the code, I pasted it into Google Colab, which is a free Jupyter Notebook environment for running Python in a browser. I then used “Run all” to test whether the program produced the output I wanted.
That is the clean version of the process. In practice, AI can make the workflow look perfect while still producing code that does not behave the way I need.
I expect issues along the way, and most of them are simple to troubleshoot if I keep the prompt and testing process clear.
First, I always state the platform I’m using. If I want code for Google Colab, I say that directly in the prompt.
Sometimes I still get code that depends on packages that are not installed. When that happens, I paste the error back into ChatGPT and ask it to fix the code or suggest an alternative. I do not need to fully understand the missing package to move forward. I can also ask Gemini inside Google Colab to identify the problem and update the code directly.
I also check outputs carefully because AI can sound confident while inventing data. One time, I forgot to specify that the source data would come from a CSV file, so the tool created fake URLs, traffic, and graphs. “It looks good” is not the same as “it is correct.”
If I connect to an API, especially a paid API from a provider such as Semrush, OpenAI, Google Cloud, or another platform, I need to request my own API key and keep usage costs in mind.
A Semrush subscription screen highlights 2 million Standard API units and a masked API key, underscoring the setup step needed for SEO automation and vibe-coded tools.
If I want an even lower execution barrier than Google Colab, I can use Replit.
With Replit, I can prompt what I want, and the platform can generate the code, design the interface, and let me test everything in one place. That reduces copy-and-paste work and gives me a shareable URL quickly. I still need to review poor outputs and keep iterating until the app behaves properly.
The tradeoff is cost. Google Colab is free unless I use paid API keys, while Replit charges a monthly subscription and usage-based API fees. The more the app runs, the more expensive it can become.
SEO vibe-coded tools that inspire me
Google Colab is the easiest place for me to start, but SEOs are taking vibe coding much further. I’ve seen people create Chrome extensions, Google Sheets automations, and even browser games.
I’m sharing these examples because they show what is possible when useful SEO ideas meet practical AI tooling. If I see a tool and wish it had a different feature, that is often a sign that I could try building a version for myself.
A Replit vibe-coding session turns a simple prompt for toddler-friendly daily jokes into a published web app, illustrating how AI tools can quickly prototype playful ideas.
GBP Reviews Sentiment Analyzer by Celeste Gonzalez
After vibe coding SEO tools in Google Colab, Celeste Gonzalez, Director of SEO Testing at RicketyRoo Inc, pushed the idea further by creating a Chrome extension. “I realized that I don’t need to build something big, just something useful,” she explained.
Her extension, the GBP Reviews Sentiment Analyzer, summarizes sentiment analysis from reviews over the last 30 days and shows review velocity. It also exports the information to CSV and works on Google Maps and Google Business Profile pages.
Instead of relying only on ChatGPT, Celeste used Claude to create stronger prompts and Cursor to turn those prompts into code.
AI tools used: Claude (Sunner 4.5 model) and Cursor
APIs used: Google Business Profile API (free)
A vibe-coded GBP Sentiment Analyzer turns review data into a quick snapshot, showing negative sentiment trends, key topics, and an export option for SEO workflows.
Platform hosting: Chrome Extension
Knowledge Panel Tracker by Gus Pelogia
I became obsessed with the Knowledge Graph in 2022, when I learned how to create and manage my own knowledge panel. Later, I discovered that Google’s Knowledge Graph Search API lets me check the confidence score for any entity.
That led me to build a vibe-coded tracker that checks entity scores daily, or at any frequency I choose, and returns the results in a Google Sheet. I can track multiple entities at once and add new ones whenever I need to.
The Knowledge Panel Tracker runs entirely in Google Sheets, and the Knowledge Graph Search API is free to use. This guide explains how to create and run it in your own Google account, or you can see the spreadsheet here and update the API key under Extensions > App Scripts.
AI models used: ChatGPT 5.1
A spreadsheet-based Knowledge Panel Tracker turns entity searches into structured SEO data, comparing names, entity types, descriptions, and confidence scores at a glance.
APIs used: Google Knowledge Graph API (free)
Platform hosting: Google Sheets
Inbox Hero Game by Vince Nero
I also like the idea of vibe coding a link building asset. That is what Vince Nero from BuzzStream did with the Inbox Hero Game. The game asks players to use the keyboard to accept or reject a pitch within seconds, and it ends if they accept too many bad pitches.
Inbox Hero Game is more complex than running a small script in Google Colab, and it took Vince about 20 hours to build from scratch. “I learned you have to build things in pieces. Design the guy first, then the backgrounds, then one aspect of the game mechanics, etc.,” he said.
The game was built with HTML, CSS, and JavaScript. “I uploaded the files to GitHub to make it work. ChatGPT walked me through everything,” Vince explained.
A retro arcade-style Inbox Hero screen turns PR pitch triage into a fast keyboard game, challenging players to accept or reject emails before time runs out.
He also found that longer prompt threads became less useful over time, “to the point where [he’d] have to restart in a new chat.”
That became one of the hardest parts of the project. Vince would add a feature, such as a score, and ChatGPT would “guarantee” it had found the error, update the file, and still return the same problem.
In the end, Inbox Hero Game shows that it is possible to create a simple game without coding knowledge. It also shows where a developer becomes valuable when the goal shifts from “working prototype” to polished product.
AI models used: ChatGPT
APIs used: None
Platform hosting: Webpage
How I think about vibe coding with intent
I do not expect vibe coding to replace developers, and I do not think it should. What I do see is a practical way for SEOs to prototype ideas, automate repetitive tasks, and explore creative experiments without a heavy technical lift.
The key is realism. I use vibe coding where precision is not mission-critical, I validate outputs carefully, and I stay alert for the moment when a project grows beyond “good enough” and needs stronger technical support.
When I approach vibe coding thoughtfully, it becomes less about shipping perfect software and more about expanding what I can test. For internal tools, proofs of concept, and SEO side projects, the best results come from pairing curiosity with restraint.
I started this series with a simple observation: AI systems do not always give the same answer to the same question. My argument was that this inconsistency is not just randomness. It is confidence loss across a pipeline we can measure, diagnose, and improve.
As I worked through the AI engine pipeline gate by gate, I eventually reached the won gate. That is where three kinds of clicks appear: the imperfect click of search, the perfect click of recommendations, and the agentic click of agents.
That is also where I realized this conversation could not stay inside marketing. When an agent makes the purchase, it becomes a client I have to satisfy directly.
The funnel now runs through machines that connect directly to the business itself. SEO therefore becomes part of something larger: assistive agent optimization, and ultimately AI-era business engineering.
To understand why, I need to connect the pieces. The framework explains why AI systems make the decisions they make and what shapes those decisions. When I apply those principles across the business, the goal becomes clear: organize the company so search engines, AI assistants, agents, and people can find it, understand it, recommend it, and buy from it.
Everything Builds On SEO
The process sits above the familiar disciplines I already work with: SEO, content, PR, paid media, and digital marketing. It helps me prioritize the actions that most affect recommendations and visibility.
Here is the part every SEO should value: assistive agent optimization is built on SEO. It does not replace it.
I think of it like a Russian doll. SEO sits at the center. It draws from the open web, the same crawled and indexed foundation search has always used.
At that core are two parts of the algorithmic trinity: the search engine, which indexes and ranks information, and the knowledge graph, which stores entities and the relationships between them.
The next layer is assistive engine optimization. It adds the third component: the large language model. The LLM provides reasoning, grounding, and conversation.
Instead of returning only a list of links, it evaluates corroborating evidence and answers the user directly. This layer builds on traditional SEO with entity corroboration, machine-readable proof, and signals that help AI systems understand what content actually means.
The outer layer is the agent. It introduces what the layers below it never had: direct access to business systems through protocols such as MCP. An agent can check inventory, compare prices, and complete transactions without visiting a page or clicking through a search result. This is where AI stops recommending and starts acting.
Each layer depends on the one beneath it. The stronger the SEO foundation, the more effectively I can build everything above it. That makes SEO more central to digital marketing, and to the business itself, than it has ever been.
If I understand how machines read the web, I hold the foundation every other AI-facing initiative depends on.
The Funnel Has Not Changed, But The Build Direction Has
The acquisition funnel has not fundamentally changed since marketers first drew it in the 1800s. Awareness still sits at the top, consideration in the middle, and decision at the bottom. The customer still moves downward while the brand tries to catch them. What has changed is where I have to stand to catch them.
Traditional marketing stood in front of people in the real world, on billboards, shelves, and stages. Digital marketing did the same online through SEO, paid search, social media, and content. AI-era marketing extends that logic again.
Now I have to stand where I always stood and also inside the AI engines. Those engines put brands in front of buyers, present the best solution, and increasingly make the purchase.
The modern buyer mixes all three modes in a single purchase, so I have to be present in all of them. The client still travels from the top of the funnel down, but the engines learn from the bottom up. That is how I need to build for them.
Marketers draw the funnel top-down because that is the customer path. But businesses have always had a reason to read it the other way. Winning the result for your own name is the cheapest and highest-converting move because it reaches the warmest traffic: people already at the door.
I have made that case since 2012, when I started working on brand SERPs. Your name is the one search result you can most completely own, yet the industry ignored it for years.
Comparison and consideration queries come next because they sit near the purchase, where buyers are most likely to convert. Awareness is the last thing I build, because those people often do not yet know what they want or what the solution might be.
The engines make this flip unavoidable. Search engines let users move between sites on the way down the funnel, so top-down building could still work. Assistive engines pull the funnel inside themselves. Now I build from the bottom up because that is how the machine learns who to trust.
Agents push this even further. The funnel goes dark, and the choice often goes with it. Each step takes more of the journey out of my hands, and each rewards the same brand: the one built from the bottom up.
The Agentic Spectrum Decides How Much Must Change
Two ideas tell me how much of a business has to change. The first is the delegation boundary. The second is the agentic spectrum.
The delegation boundary is the micro view. It tracks how much of one buyer journey, from searching to comparing to choosing to buying, a person hands to a machine.
The agentic spectrum is the macro view. It asks what share of the clientele has gone agentic and how quickly that share is growing.
The micro view tells me how to win one buyer in the moment. The macro view tells me how much of the business has to change to keep winning buyers over time. This is the number I would start measuring first.
Here is why it reorganizes the business, not just the marketing. When the agent makes the purchase, it becomes a client I have to satisfy directly, even as it acts for the person behind it. It answers to one priority: keeping its own user happy.
That means the sale turns on confidence. Can the machine trust the business to meet the need and keep its client satisfied?
That confidence has to clear a much higher bar than search or assistive engines required. It runs across the full funnel. If I earn it across the stack, I become the brand the agent buys from.
Preparing for that is what AI-era business engineering means. Pricing, qualification, product data, checkout, service, and retention all need to be built so an agent can transact as cleanly as a person can.
The agent navigates the whole funnel on its own. I have to convince it at every stage, from awareness to the final yes, while getting almost no visibility into the journey. What I do get is granular measurement at negotiation and transaction stages. The agent tells me what it wants, and I either satisfy it or I do not.
That is why I need to build the business to work cleanly with agents and people alike, from the top of the funnel to the moment the deal is struck.
Translating what a company does for humans into something machines can read and act on used to feel optional. Ignoring search engines and assistive engines was never wise, but many companies survived it. In the age of agents, ignoring the engines hands a growing share of the clientele to competitors.
Your Untrained Salesforce Is Already Selling
Every business now has a salesforce it never hired: Google, ChatGPT, Perplexity, Claude, Copilot, Siri, Alexa, and many more. The number keeps growing as major tech platforms add AI answers inside social media, video, search, operating systems, and workflow tools.
The apps people already use now embed assistants that recommend tools, vendors, and products. A buyer does not need to open a separate AI engine for this to happen.
Those engines reach prospects in explicit, implicit, and ambient ways. However they appear, the outcome is the same: they work around the clock, speak to prospects in rooms I will never see, and decide whether to recommend me or a competitor.
The default state of that salesforce is untrained. If someone asks about my category, it answers with the brands it happens to understand, and that may not be mine. It may hedge on basic facts, confuse the brand with a namesake, cite proof that does not exist, recommend the wrong use case, or name a competitor at the exact moment the user was looking for me.
The cost is real, but it often never appears on a dashboard. I cannot watch the AI research the brand, evaluate it, recommend it, or talk a buyer out of choosing it. It all happens inside the machine. That is why I pay attention to three taxes: invisibility, ghost, and doubt.
AI engines recommend the solution they are most confident in, and that is not always the best solution. It is often the one they understand best. The recommendation depends on what they grasp and how confident they are in it.
So if my solution is truly the best, I have to train them. I have to educate them and brief them. They answer to the user, and my client is their client. They retain that client by surfacing the strongest solution they can see.
The practical question is simple: have I made it unmistakably clear that I am the best answer to the specific problems I solve, for the ICP I serve?
Three Taxes Quietly Cost Recommendations
I pay a tax at every stage of the funnel for as long as this AI salesforce is not working explicitly in my favor.
Someone types the brand name directly into an engine, and instead of a clean answer, it hedges with phrases such as “claims to be,” “reportedly serves,” or “says on its website.” Worse, it may start offering alternatives.
Search engines usually do that only when a competitor pays heavily to appear on the brand SERP. Otherwise, the brand owns its own name.
AI can raise the alternative on its own, purely because it is uncertain. That is why brand SERP and AI résumé protection are no longer optional.
That hedge and nudge are the doubt tax. I pay it when the engine lacks enough independent corroboration to commit. It sits at the understandability layer, and the cost is every prospect who came looking for the brand by name and left with doubt.
The ghost tax appears when a prospect asks the engine to compare the category and name the best options. The engine lists several brands, but mine is missing. It knows I exist, yet it does not surface me because its confidence in my credibility is too low.
The invisibility tax appears at the top of the funnel. Someone asks a question I am well qualified to answer, and I am nowhere in the response because the engine never identified me as belonging in that conversation. I never see it because the conversation ends without me.
I need to track these taxes across every engine and every layer, and I should not use only my own account. It is biased toward me. The right approach is proper tracking, neutral testing, and better questions.
The funnel query pathway is the best way to read this over time and across the web. What I am measuring is leakage at each layer. Because the system is opaque, I read the macro trend rather than overreacting to one response.
Then I build from the bottom up and clear the taxes in revenue order.
I clear the doubt tax first because it affects the warmest traffic.
I clear the ghost tax next because it affects buyers comparing close options.
I clear the invisibility tax last because it sits furthest from the purchase.
That is the funnel flip again. AI engines have turned the old top-down playbook upside down.
The Algorithmic Trinity Is Where The Work Lands
I train the AI salesforce in three places, and I need to be present in all three for that training to hold.
Large language models do the reasoning at the moment of the query. This is the intelligence layer: ChatGPT, Claude, and Gemini.
Search engines index and rank fresh content. This is the information layer: Google and Bing.
Knowledge graphs store entities and verified relationships. This is the verification layer: Google’s Knowledge Graph, Wikidata, and Bing’s entity graph.
Those three layers are the algorithmic trinity.
I may be aiming at dozens of platforms and surfaces where this salesforce appears, but there are only a few machines at the root. At mass-market scale, the practical LLM list narrows quickly to ChatGPT and Gemini. There are two major web indexes, Google and Bing, and two major knowledge graph owners, Google and Bing again.
Everything I train reaches back to the same small set of underlying systems. The corroboration work I do for one engine often strengthens the foundation for all of them.
That is why the effort compounds. The knowledge graph confirms the entities the LLM reasons about. The search engine surfaces the fresh content the LLM grounds on. The AI salesforce becomes fully trained when all three converge on the same answer about the brand.
That convergence is where I win: independent systems reaching the same conclusion about who I am, what I do, who I serve, and why I am credible. When I give them that picture in detail, they can hold it with confidence.
At that point, the trinity can surface the brand at the bottom of the funnel, recommend it over competitors in the middle, and advocate for it at the top across search engines, assistive engines, and agents.
The results vary because each platform mixes technologies differently, but the direction starts to favor the trained brand.
Google owns all three layers and remains the dominant force across search and assistive engines, so it remains the main target.
I am not suggesting that I ignore smaller players such as Claude or DuckDuckGo. They matter to the audiences that use them. But for most brands, users, and SEOs, the major public engines are still the key to commercial success.
A tight digital footprint, cleaned up and optimized on-site and off-site, feeds the trinity. At mass-market scale, that means Gemini and ChatGPT, Google’s and Bing’s knowledge graphs, and Google’s and Bing’s search indexes.
The useful side effect is that this strategy also helps with smaller players.
Third-Party Proof Is What AI Believes
Knowing where the work is ingested is only half the job. I also need to know which evidence the AI salesforce believes. Not all evidence carries the same weight, and the gap between weak and strong proof is often the differentiator.
The weakest evidence is what a brand publishes about itself, in its own voice, on its own properties: homepage copy, about pages, and product descriptions. I call this first-party evidence. It is a claim and a baseline, but it proves little on its own because the engines know who wrote it.
If I surface a client outcome, case study, or customer review on my own off-site channel, I move up to second-party evidence. The substance is no longer entirely my assertion, even though I still control the publish button.
Then there is evidence I had no hand in publishing: clients and partners describing their own experiences, an independent journalist’s article, an analyst report, or coverage controlled entirely outside my reach. That is third-party evidence, and it is the strongest proof the salesforce can read because I could not directly shape it.
It is also the category many brands lack because it requires real-world activity, not just publishing. First-party claims, second-party corroborates, and third-party proves. Without proof, nothing stands.
Three Levels Of Effort Create Different Outcomes
Most brands sit at the bottom without consciously choosing to. The minimum-effort brand keeps a website, runs some content marketing, responds to occasional mentions, and otherwise lets the ecosystem do what it does. It appears in machine-readable form but does not shape that form.
Because minimum effort is treated as normal, many companies land here and never recognize it as a decision. Their AI salesforce is barely trained.
The next level appears when a brand notices specific problems and fixes them: an incorrect fact in an AI Overview, a competitor outranking it for a query, or a structured data gap. Those fixes help, and the brand becomes better positioned.
But the work is still symptom-driven. It patches what breaks loudly without building the discipline that prevents the next break. The salesforce is partially trained, but problems are driving the strategy.
The systematic brand runs an operational discipline against the pipeline every week: entity home maintenance, evidence harvested from service teams, machine-readable proof, distribution across publication tiers, and continuous monitoring of the brand SERP and AI résumé.
Most companies are not organized to make that happen naturally. But if I can harvest, codify, and distribute the evidence created by business operations, I can train the AI salesforce to work in my favor around the clock.
I would start from the entity home. I would organize the brand SERP and the AI résumé, then optimize the digital footprint wherever the brand appears. That is understandability, and it is the most important first move.
With the core entity locked, I can build credibility on top of it through engagement, reviews, client feedback, PR, and evidence that the business is genuinely good at what it does.
Deliverability follows because work on the brand SERP and AI résumé already strengthens credibility and reach. Then I can spread the same discipline across every entity the company owns: products, services, and people.
For each entity, I need the right content, presence where the audience is looking, a path down the funnel, and a clear connection back to the entity home. I need to walk the walk and apply the mirror principle.
The Salesforce Is Already Working
In 2026 and beyond, the AI salesforce operates inside the supply chain as well as the sales funnel. AI sits at the gates that decide whether to include a brand in what it knows, whether to deploy it in an answer, and whether to reselect it after every transaction.
Every outcome customers experience feeds back into the system for the next prospect who has never heard of the brand. That is the convergence this series has been pointing toward. The salesforce is selling 24 hours a day, for the brand or for a competitor. The difference is how well it has been trained.
This is why I see the discipline as AI-era business engineering, not just AI-era marketing. It is not a content tactic. It is a reorganization of how the business operates so pricing, qualification, product presentation, sales, retention, and customer success all create machine-readable evidence as a byproduct of doing the job.
SEOs Are In The Best Seat In The Room
When I speak with entrepreneurs and CEOs, I use nine questions to show where the company stands.
Tech, bottom to top: Is our entity home locked down so engines have one source of truth about who we are? Is our structured data complete enough for them to verify what we claim? Are we discoverable across every engine when topical questions appear?
Marketing, bottom to top: What does our brand SERP look like today, and what does the AI résumé say when engines are asked about us directly? Where is our third-party corroboration weakest, and what are we doing about it this quarter? Which topical territory do we own in the engines, and which territory do we want but not yet hold?
Branding, bottom to top: Does our brand story match what AI is currently saying about us, and where is the gap? Are our client outcomes being engineered into machine-readable evidence, or are they dying in CRMs and quarterly retrospectives? Are we placing proof now for the categories we want to own in three years?
All of those questions run from the bottom up, which is ironic because marketers usually work the funnel from the top down. The customer is the one moving from top to bottom, looking for a solution.
So I take a step back and read the funnel from the bottom up. Everyone is building the same thing: understandability, credibility, and deliverability. They are just approaching it from different ends.
The business builds from the foundation up: know who you are, know who you serve, become credible, then reach the right people.
The marketer wants the maximum audience and starts with reach, then works down to who the brand is and why it should be trusted.
AI starts at the bottom. Who are you? Are you credible? Only then will it put the brand in front of more people.
The SEO is the person who can see that it is all the same system. I understand that I must work from the foundation up, the way the machine does, and then meet the customer coming down from the top.
I should build for the customer, but work upward toward them. That has always been the stronger approach, and AI engines have now made it obvious.
The business now has two kinds of clients: the human and the agent. I need to speak to both. The agent is emulating a person and reflecting the world’s view of the brand, so pleasing the agent and pleasing the human are closely connected.
That is what makes SEO impossible to sideline. I am well positioned to tell the business and the marketers what must change to satisfy the agent without losing the human.
Whether agents represent 5% of the business today or nearly all of it, the agentic share will grow year after year. That means I have to step out of the SEO corner and look at the wider business. I am in a rare position to see business, marketing, and machines at the same time.
The audience used to be only human. Now it includes machines, too, and I am the one who can speak to both.
This is the 19th and final piece in my AI authority series, and it has been a long journey. My thanks to Danny Goodwin, Angel Niñofranco, and the Search Engine Land team for their immense support throughout.
When I started, the framework was a complete idea, but I had not fully worked through all the details. Week by week, I worked through each of the 15 gates, and every one turned out to be more intricate, more in-depth, and more thought-provoking than I expected.
What I have finished is a practical framework for SEO, marketing, and business in the AI age, one that search professionals, marketers, and business leaders can apply to real business problems.
Series Index
Parts 1 through 18 built this framework step by step: cascading confidence, assistive agent optimization, the AI engine pipeline, infrastructure gates, competitive gates, the entity home, the push layer, annotation, topical ownership, the funnel flip, the framing gap, pipeline repair, the delegation boundary, funnel query pathways, macro measurement, customer-success proof, AI opinion formation, and the collapse of paid and organic visibility across AI surfaces.
As I delved into audits across Prince Edward Island, one issue stood out: businesses with significant expertise weren’t visible to AI systems because their knowledge wasn’t rendered into a machine-readable format.
Despite their leadership in biotech, manufacturing, and other sectors, critical business information was often trapped in PDFs, behind forms, or muddled in vague marketing copy. It was also disconnected from structured data systems that AI engines need for verification.
We’re living in a world where 88% of companies are integrating AI. Yet, McKinsey notes that 86% of leaders admit to being unprepared for its daily integration.
Many brands mistakenly equate AI visibility with being featured in a Gemini summary or a ChatGPT result, without solidifying the structured digital groundwork needed for ongoing visibility.
AI Visibility: The Basics Before the Buzz
If you’re only focusing on large language model (LLM) responses, you’re lagging. LLM visibility reflects authority—it doesn’t build it.
According to a study by Responsive, 22% of B2B buyers now use generative AI for vendor research. Traditional search use is expected to drop by 50% by 2028 as AI solutions become the go-to answer engines, as Gartner predicts.
Now, discovery happens through synthesizing answers rather than listing URLs. Until you’re part of the Knowledge Graph as a verified entity, your brand’s visibility will be inconsistent.
The Insights from 19 Case Studies: Expertise Powers AI Search
AI systems value concrete, structured data over descriptive text. Brands chasing fleeting AI mentions without anchoring their data won’t achieve lasting visibility, but those establishing structured data relationships will always be recognized.
Thus, SEO has evolved from simply creating content to becoming an information architect. As the case studies reveal, expertise remains a key signal that AI systems can interpret.
Case No.
Entity
Industry
The discovery
The SME solution
1
BioVectra
Biotech
Technical authority trapped in PDFs
Encoded cGMP data into facts
2
Wyman’s
Food manufacturing
Sustainability was a narrative
Structured supply chain schema
3
Murphy Hospitality Group
Hospitality
Invisible venue specifications
Constructed event logic
4
Invesco
FinTech
Opaque compliance data
Built regulatory ground truth
5
Sekisui Diagnostics
MedTech
Innovation lacked readability
Engineered diagnostic logic triples
Why SEOs Must Focus on Education
The main obstacle to AI readiness is the gap in education. We must evolve into information architects, comprehending our clients’ business logic deeply.
SEOs as Subject Matter Experts
Understanding is foundational. For instance, auditing a biotech firm requires a grasp of compliance as keen as their lead scientist’s.
AI relies on structured context for accurate answers. Vague marketing language feeds insufficient responses.
Clients Must Prepare Their Data
Data quality and governance activation equate to maximizing AI-driven value. SEOs must educate clients on digital presence impacting AI brand perception.
Focus on True AI Authority
Appearing in a ChatGPT reply isn’t the goal; becoming an authoritative node in the Knowledge Graph is. It ensures visibility across AI platforms like Gemini and Claude.
AI advancements will persist rapidly. SEOs and clients not prioritizing structured data will be left behind in AI discovery systems.
