AURA GEO handles this with one rule: a task is done only when the server's own check says so. The agent can do the work and report it, but it can't mark the task complete. This post walks through how the task queue works for an agent connected over MCP: where tasks come from, how the next one is chosen, how completion is verified, and how duplicates are cleaned up without losing history.

Everything below comes from the public MCP tool definitions, which are listed with their schemas in the MCP guide. If you haven't connected an agent yet, the step-by-step connection guide covers that.

Templates: the catalog by phase

Tasks start from a catalog. aura_list_task_templates returns "the catalog of GEO task templates by phase 0-6 with actor, cadence, dependencies and the machine-checkable criterion each one is verified by."

That one sentence holds most of the design:

• Phase (0 to 6). Work is ordered. Phases 0 and 1 hold the critical setup work.
• Actor. Who does it. The queue's actor filter accepts agent_mcp, agent_browser, owner and developer, so an agent can ask only for work it can actually do.
• Cadence. Some tasks are one-off, some repeat. For example, a monthly content refresh is one of the standard tasks.
• Dependencies. A task can wait for another task.
• Criterion. Each template carries the check the server will run. The definition of done is fixed before the work begins.

The tool is read-only. Pass a projectId to see only the templates available to that project, a phase to filter, and language (en or ru).

The queue: what to do next

The agent doesn't pick tasks from the catalog itself. It asks aura_get_next_tasks, which returns an "ordered queue of what to do next, using the same engine as the cabinet." The owner's dashboard and the agent see the same order.

The queue has three properties worth knowing.

It's dependency-aware. Items carry blockedBy, so a task that waits on another isn't offered as ready.

It's phase-gated. The definition says there's "no phase 3+ work while critical phase 0-1 setup is open, unless the owner holds it." In practice, later-phase work waits until the critical setup is finished. While a critical phase 0-1 task is still open for the agent, later-phase tasks aren't even created yet.

It creates the standard tasks itself. Before answering, the server creates any missing required standard tasks: robots access for AI search bots, Bing and IndexNow, official pricing, comparison, reviews and about pages, a monthly content refresh, and llms.txt. The definition notes that "creation is idempotent," so calling the queue repeatedly doesn't pile up copies.

Each queue item includes rank, whyNow, actor, ready toolCalls, verification criteria, blockedBy, and an ownerActionUrl when the owner has to do something. There's also an expectedOutcome with a coarse label and typical time, but only "when anonymous cross-project statistics exist." The ranking comes from the server's decision engine and is expressed as rank, not as weights.

The response always has a nextAction that names a taskId or a setup stepId along with ready tool calls. The task list is empty only in two cases: the work is closed (queueState: clear) or it's waiting on the owner (queueState: awaiting_owner). In the second case, awaitingOwner lists those items with their ownerActionUrl. When quotas are in use, the response also includes limitsToday.

For projects using the measurement ladder, the queue also returns scheduled measurements that are due or have regressed, and the agent should handle regressions first. The measurement ladder post covers that part.

The definition ends with a short instruction: "Do not invent tasks."

Adding a task from a template

Most tasks arrive through the queue. When the agent or owner wants a specific template, aura_instantiate_template creates a task from a templateKey, with an optional targetUrl for page-level templates.

It's deduplicated by canonical target: "an existing open task absorbs the request and is returned instead of creating a copy." Asking twice for the same page-level task returns the same task.

Optional templates show up in the queue's suggestions list with a ready aura_instantiate_template call. The definition names Brave as the example. Templates that act on a measured ladder failure need a ladderSignalId; the server checks that the signal is current and keeps at most five ladder tasks open.

When no template fits, aura_create_geo_tasks creates custom tasks. A verificationCriterion is required for each one, and deduplication is on by default.

Doing the work and reporting it

AURA doesn't deploy code. The agent makes the change through whatever access the owner granted separately, such as a repository, a CMS or hosting. Then it reports with aura_complete_task: a summary, plus optional changedFiles, a diff and evidenceUrls.

This is where the rule applies. The definition says: "The report alone changes nothing: the task moves to awaiting_verification and becomes done only when the checks pass; otherwise failed_verification with exactly which check failed and what the server saw."

So aura_complete_task does two things: it records the report, then it immediately runs the server verification. aura_mark_geo_task_applied stays available too. It records an implementation with changed files, a diff and what was tested, and it also leaves the task awaiting verification.

What the server checks

aura_verify_task runs the check for one saved task (taskId) or one setup step (stepId). Per its definition, the server "fetches the exact project host itself (bounded, DNS-pinned, robots-respecting), reads stored receipts, inspections and observations, stores what it saw." The agent's word isn't evidence; the server's own fetch is.

The response contains:

{
  "checks": [
    { "type": "...", "required": true, "passed": false,
      "observed": "...", "reason": "..." }
  ],
  "status": "...",
  "verified": false,
  "nextCheckAt": "..."
}

Two details matter:

• passed: null means pending evidence, "never success." Some checks depend on something that hasn't happened yet, like a receipt or an inspection result. Those stay open instead of being counted as passed.
• Results younger than five minutes come from cache unless you pass force: true. If you just redeployed, force a fresh check.

The definition is direct about authority: "Only this verifier can set a task to done."

Editing tasks without bypassing the check

aura_update_task changes a task's title, explanation, priority, dependencies, verification spec or status. The settable statuses are todo, in_progress, snoozed and dismissed. done and merged aren't available here, because "done is written only by the verifier." Updates use optimistic locking through expectedVersion, so two agents editing the same task can't silently overwrite each other.

aura_list_tasks shows the full set of statuses you'll see: blocked, todo, in_progress, awaiting_owner, awaiting_verification, done, failed_verification, snoozed, dismissed and merged. It returns counts by status and open phase, which is a quick way to see where a project stands.

Duplicates: merge, never delete

Duplicates happen when several agents, an audit and a human all add tasks. Two tools handle them.

aura_dedupe_tasks finds open tasks that share a canonical dedupe key. By default it runs as a dry run and only proposes merge groups. With dryRun: false it merges them, "keeping the most advanced and oldest task."

aura_merge_tasks lets you choose: give a targetTaskId and up to 50 sourceTaskIds. The sources "become merged with a link."

Both definitions say the same thing: "Nothing is deleted." A merged task stays in the record, pointing to the task that absorbed it.

The journal

aura_get_task returns one task with its verification state, criteria and "the journal of events (created, updated, merged, applied reported, verification runs)." When someone asks why a task is done, or why it failed three times, the answer is in that history: who reported what, and what the server saw on each run.

Permissions

Reading the catalog, the queue and the task list needs read. Instantiating, completing, verifying, updating, deduping and merging need manage_tasks, which the MCP guide describes as "create and mark GEO plan tasks complete." aura_mark_geo_task_applied additionally requires the owner's separate canManageGeoTasks permission. Write calls accept an optional clientRequestId so a retried call doesn't run twice.

A sample prompt

Here's a prompt you can give a connected agent:

Use AURA GEO for my project. Call aura_get_next_tasks with actor agent_mcp and work on its nextAction only. Run the ready toolCalls it gives you. If the change needs my repository or hosting, make it only where I've given you access; otherwise tell me exactly what to change and stop. After deploying, call aura_complete_task with a short summary, the changed files and the URLs to check. If verification fails, read which check failed and what the server observed, fix that, and verify again with force=true. Don't edit task status to get around a failed check. If the queue says awaiting_owner, give me each ownerActionUrl in one sentence and wait. Before you finish, run aura_dedupe_tasks as a dry run and show me any proposed merges; don't merge without my OK. Finally, list what's done, what failed and why, and what's waiting on me.

What "done" does and doesn't mean

A verified task means the server checked the specific criterion on your live site, or in its stored receipts and inspections, and it passed. It doesn't mean the page is indexed, cited or getting visits. The aura_mark_geo_task_applied definition says outright that verification "does not prove indexing/citations." Those are measured separately, through index status, IndexNow receipts, referral tracking and the measurement ladder.

That separation is what makes the task list useful. A green item means the change is on your site and a server saw it.

To try the queue, start at AURA GEO, connect your agent through the MCP guide, and ask it for aura_get_next_tasks.

The dataset

• Menlo Ventures, 2026 State of Consumer AI: survey of 5,067 US adults (July 2026) plus market sizing.
• Menlo Ventures, 2025 State of Generative AI in the Enterprise: ~500 US enterprise decision-makers plus a bottom-up market model.
• Sensor Tower, State of AI Apps 2025: mobile downloads and in-app purchase revenue.

Caveat up front: Menlo's market sizes are estimates, and survey samples are US-only. Treat the numbers as direction, not precision.

Part 1: The funnel is no longer adoption-bound

Users grew ~11%; spend more than tripled. In funnel terms, top-of-funnel is saturating in the US and the money is being made in activation depth and expansion revenue. Menlo reports 52% of AI users use AI more than a year ago, and 46% of payers spend more versus 12% who spend less. That's net expansion behaviour, the metric SaaS investors obsess over, appearing in consumer software.

Mobile shows the same shape. Sensor Tower measured gen-AI apps at ~1.7B downloads and ~$1.9B in in-app revenue in H1 2025, roughly double the $932M of H2 2024. TechCrunch's write-up adds that time spent rose from 8.5B to 15.6B hours half over half.

Product takeaway: instrument depth: sessions per week, use cases per user, share of users touching a second feature. Menlo explicitly says these reveal product-market fit "in ways sign-ups alone cannot."

Part 2: What predicts payment? Reliance, not income

Income predicts adoption (77% of $100K+ households use AI vs 56% under $50K). But payment correlates with dependence:

• Payers use AI daily at 50% vs 26% for non-payers.
• 65% of payers use an AI agent vs 13% of non-payers.
• 92% of agent users pay for AI.

So the conversion trigger is the moment losing access "would hurt." That's a design target you can build toward: identify the workflow where your feature becomes load-bearing and get users there in the free tier.

Part 3: Billing architecture that matches behaviour

Menlo's breakdown of how payers are billed:

• 50% flat monthly
• 26% annual
• 15% subscription plus usage charges
• 17% usage-based

And the distribution is heavily skewed: the 14% paying $100+/month account for 60% of spend. Users whose employer or school pays spend about $95/month vs $55 out of pocket.

This produces a fairly concrete billing spec:

Free      -> discover value, form habit (no card)
Plan      -> predictable monthly price, generous allowance
Overage   -> metered usage above allowance (protects margin on heavy users)
Team      -> triggered by work-email signups; invoice / admin features

The work-email signal is worth highlighting. Menlo calls a work email in a consumer signup "a strong signal" for future enterprise expansion. On the enterprise side, 27% of AI application spend comes through PLG motions vs 7% in traditional software, possibly close to 40% once you count "shadow AI" on personal cards.

Part 4: Where enterprise budgets land

Menlo's 2025 enterprise model: $37B total gen-AI spend, of which $19B on applications:

• Horizontal (copilots, agents, productivity): $8.4B, with copilots at 86% ($7.2B)
• Departmental: $7.3B, with coding at $4.0B
• Vertical: $3.5B, with healthcare ~$1.5B (ambient scribes alone ~$600M) and legal $650M

Two engineering details from the same report are useful as a reality check:

1. 76% of AI use cases are purchased, not built (up from 53% in 2024). Buyers want working products, not platforms.
2. Only 16% of enterprise and 27% of startup deployments qualify as true agents. Most production systems are fixed-sequence or routing workflows around a model call, with prompt design and RAG as the dominant techniques.

Product takeaway: you don't need a fully autonomous agent to get paid. A reliable, well-scoped workflow with good retrieval is what most buyers are actually running.

Part 5: The trust requirements, as a spec

In 2026, users rank what matters as accuracy 45%, trustworthiness 40%, security/privacy 36%, ease of use 32%. Ease of use fell from first place in 2025. Translate that into acceptance criteria:

• Verifiability: every generated claim links to a source or is shown as a diff or preview.
• Least privilege: request only the scopes the core job needs. Menlo's advice: "Start with the data your core job requires, earn the permission to access it, and expand."
• Autonomy gradients: 32% of AI users have already let AI act without final approval, but consumers "let it recommend a purchase before they'll let it make one." Ship recommend → confirm → auto modes, not a single switch.
• Provenance: 36% of consumers are less likely to engage with content they know is AI-generated (14% more likely). If your product generates public-facing content, quality and disclosure matter.

Part 6: A new discovery surface

The data also shows AI assistants becoming a place where purchase decisions happen. 37% of AI-using shoppers made a final purchase decision based on an AI recommendation, and 26% let AI complete a purchase. Users now run an average of 3.0 general assistants (ChatGPT 60%, Gemini 58%, Claude 20% of AI users).

For a product team, this means "how do assistants describe us?" becomes a measurable question, much like "where do we rank?" was for search. Answers vary between assistants, so checking only one is misleading. That's the problem we work on at AURA GEO: tracking whether and how a site appears in AI answers. The method matters more than the tool, though: fixed prompts, several assistants, repeated over time.

Summary for your next roadmap review

1. Optimise for depth and expansion, not sign-ups.
2. Find the feature that becomes load-bearing; that's the conversion moment.
3. Bill as subscription + metered overage, keep a free tier, watch for work emails.
4. Ship scoped workflows, not agent hype; most paid production AI is simpler than demos.
5. Treat trust as acceptance criteria.
6. Measure your presence in AI answers across several assistants.

Sources

• Menlo Ventures, 2026: The State of Consumer AI — https://menlovc.com/perspective/2026-the-state-of-consumer-ai/
• Menlo Ventures, 2025: The State of Generative AI in the Enterprise — https://menlovc.com/perspective/2025-the-state-of-generative-ai-in-the-enterprise/
• Sensor Tower, State of AI Apps Report 2025 — https://sensortower.com/blog/state-of-ai-apps-market-overview-2025
• TechCrunch, GenAI apps doubled their revenue, grew to 1.7B downloads in first half of 2025 — https://techcrunch.com/2025/07/30/gen-ai-apps-doubled-their-revenue-grew-to-1-7b-downloads-in-first-half-of-2025/

Those questions fail for different reasons and need different fixes. So AURA GEO's MCP server now measures them as a ladder, one rung at a time, with each rung scored by the server from quotes in real answers. This post covers what the ladder does, how an agent runs it, and a prompt you can hand to your own agent.

Everything here comes from the public tool definitions in the AURA GEO MCP guide, which are generated from the same definitions the server returns in tools/list.

Step 0: a subject profile built from your own facts

The ladder doesn't use generic questions. Its questions are rendered from a subject profile for your site. That makes it work for any business, not just one type of product.

The profile holds:

• Brand: the canonical name, the aliases and spellings people actually use, and whether the name is unique, a common word, or shared with other companies.
• Domains and languages. The first language is primary.
• Category, offering, audience, use cases and pain points, per language, in a customer's words.
• Geography: global, national or local, plus countries and cities.
• Facts: short, checkable statements (category, offering, audience, region, pricing model, features, limitations, ownership, founding), each marked core or supporting, with an evidence URL on your domain.
• Alternatives: competitors or substitutes.

Your agent reads it with aura_get_subject_profile and proposes values with aura_save_subject_profile. The rule here matters: agent values are saved as a draft and never count as ground truth until the owner confirms them in the cabinet. The tool description tells the agent to fill only what it can state from the site or from you, never to guess. Competitors it proposes are stored as suggestions.

The ladder also has to be turned on by the owner. An agent can't switch it on by itself.

Rung 1: does AI know the site?

aura_begin_ladder_run with stage: 1 creates a fixed set of brand, alias and domain questions in the project language. Built-in templates exist for English and Russian. For any other language, the agent translates each reference question and passes the translations in order. The run produces one check per question per assistant. It covers the project's target assistants by default, at most six per run, capped by your plan.

The agent then asks each question exactly as written, in a fresh session of the named assistant, and saves the full answer with aura_save_ladder_answer. The assessment is one of five outcomes:

• recognized
• partial
• not_found
• confused (mixed up with something else)
• fabricated (made-up details)

Each outcome must come with an exact quote from the answer. If a check can't be done because of a login wall, a captcha or a usage limit, the agent marks it blocked or failed with the reason instead of inventing a result.

Rung 2: does AI describe it correctly?

Rung 2 opens only after rung 1 passes. The questions are now scored against your confirmed core facts. For every fact listed in the run, the agent records correct, incorrect or absent, again with exact quotes.

The integrity rules are the same on both rungs. The server rejects quotes that aren't in the answer and facts that aren't confirmed ground truth, and it computes every score itself. Completed answers can't be edited. Raw answers are kept for 180 days and scores indefinitely, so you can go back and read what an assistant actually said.

Rung 3: does AI name you on your topics?

This is the rung most people mean by "AI visibility": someone asks about the subject, not the brand. Topics are saved with aura_save_topics. A topic is a subject in the words a customer uses, tagged with intents (learn, choose, compare, cost, local, action, problem) and with where it came from (your site, Search Console, suggest data, an earlier AI answer and so on). The tool tells agents to "never invent demand."

Some rules keep rung 3 honest:

• A topic can become active only after rung 1 passes, or when rung 3 opens as preliminary after six weekly cycles with four entity tasks. It also has to fit your plan's active-topic budget.
• Activating a topic creates neutral questions that name neither the brand nor the domain. These run as ordinary monitoring questions, with an explicit country and language set for each run (aura_begin_monitoring_run).
• For each saved answer, aura_save_topic_assessment records which companies or products the assistant named and whether it recommended each one, with exact quotes. Names that keep coming back are proposed to you as alternatives, and you decide whether to confirm them.

From scores to site tasks

Measuring is only useful if it changes the site. aura_get_ladder is the starting point. It returns each rung's state (locked, active, passed, maintained, regressed), a score with confidence, the gate reasons in plain words, a per-assistant breakdown, wrong or missing facts, when the next measurement is due, and one next action with the exact tool call.

When a measurement shows a problem, the ladder offers recommended tasks tied to that signal: an entity page, a fact page, or topic pages. The agent creates one with aura_instantiate_template and the signal's ID. The server checks that the signal is still current, fills in the task from your confirmed profile, and keeps no more than five ladder tasks open at a time. A ladder task counts as done only after a later comparable measurement shows the signal is gone. Shipping a page isn't the finish line. A changed answer is.

Re-measurement is built in

You don't need to remember when to re-check. For projects with the ladder on, aura_get_next_tasks returns a scheduled list of measurements that are due or have regressed, each with a reason and ready tool calls. The guidance is to act on regressions first. The same queue also offers standard suggestions a project may be missing: Bing indexing, robots access for AI search bots, official pricing, comparison, reviews and about pages, a monthly content refresh, and llms.txt at low priority.

A prompt you can give your agent

Connect your agent (Codex, Claude Code, Grok Bot or another MCP client) to https://aurageo.io/mcp, then try:

Work on my site's AI-visibility ladder in AURA GEO. Start with aura_get_ladder and aura_get_subject_profile. If the profile is missing facts, propose only what you can quote from my public pages, each with an evidence URL, and tell me what I need to confirm in the cabinet. Don't treat drafts as confirmed. If the ladder is off, tell me how to turn it on and stop there. Otherwise, start the next due measurement. Ask every question exactly as given, in a fresh session of each assistant, and save the full answer with an exact quote. If an assistant blocks you with a login, captcha or limit, mark that check blocked with the reason. Never fill in a result. When the run is scored, summarize per assistant: recognized, partial, not found, confused or fabricated; which core facts were wrong or missing, with quotes. Then create at most the recommended ladder tasks, and tell me which page changes would remove each signal. Don't call a task done until a later comparable measurement confirms it.

What the ladder doesn't do

Be clear about its limits. AURA doesn't ask the assistants itself. Your agent runs each check in a real assistant session and reports what it saw, and AURA validates the quotes against that saved answer. The monitoring tools also state plainly that they make no provider queries and call no paid provider API. A passed rung describes those runs. It doesn't guarantee future answers, and it isn't proof of citations or visits. For those, look at citations, bot visits and referral data separately.

To try it, start at AURA GEO and follow the MCP guide to connect your agent.

It sounds like a simple analytics question, and it partly is. But AI referrals have a few quirks that make it easy to report a number that looks precise and isn't. This post shows how referral tracking works in AURA GEO, how to have your own agent set it up over MCP, and how to read the result without overclaiming.

Why AI referrals are tricky to count

When someone clicks a link, the browser may tell the destination where the visitor came from, using the Referer header. How much it sends is governed by the Referrer-Policy. Under the default, strict-origin-when-cross-origin, a cross-site HTTPS link sends only the origin (for example https://chatgpt.com/). Under no-referrer, it sends nothing at all.

So even a real click from an AI answer can arrive without a source. Some services add a tag to help: OpenAI's publisher FAQ says ChatGPT automatically includes utm_source=chatgpt.com in referral URLs. Others may not.

That leaves three kinds of visit:

1. Visits with a recognizable AI referrer.
2. Visits with a recognizable source tag.
3. Visits with no usable source, which look "direct" even if a chatbot was involved.

Any honest report has to keep the third group separate instead of guessing.

What AURA GEO's tracker does

According to AURA GEO's MCP documentation and privacy page, the tracker works like this:

• Recognition: the server matches the referring domain against a published table: chatgpt.com and chat.openai.com (ChatGPT), gemini.google.com (Gemini), claude.ai (Claude), perplexity.ai (Perplexity), grok.com (Grok), copilot.microsoft.com and copilot.com (Copilot), meta.ai, chat.deepseek.com and chat.mistral.ai. An allowed utm_source value can also be used.
• Unknowns stay unknown: if a browser or app omits the referrer, the visit stays in direct/other. AURA doesn't redistribute those visits between assistants in proportion to citations.
• Units: counts are page-load events, not unique people.
• What's stored: a sanitized page path, the referral source category, time, and events for selected goals. URL parameters, fragments and the full referrer address aren't stored.
• What's not used: no cookies, persistent visitor identifiers or fingerprinting. IP addresses aren't recorded in analytics tables, which is also why a country breakdown isn't available.
• Retention: 7, 14 or 30 days, chosen by the owner (30 by default).

There are two places the tracker can live:

• Pages AURA publishes in the /answers/ section have the tracker connected automatically.
• Your main website needs a separate installation. AURA returns a snippet, someone with access to your templates adds it, and then you verify that real events arrive. The /answers/ collection doesn't automatically extend to the rest of your site.

Setting it up with your agent

Your agent (Codex, Claude Code, Grok Bot or another MCP client) connects to https://aurageo.io/mcp. These are the tools the docs list for this job:

One boundary is important. Connecting your agent to AURA over MCP doesn't give it access to your hosting, DNS or repository. The docs say to apply the snippet "through separately authorized source access." So if you want the agent to install it, give the agent access to your repository or CMS separately. If not, the agent hands you the snippet and you install it.

A prompt you can give your agent

Set up AI referral tracking for my site in AURA GEO. First confirm the domain is verified. If it isn't, tell me exactly which file needs to go where. Then enable analytics with aura_configure_analytics and show me the snippet. Add it to the shared page template in the repository I gave you access to, deploy, and open two pages to check that events arrive in the right project. Mark those as my own test visits. Don't report tracking as working until a real event shows up. After a week, use aura_get_ai_traffic to group referrals by platform and by page. Report counts as page-load events, not people, and list direct/other separately.

Reading the first report

After a week or two you'll have something like "recognized ChatGPT referrals by page." Here's how to read it without fooling yourself:

• Check coverage first. Which pages have the tracker, and since when? A page without the snippet will always show zero.
• Separate your own tests. The docs call the first events technical acceptance, not customers.
• Read pages, not just platforms. "Which page receives AI referrals?" is a more useful question than "how many from ChatGPT in total?" It tells you which content works.
• Don't add categories together. Pageviews, browser goals and server-confirmed events are different units. AURA saves browser goals as client_conversion and server events as server_conversion, so you can tell them apart.
• Remember what's missing. A referral count says nothing about how often you were mentioned without a click, and nothing about the visits that arrived without a source.

Going one step further: goals

Visits are a start. The question a business actually cares about is "did anyone get in touch?" AURA's schema has goal categories for lead, contact, signup and purchase. For anything that matters, the guide on goals recommends sending a server event after the inquiry has actually been saved, with a unique event ID so retries don't double-count. Keep the server secret on the backend, never in a public script, and don't put email addresses or message text into analytics events.

Common mistakes

• Installing on /answers/ and assuming the main site is covered. It isn't. Install the snippet there separately.
• Reporting "visitors" or "customers." The unit is page-load events.
• Splitting "direct" between assistants. That's guesswork dressed up as data.
• Calling a button click a lead. If the inquiry wasn't saved, it wasn't a lead.
• Declaring success after the snippet is in the code. It's done when a real event shows up in the right project.

Referral data is the most down-to-earth evidence in GEO: someone read an answer, clicked and landed on your page. Count it carefully and it becomes the most persuasive line in your report. To try it with your own agent, start at AURA GEO and the MCP guide.

Does that mean the page is indexed? Does it mean ChatGPT will cite it by Friday? No, and no. This post walks through how URL submission works in AURA GEO, what the receipt actually tells you, and how to set up a "publish, then notify, then verify" workflow for your agent that doesn't overclaim.

What IndexNow is (and isn't)

IndexNow is an open protocol: you send a list of changed URLs (up to 10,000 per request) plus a key, and participating search engines get notified. The current list of participants includes Bing, Yandex, Seznam, Naver, Yep, the Internet Archive and Amazonbot. Google is not on it.

The key proves you're allowed to submit URLs for that host. A key file has to be reachable on your domain, and the key, the URL list and the declared host all have to agree.

What the protocol does not do: force anyone to crawl, index or rank your page. Each search engine decides for itself. And it's a search-engine protocol, not a direct line into every AI assistant.

The response codes, in plain English

From the official documentation:

The important bit: on an error, fix the cause first. Firing the same request again and again doesn't speed anything up and can get you rate-limited.

How submission works in AURA GEO

In AURA GEO, URL submission is one of the tools your own agent (Grok Bot, Codex, Claude Code or another MCP client) can call, within the permissions you've given the project. According to the MCP documentation, it:

• submits only changed URLs on the currently verified domain,
• saves the real IndexNow receipts (code, time, addresses),
• separately tries a connected Bing batch submission and Google/Bing sitemaps, if you've connected them,
• and never treats a receipt as proof of index inclusion.

Before any of that, the domain has to be verified. AURA can prepare the ownership and IndexNow proof files, but someone with real access to your site (you, or your agent via a repository or CMS you granted separately) has to put them in place. AURA then fetches those files from the exact domain and updates verification from what it actually finds.

For pages AURA publishes as managed pages, the notification is tied to the publication and its checks, so you can see in one place what went live and what was submitted.

A workflow that doesn't overclaim

Here's a sequence that works well for an agent:

1. Make the change for real. Publish the article or update the page. Don't notify about something that's still a draft.

2. Check the live page. The agent requests the final URL and confirms it returns 200, contains the intended content, isn't noindex, and has the right canonical. If the content isn't there, no notification will fix it.

3. Submit only what changed. One new guide means one URL, maybe plus the hub page that now links to it. Not the whole sitemap.

4. Save the receipt and report it accurately. A good report reads like: "Notification received for 2 URLs (202, key validation pending)." A bad one reads like: "Indexed in all AI search engines."

5. Check search status separately. Later, look at the URL in Bing Webmaster Tools (or Google Search Console for Google) to see what actually happened. A protocol-side "accepted" and "not in the index yet" can both be true at the same time.

6. Watch for citations and visits separately again. Use saved buyer questions to see whether answers start linking to the page, and the tracker to see whether AI referrals land on it. Those are different kinds of evidence from the receipt.

A prompt you can give your agent

After publishing, open the live URL and confirm status 200, the main content, no noindex and a correct canonical. Then submit only the changed URLs through AURA GEO. Save the receipt and report the response code and addresses exactly. Do not describe a receipt as indexing or a citation. Note anything that needs my action, like a missing key file.

Common mistakes

• Submitting before the page is live. You've notified search engines about a 404.
• Submitting a subdomain that isn't verified. If your blog lives on a different subdomain than the verified one, check its connection separately.
• Treating 202 as a win. It's a receipt. Useful, worth saving, not a ranking.
• Retrying on 429. That's the protocol telling you to slow down.

The goal of this step is a correct submission backed by evidence, so the next decision in your GEO work is based on facts rather than hopes. If you want to try this flow with your own agent, start at AURA GEO. The longer explainer is here: what an IndexNow response means and when to submit a URL.

Too little freedom, and you end up approving every comma. Too much, and you wake up to pages you never saw going live under your brand. This post walks through how AURA GEO handles that trade-off, based on its public documentation, and how to pick a setup that fits your situation.

First, what "autopilot" is — and isn't

In AURA GEO, autopilot is a permission level for your agent, not a model that runs in the background inside your website. The agent is still your own: Grok Bot, Codex, Claude Code or another MCP client that you connect yourself. AURA defines what that agent is allowed to do when it calls the MCP tools.

That also means choosing "autopilot" doesn't schedule anything by itself. When and how often your agent runs is configured separately, in the agent's own environment.

The four levels of autonomy

Think of it as a ladder. You can stay on any step as long as you like.

1. Read-only. The agent can read the project: audits, questions, reports, tasks. Good for the first session, when you just want to see how the agent understands your site and what it would suggest.

2. Drafts. The agent can prepare content — for example, an answer page — but nothing becomes public. Useful when you want to see the agent's writing quality before trusting it with anything live.

3. Publish with approval. The agent can propose a publication, but a human signs off. In practice it looks like this: the agent prepares a page, creates an approval request and returns a preview link. The owner sees the proposed action, the content comparison and the details needed to check it. After the decision, the agent reads the status and continues only with what's been allowed.

4. Autopilot within limits. Once the process is agreed, the agent performs only the allowed operations in the specified sections, without asking each time.

One level never silently upgrades into another. And a technical "publish" capability existing in the API doesn't mean the current connection is entitled to use it.

Two layers of control, both always on

Two things decide what an agent can actually do, and they apply at the same time:

• Connection permissions — what this specific agent connection was granted when you connected it. Reading reports, saving observed AI answers, working with project questions, preparing drafts, publishing and submitting URLs are separate permissions. A contractor's agent, for example, can read reports without being able to publish anything.
• Project policy — what's allowed on this project: which sections, which actions, and daily limits.

The stricter rule wins. Saved restrictions don't expand automatically the next time the agent signs in, and an agent is not supposed to widen its own privileges to finish a task.

Sensible default limits

According to AURA GEO's docs, a new autopilot starts with a deliberately small baseline: one new page and five edits per day, in the /answers/ section. The docs also recommend checking the actual saved values before you start, rather than assuming the defaults.

Equally important is what autopilot doesn't give the agent: no arbitrary DNS access, no banking, no access to your code repository. If the agent needs to change files on your main site, you grant that separately in the agent's own environment (for example, repository access in Codex or Claude Code), not through AURA's policy.

A real-world setup that works

Here's a progression that keeps risk low while you build trust:

1. Week 1 — read-only. Let the agent read the audit and tasks and summarize what it would do. Check whether its understanding of your business, region and audience is right.
2. Week 2 — drafts. Ask it to prepare one or two answer pages for real customer questions. Review facts, sources and tone.
3. Week 3 — publish with approval. Let it propose publications. Approve the good ones, reject the rest, and see how it handles a rejection.
4. After that — narrow autopilot. Allow routine work in /answers/ within the daily limits, and keep anything on your main site behind approval.

For agencies managing client sites, it's worth agreeing with each client in advance: which pages may be created, where facts come from, and what always requires a manual decision.

What happens when something goes wrong

Good automation isn't about never making mistakes. It's about being able to see and undo them. A few things AURA GEO builds in:

• An action log. Completed, rejected, failed and pending actions all stay visible, so you can tell a prepared change from an applied one. A pending approval should never be reported as a successful publication.
• Revision checks. Publishing and editing operations check the expected revision. If the agent read revision 7 but you already saved revision 8, the right move is to reread and reconcile — not to overwrite your edit.
• Rollback to an existing version for managed pages, with a check of the public URL afterwards.

The docs are also honest about limits: restoring a page doesn't un-send a search engine notification, doesn't erase what a crawler already read, and doesn't restore a previous citation. It gives you controlled public text and a clear correction history.

And if a process isn't needed anymore, you can tighten the policy or revoke the connection entirely. Revoking stops further access; pages already published need their own decision.

The takeaway

The safest GEO agent isn't the one with the fewest permissions. It's the one whose permissions match a process you've actually agreed on — with a log you can read, limits you've checked and one clear step left for the owner whenever their consent or account is needed.

Want to try this with your own agent? Start at AURA GEO, see the MCP connection guide, or read the full note on autopilot vs approval-based publication.