# Autonomous front desk

> The email channel of a ground transport marketplace, run end to end on Claude at a fixed monthly cost.

**Sector:** Ground transport marketplace
**Year:** 2026
**Role:** One engineer
**Stack:** Claude, React, Node.js, SQLite
**Runs on:** Terraform, AWS, Cloudflare
**What it does:** Agents work the inbox — outreach, support, bookings

## The problem

A marketplace inbox carries three different jobs at once. New suppliers have to be contacted, followed up and set up. Customers ask questions that need answering the same day. And a proportion of booking requests arrive as prose in an email rather than through the booking form. All three are repetitive enough to want automating and too varied to script, and doing them with metered LLM APIs prices the whole approach out before it is useful.

## What we built

A set of agents that work the email channel end to end. They run supplier outreach as a pipeline, and once a supplier agrees the details go into the mobility platform so the supplier can log in and trade. They answer customer support on the same channel. And they read booking requests that arrive as email and turn them into bookings on the platform. The agents run on Claude against a fixed-fee subscription rather than metered API calls, so cost is a known monthly number and scaling means adding another subscription rather than watching a usage bill. Orchestration runs on Agentic World, a control plane built for this: a Node.js daemon holding the shared work queue and event log in SQLite, with a React console over it.

## Outcome

- Averaging one new supplier onboarded a day, from first contact to trading.
- Responses inside 30 to 60 minutes.
- Outreach, customer support and inbound booking requests all handled on one channel by the same agents.
- The same workflow at today's volume would take around 15 people to run by hand. It runs with three.
- Cost is a fixed monthly subscription rather than a metered API bill that rises with every message.

## The long version

The economics are the point of this one. Agent workflows are easy to justify on
a slide and hard to justify on an invoice, because metered API pricing scales
with exactly the thing you want more of. Building against fixed-fee
subscriptions instead turns cost into a number that can be budgeted, and turns
scaling into a decision about how many subscriptions to run rather than a bill
nobody can forecast.

The work suits agents better than most: a long tail of
similar-but-not-identical conversations, each one low stakes on its own and
collectively the constraint on how fast a marketplace can grow. Supplier
outreach is the clearest case, because the same conversation happens hundreds
of times with different operators. Customer support is the same shape from the
other direction. And booking requests that arrive as email are the case where
an agent earns its place most obviously, because the alternative is a person
reading prose and retyping it into a form.

What makes it hold together is that the handover is into a real system rather
than a spreadsheet. A supplier who agrees gets an account on the mobility
platform. A booking request becomes a booking. The agent's job finishes exactly
where the platform's begins, which is also the line past which a mistake would
be expensive.


[Overcode](https://overcode.io/) — AI workflows and custom systems. This study as HTML: https://overcode.io/work/agent-workflow-outreach/