Skip to content

Agentic Engine Optimization: Token-First Guide

Agentic Engine Optimization isn't SEO with a new label. Here's the token-budget playbook coding agents actually use - and where bolt-on files fail.

7 min readBeginner

Most teams treat Agentic Engine Optimization like a new robots.txt checkbox. That’s backwards. If the first GET still arrives stuffed with nav chrome, legal footers, and a novel-length preamble, no index file saves you. The agent truncates, skips, or invents the missing bits – and your product analytics stay quiet.

Key takeaway: For developer docs, redesign around shared context budgets first, then add discovery files. Bolt-on-only is the weaker path. As of Osmani’s April 2026 post: quick starts under ~15K tokens, API refs under ~25K.

Brief background: what agents actually do

Agentic Engine Optimization (AEO) got a public name on Addy Osmani’s April 11, 2026 post: structure technical content so coding agents can use it, not merely render it. Five signals sit at the center – discoverability, parsability, token efficiency, capability signaling, access control.

Different job from Answer Engine Optimization (citations inside chat-style answers) and from classic SEO. Coding agents often collapse a human multi-page path into one or two HTTP requests, strip markup, count tokens, then load or silently drop the page. Turns out one research callout on that same post is brutal: Cisco’s Secure Firewall Management Center REST API Quick Start measured 193,217 tokens. Plenty to eat a practical agent window people discuss in the ~100K-200K band.

Broader academic framing shows up as “Agentic AI Optimisation” for agent-platform fit (arXiv:2504.12482). Docs teams feel a narrower pain: failure with no error banner.

Method A vs Method B

Two patterns show up in the wild. Straight comparison:

Dimension Method A: Bolt-on discovery Method B: Token-first redesign
Core move Ship robots.txt allows, /llms.txt, maybe skill.md / AGENTS.md Split and rewrite pages to hard token budgets; front-load outcomes; serve clean Markdown
Effort Hours to a weekend Days to weeks on a real docs set
Fixes Findability and “can I access this?” Whether the fetch fits remaining context and parses cleanly
Failure mode Agent finds a 150K page and still truncates or hallucinates Under-signaling if you skip capability files
Best for Quick triage; already-lean docs API/reference-heavy portals agents implement from

Method A feels productive because the files are new and visible. Method B is uglier editorial work. For coding-agent traffic, Method B wins – discovery without budget fit is a false green light. Pair B with the lightest A layers once pages fit.

Think of the context window like a carry-on already half full of socks (user code), a laptop (tool traces), and a snack bag (chat). Your doc isn’t getting an empty suitcase. A “compliant” 24K page still loses the tail when the agent is halfway through a task.

The catch is simple: budget is shared, not page-local. That’s the whole argument for redesign before ceremony.

Token-first walkthrough

Do this in order. Skip the romance of a perfect stack on day one.

1. Measure before you moralize

Pull token counts on the real entry doors – quick start, auth, top three API resources. Rough pass: characters ÷ 4. Better: a real tokenizer. Flag pages past the guidance Osmani published in April 2026 (not law – guidance): quick starts ~<15,000, conceptual guides ~<20,000, per-endpoint API refs ~<25,000, avoid singles past ~30,000 without chunking. Keep llms.txt itself lean (~<5,000).

# Scaffold + audit with the community CLI
npx agentic-seo --url https://docs.yourproduct.com
npx agentic-seo init # llms.txt, AGENTS.md, skill.md stubs

agentic-seo on GitHub scores Discovery, Content Structure, Token Economics, Capability Signaling, and UX Bridge out of 100 (A-F). Structural heuristics, no API key, not a Google project. Handy triage. Not a promise any agent will behave – more on that under edge cases.

2. Split and front-load

Chunk by task or endpoint – not “whole product.” Outcome first. Code sample right under the claim. Tables for parameters; they compress harder than nested prose. Sidebar/footer noise? Out of the parse path.

Pro tip: Markdown twins (append .md or a raw route) when the platform allows it. Agents usually pay less token tax on clean MD than on full HTML chrome.

3. Then discovery and capability signals

Host a curated /llms.txt. Jeremy Howard floated the idea in September 2024; the spec lives at llmstxt.org – H1 name, short summary, H2 sections with links and one-line notes, token hints so agents can budget. Add skill.md-style cards (what it can do, required inputs, constraints, key links) so fit gets decided before a full read. In repos, AGENTS.md is drifting toward the agent-facing README: structure, conventions, sandboxes, rate limits, MCP links.

  1. Audit robots.txt so known AI patterns aren’t blocked by accident.
  2. Point llms.txt at the new lean pages.
  3. Surface token counts in the index and/or page meta.
  4. Ship a “Copy for AI” control that pastes clean Markdown.
  5. Watch server logs for agent fingerprints (axios, got, curl variants) – client analytics often show ~0 dwell.

Same order he sketches on the post: robots → llms.txt → measure tokens → skill.md for top APIs → Copy for AI → traffic monitoring.

If “optimized for agents” only means prettier files on a fat page, what exactly did we optimize – the catalog, or the thing the model can finish reading?

Edge cases that break the happy path

Silent lockout. A broad Disallow in robots.txt doesn’t throw to your dashboard. Agents simply never read you. Fix access before debating prose quality. (Osmani’s Layer 1 problem: misconfigured robots, zero traffic, zero errors.)

Shared-window math. Under 25K on the page still isn’t a ticket in. Heavy session already? Truncation or parametric guesses. Users blame the model, not your doc length.

Two Google-shaped stories. Osmani writes for developer portals and coding agents; his own disclosure notes Search/Webmaster guidance does not officially recommend llms.txt. Search coverage has also stressed normal SEO for AI Overviews and pushed back on separate markdown-for-LLM pages as a Search strategy. You can be agent-ready for a coding IDE agent and still follow different rules for organic Search. Don’t paste one playbook onto the other without naming the audience.

Score ≠ selection. A high agentic-seo grade means files and structure look right. The README is explicit: community tooling, directional only – not a Google endorsement, not a guarantee of agent behavior.

FAQ

Is Agentic Engine Optimization the same as Answer Engine Optimization?

No. Same acronym, different job. One chases citations inside generated answers. Osmani’s AEO asks whether a coding agent can fetch, parse, and act without choking on tokens or structure.

Do I need llms.txt if Google Search doesn’t use it?

For pure Google organic / AI Overview goals: Search has said normal SEO is the path; llms.txt isn’t a ranking input there. For docs portals aimed at coding agents – the audience in Osmani’s framing – a curated markdown map still helps pick the right URL without walking the whole tree. Ship it for that job. Agent behavior shifts; re-check the agents you actually care about.

What’s the minimum viable pass for a small API docs site?

Unblock robots for the agents you care about. Split anything past ~25-30K. Get the quick start under ~15K with the first successful call shown early. Add a short llms.txt with token notes. Run npx agentic-seo once; fix red Discovery/Token items. Skip a full skill.md garden until the top three endpoints are lean.

Otherwise you’re decorating a door that doesn’t fit the hallway.

Tonight: highest-traffic quick start → measure tokens → cut or split until it’s under 15K with “hello world” in the first screen → then add llms.txt. That loop beats a month of acronym slides.