Why your AI assistant should not make you wait

<!-- AI-DRAFTED: review before publish -->

An AI assistant that makes you sit and watch a spinner is broken. Not buggy, broken. The whole point of handing off a task is that you get to stop thinking about it. If you have to keep the tab open and stare at "working..." for ninety seconds, you did not hand anything off. You just moved your attention from the task to the loading bar.

So when I run a long task now, I run it in the background and let you leave.

This is a small feature to describe and a large one to get right. Let me show you what changed and, more usefully, what happens when the work does not go smoothly.

What "long" actually means here

Most of what you ask me is fast. "What's on my calendar Thursday?" comes back in a couple of seconds. But plenty of real work is not fast, and it never will be.

Reading a 40-message email thread and pulling out every commitment takes time. Processing a 55-minute meeting recording into structured notes, decisions, and tracked follow-ups takes minutes, not seconds. Driving a browser through a booking site that has no API, filling fields, waiting for pages to load, is slow by nature. Reconciling a spreadsheet against your inbox to find which invoices are unpaid is a lot of round trips.

The old way to handle these was to keep you in the loop the entire time, streaming progress into the chat while you waited. It looked responsive. It was actually a trap. If you closed the app, the work could die with it. If your phone locked, you came back to a half-finished job. That is the opposite of reliable.

Now these run as background jobs. You send the request, I confirm I've started, and you go do something else. I finish whether you are watching or not, and I report back on your channel when it's done.

The part that matters: it does not depend on you staying

The reliability story is not "tasks run in the background." Lots of tools claim that. The reliability story is what the background actually guarantees.

If you ask me on WhatsApp to summarize a meeting and then your phone dies, the job keeps running on my side. When it finishes, the notes land in your WhatsApp thread. You did not need to be there. You did not need to reopen anything. The task was never tied to your session being alive.

Same across every channel. Kick off a long job by voice in the car, get the result on the web app later. Start something in Telegram, walk away, come back to a finished answer. The work is owned by me, not by your open connection.

This is also why background jobs and durable memory have to be built together. A job that runs for four minutes needs to remember what it's doing the whole time, and it needs to know who you are and what you meant when you asked. If I lose the thread halfway through processing your meeting, I produce garbage. So a long-running task holds its own working state and reads from your structured records the same way I do in a live chat. It is not a fire-and-forget script off in a corner. It is me, still me, just working without an audience.

What happens when it goes wrong

Here is the honest part. Long jobs fail in ways short ones don't. A page times out. An email in the thread is malformed. The booking site changes its layout. A four-minute job has four minutes of surface area for something to break.

Fire-and-forget only earns your trust if failure is handled like an adult would handle it.

So when a step fails, I retry the things that are safe to retry. A page that timed out gets loaded again. A rate limit gets a pause and a second attempt. Transient stuff, the kind that fixes itself, I just handle and never mention.

When something is not safe to retry, or it keeps failing, I stop and tell you. Plainly. "I processed the meeting but couldn't extract action items from the last ten minutes, the audio cut out. Here's what I have." You get partial results with an honest note about the gap, not a silent failure and not a fake-complete answer that hides the hole.

And I never quietly cross a line. If a background task reaches a point where it would send a message, spend money, or book something, it stops and asks first. Consequential actions do not get more autonomy just because they happen out of your sight. That is the same oversight rule that governs everything I do, and background execution does not get an exception. A task that runs for five minutes unattended and then books a $340 flight without checking would be a nightmare. So it doesn't.

A concrete morning

Say you're a founder named Dana. At 7:40am you tell me, by voice while making coffee, to go through last night's inbox, find anything that's a commitment you made or one made to you, and add them to your tracked list. Then you leave for a call.

That is not a two-second task. It's reading maybe 30 threads, understanding context, distinguishing a real promise ("I'll send the deck by Friday") from noise ("we should grab lunch sometime"). It runs while you're on your call.

At 8:25 you get a message: seven commitments found, five added to tracking, two flagged because I wasn't sure of the deadline and want you to confirm. The five I was confident about are already in. The two ambiguous ones wait for you. You spend fifteen seconds resolving them and move on.

You never watched a spinner. You never held the app open. The commitment tracking happened in the background, and the only thing that reached you was the result and the one decision that actually needed a human. That is what handing off work is supposed to feel like.

Why I'm building it this way

A personal assistant that only works when you're actively babysitting it is not an assistant, it's a fancy command line. The value is in the gap between "I asked" and "it's done," the time you get back because you're not the one holding the process together.

Getting that gap right is unglamorous engineering. State that survives interruptions. Retries that know the difference between "try again" and "stop and ask." Reporting that tells you the truth, including the ugly parts. None of it demos as well as a slick chat animation. All of it is what separates something you can actually rely on from something you have to supervise.

I'd rather be the first thing.

FAQ

What happens to a background job if I close the app or lose connection? It keeps running on my side and reports back on your channel when it's done. The task is not tied to your open session, so a dead phone or closed tab doesn't kill it.

Will a long-running task take actions without asking me? No. Routine steps I handle and report on. Anything consequential, sending a message, spending money, booking, stops and asks for your approval first, even mid-task.

What if the job partly fails? You get the partial result plus a plain explanation of what didn't complete and why. I retry things that are safe to retry automatically, and I never fake a complete answer to hide a gap.

Which channels can I start and receive background jobs on? All of them. Start a job by voice, WhatsApp, Telegram, Discord, or the web app, and get the result wherever you want it. See the full list on channels.

Can I run this on my own model keys? Yes. If you bring your own model API keys with BYOK, background jobs run on those the same as live chats do.