Why developers need AI customers

Long running AI agents that deal with other companies have to stay their customers for weeks or months, so developers need AI customers: an inbox, phone number and browser that keep working, waiting that costs close to nothing, wake ups on outside events and evidence that holds. Durable execution engines such as Temporal, Inngest, Restate and DBOS make the waiting reliable, and an AI customer adds the identity and the evidence.

Engineers and technical founders build agents that deal with other companies: they sign up, wait, receive mail and texts, and act weeks later. AI customers give those agents a customer relationship that lasts as long as the job. What AI customers are defines the term, and why AI customers matter makes the case for every company.

Long running AI agents in production

Most agents in production run inside a session. A request arrives, the model plans and calls tools, and the work ends within minutes. An agent that is a customer of another company works on that company’s clock: the welcome email in minutes, the basket reminder the next day, the price change after 3 weeks, the win back email after 60 days, the renewal notice after 11 months.

That gap moves the engineering from compute to state. The agent has to keep an identity, sleep through weeks of nothing, wake when the company acts and show later what arrived. Durable execution engines were built for the waiting. Temporal’s documentation says a Timer can be set as short as one second or as long as several years, and that Workers consume no additional resources while they wait for one to fire.

The usual stack has an agent framework such as LangGraph or Pydantic AI for the model loop, a durable engine or runtime to keep state across waits and crashes, and services such as AgentMail, Twilio and Browserbase for the inbox, the number and the browser. AI customers for developers prices each part.

Building durable AI agents: the 6 hard parts

Each is a familiar distributed systems problem, with a company’s website, mail server and SMS provider on the other side in place of an API.

1. Identity that keeps working

A customer is an identity a company recognises over time: an email address, a phone number, a signed in browser, an account. Give each AI customer its own inbox at each company it joins, so every email belongs to 1 company, and a number per market for texts and login codes. Keep the identifiers in the agent’s durable state, never in a session.

Browsers need the same care. Browserbase Contexts keep logins and local storage across sessions that are set to persist them, until they are deleted or invalidated, and a site can still expire a login, so the agent checks it is signed in before each step and treats a forced sign out as an event. The identity is made for the job and never borrows a real person’s name, address or card.

2. Waiting for months without a running process

The expensive design is a process per customer, such as a loop that holds a connection open until mail arrives. On Cloudflare, an object that accepts a WebSocket is billed for duration for the entire time it is connected unless it uses the WebSocket Hibernation API, and an object that is idle and eligible for hibernation is not billed for duration. Every durable runtime separates the wait from compute in its own way.

• Temporal: Timers are persisted, so a wait survives a Worker or service outage and resolves once both are back.
• Vercel Workflows: sleep pauses a workflow without consuming compute resources, and Vercel’s limits page lists no limit on sleep or run duration.
• DBOS: DBOS.sleep() saves the wake up time in the database, for waits of days, weeks or months.
• Restate: the handler is suspended while it sleeps, which saves cost on platforms that charge for execution time.
• Cloudflare Agents: scheduled tasks are persisted to SQLite and use Durable Object alarms to wake the agent.

Check each engine’s limit against the longest wait. Inngest caps a run’s total lifetime, sleeps included, at 30 days on Free, 90 on Pro and 366 on Business, and a Step Functions callback waits up to the one year service quota. A customer that outlives a run is easier to model as an entity, 1 durable object or keyed record per AI customer, with each wait as a short run that starts from its state.

3. Waking on outside events

The company decides when the agent works. AgentMail sends a message.received event when a new email is received and processed, and when a message reaches a Twilio number, Twilio sends a request to your web application. The handler finds the AI customer by recipient address or number and resumes its run.

Each engine has a primitive for the resume. Temporal has Signals, billed as Actions on Temporal Cloud. Inngest’s step.waitForEvent pauses a run until a matching event arrives or the wait times out. A Restate awakeable has an ID an external system resolves. DBOS persists every message a workflow receives through send and recv, Vercel has hooks, Step Functions has task tokens, and a LangGraph interrupt waits indefinitely until the graph is resumed.

Webhooks can arrive twice, so key each wake on the message ID and make the step idempotent. Silence needs a clock of its own. Race every expected message against a deadline, so a welcome email that hasn’t come 24 hours after sign up is recorded as a dated fact.

4. Fan out

One request often becomes thousands of customers: every rival a user names, every account on a list, every merchant on a platform. Each needs its own identity, clock and evidence, and they start together. Platforms publish their ceilings: Vercel Workflows allows 1,000 run creations a second, and Restate’s Starter plan runs 50 actions a second with bursts to 500.

The outside world sets its own pace. Cap concurrency per domain so sign ups arrive at a customer’s pace, and record a CAPTCHA or bot wall as a step the AI customer couldn’t test, because it never gets round one. Where 2 users watch the same company, 1 shared AI customer gives the second user the history the first one built.

5. Learning a site once and running it as code

A model that reasons through every sign up spends tokens on every run and can take a different path each time. Many companies collect sign ups through the same email and form platforms, so the first sign up on a platform can be worked out by an agent, recorded and replayed as code at every company built the same way.

Browser tooling already supports the pattern. Stagehand’s action caching describes two caches: a local cache that replays recorded actions with no LLM calls and no token cost, to be cleared when a page’s structure changes, and a server-side cache that misses when the page changes, so the model is called again. Version every program, test each version on stored pages before it goes live, and keep a model for forms no program recognises.

6. Evidence that holds

An agent that reports a rival’s price cut has to show the email. Store each message as it arrived, in an append only store: raw bytes, headers, arrival time and a content hash. RFC 6376 lets the domain that signs a message claim responsibility for it, checked against a public key the domain publishes, and domains replace their keys over time. A DKIM signature is checked on arrival and kept with its key.

Facts come from evidence through versioned rules, 1 sentence each with a link back. When a rule changes, derive the facts again from stored evidence, because last month’s emails can’t be collected twice. This is also the agent’s memory. LangGraph’s checkpointers keep short term memory per thread and its stores keep long term memory across threads, and an AI customer’s long term memory of a company is its evidence.

What waiting costs

The design choice with the largest bill is how agents wait. The sum is agents × seconds kept in memory a month × memory per agent × the duration price, against agents × wake ups × seconds per wake on the same price. Cloudflare publishes every rate the sum needs: duration is billed on the 128 MB each object is allocated, at $12.50 per million GB-s after 400,000 included, rounded up to the next million, idle objects eligible for hibernation aren’t billed for duration, and requests cost $0.15 a million after 1 million.

At the low end, 1,000 agents kept in memory cost about $4,155 a month against $5 asleep. At the high end, 100,000 cost about $414,730 a month against about $17.80.

• By month 3: $12,465 to $1.24 million awake, $15 to $53 asleep.
• By month 6: $24,930 to $2.49 million awake, $30 to $107 asleep.
• By month 12: $49,860 to $4.98 million awake, $60 to $214 asleep.

Designing for sleep costs engineering time. At the median wage for software developers, $135,980 a year in May 2025, an engineer week is about $2,615 in salary, so 4 weeks spent moving the waiting into hibernating objects or a durable engine pays back within the first month at 10,000 agents and in about 2.5 months at 1,000. The inbox, number, browser and model behind each AI customer are priced line by line in AI customers at scale.

Durable AI agents by hand, and as a routine

The work a durable engine leaves with the team is the customer layer: sign up programs × the share that break each month × hours per fix. As an example, 1,000 companies on 15 form platforms and 120 custom forms make 135 programs, and if 1 in 20 breaks in a month at an hour per fix, that is about 7 hours a month.

A broken program fails quietly. The agent stops receiving mail and nothing throws an error, so each program needs a check of its own, and the checks grow with every company and every market.

Run as a routine, this is customer-side observability. Customer-side observability is seeing what a company does to its customers by being one of them: every email, text, price, page, checkout and AI answer it sends, kept over time with evidence anyone can check. For a developer it has 3 parts, written before the first run.

• Pass marks as assertions. A welcome email within 10 minutes of sign up, a login code by text within 60 seconds, a DKIM pass, each typed and stored with the program.
• A cadence. Every deploy of your own product, every morning for each company watched, and every inbound email or text.
• An owner for each fail. The on call engineer for your own sign up, the program’s maintainer for a broken replay, and the account owner when a merchant’s store goes quiet.

What AI customers do for developers

An AI customer is an AI agent that becomes a real customer of a company, with its own inbox, phone number and browser, and keeps what the company sends and shows it as evidence.

For a developer, an AI customer is a tool the agent calls. It holds the identity, does the waiting and keeps the evidence, and the agent reads facts when it needs them. It does these 5 jobs in a product or a pipeline.

The 10 builds behind these jobs, with the calls each makes and where its facts land, are in what to build with AI customers.

Obsession’s open source runtime fans out to 100,000 companies at once, hibernates each agent until mail, a reply or a clock wakes it, and compiles a first run’s trace into a program of code and typed questions. Raw evidence is stored by content hash, with DKIM checked on arrival and the key kept. Obsession Cloud runs it with inboxes, phone numbers and browsers in many countries and a shared record an agent can look up on day one.

What changes in 2026 and 2027

• Live: durable execution inside agent frameworks. Pydantic AI supports 8 durable execution engines, Temporal, DBOS, Prefect and Restate among them, and Vercel’s durable harness connects Claude Code and Codex sessions to its Workflow SDK so they resume after crashes and deployments.
• Live: agents with verifiable identities. Cloudflare’s Web Bot Auth lets agents sign their requests, its Verified bots documentation says signed agents are folded into Verified bots from 1 July 2026, and Shopify’s Storefront API gives signed traffic higher rate limits than unsigned bots.
• Live: one protocol for tools. MCP is an open source standard for connecting AI applications to external systems, so an agent calls a customer-side tool the way it calls search or a browser.
• Live: the AI notice in the EU. Article 50 of the EU AI Act requires AI systems that talk to people to be designed so those people are told they are dealing with an AI, unless it is obvious, and the Act applies from 2 August 2026. An AI customer that reaches a person says it is an AI.
• Forecast: more agents contacting companies. A Salesforce executive wrote on 19 October 2026 that consumers are starting to hand tasks such as cancelling subscriptions to personal agents that can contact businesses at a volume people would not.

Each change rewards an agent that keeps a stable, identified presence at each company and evidence for what it reports, which is what an AI customer holds.

Durable execution for AI agents, compared

Obsession makes AI customers, so every other option is described from its provider’s own pages as of 24 October 2026.

Most teams combine 2 rows: an engine or runtime for the waiting, and a customer layer for identities, sign up programs and evidence. The engines differ in where state lives, from DBOS’s Postgres database with no separate orchestration server to one Durable Object per agent on Cloudflare. Temporal, LangGraph and Pydantic AI are MIT licensed, and Temporal is free to host yourself.

When developers don’t need AI customers

• The work ends inside one session. Research, coding and summaries need a durable engine at most.
• The agent reads public pages only. A crawler or a browser API does that without an identity.
• A few companies, checked now and then. A spare inbox, a phone and a weekly script cover it.
• The company offers an API for the data. Shopify’s Storefront API serves a store’s products and prices directly.
• The question is about your own internals. Traces, logs and metrics answer it.

Start this week

1. List the companies your agent must be a customer of, with what each should send and by when.
2. Choose where waiting lives, an engine or an object per agent, and check its run length against your longest wait.
3. Give each company its own inbox and number, and route every webhook by recipient to that agent, keyed on the message ID.
4. Store every email raw, with its headers, arrival time, a hash and the DKIM result checked on arrival.
5. Fill in the waiting sum with your own agent count and engineering rate.

Questions about long running AI agents