Mireye

The most dangerous sentence an AI agent can produce is a confident guess about a place. Ask a model for the elevation at 40.7128, -74.006 and it will happily tell you something like "10 to 50 meters" — no source, no timestamp, no way to audit. Mireye, a Y Combinator-backed seed startup, treats that failure as the entire problem. Instead of another map API, it has built what it calls "physical world context for AI agents": a single API that returns cited, timestamped, confidence-scored data for any US location, with the explicit goal of making agents trustworthy when they reason about terrain, flood zones, power lines, or property boundaries.

The pitch is not "more data." It is "data with receipts." Every field in every response carries a source name, a source URL, a fetched-at timestamp, and a confidence level. That provenance is designed to pass straight through to the end user or auditor. Mireye is not selling coordinates; it is selling the ability to say "I know this because USGS says so, and here is the link."

The agent's blind spot is a parcel boundary

Large language models are brilliant at language and terrible at geography. They do not know the elevation of a specific coordinate, the FEMA flood zone for a parcel, or the distance from a site to the nearest 345 kV transmission line. They can approximate, but approximation is exactly what you do not want when deciding where to build a data center or whether to underwrite a coastal property.

Mireye's homepage makes this explicit with a side-by-side comparison. Asked for elevation at 40.7128, -74.006, a stock Claude response hedges: "I don't have real-time access to elevation databases... ranging from roughly sea level to about 10 to 50 meters." No source. No timestamp. Estimated range. The same question through Mireye returns: "13.03 meters above sea level (NAVD88 datum), source=USGS_3DEP_COG, fetched=2026-07-28, confidence=medium." That difference is the product. Mireye is not making agents smarter; it is making them honest about what they do not know and precise about what they do.

The company's blog reinforces this mission with research posts like "We Screened Every Meat Plant in America in One Afternoon" and "Site Selection Is Now Grid Selection: Screening Land for Data Centers." These are not marketing fluff; they are demonstrations that the API can handle large-scale, real-world screening tasks that would be impractical with manual data gathering.

One API, five verbs: how Mireye structures the physical world

Mireye's API is organized around five core endpoints, each a verb that maps to a distinct workflow. This is not a RESTful grab bag; it is a deliberate decomposition of how an agent might need to interact with a place.

• POST /v1/ask — "Ask anything about a place." Natural language question, cited answer. One call can resolve an address, fetch fields, and measure distances, returning the plan it ran so you can replay it.
• POST /v1/geocode — "Turn anything into a place." Street address to coordinate, with derivation method (parcel vs. interpolated) and confidence. Low-confidence matches are refused, not guessed.
• POST /v1/lookup — "One string, the whole stack." Geocoding gives a point; lookup gives the place: county, tract, congressional district, timezone, elevation, flood status — all in one call, again with typed refusals when the match is not good enough.
• POST /v1/fetch — "Cited facts at any location." Named fields or presets, typed values for any US location, each with source, fetch time, and confidence. Batch hundreds of locations; one bad address does not fail the rest.
• POST /v1/proximity — "Measure what the data can't say." Drive-time operations: point-to-point, nearest-by-road over curated infrastructure sets (airports, substations, power plants, rail, ports, urban areas), and labor sheds. Every answer states what it charged and what it can't know.

These five verbs cover the lifecycle of a location-based decision: identify a place, understand its context, measure its relationships, and fetch specific facts. The design is agent-native — each endpoint is a tool an agent can call, and the docs show examples with Claude and GPT-5 using Mireye tools.

The refusal is a feature: geocoding that says no

One of the most striking details in Mireye's documentation is the emphasis on refusal. The geocoding endpoint "refuses" centroid-grade and low-confidence matches rather than guessing. The lookup endpoint gives a "typed refusal when the match is not good enough to stand behind." The field-requests endpoint returns a "typed no" for asks it cannot index — real-time, commercially licensed, or personal contact data — and points the user somewhere else.

This is a deliberate design philosophy. In the world of AI agents, a wrong answer is worse than no answer, because the agent will confidently pass it along. Mireye's refusals are not errors; they are guardrails. They force the agent to stop, ask for clarification, or fall back to a human. For regulated industries like insurance or mortgage underwriting, this is the difference between a tool that is useful and a tool that is a liability.

Field requests: the catalog that builds itself

Mireye's data catalog is deep but not infinite. It covers 85 authoritative sources, mostly US federal datasets (USGS, FEMA, NOAA, USDA, EPA, EIA) plus open data like Overture and Sentinel-2. But what happens when an agent needs a field that is not in the catalog? That is where POST /v1/field-requests comes in.

A developer can describe the data in plain language, with the locations where it is needed. Mireye first matches against the existing catalog: if the field exists, you get it immediately with a cited sample. If it is close but not exact, you get a near miss to accept or reject. If nothing answers, a build is queued with a request_id to poll. When the field goes live, it is available permanently for every future caller.

This is a clever crowdsourcing loop. Every field request that turns into a build enriches the platform for everyone. The catalog grows in response to real demand, not guesses about what developers might need. It also creates a moat: the more requests, the more fields, the more reasons to stay.

Sector presets: from data center to mortgage desk

Mireye is not a generic data API; it is tuned for specific industries. The homepage lists six sectors: data center siting, renewable energy siting, insurance underwriting, mortgage & title, residential land, and commercial lending. Each has a preset in the /v1/fetch endpoint — for example, data_center_siting (90 fields), solar_siting (26), flood_risk (13), grid_interconnect (29).

These presets are not just convenience; they are the product's thesis. Mireye is not asking developers to assemble their own data stacks. It is saying: "We already know what a data center siting screen looks like — slope, FEMA flood zone, nearest 345 kV line, substation voltage, interconnection queue. Here is one call that returns all of it." The sector pages show real examples: screen a data center in Ashburn, VA; a solar farm in Central Iowa; a coastal property in Galveston, TX. Each returns a list of relevant fields (Power, Flood, Terrain, Queue; Slope, Irradiance, Interconnect, Land cover).

This sector focus is also a go-to-market strategy. Instead of selling to every developer, Mireye targets the desks that already ask "should I care about this place, and why?" — and gives them a single API to answer it.

Naming the physical layer: what 'Mireye' signals

The name "Mireye" is a portmanteau of "mirror" and "eye" — a mirror that sees, or an eye that reflects. It is a fitting name for a product that holds up a data-backed mirror to the physical world, letting agents "see" a place with cited facts instead of vague impressions. The name is short, distinctive, and easy to pronounce, though its meaning is not immediately obvious. It does not contain "geo," "map," or "location," which might slow discovery but also sets it apart from the crowded geospatial space.

The domain mireye.com is clean and brandable, matching the name exactly. The visual identity leans on natural imagery — coastlines, hillsides, pampas grass — reinforcing the connection to the physical world. The tagline "Physical world context for AI agents" is descriptive and category-defining, though it leans on the AI-agent buzzword. The positioning is clear: Mireye is not a map API; it is the trust layer for location-aware AI.

Open questions: coverage, pricing, and the trust burden

Mireye's biggest limitation is geography. The data catalog covers the United States only, with drive-time analysis extending to Canada. That is a deliberate choice — US federal data is abundant and authoritative — but it means the product is not yet global. For a startup, focusing on one market is sensible, but it limits the addressable market.

Pricing is credit-based: 5,000 credits free per month, paid plans starting at $19/mo, with extra credits at $1.00 per 1,000. The credit cost per call type is published, which is transparent but could get expensive for high-volume batch operations. The free tier is generous enough to test, but serious production use will require a paid plan.

Finally, the trust burden is real. Mireye promises cited, timestamped data, but the confidence levels vary by layer — elevation is static, FEMA flood maps refresh on their own cadence, USDA cropland updates yearly. Agents must be able to interpret these confidence levels correctly, and Mireye's documentation emphasizes that every response includes the fetched_at timestamp so the agent knows what it is looking at. Whether developers will correctly handle "medium" confidence in high-stakes decisions is an open question.

Despite these caveats, Mireye is addressing a genuine gap. AI agents are being asked to make decisions about the physical world, and they are doing so with blinders on. Mireye gives them eyes — and a mirror to check their work.