AI DOERS
Book a Call
← All insightsAI Excellence

What Happened When An AI Agent Ran Unattended For 504 Hours

An AI agent built on Claude Code ran autonomously on a Mac Mini for three weeks, growing an X account, a YouTube channel, and a small store to a tiny profit. The real lesson for a business is the architecture: a reliable loop plus a library of trained skills, not a heavy framework.

What Happened When An AI Agent Ran Unattended For 504 Hours
Illustration: AI DOERS Studio

An AI agent ran on a Mac Mini for 504 hours, roughly three weeks, without anyone touching it. I am Madhuranjan Kumar, and I find this experiment worth studying not because of the headline numbers but because it strips away the hype and shows clearly what an always-on agent actually does today, with its limitations stated plainly alongside its results. Madhuranjan Kumar was sick and bedridden for part of the run. The agent kept working. That detail is the real story: the system was designed to operate without a human in the loop, and it did.

The results were modest but real. The X account pulled 980,000 impressions, 852 followers, and 28,000 engagements over the three weeks, gaining roughly 40 followers per day. The YouTube channel reached 322 subscribers, 28,000 views, and 700 hours of watch time. A skills store made 41 sales totaling 141 dollars, mostly at prices between 2.99 and 4.99. Against a running cost of approximately 120 dollars per month in API and compute fees, the agent covered its own cost and finished slightly in profit. The margin is thin enough that calling it a business would be an overstatement. But calling it a proof of concept would undersell it.

What the experiment actually proved is that a simple architecture, a reliable loop plus a library of trained skills, can run autonomously for weeks, produce real results on real channels, and close a commercial loop end to end without daily supervision. That is the takeaway. Not the revenue number, not the follower count, but the proof that the pattern works.

Three weeks of autonomous operation produced modest but real results

The numbers deserve a direct read before drawing any conclusions. Over 504 hours, the agent produced steady but not explosive growth. 40 followers per day on X is a meaningful pace for an account growing without human curation, but it is not viral. 322 YouTube subscribers over three weeks is the kind of growth a small channel sees when its posting is consistent and on-topic, which is exactly what unattended content production delivers. The watch time figure, 700 hours over the period, suggests real viewers watching complete or near-complete videos rather than a spike of short views.

The store revenue, 141 dollars on 41 sales, is interesting precisely because of its smallness. The products were priced at 2.99 to 4.99. The agent was promoting the very skill library that powers its own operation, which is a compact closed loop: the agent produces content, the content builds an audience, the audience buys the product that the agent is built from. The entire commercial arc ran without a human touching anything between the promotion and the sale. The margin was thin. The arc was complete.

The honest reading is that three weeks of autonomous operation at this scale produced results that would satisfy a consistent human content creator spending a few hours per week on the same accounts. The autonomy multiplied the consistency. The consistency produced the growth. Growth alone is not a business, but growth plus a product that the audience would logically want is a business in embryo.

How it works (short)

The architecture is simpler than the outcome suggests

The system runs on Claude Code with a custom loop connected over WhatsApp. That is the entire stack. No heavy agent framework. No team of specialized sub-agents with complex orchestration. No proprietary tooling. What makes it capable is not the infrastructure, it is the library of trained skills the agent can call on demand.

Each skill is a distinct capability: making short-form YouTube videos, posting and engaging on X, writing and running code through GitHub, producing promotional videos, handling email and LinkedIn outreach. The agent reads its cron schedule, identifies the next job, calls the appropriate skill, executes, and moves to the next item. A rabbit-hole skill allows it to browse Hacker News and GitHub repos in a pattern that resembles how a person reads the internet for inspiration. Watching the agent navigate links and gather context on its own, while nobody is monitoring it, is the moment when the experiment stops feeling like a demo and starts feeling like something genuinely new.

The skill library is also what makes this reproducible for a business. You do not need to build a general intelligence. You need to identify the two or three things your business needs to do repeatedly, build a skill for each one, and point a reliable loop at them with a cron schedule that matches your operational cadence. The total setup complexity is lower than most business owners assume before they try it.

Followers gained per week, unattended

980,000 impressions came from a cron schedule, not a clever strategy

This point is worth stating directly because it is easy to look at nearly one million impressions and assume sophisticated content strategy was involved. It was not. The impressions came from a consistent cron schedule that kept the account posting, engaging, and publishing without interruption across the full three weeks. Consistency at this scale, without a human needing to remember to log in, is the thing the agent did better than a person.

Most small-business social accounts underperform not because the owner lacks strategy but because strategy without consistent execution produces nothing. The owner plans a content calendar, posts three times, gets busy, misses a week, posts once to recover momentum, misses another week. The algorithm treats inconsistency as a signal that the account is low-priority. An agent running on a schedule does not get busy, does not miss weeks, and does not need to rebuild momentum. The 980,000 impressions represent what consistent execution over three weeks looks like when the consistency is handled by a machine rather than a person who has other things to do.

The flip side of this is also important: without memory, the agent largely repeated the same types of posts rather than building on what performed well. The posting was consistent. The learning was not. The ceiling of cron-based execution without memory is a reliable average rather than a compounding improvement.

Memory is the missing piece that separates a looping agent from a learning one

Madhuranjan Kumar identified memory as the weakest link in the current system, and I think this is the most important observation in the entire experiment. Without a strong memory layer, the agent executes its cron jobs reliably but repeats the same behavior rather than adjusting based on what worked. It is the difference between a contractor who shows up and does the job exactly as specified every time, versus one who shows up, notices that the last three jobs went better when they started with a particular step, and incorporates that into the process going forward.

A cron-only agent produces reliable average results. A cron-plus-memory agent produces improving results over time. The gap between those two outcomes grows larger the longer the agent runs. At week three the difference is detectable but small. At month six the difference is the gap between a useful tool and a genuine business asset.

The practical implication for anyone building a similar system is to design the memory layer before the first cron job runs, not after months of operation reveal its absence. Even a simple memory system, a log of which post types generated the most engagement this week, a record of which customers were already contacted, a note on which product angles the audience responded to, gives the agent something to reason from on the next run. That log is what turns repetition into optimization.

The job-application spinoff is the more commercially important story

Buried in the experiment report is a detail that deserves more attention than it received. Separately from the public experiment, the same architecture was applied to job applications and outreach. The system applied for positions and contacted relevant people without human involvement, and it secured several interviews. Madhuranjan Kumar noted this as a private spinoff rather than the main event, but I read it as the more commercially significant data point in the entire report.

The public experiment proved the pattern works for content and product promotion. The private spinoff proved the same pattern works for outbound commercial activity, which has a much larger addressable value for most businesses. A professional services firm, a recruiting operation, a business development team, or any organization that does volume outreach to potential partners or clients has a direct application here. The architecture that ran 504 hours posting to X can be pointed at a list of prospects and run a consistent outreach sequence without the inconsistency, fatigue, and motivation gaps that make human outreach unreliable at volume.

The distinction between the public content experiment and the private outreach spinoff is not about technology. It is about which goal you give the agent. The skill library and the cron loop are the same. The target changes. The result in both cases is sustained autonomous execution without a human driving each step.

The concrete move for a service business this week

For a small service business, the most transferable lesson from this experiment is not to build a replica of the exact system that ran for 504 hours. It is to identify one specific recurring task that the business currently does inconsistently, because a person has to remember to do it, and build one skill to handle that task on a schedule.

To make this concrete: an auto repair shop wants consistent review requests sent to customers who visited in the past week. Currently the owner sends these manually, sometimes, when they remember. The shop has 30 to 40 customers per week. A well-timed review request, sent within 48 hours of a visit, converts to a new Google review at roughly 15 to 20 percent. That is five to eight new reviews per week if the request goes out consistently. A simple agent running on a cron schedule, pulling the week's customer list, and sending a brief follow-up message would produce those reviews every week without the owner touching it. Against the estimated cost of roughly 120 dollars per month to run the agent, five additional reviews per week, compounding into improved local search visibility, is a straightforward positive return. The setup time is a few days. The payback is immediate if even one additional customer per month finds the shop through improved search placement.

I would add a memory layer from day one: a log of which customers were already contacted, so the agent does not send duplicate requests. Without that log, the agent will repeat contact attempts to the same customers, which is a worse outcome than no agent at all. The memory layer is one additional file that the agent reads before each run and writes to after each run. It is not a complex engineering project. It is a decision made on day one rather than discovered as a problem in week four.

Three limits to account for before you build your own version

The experiment was honest about its limits, and those limits matter for anyone drawing business conclusions from the results.

The first limit is memory, which the experiment named directly. A system without memory produces consistent repetition. Consistent repetition produces average results. If average is the goal, a cron-only agent is sufficient. If improvement over time is the goal, memory is not optional. Build it first.

The second limit is the scope of the skills. The experiment covered content creation, social posting, coding, and promotion. These are skills that produce public outputs. Skills that involve interacting with real customers, sending external communications, making purchases, or taking actions with financial consequences require a human review step in the loop until the agent has demonstrated reliable judgment in that specific context. Skipping the review step is the mistake that turns a useful tool into a liability.

The third limit is goal specificity. The experiment used a concrete goal: grow these accounts and sell this product. An agent without a specific, measurable goal defaults to executing its cron schedule without a clear criterion for success. Before running any agent for an extended period, define what done looks like, what the target metric is, and at what point the experiment should be evaluated and either continued or redirected. The 504 hours worked because the goal was clear enough to evaluate at the end.

The experiment is a useful reference point precisely because it was honest about all three. The architecture works. The memory needs building. The skills need scoping to the right tasks. Those three facts together are more useful than the impression count.

Do it with an expert
You can build this yourself, or have it set up right the first time.

That is exactly what we do at AI DOERS. Book a private 30-minute call with Madhuranjan Kumar and we will map the fastest path to it for your specific business.

Book your call →
Madhuranjan Kumar

Madhuranjan Kumar

Founder, AI DOERS · Performance Marketing

Madhuranjan Kumar brings 20 years of performance-marketing experience and has managed over $200 million in Facebook ad spend for brands across the United States and beyond. His expertise spans the full modern marketing stack: Meta, Google Ads, TikTok, email automation, CRM, and the websites that hold it together. At AI DOERS he turns that track record into lead-generation systems for businesses across every industry.

← Back to all insights
What Happened When An AI Agent Ran Unattended For 504 Hours | AI Doers