The Stateless Data Model: How Treg, Deepline, Landbase, and Orthogonal Work

There are two data models for GTM enrichment right now. One is the stateful table that tools like Clay are built on, which I wrote about in the stateful data model. This post is about the other one: a catalog of stateless endpoints, handed to an AI agent.

Treg, Deepline, Landbase, and Orthogonal all work this way. You ask for data, they give it to you, and you own it. pipe0 works this way too, and then it doesn't stop there. More on that at the end.

How the model works

The vendor holds accounts with many data providers and puts each one behind an endpoint. Your agent gets one key and a catalog.

• Treg lists 3,800+ endpoints across SEO, ads, social, and enrichment, priced per call at each provider's own rate.
• Orthogonal, from Y Combinator's Winter 2026 batch, puts 35+ paid APIs behind one REST API, MCP server, SDK, and CLI, and bills per call.
• Landbase and Deepline focus on GTM: searches, enrichment, verification.

Every call stands on its own. The agent sends a LinkedIn URL, a phone number comes back, and the vendor forgets the request ever happened. There is no table, no project, no workflow on the vendor's side. Whatever the agent builds from those answers lives in the agent's conversation, or in files on your machine.

That's the model's strength. It's simple, it's broad, and any agent can use it without learning a UI.

Nothing runs when your agent isn't running

The model has one hard edge: it only does something while an agent is calling it.

Take a schedule. "Re-check these 2,000 accounts for job changes every Monday" is a normal GTM job. With a stateless tool, the schedule has to live in the agent. You can set that up, but most agent schedules run on your own machine. If the laptop is closed on Monday morning, nothing happens. And when it does run, the agent rebuilds the whole workflow from its instructions, making fresh decisions each time.

Webhooks are worse. A webhook is someone else's system knocking on your door when something happens: a form fill, a new signup, a reply. That needs a public URL that is always online. Your laptop has neither. You can get there with a tunnel like ngrok, which is a developer tool most GTM teams shouldn't need to learn, and the machine still has to stay on around the clock.

Signals and monitoring have the same problem. Watching 40,000 companies for funding rounds is a job for something that runs in the cloud and remembers what it saw last week. A stateless catalog remembers nothing by design.

So these tools are optimized for retrieval. They're very good at getting data. The logic you can build around that data is limited to whatever an agent can rebuild in one session.

Primitives the agent has to assemble

The second limit is the level of abstraction. Most catalogs give the agent single-provider endpoints: this provider's email finder, that provider's phone lookup. Concepts like waterfalls, fallback providers, and verification are rarely built in. Deepline is the exception with real waterfalls, and Treg routes some lookups through providers cheapest first. For most of the catalog the agent gets raw parts.

So the agent assembles them, every time. Call one provider, read the answer, decide whether it's good enough, try the next one, verify. That's a lot of reasoning per row, and reasoning is slow.

We measured it. Asked for a single mobile number from a LinkedIn URL, pipe0 answered in 17 seconds. Deepline took between 2.5 and 4 minutes, most of it spent working through the profile before it returned a number.

Where pipe0 sits

pipe0 gives an agent the same stateless contract. Searches find companies and people, pipes enrich them, and each call returns records the agent owns. But the blocks are bigger: a pipe that finds a mobile number is already a benchmarked waterfall with verification inside, so the agent asks once instead of assembling five providers.

And the data has somewhere to go. When a list needs a schedule, a webhook, or a signal, the agent writes it to a pipe0 sheet. The same records become a table in the cloud, up to 2M rows, that runs on a schedule and listens for webhooks while your laptop is closed.

That takes a contract that works the same across interfaces: one call through the API, the same block in a sheet column, the same block from an agent over MCP. Stateless when that's enough, stateful when the work has to keep running. We compared the tools in detail on the Treg, Deepline, and Landbase pages.