Building for Agents, Not Humans

Aether has no search bar. No product pages. No comparison tables or filter sidebars. There is no consumer-facing interface at all. Everything about the service is designed for machines to use, not people to look at. This is a deliberate architectural choice, not a gap to be filled later.

Why no website?

The default assumption for any product data service is that it should have a website where people can search and compare products. That is how price comparison has worked for twenty years: build a consumer frontend, drive traffic, monetise through affiliate links.

Aether takes a different approach. The premise is that AI agents are already becoming the interface layer between people and information. When someone wants to find the best price on a pair of headphones, they are increasingly asking an agent rather than visiting a comparison site. The agent does the searching, the filtering, and the presenting. It does not need a website to look at - it needs an API to query.

Building a consumer frontend would mean designing for two audiences simultaneously: the agents consuming data programmatically and the humans browsing visually. These audiences have fundamentally different needs. A human wants a scannable layout, images, and intuitive navigation. An agent wants predictable JSON, consistent field names, and low latency. Trying to serve both well usually means serving neither particularly well.

By building exclusively for agents, every design decision can optimise for machine consumption without compromise.

What agent-first design looks like

Designing for agents instead of humans changes the priorities at every level.

Response format over presentation: A human-facing service invests heavily in how information looks. An agent-facing service invests in how information is structured. Every field in an Aether API response has a predictable name, a consistent type, and a defined set of possible values. An agent that can parse one response can parse every response, across all merchants and categories.

Compact by default: Large language model agents process responses as text tokens. Every unnecessary field in a response costs tokens and processing time. Aether returns a compact set of fields by default and lets agents request additional detail only when needed. This is the opposite of a human-facing product page, which tries to show everything at once and lets the user decide what to ignore.

Freshness over completeness: A human browsing a product page will tolerate slightly stale information because they can see the page was last updated and make a judgement call. An agent making automated decisions needs to know exactly how fresh each data point is. Aether timestamps every piece of data so agents can make their own trust calculations. A price last checked two hours ago is more reliable than one checked two days ago, and the agent can factor that into its response to the user.

Identifiers over names: Humans recognise products by name and appearance. Agents need unambiguous identifiers. Aether uses GTINs (the barcode numbers on physical products) as the canonical way to identify a product across merchants. When an agent queries for a specific GTIN, it gets every merchant listing for that exact product - not a fuzzy name match that might return similar but different items.

What this means for developers

For anyone building an agent or tool that involves product comparison, the practical implication is that Aether is a data source, not a destination. You do not send your users to Aether. You query Aether from within your application and use the structured response to build whatever experience your users need.

The API handles the hard parts - data ingestion, normalisation, cross-merchant matching, freshness tracking, affiliate link wrapping. Your agent handles the parts it is good at - understanding user intent, processing structured results, and presenting clear options.

This division of labour is the core design principle. Aether does not try to understand what the user wants. The agent does that. Aether provides the clean, reliable data the agent needs to answer well.

The quiet part

There is a secondary benefit to having no consumer frontend: it keeps Aether invisible during its validation phase. The service can prove its model works - agents query, users click through, purchases convert - without attracting attention from larger players who might build the same thing. By the time the concept is proven, the data quality and merchant coverage should be hard to replicate quickly.