{"slug": "errand-open-source-grok-bot-and-muse-alternative-built-in-a-week", "title": "Errand – open-source Grok Bot and Muse alternative, built in a week", "summary": "A developer built Errand, an open-source alternative to Grok Bot and Muse, in about one week as a roughly 4,000-line TypeScript desktop app that runs on the Runta Cloud Agents API. Errand relies on Runta for the agent runtime, computer use, agent loop via the Pi Agent framework, VNC live desktop, and persistence, so the app acts only as a client and tasks continue running in the cloud after the user quits. The developer said the three components not built — a job queue, a worker, and a durable event log — would otherwise have taken a month to build.", "body_md": "Imagine handing an AI teammate a task, closing your laptop, and leaving for the day. Its computer keeps running in the cloud, and the result is waiting when you come back. That’s [Errand](https://github.com/runta-dev/errand), an open-source alternative to Grok Bot and Muse. I built the first version by myself in about a week.\n\nI have a confession: I didn’t build the hard parts. We’d already built them into Runta. What I built that week was Errand’s desktop app. It’s about 4,000 lines of TypeScript. This is what an agent application looks like when execution infrastructure stops being application code.\n\n## What I didn’t have to build\n\n**The agent’s runtime.** Every Errand teammate gets a Runta runtime: an isolated machine with a shell, a browser, and a filesystem that sticks around between tasks. When you create a teammate in Errand, the app makes one API call and a computer appears in a few seconds. I never wrote a provisioner, a lifecycle manager, or a cleanup job. Which means I never had to worry about idle machines wasting money or files disappearing when a task crashed. If I’d had to solve those first, Errand would not exist yet.\n\n**Computer use.** The runtime comes with a desktop and Chrome, and the agent can look at the screen, click, and type. So the agent can use software like a human without an API: fill in a form on some website, click through a settings page, move between two web apps. The model picks the action; Runta executes it. Nothing about this touches your own laptop.\n\n**The agent loop.** Runta doesn’t force the agent layer either. Our Cloud Agent runs on [Pi Agent](https://github.com/badlogic/pi-mono), a small agent framework that handles the model call, the tool calls, and the loop between them. Runta wraps Pi with the runtime, the computer, and an API; Errand sits on top of that API. Pi is what a Cloud Agent runs by default rather than something Errand is welded to, so the harness is a thing you can swap.\n\n**The live desktop.** You can open a teammate’s screen from Errand and watch it work, or take over. That’s a VNC session to the runtime, rendered with noVNC in the renderer. The only part I wrote is [`VncDesktop.tsx`](https://github.com/runta-dev/errand/blob/main/src/ui/components/VncDesktop.tsx), 72 lines, plus a small bit of origin checking in the main process.\n\n**The persistence.** The interaction Errand is really about is leaving. You hand off a task, quit the app, and expect it to be done when you’re back. If the app were the thing running the agent, that wouldn’t work. In Errand the app is just a client: the run lives on Runta, the workspace lives on the runtime, and quitting the app does nothing to either. When Errand reopens, it fetches the runs for each conversation and replays each run’s events from the beginning (`events?after=-1`) to rebuild the conversation, then loads the artifacts. A conversation with 500 events comes back in about 100ms. If the stream drops while you’re watching, that’s a connection problem, not a task problem; the run record still says whether it finished or failed.\n\nThere’s no job queue, no worker, no durable event log behind that. Those are the three things I’d have spent a month building. The event log is the one that would have kept me up at night. It looks fine until a task’s history stops matching what the user saw. I built the reconnect path in the client, and the tests for it.\n\n## I didn’t have to invent another state model\n\nThe Cloud Agents API resources Errand uses are already things the user sees. Agents are teammates, runs are tasks, events are activity, artifacts are files. I didn’t need an application model sitting on top of a separate infrastructure model.\n\n- Agents → teammates in the sidebar, each with its own runtime\n- Runs → tasks, with a status and a result\n- Events → the live activity you see while a task runs\n- Artifacts → files attached to a task, in or out\n- Computer sessions → the open computer button\n\nSend a message, that’s a run. Open a conversation, that’s listing runs. Click on the computer, that’s a computer session. The whole client is one file, [`RuntaCloudAgentsClient.ts`](https://github.com/runta-dev/errand/blob/main/src/clients/http/RuntaCloudAgentsClient.ts), 476 lines, and most of it is mapping JSON to the domain types the UI wants.\n\nI still had to make a lot of small decisions: how a task should look in the sidebar while it’s running, how an error should read, how much tool activity to show before it becomes noise.\n\nThose decisions are the product. They’re also the ones you never get to if you’re still deciding where run state lives and who owns the filesystem. I got to spend the week on them because the state underneath was already concrete.\n\n## Where the week went\n\nMost of the week was ordinary desktop app work. What made it a week instead of a quarter is that nothing in it required me to stop and build something else first. Every time I needed a machine, a screen, a file, or the history of a run, it was already there behind an API call. Here’s what that week actually contained:\n\n- Electron setup with a strict split between the main process, a typed preload bridge, and the React renderer. Credentials never leave the main process; the renderer gets a narrow API and nothing else.\n- Agent creation, including waiting for the runtime to come up and for the agent’s first reply.\n- Conversation state, and the replay logic above.\n- Attachments, both directions.\n- The VNC view.\n- Packaging, and getting the DMG from 300+ MB down to 97 MB.\n- Loading states and error copy that make sense to someone who just wants their task done.\n\nThat’s the shape of the work when the runtime, the computer, the agent loop, and the API already exist. Runta itself took us 6 months to get to that point, which is the honest comparison: either someone has already spent those months, or your product doesn’t exist until you have.\n\nErrand is early: macOS only, needs a Runta account, bring your own model provider. The model and the harness are both yours to swap, and we’re building a bring-your-own-cloud option so the runtime can sit in your account instead of ours. The [source](https://github.com/runta-dev/errand) is open if you want to read how it’s put together, and the [Runta docs](https://runta.com/docs/) cover the runtime side.\n\nAnd if you’re building this same layer yourself right now, I’d like to hear where you’re stuck.", "url": "https://wpnews.pro/news/errand-open-source-grok-bot-and-muse-alternative-built-in-a-week", "canonical_source": "https://runta.com/blog/building-errand-in-one-week/", "published_at": "2026-09-22 15:36:03+00:00", "updated_at": "2026-09-22 15:54:57.946069+00:00", "lang": "en", "topics": ["ai-agents", "ai-tools", "ai-products", "developer-tools", "ai-infrastructure"], "entities": ["Errand", "Runta", "Grok Bot", "Muse", "Pi Agent", "noVNC", "TypeScript", "VncDesktop.tsx"], "alternates": {"html": "https://wpnews.pro/news/errand-open-source-grok-bot-and-muse-alternative-built-in-a-week", "markdown": "https://wpnews.pro/news/errand-open-source-grok-bot-and-muse-alternative-built-in-a-week.md", "text": "https://wpnews.pro/news/errand-open-source-grok-bot-and-muse-alternative-built-in-a-week.txt", "jsonld": "https://wpnews.pro/news/errand-open-source-grok-bot-and-muse-alternative-built-in-a-week.jsonld"}}