The Agent That Clocks Out While It Waits for You

Every conversation about autonomous coding agents eventually collides with the same wall: the terminal. Claude Code, Codex, and their many imitators are, in their default form, pets. You type something, you watch it run, it asks you a question, you answer. Close the window and the work dies. The agent didn’t fail; the harness did. There was nowhere for the conversation to go while you were at lunch.

Agent Autoloop, a small open-source project out of a solo GitHub account, is a direct answer to that gap — and its answer is more interesting than the usual “wrap it in a dashboard” approach. It’s a lightweight automation middle layer that runs on your own Mac or Linux box, needs no cloud server and no open ports, and turns command-line agents into background workers that take events (a cron tick, a new GitHub issue, an ops alert), work them to completion, and only ping you when they genuinely need a human decision. When they do need you, they push a card to Feishu, DingTalk, Slack, Discord, or your desktop. And then — this is the part worth paying attention to — they exit.

Waiting should cost nothing

The project’s central mechanism is almost embarrassingly simple once stated: when an agent needs your approval, the process terminates. The waiting state lives in a local database, not in a hung process. If you take three days to answer, there is no agent process running for those three days, no tokens being spent, no session idling at the edge of a timeout. When you tap a button on the card, the middle layer resumes the original conversation — same agent, same context — and the work continues.

This inverts the default economics of agentic automation. Most orchestration systems keep the loop warm: the agent process, or at least a session handle, persists while a human is somewhere in the approval chain. Autoloop treats human latency as the dominant cost in any pipeline — which, for anyone who has watched an agent wait eight hours for a sign-off, it obviously is — and designs the entire system around making that latency free. The agent’s only contract with the platform is that its final reply states the result, optionally with a structured block asking a question, sending a notice, scheduling a recheck, or triggering follow-up events. Everything else is process lifecycle.

There’s a second-order benefit that the README doesn’t belabor but deserves attention: crash tolerance falls out of the design. Because nothing important lives in a running process, there’s nothing to lose when one dies.

A kernel, not a framework

The heart of the project is deliberately austere: roughly 1,651 lines of code, zero runtime dependencies, and a kernel that doesn’t read the system clock, doesn’t use randomness, and makes no outbound requests. Plugins connect to it; it connects to nothing. The same input always produces the same result. This is a level of discipline you more often see in databases and payment systems than in agent tooling, and it’s the clearest signal that the author understands what kind of software this is: not a demo, but infrastructure that will be trusted with unattended execution.

The state model is event-sourced. Everything — every round, every decision, every card — is computed from an append-only log, written to disk transactionally before acknowledgment. The project’s own verification suite is unusually specific: a simulation harness that runs 200,000 steps of network failures, packet loss, crashes, and duplicate submissions from a reproducible seed; a crash test that force-kills the process a thousand times and confirms no acknowledged record is lost; a benchmark reporting sub-2-millisecond p99 dispatch latency, ~2,400 durable writes per second, and a 99.8 ms cold start even with 1.1 million facts in the log. Those numbers come from one machine (an Apple M5 Pro), and the README says so plainly — the pass thresholds are calibrated to that hardware. Full-machine power loss, notably, has not been separately tested. That’s the kind of caveat that builds more trust than it costs.

The plugin architecture covers four axes — event sources, agents, notification channels, and even the CI/CD delivery pipeline — all replaceable. Any command-line tool that accepts a prompt and prints a final reply can be an agent; no SDK, no source modification. The README lists adapters for DeepSeek’s harness, pi, OpenClaw, Hermes, Cursor’s CLI, and CodeBuddy, with the honest disclaimer that these commands were compiled from official docs and not individually tested. Claude Code, Codex, and ACP, by contrast, are reported as actually verified for multi-turn Q&A and cross-process session resumption.

Paranoia as architecture

The security posture is where the project’s engineering taste shows most. Two mechanisms stand out.

First, instruction/data separation, applied to agent prompts the way parameterized SQL applies to databases. External text — an issue title, an issue body, an error message — is written to a file as material, never concatenated into the prompt. The prompt itself contains only validated types, numbers, and links. Which agent runs, in which directory, with what permissions is decided exclusively by local rules on your machine; an incoming event that tries to carry its own working directory, agent name, or access level is rejected outright. This is a direct defense against prompt injection via the event stream, and it’s rare to see it stated this crisply in agent infrastructure.

Second, a hop counter with a fuse, borrowed from network packet TTL. When an agent’s output triggers new events, which get dispatched to agents, whose output triggers more events, the layer count accumulates — and it does not reset through human questions or scheduled rechecks, and agents cannot modify it. Past eight layers, the system logs but refuses to dispatch, and sends you a card about it. Runaway agent loops are the failure mode everyone in this space hand-waves about; Autoloop implements a hard, unforgeable ceiling.

The delivery pipeline extends the same caution. Tag a GitHub PR for delivery and the system follows it through review, CI, merge, deployment, and production verification — but review and delivery configuration are read only from the main branch, and PR code is never checked out or executed on the machine that took the job. The pipeline reuses the kernel’s queueing, concurrency, and retry machinery rather than bolting on a second system.

Where this sits in the field

The timing of this project is not accidental. The industry conversation has spent the past year converging on the idea that the interesting engineering in agents is in the harness, not the model. Oracle’s developers blog frames agent architecture as two separable layers and argues most agent engineering work happens in the harness. LangChain’s “The Art of Loop Engineering” stacks loops — agent, verification, event-driven triggering, self-improvement — and identifies the event-driven loop (cron, webhooks, continuous operation) as the level where agents stop being tools and become systems. C3 AI is pushing the same idea upmarket, arguing that “headless” autonomous coding agents embedded in production software will turn static deployments into living systems, and criticizing current commercial offerings for confining agents to predefined UIs and narrow workflows.

Autoloop is, in effect, the single-machine, single-person version of that thesis. It is Loop 3 from the LangChain taxonomy — event triggers, schedules, webhooks, an agent running inside a larger system — implemented not as a hosted platform but as a local daemon you could describe in a paragraph. Where C3 wants agents as cloud infrastructure and Kore.ai sells continuous agent optimization as a product, this project asks what the minimum viable version looks like on a laptop. The answer turns out to be: a small deterministic kernel, a plugin bus, and a willingness to kill processes.

It also aligns with what the usage data actually says about how humans and agents divide labor. Anthropic’s analysis of roughly 400,000 Claude Code sessions found that in typical sessions, humans make most planning decisions while the agent makes most execution decisions — and that over seven months, usage shifted decisively toward end-to-end agentic tasks like deploying code and analyzing data. Autoloop formalizes exactly that division: the human sets rules (what, to whom, where), the agent executes, and the card-based approval flow is the narrow, explicit channel where planning authority re-enters the loop. Notably, Anthropic’s report also found that success depends on how well the person understands the problem — which cuts against the fantasy, peddled by vendors claiming 252× speedups and millions in reclaimed productivity, that delegation is a substitute for expertise. A system that asks you structured questions at decision points is a system that assumes you still matter.

There’s a social observation lurking here too. A post in a three-million-member Claude community group, from a self-described daily user, asks what agents are even for — overwhelmed by the tooling, working entirely in the web app, unable to see what a group of agents accomplishes beyond back-and-forth prompting. That confusion is the market condition Autoloop addresses: not more agent capability, but a legible structure in which an agent’s work, questions, and results have a defined shape.

The honest caveats

The README is unusually forthcoming about what has and hasn’t been tested, which is worth taking seriously rather than glossing. The four webhook channel templates (DingTalk, WeCom, Slack, Discord) were verified only against local mock servers. The scenario recipes — feedback handling, website monitoring, Feishu weekly briefs — use fictional sample data, and the scripts and card callbacks were validated with local HTTP and a fake Feishu CLI; no full business flow has run against a real account. The text channels require a reachable public URL for answer links, which quietly reintroduces the “no open ports” promise’s fine print. History growth degrades state summarization, and a format change forces a full log rebuild — 43 seconds at 1.1 million facts.

There’s also a compliance tension the project names directly: it drives agents through your locally installed, personally logged-in CLI tools, meaning model usage bills to your subscription account. Both Anthropic and OpenAI recommend API keys for high-frequency automation, since personal subscriptions are priced for human-paced interaction. The README says if you’re serving others, use an API key. It’s a refreshingly non-evasive treatment of a gray zone most projects in this space ignore entirely.

And it should be said plainly: much of this is glue, in the honorable sense. The agents are other people’s agents; the notification channels are other people’s APIs. The genuine intellectual property here is the kernel — the suspension model, the event-sourced state, the injection defenses, the hop fuse — and glue built on a sound kernel is exactly what this layer of the stack should be.

Outlook

The open questions are the ones you’d expect for a young, apparently solo project: whether the plugin ecosystem materializes, whether the untested integrations hold up against real accounts, and whether single-machine scope is a feature or a ceiling. The delivery pipeline — agents shepherding PRs all the way to verified production — is the most ambitious piece, and also the one where trust will be hardest to earn. But the core bet is well placed: the industry has agreed the harness is where the work is, and this project’s harness has better-mannered failure modes than most. An agent that exits while it waits for you is a small idea. It might also be the correct one.