Sync and async agents: the two kinds every business launches

Every business that launches an agent on JustCopy launches one of two kinds: one that answers customers now, or one that works in the background every day. The same file, the same agent runtime, and one very different line.

September 4, 2026 · 5 min · by oncell

Two verbs, two agents

A JustCopy website already ends in a form: a table reservation, an appointment request, a free-trial booking. The owner’s next request is the same description with a verb. “Answer my customers and book them” is one kind of agent. “Follow up with everyone who asked for a quote” is the other. On the project card the owner presses Launch an agent, picks “answers customers now” or “works in the background,” and types one sentence about the job.

The sync kind: the front desk

Port Orchard Bakery’s agent is a front desk. A customer’s message goes to the agent’s chat task; the cell wakes, the model call goes through the gateway, and the reply comes back with its cost and run id.

The sync agent is the one people picture when they say “agent.” It is also the easy one to host, because a request arrives and a reply leaves. The hard one is the agent nobody is talking to.

The async kind: the morning follow-up

Summit Plumbing’s follow-up agent has no customer in front of it. It wakes every morning, reads yesterday’s inquiries, drafts the follow-ups, and flags what needs the owner. Between wakes it does nothing, and on oncell doing nothing costs nothing. The owner can also press Run now, which invokes the same task by hand.

POST https://api.oncell.ai/api/v1/agents/jc-<customer>-follow-up/run
{ "prompt": "Do today's follow-ups." }        # or let the daily schedule fire
→ { "text": "3 customers asked about cakes yesterday and did not order. Drafts: ...", "cost": 0.0012 }

JustCopy generates both kinds the same way. It writes a brief from the website’s own facts with one model call, then generates a one-file oncell agent: instructions, model, and a chat handler, and for background agents a run task plus a daily schedule. One call to the deploy endpoint, under a name that carries the customer id, stores version one and assigns the cell. Nothing else is provisioned.

Hosting this kind of agent is where most teams end up building infrastructure: a cron box, a queue, a worker that must stay alive, and a retry policy for when it does not. JustCopy built none of that. A background agent gets one extra line in its source, a daily schedule, and the runtime owns it from there.

A schedule is durable intent

The line is agent.schedule(). The docs put it plainly: the tool expresses intent, and the runtime owns time. The agent parks at no cost between wakes and resumes on whatever host is alive. Sleeping agents park to S3 at about $0 and resume mid-function, across crashes, deploys, and host replacement; the host that wakes the agent does not need to be the host that put it to sleep, and waking from a snapshot takes a few hundred milliseconds.

agent.schedule("followup", "every monday 9am", async () => {
  const open = await agent.db.sql`SELECT * FROM tickets WHERE status = ${"open"} LIMIT ${20}`;
  for (const ticket of open.rows) {
    await agent.llm(`Write a status update for "${ticket.title}"`, { maxSteps: 3 });
  }
}, { maxCost: 20.00 });  // always budget schedules

The schedule trigger and the other three, chat, task, and webhook, are in the docs under Triggers. The docs example above is a weekly schedule; JustCopy’s follow-up runs daily.

Durability is what makes the schedule trustworthy. Every await agent.* is a checkpoint in the run log, so if the process crashes mid-run it replays to the last completed step and continues, and completed model calls are never paid for twice. A morning run that was interrupted finishes; it does not start over and send the same follow-up again.

When the background agent needs a human

A follow-up that quotes a price should not go out on its own. The next step on JustCopy’s list is for the background agent to ask the owner before sending one. On oncell the asking is a tool, ask_human, and the crash-proof waiting is the runtime: the agent parks on approval for as long as it takes, at no cost, survives crashes, deploys, and host replacement while it waits, and resumes exactly where it stopped when the owner answers. Every decision is logged with the run.

One file, one budget, one log

Both kinds of agent are one file per business, deployed under a name that carries the customer id, with the same $1 per day budget set from the customer’s plan. Both write to the same run log, so the owner’s agent page shows recent conversations and recent runs side by side, with cost and latency under each. And both can be tested the same way, because every trigger runs as a durable run through the same loop, and every trigger is something an eval can target. A schedule case runs the schedule; a chat case runs the chat.

The three businesses, the evals, and the per-business cost are in the JustCopy customer story.