10 AI Agents Running 24/7 on My Mini PC: What You Can Really Let Go and What You Should Never Hand Over

Starting from "50 Agents": How many are truly unattended?

A popular Reddit thread once asked: what are all those people who claim to be "running 50 agents overnight" actually running? A user who is a PhD student while also running a small online store and a YouTube channel gave an honest answer: he keeps about 10 agents running on a mini PC year-round, but the conclusion may disappoint anyone hoping for "income while you sleep" — there is not a single task that runs completely without him.

According to this user's share in the r/... community, his core analogy is: models have context windows, and so do human brains. PhD research is one context, the online store is another, and the YouTube channel and fitness are each separate contexts. Every time you switch, your train of thought breaks. So he configured a dedicated agent for each part of his life, letting them soak in the same context all day accumulating data, so that when he comes back he doesn't have to reload from scratch.

This framing is far more pragmatic than "AI works for me": agents don't replace the human, they just absorb the cost of "reloading memory."

Tasks that actually run in unattended mode

He listed three categories of work that genuinely run without his involvement:

• Research agent: Every morning at 9 a.m. it scans YouTube, scores video topic ideas, and pushes the highest-scoring ones to him.
• Fitness agent: Receives a Fitbit update each week and analyzes it on top of months of accumulated weightlifting logs.
• Coding agent + SEO agent: A coding agent running on Claude Code opens a Pull Request on his online store's website every day based on the SEO agent's findings.

Note what these tasks have in common: large input data, high repetitiveness, and outputs that are "lists to review" rather than final decisions. The research agent doesn't decide which video he makes — it just ranks the candidates; the coding agent doesn't merge code — it just prepares the PR.

Pull Request (PR) is the core collaboration mechanism in Git version control platforms (such as GitHub): a developer pulls a feature branch from the main branch, commits changes, and opens a PR requesting that the changes be merged back into the main branch. A PR is itself a "proposal awaiting review" — it doesn't change the live code, it just presents the diff for humans to review, comment on, approve, or reject. "The coding agent opens a PR every day" in this article means the agent has only completed the "propose changes" step; merging into the mainline still requires a human to click the merge button. This mechanism naturally provides a safety boundary for agents: even if the agent generates bad code, it won't directly affect production, and humans can review it line by line or simply close the PR before merging.

Claude Code mentioned in the article is a command-line coding agent tool released by Anthropic. It runs in the terminal and can directly read and write local files, execute shell commands, run tests, and iterate on fixes based on errors. Unlike IDE-plugin-style completion tools, Claude Code is designed for scenarios where it "autonomously completes multi-step operations given a task," such as modifying multiple files based on a requirements description, fixing failing tests, and generating commits. Precisely because it has file-write and command-execution permissions, the coding agent in this article narrows its permissions by "opening a PR rather than pushing directly" — leaving irreversible operations to humans.

Every automated workflow ends with a human

The line this user repeatedly emphasized is "every workflow ends with me." He decides the video topics, he edits the scripts, and he personally merges the PRs. Store-related agents can only see read-only data and have no access to the payment flow at all.

Rather than saying "the work is done while I sleep," it's more like "when I sit down, the boring part is already organized and waiting for me."

This description precisely captures the current boundary of agent capabilities: they are already quite reliable at information gathering, initial filtering, and formatted output, but in steps that carry consequences — payments, publishing, merging — humans still need to gate-keep. The so-called "efficiency gain" saves time on organizing and retrieval, not time on judgment.

His iron rule: outsource repetitive, data-heavy work; never hand over your own thinking

After months of practice, he distilled a criterion: if a task is highly repetitive and depends on large amounts of data, hand it to an agent; if it's your own thinking, keep it.

Specifically for PhD research: the agent tracks papers and organizes literature, and AI can help polish sentences or write plotting code, but reading, thinking, and writing must be done by himself, because "that's the part that keeps me sharp." This judgment is worth pondering — it positions AI as an extension of memory and retrieval rather than a replacement for cognitive ability. For knowledge workers, where this line is drawn may determine whether long-term capability degrades or amplifies.

Two warnings from real deployment: permissions and supervision

The author offers two warnings from actual deployment:

First, read permission pop-ups one by one. He mentions that when connecting Gmail, the authorization request asked not only for read access but also for permanent delete permission. Granting that kind of permission all at once means the agent (or any tool it calls) could theoretically wipe the mailbox. The default checkboxes on authorization pages are often more aggressive than users imagine.

Second, supervise continuously, even the most boring bot. Automated workflows fail silently, keep running with stale data, and do strange things when no one is watching. Treat agents like colleagues who need handoffs, not like set-and-forget timers.

He also disclosed, per community rules, that the app he used is an open-source project not developed by him, and that he made a video about it in the comments. That transparency itself is worth emulating.

OAuth authorization scope is the granularity of permissions a third-party app requests when accessing a user's account. For Google, for example, connecting to Gmail can request different scopes such as read-only (gmail.readonly), send-only (gmail.send), or full access (https://mail.google.com/, including permanent deletion). The problem is that once granted, the token remains valid for a long time, and any tool call behind the app inherits that permission; at the same time, authorization page wording is often vague, making it easy for users to click through with "one-click continue." The "read access with permanent delete attached" mentioned in the article is a typical case of scope creep — under the principle of least privilege, a read-only agent should be strictly limited to the readonly scope to avoid a single mistake causing unrecoverable data loss.

Open question: Can agents do "judgment" well?

The question posed at the end of the post is more discussion-worthy than the main text: has anyone found agents to be genuinely reliable at judgment tasks — for example, deciding which topic to pursue, rather than just ranking options for you?

From this user's practice, the answer leans conservative: agents are good at serving up "ranked options," but "which one to choose" is still up to the human. This aligns with the limitations of current agent architectures — they optimize for information-processing throughput, not value judgment. If your work has a high proportion of judgment, the leverage agents provide may be far less than advertised; if repetitive labor dominates, the gains are quite real.

For anyone who wants to replicate this mini PC setup, the real barrier isn't hardware — it's whether you're willing to first accumulate data for each life context, and whether you can hold the line on "what not to hand over."

Context window refers to the total number of tokens a model can process in a single inference, including system prompts, conversation history, and tool return results. The analogy in the article that "human brains also have context windows" points to an engineering reality: an agent's "memory" is not persistent — it is reloaded on every run, either from conversation history or retrieved from external storage (files, databases, vector stores). This is also the real meaning of "letting agents soak in the same context all day accumulating data": through externalized logs and knowledge bases, compensating for the model's inherent statelessness and its forgetting at the end of a session. Agent reliability depends largely on how well this external memory is organized, not on the model parameters themselves.