diff --git a/Agentic-Engine-Optimization-%28AEO%29.md b/Agentic-Engine-Optimization-%28AEO%29.md
new file mode 100644
index 0000000..7307352
--- /dev/null
+++ b/Agentic-Engine-Optimization-%28AEO%29.md
@@ -0,0 +1,9 @@
+<br>How AI coding agents consume documentation is fundamentally different from how humans do - and if you’re still optimizing only for human readers, you’re leaving a growing share of your audience invisible to your tooling. Docs, CLIs, MCPs, Skills… ’s a whole ecosystem of interfaces that AI agents interact with. Disclosure and context. I’m a Director at Google Cloud AI, so a few things are worth flagging before you read on. The Lighthouse team in Chrome have shipped an experimental llms.txt check (docs, coverage); independently, the Google Search / Webmaster team have published their own guidance on SEO and AI agents, and Search does not officially recommend llms.txt as a standard. My position on AEO in this post should be read through a specific lens: my audience here is developers, and for that audience we should fully expect agents to consume docs more and more (vs humans) via agentic coding tools like Claude Code, Gemini CLI, Cursor, and Copilot. Optimizing for that consumption pattern makes sense for developer-facing docs even where it diverges from broader Search guidance aimed at the open web.<br>
+
+<br>Treat this as one practitioner’s view from inside the developer-tools world, not a Google-wide recommendation. I’ve been watching something play out across developer portals that I think deserves more attention than it’s getting. An engineer opens Claude Code, asks it to implement a spec and hits enter. The agent fetches some of your documentation. It might grab some of what it needs, parse it as raw text, strip the HTML, count the tokens, and either use it as context - or silently discard it because the token count exceeds its context window. Your analytics recorded nothing useful. Scroll depth was zero. Time-on-page was 400 milliseconds. No link clicks, no tutorial completions, no UI interactions. The funnel you’ve optimized for years showed nothing. But the agent was absolutely there. It read your docs. And depending on how those docs were structured, it either completed the task successfully - or hallucinated a solution because the content was too token-heavy, poorly structured, or blocked by a misconfigured robots.txt.<br>
+
+<br>I’ve started calling the discipline that addresses this Agentic Engine Optimization. What is Agentic Engine Optimization? Agentic Engine Optimization (AEO) is the practice of structuring, formatting, and serving technical content so that AI coding agents can actually use it - not just human readers. The analogy I keep coming back to is SEO. We spent years learning to optimize for search crawlers and human click patterns. AEO is the same idea, but for a different consumer: AI agents that autonomously fetch, parse, and reason over your content. Discoverability - can agents find your documentation without rendering JavaScript? Parsability - is the content machine-readable without requiring visual layout interpretation? Token efficiency - does the content fit within typical agent context windows without truncation? Capability signaling - does the documentation tell agents what your API does, not just how to call it? Access control - does your robots.txt actually let AI traffic through? If any of these fail, agents either skip your content entirely or produce subtly wrong outputs.<br>
+
+<br>The tricky part is you’ll probably never know, because no analytics event fires. It’s worth spelling out the behavioral difference here, because it’s bigger than I initially expected. A human developer lands on your docs homepage. They navigate to a relevant section. They skim headings, read a few paragraphs, maybe run a code sample in the interactive console, follow two or three internal links, and spend 4-8 minutes in session. Your analytics captures all of it. A recent research paper (Developer Experience with AI Coding Agents) studied HTTP traffic from nine major AI coding agents - including Claude Code, Cursor, Cline, Aider, VS Code, and Junie - fetching developer documentation. The findings were pretty striking. Agents typically compress multi-page navigation into one or two HTTP requests. Where a human would spend minutes clicking through your documentation hierarchy, an agent issues a single GET request, receives the full page, and moves on. The whole concept of "user journey" collapses into a single server-side event.<br>
+
+<br>The practical consequence: every client-side analytics event - scroll depth, time-on-page, button clicks, tutorial completions, link follows, form interactions - becomes invisible. The agent just bypasses all of it. Beyond coding agents, AI assistant web [online visibility services](https://ashandbloommush.com/index.php?title=User:BonnyA7081208) (ChatGPT, Claude, Google Gemini, Perplexity) also [generate distinct](https://soundcloud.com/search/sounds?q=generate%20distinct&filter.license=to_modify_commercially) fingerprints when users share URLs in chat interfaces - triggering their own server-side fetches. Once you know what to look for, you can start segmenting AI agent traffic in your analytics. I was surprised how much of it was already there in my own logs. This is probably the most underappreciated part of the whole picture: token economics. Agents don’t have infinite context. Most have practical limits between 100K-200K tokens, and context management is an active constraint in every task. The paper highlights a concrete example: the Cisco Secure Firewall Management Center REST API Quick Start Guide (Version 10.0) comes in at 193,217 tokens - nearly 718,000 characters. That single document threatens to consume or exceed most agents’ entire usable context window. I think this means token count is now a first-class documentation metric. If you’re not tracking token counts for your documentation pages, you’re missing a signal that agents actually use to decide whether to even attempt reading your content.<br>
\ No newline at end of file