EvalSignal 011 / Independent agent analysis
Persistent AI coworkers, your choice of models, and a computer you control.
At EvalSignal, we keep returning to open-source tools that reduce dependence on proprietary agent platforms. We recently covered OpenCode, the model-neutral terminal agent. Before that, we looked at WebBrain, the open-source browser agent that can run with local or hosted models.
Rakazo brings the same question to another part of the stack: who controls the persistent AI coworkers doing your work?
Grok Bot's pitch is easy to understand. Give an AI teammate a computer, access to your tools, and an ongoing responsibility. Message it like a colleague. Let it work across applications and return when it needs your judgment.
Rakazo brings that product idea into an Apache-2.0 project. It provides persistent bots with conversations, memory, routines, and history; browser, terminal, file, and graphical desktop access; and the ability to delegate work to other bots. It has web, Electron desktop, and Expo mobile clients.
The appeal is continuity. Imagine giving a research bot a standing assignment: every weekday, review a shortlist of projects, identify meaningful releases, and prepare a brief with source links. You correct its priorities in the same conversation. Tomorrow's assignment begins from an established working relationship.
That is an illustrative workflow, not a result from our testing. For this issue, we inspected Rakazo's source and documentation to see what supports the promise.
Routines store their prompts, schedules, time zones, and next execution times in the database. The executor claims a scheduled occurrence in a transaction before creating its run. A separate reconciliation process looks for due routines and stranded work to enqueue again.
Those details matter when an assignment is supposed to happen tomorrow morning after a worker has restarted. A recurring-agent product needs more than a cron expression in the interface; it needs durable state and a recovery path.
Rakazo uses Pi for its agent runtime. Its adapter interfaces separate that runtime from the machinery that provisions computers, executes commands, and accesses files. Available computer providers include Docker, E2B, Daytona, and Box.
This gives the project room to change models and infrastructure independently. You can bring your own model credentials, keep a local Docker computer for one workload, and use a remote sandbox where isolation or uptime matters more.
The run lifecycle distinguishes running, waiting for input, waiting for takeover, completion, and failure. The approval machinery identifies an action using its run, tool, and arguments.
These are useful foundations for showing what a bot needs and exactly which action a user approved. They do not prove that every workflow is safe, but they make the human boundary concrete enough to inspect and test.
Our reading is that Rakazo is taking the operational side of persistent agents seriously. These mechanisms do not establish its success rate on real work, but they give us real engineering to evaluate.
Ownership extends to the working environment. Rakazo's computer runtime supports preserving workspace files and browser profiles and restoring them onto replacement computers. Portability has limits: system packages installed outside the workspace do not automatically move with it. Still, keeping the work separate from one rented machine is a useful design decision.
That matters more as a bot accumulates context. Replacing a tool becomes harder when it holds your recurring instructions, working files, and established sessions. An open implementation gives you more options to inspect, modify, and maintain that environment yourself.
Rakazo is in beta. Its local desktop setup requires Docker, and you supply model access. Quitting the desktop app leaves the local stack running, but an asleep laptop cannot execute scheduled jobs. For work that continues while your laptop is off, the documented route is an always-running server. The managed cloud service is still coming. Model and hosting bills remain part of the calculation.
The isolation model deserves attention, too. Team Computers share a workspace and operating-system user. Separate bot screens help coordinate work; separate computers are needed when workloads require isolation. The project documents that boundary rather than hiding it.
For EvalSignal, the next question is measurable: how much useful work gets completed per dollar and per minute of human intervention?
A recurring research brief succeeds when it consistently finds the right changes, cites them accurately, and avoids repeating yesterday's news. A convincing demo is only a starting point.
Rakazo's verification guide distinguishes scripted execution tests from real-model quality tests. We would want the same distinction in any comparison with Grok Bot: identical assignments, explicit success criteria, and a record of costs, failures, retries, and human corrections.
Rakazo is worth watching because it makes persistent AI coworkers something people can build on, run themselves, and adapt as models improve. For technical readers willing to operate a beta, there is already enough substance to try one recurring job and measure the result.
Open source gives us the freedom to choose the machinery. Reliable execution will determine how much work we entrust to it.
Research note: Source and documentation reviewed on September 9, 2026, at commit 2241538.
Sources and further reading
Explore Rakazo | Source code | Self-hosting guide
