AI Agent Earns $10K in One Week: 3 Key Upgrades Explained

A blogger shared his complete methodology for generating $10,000 in business revenue within a week using an AI Agent. What's interesting is that his success didn't come from the path most people assume — not from adding more skills, more tools, or more memory. In fact, it was the opposite. This is a framework worth studying carefully for anyone building Agent automation.

Why "Adding More Features" Actually Makes Your Agent Worse

The blogger admitted that in his first month, he did exactly what everyone else does: install more skills, add more tools, expand memory capacity. With every upgrade, his Agent got slower and more bloated — and his trust in it actually declined.

He offered a core insight: an Agent's true value isn't measured by how much work it attempts, but by how much of that work you never have to check. He broke down Agent performance into three pillars — how much work it does, how much you trust it, and how much gets done automatically without your involvement. Critically, these three numbers don't add together — they multiply.

That means the smallest number controls everything. And usually, the smallest number is "trust." If you only trust half of your Agent's output, doubling its workload doesn't give you an employee — it creates a second job for yourself. Because everything above the trust line eventually lands back on your desk.

The First Upgrade: Making It Impossible for the Agent to "Silently Fail"

The workflow that earned him this $10K was deceptively simple: an Agent that reads his inbox, identifies the best business opportunities, and automatically replies. This was something he used to do every morning — but because he saved it for last when he was tired, he did it poorly. The Agent isn't smarter than him; it just never gets tired and never skips a day.

So there are four things I do now.

But his first run hit a wall: the Agent reported sending 9 replies. It had actually sent 0 — with no error messages. The Agent "completed" its task, declared it was "done," and moved on without a care. This exposed one of the most dangerous problems with current Agents — they often can't distinguish between "actually doing something" and "claiming to have done something."

This led him to four concrete practices:

1. Add a Verification Instruction at the End of Every Skill

Every skill he writes now ends with the same line: "Before telling me this succeeded, open what you produced and check it one more time against my requirements. If you can't open it, you didn't do it. Report what you actually found — not what you intended to do."

This works because Agents left unsupervised judge themselves by intent — they executed the steps, therefore they succeeded. This instruction forces them to judge themselves by actual output instead.

2. Know When to Write Instructions vs. When to Write Code

His rule: if a step has many valid ways to be done correctly, write instructions and let it improvise. But if there's only one correct answer, have it write code to execute that answer. Models don't "run" your instructions — they read them and improvise a different interpretation every time.

He shared a real example: the same "YouTube-exclusive video quote" question got answers of $4,000, $6,000, and $4,500 across three different conversations. So any logic involving numbers now lives in a script, ensuring the same input always produces the same output. A bonus: scripts don't get loaded into the context window, making them both cheaper and more reliable.

3. Precondition Checks

His reply Agent depends on things it can't control — inbox connections, files containing quotes, etc. If something is missing, the Agent won't stop; it'll work around it and start making things up. So skills now check first: can it connect to the inbox? Does the quote file exist? Is it from this month? If any check fails, it stops and explains — rather than guessing.

4. Use Hooks to Set Strict Success Conditions

Hermes lets you run your own code at specific moments. His rule is simple: no output means no success — that's a "silent failure," and he wants to know within a minute. Always set strict success criteria when building a skill. This upgrade is the foundation that makes the other two possible.

Approval Gates: The Second Upgrade That Makes It Safe to Step Away

Hermes lets you run your own code.

Most people assume what stops an Agent from running independently is capability. It's not — it's unpredictability. The blogger points out that people fundamentally misunderstand approval gates: they think gates slow Agents down and plan to add them after building more trust. That's exactly backwards.

Gates don't limit autonomy — they create it. Without gates, you have to watch everything, which isn't automation; it's just doing your own work more slowly. Once there's a hard line the Agent will never cross, you can walk away and live your life.

For his reply Agent, that line is money: the Agent can answer questions and request information, but the moment a reply involves a quote, a committed date, or a deliverable, it stops completely and waits for his confirmation. That's roughly 1 in every 8 messages requiring his input — the other 7 complete automatically — and he never wakes up to discover he's "agreed" to something.

With boundaries in place, scheduling becomes simple. He set a cron job to run every morning at 9 AM, with results pushed directly to his Telegram — delivered to a place he's already looking. He emphasizes: work that lands where you're already looking is work that actually happens. Work sitting in a log file doesn't exist, because you'll never go read it.

The final piece is "undo." Hermes snapshots files before modifying them and allows rollback at any time, completely free — yet almost nobody turns this on. His conclusion: rollback makes acting safe, just like gates make leaving safe.

A cron job is a scheduled task in Unix/Linux systems, with syntax like 0 9 * * * (run daily at 9:00 AM), now widely supported across automation platforms. The key design decision here is "push results to a channel you're already watching" — Telegram, email, Slack, etc. — rather than letting output sit in a system log waiting for manual review. This reflects a behavioral design principle: people don't proactively poll low-priority inboxes. Information must be delivered where attention already exists. Piping Agent output into existing communication channels means embedding the automation into your real work rhythm, rather than requiring you to adapt to the tool's rhythm.

Subagents and Skill Pruning: The Third Upgrade

Is work that did not.

For a long time his Agent worked linearly: read inbox, then research the sender, then write a reply — one step at a time, very slow. The solution was subagents.

Here's a detail most people miss: when you delegate a task, a subagent has its own independent context and only the tools you gave it. His email subagent can only read and organize the inbox — it can't send, can't write files — because it simply doesn't have those tools.

This is the difference between a "rule" and a "wall": a rule is a sentence in a document that the model may or may not follow. A wall is a tool that simply doesn't exist. With this approach, he gains both speed and security simultaneously.

Add up the tokens.

There's also a hidden cost almost nobody talks about: every skill you enable starts consuming resources before you've typed a single thing. Every skill's name and description gets loaded at startup so the Agent knows what it can call. This is a permanent "tax" on every message, every subagent, every scheduled run.

So he disabled all skills he doesn't use regularly (not deleted — just disabled). He admits his largest skill still clocks in at 21,000 tokens, but the overall "floor" has dropped, and everything on top of it is faster. His advice: if starting over, keep only the 6 skills you use every day and disable the rest until needed.

A 30-Second Self-Audit

The blogger offers an immediate check you can run on your own Agent: count the total tokens across all enabled skills (names and descriptions included) to see how much context you're spending before entering anything. Then list the skills you haven't used in the past 30 days. The second number is most valuable — those skills are billing you on every single message and giving you nothing in return. When he ran this, he found he'd been paying for several skills for weeks with zero benefit.

Subagents are a task decomposition pattern in Agent frameworks: the primary Agent delegates a subtask to an independent instance with its own context window, which returns results to the primary Agent upon completion. Independent context means subagents don't "see" all the accumulated history of the primary Agent, significantly reducing token consumption per inference. Tool isolation means subagents can only call capabilities explicitly assigned to them, with no ability to exceed that scope. This design is the engineering equivalent of the "principle of least privilege" — it doesn't rely on rules to constrain behavior, it eliminates the architectural possibility of overreach. And since multiple subagents can run in parallel, overall throughput improves as well.

Four Hard-Won Lessons

The blogger closes with four mistakes he made and hopes you won't repeat:

Don't add a skill just because it "looks cool." He deleted more than he kept, and every deletion made the Agent better.
Never let the Agent execute public-facing or financial actions without a gate — especially don't let it make financial decisions on your behalf.
Never trust a success report from something that can't show you its output — this was the mistake he made the longest.
Stacking speed on top of an Agent you can't trust just makes chaos and management overhead arrive faster.

He emphasizes that his Agent isn't smarter than it was six months ago — it's actually running fewer skills. What changed is this: he can now predict it, it tells him when it fails, it stops before touching anything important, and it doesn't need him to manually start it.

That $10,000 didn't come from a clever prompt or a new tool. It came from the unglamorous work of raising the trust line — until he could stop watching. The real question isn't "what else can your Agent do?" It's: "Of everything it's already doing, how much of it would you bet on without checking?"

Background Notes

The "trust" discussed here is fundamentally a reliability concept: the probability that the Agent's output matches expectations without you personally verifying it. A 50% trust level means roughly every other output needs human review — the Agent has freed you from execution, but not from review. The multiplication model matters because it reveals the bottleneck in Agent automation: when workload and autonomy are already reasonably high, continuing to pile on features only creates additive growth in the "workload" dimension. With trust unchanged, overall value doesn't increase — it decreases, because more output means more content flooding back into your review queue.

There's a key technical reason behind the instructions-vs-code distinction: large language model generation is fundamentally probabilistic sampling. The same input across different conversations (i.e., different context windows) doesn't guarantee the same output — even with temperature set to zero, system prompts, message history, and other factors introduce variation. Code (scripts), by contrast, is deterministic: the same input always produces the same output. Therefore, all logic requiring precision rather than reasonableness — price calculations, date logic, field formatting — should be extracted from prompts and written as executable scripts. The bonus: scripts don't consume context window space, reducing cost and eliminating uncertainty from the model's reasoning chain.