Apps, Ambassadors, and Agents — which one do I build?

Waymaker Host gives you three ways to run something. They share the same fast global platform underneath, but they behave differently — and picking the right one is a one-question test.

The one-question test

If it…	Build a…	Because…
has an audience — a web address people visit	App	Apps are made for visitors: pages, domains, staging, a database, a team.
has a job — it acts on your behalf	Ambassador	Ambassadors run your automations: webhooks, schedules, integrations. Nobody "visits" them.
has a memory — it keeps working on something between interactions	Agent	Agents are long-lived workers that remember: an ongoing conversation, a workflow they're shepherding, a queue they own.

Think of it like the difference between the programs on your computer: an application you open, a scheduled task that runs at 9am, and an assistant that keeps working in the background. Same computer — three different kinds of thing.

Apps — something people visit

An App is anything with a web address: your marketing site, a customer portal, an internal tool, a booking system. Apps can be static (pre-built pages, blazing fast) or server-rendered (pages built per-visitor, API routes, sign-ins) — Host detects which automatically on every push.

Apps get the full audience toolkit: custom domains, staging, environment variables, their own Postgres database, team collaborators, and an App Store listing.

Ambassadors — something with a job

An Ambassador represents you to other systems. It wakes up when something happens (a webhook fires, a schedule ticks, a form is submitted), does its job, and goes back to sleep. Sync a spreadsheet nightly. Post to Slack when an order lands. Reconcile invoices every Monday.

Ambassadors get the job toolkit: schedules, invocation logs, and ctx — built-in access to your tables, AI, and your app's database.

Agents — something with a memory

An Agent is a long-lived worker that holds state between interactions. Where an Ambassador forgets everything the moment its job is done, an Agent remembers — the conversation so far, the workflow it's halfway through, the queue it's draining.

Agents are addressed by an id rather than a web address, and every id gets its own isolated memory. Ask for agent acme and you reach acme's instance, with acme's data; ask for globex and you reach a different one. That isolation is why an Agent is the right shape for per-customer work: one agent, many tenants, no cross-contamination.

Agents get the memory toolkit: durable state that survives between calls, schedules they set for themselves, and AI — either through your Waymaker credits or your own provider key.

The grey zone

Could your App's API routes do an Ambassador's job? Technically, sometimes. Use the management test: if the thing needs a domain and staging, it's an App; if it needs a schedule and run-by-run logs, it's an Ambassador. When in doubt, build the App first — you can always add an Ambassador beside it.