AgentStatus

Abstract

Does network origin actually matter for AI agents, or is residential monitoring just a latency story? Scoped carefully: origin matters for reachability.

What it proves

Across 6,228 matched agents: mean 4xx 74.2% from cloud vs 22.6% residential. ~4,000 blocked datacenter while allowing residential; zero the reverse.

What it does not

Residential outside-in does not relocate the agent’s outbound tools. A probe from Comcast does not make Google see Comcast. This is a reachability document.

One narrow correctness bridge (client-IP localization) and an explicit boundary around semantic “up but wrong” failures, which need answer evaluation, not residential IPs.

This is the question we keep being asked.

“If the model doesn’t care, why does the network matter?”

A version of this question comes up in roughly half of the technical conversations we have with founders, engineers, and investors. Sometimes it is phrased as “why can’t I just spin up a thousand AWS servers and do what you’re doing.” Sometimes it is “the HTTP request is the same regardless of where it comes from.”

Those framings share a mental model: the agent runs in the cloud, receives a request, processes it, returns a response, and the requester’s network position is incidental. Under that model, residential validation could only matter for transport reliability. That model is incomplete in one important place and oversold in another.

Incomplete: the edge in front of the agent — WAF, bot management, ASN reputation, rate limits — scores the caller before the harness runs. Datacenter ASNs and residential ASNs are not scored the same. If your monitor never gets a usable response, it is not measuring the agent; it is measuring whether the wall let it in.

Oversold: the idea that residential vantage rewrites what the agent’s tools see, or that home Wi‑Fi slows tool calls and thereby changes the model’s context. For normal server-side agents, tool traffic leaves from the agent’s infrastructure. Outside-in monitoring cannot change that egress. Claiming otherwise is a credibility tax on the reachability claim that is true.

Here is what this report claims — and does not.

Scope before mechanisms.

In scope

Reachability. Whether a caller with a given network identity can open a usable conversation with the agent endpoint.

Observer bias. Datacenter-only synthetics systematically sample a different access surface than residential users on WAF-protected public agents.

Harness localization (narrow). When the agent geoips the connecting client IP (or accepts an explicit location param) to choose locale, hotline, store hours, or regional defaults.

Sampling validity for correctness stats. If most datacenter probes are blocked, any “correctness rate” computed on the surviving DC sample is access-skewed — even though grading a single HTTP 200 answer is not itself origin-dependent.

Out of scope / not claimed

Agent tool egress. Residential probes do not make Amazon, Google, or MCP upstreams see a residential caller when the agent is server-side.

User Wi‑Fi → tool speed → model context. Last-mile latency affects the pipe into the agent. Tool calls run on the agent’s pipe out. Conflating those is false for standard hosted agents.

Same-reachability correctness-by-origin as a population finding. When both origins reach the model in the Anti-Synthetic cohort, gold pass rates were nearly identical (~59% vs ~57%). Access asymmetry is the empirical story; origin-caused answer quality is not.

“Residential catches wrong answers datacenter can’t.” A stably wrong answer is wrong from anywhere you can connect. Semantic evaluation is a separate product layer.

There are three pipes, not one causal chain.

Where source IP does and does not enter the system.

Older drafts of this argument drew a single chain: source IP → tool response → model context → answer. That diagram treats the probe’s IP as if it traveled with every tool call. It does not. Split the architecture:

Three paths, not one causal chain

How to read this: A residential monitor sits on path 1 (and path 2 only if the agent uses the caller’s location). It does not move the agent onto a home network for path 3.
Core finding

Residentiality is a property of the observer on the inbound path. It answers whether you are measuring the edge users hit. It is not a property that rewrites the agent’s outbound tool universe.

These are the mechanisms that survive scrutiny.

Reachability first; localization second; nothing dressed as tool magic.

4.1WAF and ASN classification on the agent endpoint

When a request crosses Cloudflare, Akamai, DataDome, Imperva, or similar, the edge scores the connection before the application runs. ASN and IP reputation are first-class features. Datacenter ranges start with degraded trust; residential consumer ASNs do not.23

This is the broadest mechanism in the cohort. It produces access failure: 429, challenge pages, silent drops — not a different gold answer after HTTP 200. The agent’s tools are irrelevant here; the probe never reaches reasoning.

4.2Client-IP localization in the harness

Some agents infer country or region from the connecting IP and branch: crisis hotlines, language defaults, store hours, jurisdictional content. That is Pipe B. Validating it requires probing from the geographies you care about, because the correct answer is region-dependent.

This is the one honest correctness-by-origin bridge. It is not “tools saw residential IP.” It is “harness read client IP and chose a branch.” We have benchmark prompts for crisis routing (US → 988, UK → 116 123, Germany → Telefonseelsorge, Ukraine → 7333). Verbatim production galleries by geography are still being collected; until published, treat crisis routing as a mechanism, not as a claimed prod exhibit.

4.3Organic residential vs residential proxy fingerprint

Modern bot management scores IP jointly with session history, TLS fingerprint, and behavior. Cloudflare’s residential-proxy models explicitly separate organic residential from proxy exits.10 An owned device mesh with persistent identity is not interchangeable with rotating commercial proxy minutes. That supports the substitute analysis below; it does not imply tool-egress relocation.

4.4What we are not elevating as residentiality mechanisms

Blind search/price localization via probe IP. Academic work on search personalization and ecommerce price discrimination is real when the browser or scraper talks to Google/Amazon from different origins.56 A server-side agent’s tool calls usually leave from the agent’s cloud. Probe residentiality does not automatically reproduce shopper-origin pricing. Only explicit location params (or client-side tools) close that gap.

MCP allowlists as a residential-mesh pitch. Enterprise MCP gates usually care who calls the MCP — typically the agent connector — not who opened the chat UI from a home laptop. Residential chat probes do not satisfy those allowlists.

Voice/STIR as proof of HTTP residentiality. Telephony attestation is a real adjacent problem. It is not evidence for the HTTP inbound thesis and is not treated as such here.

Provider nondeterminism. Real, and separable. Multi-vantage probing helps decompose variance; it does not make residentiality the cause of batch-composition noise.

Here is the empirical receipt from the cohort.

Access asymmetry across 6,228 agents — not same-reachability correctness-by-origin.

The Anti-Synthetic Report is a controlled population comparison: identical prompt corpus, matched agents, two observer classes. Methodology note that matters for readers: Group A was completed rora jobs whose nodes belonged to terminated gaming-farm providers; Group B was all other completed rora jobs in the window. It is a retrospective cohort study on historical jobs, not a claim that continuous dual-vantage DC-vs-residential monitoring is how every AgentStatus run works today.

Finding 1 · Block-rate asymmetry

74.2% mean per-agent 4xx from datacenter origins. 22.6% from residential. Same agents, same prompts.

Finding 2 · Directional gap

~64% of agents (~4,000 / 6,228) blocked datacenter while allowing residential at normal rates. Zero reverse cases in the matched cohort.

Finding 3 · When both reach, gold is tied

When both origins reached the model, gold evaluation pass rates were nearly identical (~59% vs ~57%). The population gap is network access, not origin-caused model capability.

How to read the 74%: it is not “users are broken 74% of the time.” It is the share of datacenter-origin test attempts that never got a usable agent response. Teams are often measuring from a network position the edge refuses to serve.

Two failure classes (do not conflate)

Access failure — probe blocked or empty (this report’s empirical core). Datacenter synthetics often never see the surface users see.

Answer failure — HTTP 200, answer wrong. Requires semantic evaluation. Origin does not make a stably wrong answer suddenly correct. Residential vantage improves sampling for grading (you grade answers you can actually retrieve); it does not invent correctness-by-origin.

These substitutes don’t close the reachability gap.

Cheaper observers that sit on the wrong side of the wall.

6.1Datacenter synthetics alone

Elastic and cheap. On WAF-protected public agents, they often run in the failure mode the Anti-Synthetic cohort measured. Validity collapses where access is the question. (Operators who own the agent can allowlist synthetic IPs or expose an authenticated health path — that fixes their monitor; it does not make naked AWS probes representative of anonymous consumer traffic against third-party edges.)

6.2Commercial residential proxies

Useful for scraping. Weak for continuous outside-in validation: WAFs classify proxy residential differently from organic residential;10 sessions are often short-lived; rotating pools cannot be pre-registered where persistence matters. Unit economics for high-volume monitoring favor an owned mesh. None of this relocates agent tool egress.

6.3Fingerprint spoofing from a datacenter

Application-layer lies do not rewrite ASN reputation or JA3/JA4 computed at TLS handshake time.30 Spoofing is a treadmill, not a foundation.

Here is what access failure looks like.

Same prompt, different origin — production pairs from the Anti-Synthetic cohort.

These pairs are reachability exhibits. Datacenter arm blocked or empty; residential arm reached the product. Do not read them as “different correct answers.”

Anti-Synthetic cohort · April 2026

Mean per-agent 4xx: 74.2% datacenter vs 22.6% residential. Mean 429: 67.3% vs 15.8%. ~4,000 / 6,228 agents blocked DC while allowing residential; zero reverse. Gold when both reached: ~59% vs ~57%.

Example 1 US grocery retailer Δ4xx 79pp
Same prompt to both origins
Hi, we’re AgentStatus. We independently test AI agents from the outside in… Hello — what can you help me with today?
From a datacenter Blocked · HTTP 429
Proxy returned 429: rate limited. The edge stopped the request before the grocery assistant ran.
86.5% of datacenter probes on this agent
From a home / ISP network Reached · HTTP 200
Howdy! Welcome! Here are some ways I can help you today: Product Info, Pharmacy & Wellness…
92.2% HTTP 2xx on residential probes · verified in production logs

192 datacenter probes · 780 residential probes · same agent, same prompt

Why it matters: Cloud synthetics report the agent down. Real consumer networks get the branded assistant. The monitor measured the wall, not the product.
Example 2 European retail bank Δ4xx 78pp
Same prompt to both origins
Standard AgentStatus disclosure + capability greeting request (same corpus as Group A)
From a datacenter Blocked · HTTP 429
Edge throttles cloud-origin traffic before banking assistant logic runs.
90.1% of datacenter probes rate-limited
From a home / ISP network Reached · HTTP 200
Assistant reachable from consumer networks.
87.5% HTTP 2xx · 12.2% residual 4xx

192 datacenter probes · 728 residential probes

Why it matters: Financial-services edges are aggressive against synthetic/cloud traffic. Inside-out checks never see the block.
Example 3 SaaS productivity agent Δ4xx 85pp
Same prompt to both origins
Standard AgentStatus disclosure + capability greeting request
From a datacenter Blocked · no response
Connection dropped or blocked before any model output — often a silent RST or pre-HTTP rejection, not a visible 429.
97.9% transport failure · 0% HTTP 2xx
From a home / ISP network Reached · HTTP 200
Agent responds normally from consumer devices.
82.3% HTTP 2xx · 12.9% residual 4xx

188 datacenter probes · 5,724 residential probes (largest matched sample in cohort)

Why it matters: “No response” from cloud IPs is often observer failure, not a user-facing outage.
Example 4 Footwear brand agent Δ4xx 81pp
Same prompt to both origins
Standard AgentStatus disclosure + capability greeting request
From a datacenter Blocked · HTTP 429
Rate limited on nearly nine in ten cloud-origin attempts.
89.3% HTTP 429
From a home / ISP network Reached · HTTP 200
Brand assistant reachable on consumer networks.
90.6% HTTP 2xx · 7.9% residual 4xx

168 datacenter probes · 668 residential probes

Why it matters: Dominant pattern in high-divergence agents: datacenter rate-limited at the gate; residential gets the product.

Geographic consistency is part of reliability.

The underclaimed pillar between reachability and correctness.

Once access works from multiple regions, a separate question opens: does the agent behave consistently enough across geos for your SLOs? Cross-geo divergence in response hashes (same prompt, different regions, both HTTP 200) is a reliability / metamorphic signal — not proof that tools localized by residential egress.

Causes can include harness locale branches (Pipe B), CDN routing, regional feature flags, or ordinary provider variance. The discipline is attribution: residential multi-geo probing gives you the samples; it does not automatically label the root cause. AgentStatus records geo probe snapshots for this differential work; treat unexplained divergence as a reliability investigation, not as a correctness-by-origin trophy.

Semantic evaluation is a separate layer from reachability.

Up but wrong is real. It is not residentiality.

Production agents routinely return HTTP 200 with wrong retrieval, wrong tools, or confident nonsense. That failure class needs outside-in prompts plus answer judges. Residential vantage helps because you can retrieve answers to grade on user-class networks. It does not make grading origin-dependent for stably wrong answers.

In a single-day sample of 7,133 validation runs, 62% had perfect transport uptime (99%+) and a zero gold pass rate. That is an argument for semantic monitoring — adjacent product surface, not a residential-IP theorem. We do not use those transcripts as evidence that datacenter and residential origins disagree on correctness after both receive 200.

Here is the synthesis of what residentiality can and cannot claim.

The datacenter blind spot, stated precisely.

Every monitoring architecture chooses an observer. For AI agents behind modern edges, a datacenter observer often cannot open the door users walk through. That is the residentiality thesis, scoped:

Mechanisms in Section 4 explain why the door discriminates. Numbers in Section 5 show how often in a large matched cohort. Access pairs show what it looks like in transcripts. Localization (Pipe B) is the narrow place correctness honestly depends on origin. Everything else that looks like “wrong answer because residential” should be checked for a blocked datacenter arm first.

Here is what we built to close the inbound gap.

Honest product mapping.

AgentStatus runs outside-in validations on the Carmel residential Fabric mesh: real devices, ISP egress, probes executed on nodes; orchestration and semantic judging on the backend. A probe’s TCP identity at the target is the node’s public IP. We do not spoof X-Forwarded-For to fake client IP. Optional inject_geo_context can prepend [User location: …] for harnesses that honor text hints; Perplexity can receive structured user_location when enabled. Neither relocates agent tool egress.

Point the product at an endpoint to see where access holds, where it fails by region, and — separately — where answers fail evaluation after transport succeeds. This report is the long-form case for why the first question is residential. The second question is semantic. Do not merge them.

References & Further Reading

  1. Cloudflare, “Bot Management variables,” developer documentation. developers.cloudflare.com/bots/reference/bot-management-variables/. See also Cloudflare, “Announcing Friendly Bots,” Cloudflare Blog.
  2. Technical analyses of Cloudflare bot management emphasizing IP reputation / ASN as primary risk features (industry 2026 literature).
  3. Industry and academic work on location-driven search personalization (Hannak et al., WWW 2013; Kliman-Silver et al., IMC 2015) and LLM-era geo response variation.
  4. J. Mikians et al., “Detecting price and search discrimination on the internet,” HotNets 2012; follow-ons at CoNEXT 2013 and IMC 2014 on ecommerce price steering.
  5. Cloudflare, “Using machine learning to detect bot attacks that leverage residential proxies,” Cloudflare Blog. blog.cloudflare.com/residential-proxy-bot-detection-using-machine-learning/
  6. Cloudflare, “JA3/JA4 fingerprint,” bot solutions documentation. developers.cloudflare.com/bots/additional-configurations/ja3-ja4-fingerprint/
  7. Carmel Labs, “The Anti-Synthetic Report,” agentstatus.dev/anti-synthetic-report. Empirical cohort underlying Section 5. Frozen methodology: docs/reports/anti-synthetic-april-2026/ in the backend repo.