# I Built an AEO Agent Workflow. Google Made Me a Skeptic. A field note from setting up a local Pi workflow with OpenRouter agents to research AEO topical authority. The real surprise was not any agent tactic — it was what Google's own guidance actually says. Source: https://appheat.co/posts/i-built-an-aeo-agent-workflow/ Published: 2026-07-02 Tags: aeo, agents, ai-workflows, seo, building-in-public, content-strategy ## Quick answers - AEO is not a separate discipline. Google's own guidance roots AI Overviews and AI Mode in the same core Search systems that handle regular results. - The most useful outcome of an AEO agent workflow was not a checklist of tactics. It was a pressure-tested publishing philosophy: make content more original, crawlable, source-backed, and citable. - The agent system earned its keep as a reviewer and pressure tester. It also created giant context handoffs and overconfident research until verifier agents pushed back. I wanted to build an AEO agent workflow that would help AppHeat grow topical authority around [answer engine optimization](/topics/answer-engine-optimization/). I ended up more skeptical of AEO as a separate discipline, and more convinced that the real work is the same work that has always mattered. This is the field note from that build. Scope note: this is a first-person build note, not a universal AEO study. I verified the Google Search guidance most deeply here; OpenAI, Perplexity, Anthropic, and other retrieval products deserve their own pass before I make broad claims about all AI search. ## The hypothesis The idea was straightforward. If AI search tools are pulling sources from crawlable, indexable pages, then a site that wants to show up in those answers should be: - Crawlable and well-linked, so the bot can find everything - Source-backed and citable, so nothing looks made up - Organized by topic hub, not just reverse-chronological feed - Schema-parity checked, so the structured data matches what is visible on the page - Visible-answer-first, so the machine and the reader get the same point I wanted a deterministic local agent workflow that would research, verify, and pressure-test content against those standards. Not a one-shot prompt. A repeatable editorial loop with clear roles, source checks, and enough structure that I could trust the shape of the output without pretending the model itself was deterministic. I set up a local Pi workflow with OpenRouter models and gave the agents distinct jobs. I am intentionally not turning this into a full recipe, because some of the orchestration details may become product work later. The public part is the lesson: the workflow was most useful when it separated planning, source gathering, verification, and synthesis instead of asking one model to do everything. The first real run was an `appheat-research-brief` workflow: research AEO topical authority from primary sources, identify what search platforms actually recommend, flag the vendor claims that do not hold up, and produce a durable brief for content planning. ## The build The workflow config was deterministic enough to be inspectable: declared phases, role boundaries, timeouts, and output schemas. The runner executed locally. The model calls were still nondeterministic, but the outer system gave me a way to see where a run failed and which role produced which claim. The research pass asked a narrow question: what do the primary sources actually say about AI Overviews, AI Mode, structured data, crawlability, `llms.txt`, and content formatting for AI systems? The important constraint was source quality. Platform docs counted differently from agency posts, tool-vendor claims, and third-party studies. The gathering step split web research from local-site review. That mattered because the public question and the site-quality question are related, but not the same. The verification step was the most important part. Its job was to reject weak metrics, flag unsourced claims, and distinguish platform guidance from third-party analysis. The synthesis phase assembled the verified research into a durable brief artifact with content angles, source limits, and operational notes. ## The failures The first live run timed out at 90 seconds. The research planner hit the wall before the scouts even started. The prompt was detailed, the model reasoning was thorough, but the timeout was set for a quick pipeline that did not account for how many tokens the planner would burn through before handing off. I raised the research workflow timeout to 240 seconds and ran it again. This time the full run completed: 6 agent calls, approximately 569,000 tokens, roughly $0.10 total (estimate, not measured billing data). Four agents finished. One web scout consumed 274,000 tokens and finished. Another consumed 155,000 tokens and finished. The source verifier and synthesis writer both completed. The call and token counts came from the local workflow's run summary. The underlying logs are not public; the dollar figure is an estimate from configured model rates, not measured billing data or a general cost benchmark. The local scout still timed out. The context handoff was too large. The local scout received the full planner JSON output instead of a compact summary, and the model spun for 240 seconds without producing a result. The agent did not fail cleanly. It just disappeared at the timeout boundary. Two takeaways from the failures: First, agent context handoffs are a real design surface. Sending the full planner output to every downstream agent burns tokens, hits timeout walls, and produces inconsistent results. The next iteration needs compact plan summaries, not full JSON dumps. Second, role separation matters, but it does not solve the handoff problem by itself. A fast agent does not help if the prompt is already bigger than the useful work it needs to do. ## The research surprise I expected the research workflow to surface AEO tactics. Structured data tricks. Content formatting patterns. Entity-density ratios. Maybe something about prompt-visible summaries. What I got instead was Google's own guidance making most of those ideas look unnecessary. Google Search Central has a dedicated page on [AI features and your website](https://developers.google.com/search/docs/appearance/ai-features). The practical reading is blunt: AI Overviews and AI Mode still lean on Google's core Search systems, and eligible pages need the normal Search basics rather than a separate AEO checklist. That page says AI feature eligibility depends on being indexed, snippet-eligible, and compliant with Search requirements. It also says existing SEO fundamentals still matter: crawl access, internal links, page experience, textual content, useful media, and structured data that matches visible page content. Separately, Google's [guide to optimizing for generative AI features](https://developers.google.com/search/docs/fundamentals/ai-optimization-guide) says Google Search does not use `llms.txt` as a special visibility or ranking input. This is a direct answer to the growing vendor narrative that `llms.txt` is an AEO signal. The same guide pushes back on other fashionable tactics. It says chunking content into tiny pieces is not required, rewriting for AI systems is not needed, and special schema is not required for generative AI search. Structured data can still be useful for normal Search features and machine understanding, but it is not a citation shortcut. The vendor AEO narrative — special markup, AI-only content formatting, `llms.txt` as a ranking signal, entity optimization as a new discipline — does not come from Google. It comes from SEO tool companies and agencies building products around a perceived new market. That does not mean AI search is irrelevant. It means the useful advice is not new advice. ## The new philosophy The workflow pushed me back toward craft. The useful AEO insight was not a tactic. It was a publishing philosophy that holds up under scrutiny: **Write first-hand build notes.** An AI system pulling from sources cannot distinguish between a surface-level summary and a field note from someone who actually built the thing. But a search quality system can measure originality, and a reader can tell the difference. Build in public. Write what you learned, not what you think a machine wants. **Cite primary sources.** Do not cite someone else's roundup. Find the actual guidance from the platform. Link to the documentation page. This makes the content useful to people and harder for search quality systems to dismiss as derivative. **Keep visible answer summaries honest.** If the page makes a claim, the claim should be visible, specific, and verifiable. The same structure that helps a reader decide whether the page is worth their time also helps a search system decide whether the page is a credible source. **Make topic hubs crawlable.** A reverse-chronological feed is useful for people who follow along. It is not useful for a machine trying to understand what topics a site covers. Topic hub pages that link to the strongest posts in each cluster serve both audiences. **Use schema only when it matches visible content.** Schema is documentation for machines. If the structured data describes something that is not visible on the page, the mismatch creates trust problems for both search systems and readers. Schema parity — making sure the markup reflects what is actually on the page — matters more than adding more markup. None of these are AEO-specific. They are SEO fundamentals that predate AI search by years. The difference is that AI search systems, by pulling directly from page content rather than from a link graph, make content quality and source backing more directly observable. ## What the agent workflow is actually good for The workflow earns its keep, but not as a hack generator. As a reviewer, it catches claims that lack source backing. The verification step rejected specific multipliers, overly precise metrics, and vendor citations that could not be traced to platform documentation. As a pressure tester, it surfaces structural weaknesses in content organization. The local scout's job was to audit crawl topology and schema parity, and even though it timed out, the question it was supposed to answer — does the site's structure hold up when a bot tries to map it? — is the right question. As a source tracker, it maintains a record of what primary sources were consulted, what was rejected, and why. The durable brief artifact includes source limits, operational notes, and a labeled distinction between platform guidance and third-party analysis. What it does not do is guarantee AI citations, generate magic markup, or replace the writing. The workflow is a pressure-testing layer, not a content factory. ## The limits The workflow has real limits, and I should name them. **Cost and token efficiency.** Six agent calls at 569,000 tokens is not the budget breaker it sounds like on a per-run basis. But scaling to frequent content review runs would require prompt compaction, shorter handoffs, and smarter routing. The current design still burns too many tokens on planning and handoff steps. **Timeout fragility.** A single oversized context handoff can kill a downstream agent silently. The local scout timed out without producing a result or a clean error, and the workflow ran as "completed" because the other agents finished. This is not a correctness guarantee. It is a survivorship report. **Overconfidence risk.** Without a verification agent that explicitly rejects weak metrics, the synthesis writer would have included vendor-sourced multipliers and entity-density claims that do not hold up to platform documentation. The verifier is not optional. It is the safety layer. **Vendor platform coverage.** This run focused on Google Search Central as the strongest primary source. OpenAI, Perplexity, and Anthropic publisher guidance was not verified at the same depth. A future run should expand scope, but the core finding — that the platform whose AI search product has the broadest reach says AEO is just good SEO — is not fragile. ## Next experiments This is not the end of the AEO investigation. It is a baseline, and the baseline is skeptical. The next experiments I want to run: **Compact handoff architecture.** Shorten downstream prompts and separate local-site audit from web research so one oversized context handoff does not distort the whole run. **Multi-platform verification.** Run the same research workflow against OpenAI, Perplexity, and Anthropic publisher guidance at the same depth. The question is whether any platform contradicts Google's position, or whether the answer is the same everywhere: good pages, crawlable structure, source-backed claims. **Drift monitoring.** After publishing a post, check the rendered page against the claims the workflow thinks are visible. Catch schema drift, broken internal links, and missing answer summaries before they become invisible problems. **Real ingestion measurement.** Track bot crawl patterns, AI referral traffic where detectable, and source-citation appearances in AI search responses. Even partial signals would be more useful than third-party citation-rate studies with opaque methodology. ## What I would tell another builder If you are building a site and wondering whether AEO is a separate thing you need to learn, here is the short answer: it is not. Google's AI Overviews and AI Mode run on the same Search systems that rank your pages now. The platform whose AI search product reaches the most people says there are no special AEO requirements beyond being indexed and eligible for snippets. Schema helps machines understand your page, but it does not guarantee citations. `llms.txt` is not a Google signal. Rewriting content for AI systems is not recommended. The thing that actually moves the needle is writing first-hand build notes, citing primary sources, making topic hubs crawlable, keeping visible answers honest, and checking that your schema matches what is on the page. That is the thread I started in [AEO from the jump](/posts/aeo-from-the-jump/), and this workflow made me trust it more. It is also why the next infrastructure question was not "how do I add more AI-only markup?" but "can agents fetch the same page as Markdown when they ask for it?" That turned into the [Accept: text/markdown Cloudflare Workers debugging note](/posts/accept-text-markdown-cloudflare-workers/). An agent workflow can help with that. It can verify sources, pressure-test claims, and catch drift. But the workflow is a reviewer, not a shortcut. The craft is still the craft. That is not the conclusion I expected when I started building the workflow. It is the conclusion the workflow pushed me toward by running the research, surfacing the primary sources, and letting the verifier kill the claims that did not hold up. The agent did its job. It just did not give me the answer I wanted. ## FAQ ### Is AEO a separate discipline from SEO? No. Google's AI Overviews and AI Mode docs say they are rooted in core Search systems and have no additional technical requirements beyond standard indexability and snippet eligibility. ### Does Google use llms.txt? No. Google's Search Central guidance explicitly says llms.txt is not used by Google Search. ### Does schema guarantee AI citations? No. Schema helps machines understand the page, but citations depend on usefulness, authority, clarity, crawlability, and how each search tool retrieves sources. Treat schema as documentation for machines, not a citation shortcut. ### Should I rewrite content specifically for AI systems? Google says no. The guidance is to write for people, make content original and source-backed, and let AI systems discover it through standard crawlable, indexable pages. ### What is the agent workflow actually useful for? The workflow is useful as a reviewer, pressure tester, and source-verification layer. It pushes you toward craft: write first-hand build notes, cite primary sources, keep visible answer summaries honest, and make topic hubs crawlable. ### What did the workflow cost to run? The live research workflow completed 6 agent calls totaling approximately 569,000 tokens at roughly $0.10 (estimate, not measured billing data). One local scout agent still timed out due to oversized context handoff.