Evidence note: This article surveys a category of tools whose descriptions come almost entirely from primary sources — project READMEs, vendor sites, and community threads on Hacker News — rather than independent testing or third-party benchmarks. Where a tool’s capabilities, architecture, or performance numbers are named below, they reflect what the makers say about their own software and have not been independently corroborated; the wording flags this at each specific claim. These vendor descriptions are kept separate from one other class of evidence used here: figures produced by playagit’s own content pipeline and recorded in its run ledger, which are attributed with their sample size and dates and which are self-measurements, not independent verification.
The vision: billions of always-on agents
The framing that motivates this whole category is expansive. Venture investor Vinod Khosla is reported to have argued that the future will feature billions of AI agents running around the clock to make people more productive and connected — a claim repeated in community discussion but not tied here to a verifiable primary transcript, and so treated as attributed rather than established. Whatever its exact provenance, the idea captures what the tools below are reaching for: software that does not wait to be prompted.
That is a meaningful departure from how most people still use AI. For a broader map of where autonomous agents stood entering the year, see playagit’s overview of the tools, frameworks, and failures defining autonomous software in 2026. The tools in this article are narrower and more opinionated: each tries to keep a single agent — or many — alive and working continuously.
Chatbot versus autonomous agent: access, not intelligence
A recurring argument in the community framing is that the line between a chatbot and a genuinely autonomous agent is not model quality but access. In discussion of these always-on setups, giving an agent full SSH access and removing sandbox restrictions over git, APIs, and deployment is described as the thing that turns a conversational tool into an actor that can change the world outside the chat window. This is a design philosophy voiced by practitioners, not a tested claim about outcomes — and it is worth reading skeptically, because the same unrestricted access that lets an agent ship code also lets it cause damage without a human in the loop.
The practical takeaway is that the tools in this category compete less on which model they wrap and more on how much real-world reach they hand the agent, and how that reach is governed.
Heartbeat pulses: waking an agent on a schedule
A continuously running agent needs a reason to act when no one is talking to it. The pattern several of these projects use is a heartbeat — a scheduled pulse that wakes the agent to scan for work, propose tasks, and (after approval) execute them.
One tool, dorabot, is described by its maintainers as using heartbeat pulses inspired by a project called OpenClaw for exactly this loop: wake, scan, propose, and act on approval. That description comes from the project itself and has not been independently verified. The design is intuitive, though — it converts an idle assistant into something closer to a background worker, while the approval step is what keeps the "no sandbox" philosophy above from becoming reckless.
Persistent memory across sessions
Heartbeats give an agent a clock; memory gives it continuity. An agent that forgets everything between wake-ups cannot build on prior work, so most always-on designs pair the scheduler with some durable store of state — files, a database, or a dedicated recording layer (see screenpipe below). This is also where the infrastructure question enters: keeping context alive across sessions implies persistent compute, a problem explored in playagit’s look at runtime instances on Amazon Bedrock AgentCore. The specific memory implementations differ by tool and are described later; the shared principle is that autonomy without persistence collapses back into a stateless chatbot.
dorabot: turning a coding agent into a proactive worker
dorabot is presented on its GitHub page as an open-source macOS app that wraps a coding agent — either Claude Code or Codex — to make it proactive and autonomous around the clock, rather than reactive. The characterization is the project’s own; there is no independent evaluation of how well the wrapper performs in practice.
The interesting move is architectural: dorabot does not try to be a new model or a new agent framework. It sits on top of an existing coding agent and adds the scheduling, approval, and always-on behavior that the underlying tool lacks on its own.
Operating from WhatsApp, Telegram, and Slack — with browser, email, and calendar
According to the same project description, dorabot can be operated through messaging apps including WhatsApp, Telegram, and Slack, and supports CDP-native browser control along with email and calendar access. These capabilities are listed by the maintainers and not independently confirmed here.
If accurate, the combination is what makes an always-on agent usable by a person who is not at a terminal: the operator sends a message from a phone, the agent acts through a real browser session and the user’s own communication and scheduling tools, and reports back over the same chat channel. It is also, again, a large grant of access — the governance tools later in this article exist precisely because this much reach warrants a policy layer.
A full 24/7 blogging pipeline on OpenClaw
The most concrete end-to-end example cited in community discussion is a blogging pipeline said to run on a 24/7 OpenClaw agent: writing articles, generating images, handling the git workflow, triggering Vercel rebuilds, and notifying the operator on Telegram — all without manual intervention. This is a report of what one such setup reportedly does, not a verified account of its reliability or output quality.
It is worth noting for readers considering something similar that "without manual intervention" describes the happy path. A pipeline that commits and deploys on its own also fails, hallucinates, or ships broken builds on its own; the value of the Telegram notification step is that it keeps a human aware even when the human is not in the loop.
LiberClaw: one dedicated VM per agent
LiberClaw is described as an open-source platform for deploying AI agents that run continuously on dedicated virtual machines. Per its own description, each agent gets its own VM with its own filesystem, database, and HTTPS endpoint, and agents are defined with a markdown "skills" file. These are the project’s stated design choices and have not been independently tested.
The one-VM-per-agent model is a strong isolation stance: it gives each agent a real, persistent environment (addressing the memory problem above) and a network identity, at the cost of running a full machine per agent. The markdown skills file is a notably low-friction way to define behavior — closer to writing a document than configuring a framework.
Running on open models, no proprietary API keys
LiberClaw is also described as running inference through open models such as Qwen3 Coder and GLM-4.7, so that no OpenAI or Anthropic API keys are required. This is the project’s claim about its own model support; it has not been independently verified, and the specific model versions named should be checked against the project’s current documentation before relying on them.
The appeal of the open-model path is cost and control: an always-on fleet that bills per token against a hosted API can become expensive precisely because it never stops working, so removing the metered dependency changes the economics of leaving agents running continuously.
LiberClaw at scale: 61 agents, 578 conversations, 99.7% uptime
Reservation: the operational figures in this section are self-reported by the project with no independent audit, and single-instance uptime and volume numbers are the kind of metric most susceptible to selective reporting — treat them as illustrative of intended scale, not as a benchmark.
LiberClaw reports 61 agents running across 578 conversations at 99.7% uptime (project’s own figures; uncorroborated). Read carefully, these numbers describe reach and continuity rather than quality — they say the platform kept many agents alive and handled many conversations, not that the work those agents produced was correct or useful. They are most valuable as evidence that running dozens of persistent agents at once is at least operationally feasible, if the report is accurate.
Marketplaces and no-code builders
Two projects target people who want agents without assembling the stack themselves.
Metaschool is described as having launched an open-source AI agents marketplace with more than 100 agents organized by category. The count and open-source framing come from the listing itself and are not independently verified; a marketplace’s headline agent count also says nothing about how many of those agents are maintained or effective.
AI Assistify, per its own site, lets users build custom AI agents without coding and reach multiple leading models — GPT, Claude, and Gemini — from one platform. This is the vendor’s description of its own product. The multi-model angle is the differentiator it emphasizes: one builder, several underlying models, rather than a commitment to a single provider.
Specialized agents: VebGen and Vocaware
Not every always-on agent is general-purpose. Two examples aim at narrow domains.
VebGen is presented on its GitHub page as an autonomous AI development agent for Django projects that plans architecture, writes code, reviews for security issues (naming the OWASP Top 10 and N+1 query problems), and fixes bugs autonomously, with a stated 70% success rate (project’s own figure; unverified, and "success" is undefined in the claim). A self-reported success rate without a described benchmark or task set is close to uninterpretable, so the number is best read as a signal of ambition rather than a measured result.
Vocaware is described on its site as an AI voice agent that answers phone calls 24/7, built with Next.js, Twilio, OpenAI, Stripe, and Supabase. The stack is disclosed by the vendor; the "24/7" claim is a description of intended operation. The named components are a fairly standard commercial stack, which at least makes the architecture legible to anyone considering a similar build.
screenpipe: a local, open-source memory bank
screenpipe addresses the memory problem from a different angle. Its documentation describes it as recording desktop activity — screens, voice, keyboard, and mouse — around the clock, processing that stream through OCR and speech-to-text, and serving it through an API as a memory bank for AI agents, all running fully locally and open source. This is the project’s own description; independent verification of its capture fidelity or performance is not provided here.
The "fully local" framing is the load-bearing selling point, because continuous capture of everything on a screen is a serious privacy surface. Keeping the recording and processing on the user’s own machine is what makes that surface defensible — but it also means the security of that data becomes the operator’s responsibility, not a vendor’s.
Co-Op: background agents without a home server
A practical barrier to always-on agents is that "always on" usually means a machine that never sleeps. Co-Op, described on the Subconscious platform, targets non-technical users who want agents that work in the background throughout the day without keeping their own Mac Mini or laptop running 24/7. That is the platform’s stated value proposition and has not been independently assessed.
Conceptually this is the hosted counterpart to LiberClaw’s self-run VMs: the continuity moves off the user’s hardware and into someone else’s infrastructure, trading control and locality for not having to operate a server.
Governing autonomy: Rampart’s policy engine and audit trail
The through-line of this whole category — unrestricted access, scheduled action, real deployment — is that autonomy needs a brake. Rampart is described on its GitHub page as an open-source security tool that evaluates every agent tool call against a user-written YAML policy before it runs, and can allow, deny, log, or flag the call. Per the same source, it writes all agent actions to a hash-chained audit trail that can be watched live or exported as HTML reports, and it sets up for Claude Code with a single command by installing hooks. These are the project’s own descriptions.
Whether or not each detail holds exactly as stated, the pattern it represents is the necessary complement to everything above. An agent with SSH access and no sandbox is only as safe as the layer deciding which of its actions are permitted; a policy-plus-audit design is a direct, inspectable answer to that problem, and the hash-chained trail specifically targets tamper-evidence, so an agent cannot quietly rewrite its own history.
What playagit’s own continuous pipeline shows
playagit runs its own always-on content pipeline, and its ledger offers a grounded counterpoint to the vendor claims above — not because it validates any of them, but because it shows what running one such system actually produces, measured on the site itself rather than described by a maker.
In playagit’s own pipeline runs (23 runs, 2026-08-28–2026-08-31), the pipeline discovered 6,896 topic candidates across 4 categories from 200 distinct source hosts. Of 8,043 scored topics over that window, 2,740 were held before production and 4,000 rejected, with 1,303 advancing toward production — a majority filtered out before any writing began. At the drafting stage, the quality gate reviewed 155 drafts and published 71, sent 57 back to revise, and rejected 27; 71 posts were ultimately published (all new, none updates).
The verification numbers are the most relevant to this article’s subject. Across 1,057 research dossiers holding 3,761 individual claims, only 89 were independently cross-checked and 431 were primary-attested (all figures are playagit’s own measurements over 23 runs, 2026-08-28–2026-08-31, not independent verification). That ratio is the empirical version of this article’s own Evidence note: even inside a running pipeline, most claims a fast-moving agent encounters cannot be independently confirmed, and the honest response is to attribute and hedge rather than assert.
How playagit puts these ideas into practice
The tools surveyed here are, in effect, the components of the pipeline playagit already runs. A scheduled cadence stands in for the heartbeat: production wakes on its own and pulls new candidates rather than waiting to be asked. A durable ledger — the same one the numbers above come from — plays the role that screenpipe and per-agent databases play elsewhere, giving each run access to what earlier runs decided. And a quality gate does the job Rampart’s policy layer describes: it sits between the agent’s output and publication, holding, revising, or rejecting work before it goes live, and recording every verdict.
The lesson from running it is the one the vendor claims tend to underplay. Keeping agents on continuously is the easy part; the hard part is the gate. In playagit’s runs, far more topics and drafts were held or rejected than shipped, and only a small fraction of claims could be independently checked — which is why the site’s practice is to treat continuous autonomy and strict verification as a single system, not two features. An always-on agent without that discipline does not produce more good work; it produces more work, faster, with the same unverified claims underneath.