Evidence note: This article draws on three kinds of evidence, and they are not interchangeable. The first is what projects say about themselves — release notes, project readmes, and launch posts. Those are quoted as announcements, attributed to whoever made them, and nothing here treats a vendor’s description of its own product as independent confirmation that it works as described; at the time of writing, no independent testing of any tool named below was located. The second is marketing and forum claims that lack even a primary source, which are marked as unverified where they appear. The third is PlayAgit’s own pipeline measurements, which are real numbers from real runs but describe one publishing system’s behavior and nothing beyond it. Every figure below carries its own marker. Where a claim has no record behind it, the article says so rather than smoothing it over.
The always-on pitch: 61 agents, 578 conversations, 99.7% uptime, and a prediction of billions more
The pitch for always-on agents has converged on a small set of numbers. One recent platform, LiberClaw, describes itself as an open-source system for deploying agents that each get a dedicated virtual machine with its own filesystem, database, and HTTPS endpoint, and reported 61 agents running across 578 conversations at 99.7% uptime (the platform’s own figures; no independent measurement of any of the three was found, and the reporting window and how uptime was calculated are not stated). It also describes running inference through open models rather than commercial APIs, so that users hold no vendor API keys — again, its own description, untested elsewhere.
Above the product tier sits the forecast. Investor Vinod Khosla has reportedly predicted that billions of AI agents will eventually run around the clock to make people more productive and connected; sources available here do not confirm the wording, venue, or date of that statement, so it belongs in the article as a widely repeated attribution rather than a quotation.
What makes the forecast worth taking seriously is not the arithmetic but the direction of a specific design choice: these systems are pitched on the removal of the human from the loop. That is exactly the condition under which a pre-execution check stops being paperwork.
Four mechanisms that keep showing up: heartbeats, persistent memory, one machine per agent, and a chat window for control
Across a dozen unrelated launches, the same four mechanisms recur. None of the following descriptions has been independently tested; each is the project’s own account of itself.
Heartbeats. dorabot, an open-source macOS app, says it wraps Claude Code or Codex in a harness and uses heartbeat pulses — inspired by OpenClaw — that wake the agent on a schedule to scan for work, propose tasks, and execute them after approval (project repository). The approval step is notable precisely because most of its peers omit it.
Persistent memory. dorabot’s own description includes maintained memory, research notes, and daily journals. LiberClaw claims memory persisting across conversations alongside bash, file operations, web fetch, web search, and subagent spawning. Screenpipe takes the idea further, describing continuous capture of desktop activity — screens, voice, keyboard, mouse — processed through OCR and speech-to-text and served through an API as a memory bank for agents, with a Rust core and TypeScript plugins running locally on macOS, Windows, and Linux (plugin documentation). These are unverified product descriptions, and the privacy surface of always-on screen capture is not something the descriptions themselves resolve.
One machine per agent. Computer Agents describes giving each agent an isolated cloud computer with a persistent workspace whose files, code, and memory survive indefinitely, triggered by cron schedules, webhooks, or an open-ended "keep working until done" mode, with results delivered by email or Telegram (product site). It also lists automatic package installation inside isolated containers, a Deep Research skill that cites sources, and orchestration patterns including chain, parallel, map-reduce, and conditional flows. All unverified.
A chat window as the control surface. v16 reportedly runs persistent agents locally as roughly 40MB Go processes controlled over Telegram, executing cron jobs for git checks, research, and monitoring across Claude, GPT-4, and Groq (unverified; the memory figure in particular has no corroborating measurement). Its author’s stated motivation is more interesting than its specs: manually orchestrating Claude Code and Cursor — run a command, wait, check the output, repeat — was consuming more time than coding. A scheduling agent built as a free Calendly alternative makes the same bet, syncing calendars and booking meetings over WhatsApp, Slack, or the web while keeping data local (repository, unverified).
A fuller inventory of these mechanisms appears in our survey of the 24/7 autonomous agent stack. What matters here is that three of the four mechanisms expand what an unattended agent can reach, and only one of them — dorabot’s approval step — narrows it.
What a check before execution actually is: a YAML policy, every tool call evaluated, denied commands that never execute
Rampart is described by its own project as an open-source security tool that evaluates every agent tool call against a YAML policy before the call runs, blocking denied commands so that they never execute (project repository). That is the project’s own statement of design; independent verification that the interception is complete — that no tool call path bypasses the policy — remains open, and no third-party audit was located.
The design distinction worth holding onto is the position of the check. A policy consulted after execution is monitoring. A policy consulted before execution is a gate, and the difference shows up only in the cases where something would have gone wrong. An agent that has already run kubectl delete has produced an incident and a log line; an agent whose kubectl delete never dispatched has produced a log line.
That distinction generalizes past this one tool. Most of the always-on platforms above describe permission through what the agent has — a machine, a filesystem, credentials. A policy gate describes permission through what the agent may do at the moment it tries.
The record left behind: a hash-chained audit trail, a live watch command, and an HTML report
By its own account, Rampart writes every evaluated action to a hash-chained audit trail, readable live through a watch command or rendered as HTML reports. Hash chaining is the ordinary tamper-evidence construction: each entry commits to the previous one, so a later edit to an earlier line breaks the chain and is detectable. Whether this particular implementation achieves that property in practice is not established by anything independent — it is the project’s stated design, and the gap is open.
The reason the log matters as much as the gate is that a gate without a record cannot be tuned. A denial that nobody can review is indistinguishable from a bug, and the most common failure of a security layer is not that it lets something through but that it becomes too noisy to keep enabled.
One install command, three intercepted surfaces: hooks on every shell command, file read, and file write
The project states that its Claude Code integration installs with a single setup command, which registers hooks intercepting every Bash command, file read, and file write before execution. Those three surfaces are a reasonable minimum for a coding agent: shell is where destruction happens, file writes are where silent drift happens, and file reads are where secrets leave.
Two questions the announcement does not answer, and which no independent source answers either: what happens to tool calls that are none of those three — network fetches, MCP server calls, subagent spawns — and what the latency cost of per-call evaluation is under load. Both are open.
Why the tool exists: a home lab, cluster management and config edits running unsupervised around the clock, and no brake
Rampart’s author describes building it after running an agent unsupervised and continuously on a home lab through OpenClaw, handling k3s cluster management, shell commands, and configuration edits, and finding no way to stop a bad command before it executed. That origin account comes from the project itself and is not independently corroborated, but it is the most useful sentence in the whole announcement, because it names the failure mode as an absence rather than an incident: not "the agent did something terrible," but "nothing in the path could have stopped it."
That framing is worth separating from the usual objection to autonomous agents. The concern is not that a model is malicious. It is that a correct-looking command issued against the wrong cluster at 3am has no reviewer, and a system whose safety depends on the operator being awake has no safety property at all.
The operator who credits the missing sandbox: full SSH, full git and deploy control, and a blogging pipeline that ships without a human
Directly against that reasoning sits a claim that deserves to be stated at full strength rather than dismissed. An OpenClaw agent on a dedicated hosted instance is reported to run a complete blogging pipeline with no manual intervention: writing articles, generating images, handling a branch/merge/deploy git workflow, triggering rebuilds, and notifying its owner over Telegram for each action. Its operator reportedly attributes that effectiveness specifically to a real environment — full SSH access, no sandbox restrictions, and full control over git, APIs, and deployment pipelines. Both the pipeline description and the attribution are unverified reports from the operator, with no independent confirmation of output volume, error rate, or the deployments it touched.
The claim and the gate are not actually incompatible, and reading them as opposites is the mistake. "No sandbox" is a statement about capability breadth: the agent can reach the real systems. A policy gate is a statement about specific denied actions. A system can grant SSH and still refuse rm -rf /, and the practical argument for pre-execution policy is that it is the only mechanism that permits breadth without accepting every action breadth implies. What the operator’s account genuinely does undercut is the heavily sandboxed alternative — the claim that capability restriction is free is not supported by this report.
Where the confidence numbers get soft: a 70% autonomous fix rate, a claimed 64% monthly efficiency gain, and 578 conversations spread across 61 agents
Three figures from this cohort illustrate three different kinds of softness.
VebGen is presented as an autonomous development agent for Django projects, built over eight months by a 20-year-old developer in India with no team and no funding, using free-tier models for a 500KB codebase (repository). Its stated capabilities include adaptive architecture planning, writing models, views, URLs and tests, reviewing for issues such as the OWASP Top 10 and N+1 queries, and fixing bugs autonomously at a 70% success rate with rollback-protected auto-save. The 70% figure is the project’s own and unverified: no denominator, no bug taxonomy, and no statement of who judged a fix correct. A 70% rate on trivial bugs and a 70% rate on production regressions are not the same number.
Maven AI Agents is positioned as replacing outsourced teams rather than assisting them, describing agents that learn workflows by observing human employees and then execute them with 24/7 availability. Its team reported 25 or more companies onboarded and claimed the agents improve at 64% efficiency per month, citing over $500B spent annually on outsourced repetitive work as the addressable market (all unverified team claims). "64% efficiency per month" is not softness in the measurement — it is softness in the unit. Compounded monthly improvement of that size describes no observed process, and no definition of the metric was located.
LiberClaw’s 578 conversations across 61 agents works out to roughly nine conversations per agent, which for a platform pitched on continuous unattended operation is a small number per agent rather than a large one in aggregate. The figure is the platform’s own and unverified; the point is only that the aggregate reads larger than the per-unit reality.
By coincidence of magnitude, the autonomous-fix rate above sits near a figure from PlayAgit’s own pipeline in the next section. The two measure unrelated things and are not comparable; the resemblance is noted only to pre-empt the comparison.
What refusal costs in one always-on publishing pipeline: 498 drafts reviewed, 349 published, 112 returned for revision, 37 rejected
In PlayAgit’s own pipeline runs (80 runs, 2026-08-28 to 2026-09-12, recorded in this site’s own publishing ledger), the quality gate reviewed 498 drafts: 349 were published, 112 were sent back for revision, and 37 were rejected outright, as of 21:23 UTC on September 12, 2026. These are this site’s own measurements of its own gate, not an independent evaluation of anything.
The useful reading is the cost column. Roughly three in ten drafts that reached the gate did not pass on first attempt — 112 revisions and 37 rejections out of 498 across those 80 runs. Every one of those is compute and wall-clock time spent producing output that was then refused. That is what a gate costs when it is actually enforcing, and a gate with a near-zero refusal rate is usually not measuring anything. The same dynamic applies to a pre-execution policy: a policy that has never denied a command is either protecting an agent that never tries anything or is not being consulted.
The thinner number underneath: 376 independent cross-checks against 10,209 collected claims, and 10,079 topics rejected before anyone wrote a word
The gate figures look healthy. The number underneath them does not, and it is the more honest one.
In the same PlayAgit runs (80 runs, 2026-08-28 to 2026-09-12, from this site’s own run records), research work produced 2,691 dossiers holding 10,209 claims. Of those claims, 1,648 were attested by a primary source and only 376 were independently cross-checked. That is roughly 3.7% of collected claims with independent corroboration, against about 16% resting on a primary source and the large remainder resting on neither. This is a self-measurement of one pipeline; it establishes nothing about research pipelines in general. The ratio has been tracked before and has stayed in the same range, as recorded in our earlier piece on cross-checking the checkers.
Refusal earlier in the chain is far more aggressive. Of 21,406 scored topics in those same runs, 10,079 were rejected before production, 8,064 were held, and 3,263 proceeded — meaning under one in six scored topics became work at all. The comparison is the lesson: a cheap early gate refused 47% of candidates, while the expensive independent-verification step reached under 4% of claims. Gating is cheap where the unit of work is small and expensive where it is large, and the same asymmetry is why intercepting a command costs almost nothing while reviewing an agent’s finished output costs a great deal.
What to insist on before leaving an agent running overnight
Nothing in the record below has been validated as a checklist; it is what the evidence above supports asking for.
- A decision point before execution, not after. Post-hoc logs describe damage; a pre-execution evaluation prevents it. dorabot’s approval-before-execute step and Rampart’s stated pre-call policy check are the only two mechanisms in this survey that sit on the right side of that line.
- A record that survives the agent. Tamper-evident or not, a log that the agent itself can rewrite is not evidence. Hash chaining is the standard answer; verify the chain is actually checked, not merely written.
- A named blast radius. "Its own VM, its own filesystem, its own database" bounds a great deal — and bounds nothing about the production credentials sitting inside that VM. Ask what the agent can reach with what it holds, not what it runs on.
- A refusal rate you can see. If the gate has never blocked anything, treat that as an unresolved question rather than a clean bill of health.
- Confirmation that success reports correspond to real effects. A finished-looking report is not an outcome, a failure mode examined in our review of 303 agent runs across three Roblox games.
The long tail of this cohort is worth noting only for what it shows about how thin most descriptions are: an open agentic runtime said to research, ship, and maintain entire businesses around the clock (repository), a personal autonomous agent project (repository), an agent that works at midnight so a factory can run continuously (repository), a 24/7 digital teammate for freelance opportunities and business insight (repository), an agent freelancer (repository), an M&A due-diligence team (repository), a 24/7 exam-paper generator claiming error-free output (repository), a Copilot Studio accounting tutor for students when faculty are unavailable (repository), a 24-item portable skills collection (repository), a marketplace of 100-plus listable agents (Metaschool), a 24/7 phone-answering voice agent assembled from telephony, model, payment and hosting services (Vocaware), a background-agent app for non-technical users who lack a machine running continuously, and an all-scenario agent that completes work on a user’s behalf (LobsterAI). Every one of those descriptions is the vendor’s own and unverified. Not one of them, as described, states what it will refuse to do.
How we apply this in Vision
The measurements below are PlayAgit’s own, taken from this site’s own publishing ledger across 80 pipeline runs between 2026-08-28 and 2026-09-12. They describe one system’s behavior and are not independent verification of anything in this article.
Refusal is placed where the unit of work is cheapest. In those 80 runs, 18,577 topic candidates were discovered across 4 categories from 213 distinct source hosts — and of the 21,406 topics that were scored, 10,079 were rejected and 8,064 held before any production work began, leaving 3,263 to proceed. Rejecting a candidate costs a score; rejecting a finished draft costs a draft.
The gate downstream still refuses, and the cost is recorded rather than hidden. Across the same 80 runs, the quality gate reviewed 498 drafts and published 349, returned 112 for revision, and rejected 37. Output over the window was 395 posts published, of which 211 were new and 75 were updates to existing work — the update count matters because a pipeline measured only on new posts has an incentive never to revisit what it already shipped.
The weakest number is kept in view rather than averaged away: of 10,209 claims collected into 2,691 research dossiers in those runs, 376 were independently cross-checked and 1,648 were primary-attested. That ratio is the reason this article marks vendor claims as vendor claims instead of restating them. A pipeline that can measure how rarely it achieves independent corroboration has at least established the one fact that lets a reader discount the rest correctly — which is the same property a pre-execution policy gate provides for an unattended agent, and the property that every launch announcement surveyed here leaves open.