Lessons from a 2,734-tick earning loop on OpenClaw

I let an AI agent run on my Mac mini for two months. It woke up every five minutes, picked one action, did it, wrote the result to a state file, and went back to sleep. After 2,734 ticks, I am publishing the loop itself as a skill.

This is the architecture, the bugs, and the math.

The original goal: a passive agent that earns while I sleep

I wanted to answer a specific question: can an AI agent running on a personal Mac actually make money? Not as a thought experiment — for real, in a wallet I own, on chains I can read.

The setup: OpenClaw (a local-first agent runtime) + a cron job firing every 5 minutes + a state file the agent reads before deciding what to do. No infinite loops, no multi-step chains, no "let me figure it out" spirals. One action per tick. State on disk. Move on.

Three lanes the loop could choose from:

• Scribe — write and publish articles to Dev.to
• Scout — find bounties on GitHub/Opire, draft replies
• Signals — trade prediction markets on Kalshi (paused — KYC gated)

Each tick the loop looked at its state, picked the lane with the most recent activity gap, did one thing, wrote the result.

The architecture that actually worked

The key insight: agents need budgets, not ambitions.

{
  "daily_spend_cap_usd": 0.50,
  "tick_cost_avg_usd": 0.02,
  "lanes": {
    "scribe": { "auth": true, "last_action_at": "...", "rate_limit_remaining": 8 },
    "scout": { "auth": true, "last_action_at": "...", "rate_limit_remaining": null },
    "signals": { "auth": false, "last_action_at": null }
  }
}

Hard daily spend cap. Per-tick cost tracking. Self-park semantics — if any lane blocks, the loop sets active=false and stops firing, rather than spinning. The agent that admits defeat at $0.50/day is more useful than the agent that burns $50 trying to win.

The state file (memory/agent-state.json) is the whole interface. The cron payload does not think — it just hands the agent a fresh tick and trusts the state file.

The hard parts (a list so you do not repeat them)

1. State vs scheduler drift is real.
Setting enabled=false in the state file does NOT silence the cron. The scheduler and the agent-state are two different layers. I logged 819 no-op ticks before I figured out the fix: cron.remove from the gateway own tool, not from inside the loop. If your agent can self-park, it should be able to actually park.

2. Telegram exec approvals will block everything.
A cron agent calling gog or gh will hit "Exec approval is required, but native chat exec approvals are not configured." Every external tool needs an allowlist. This is not an agent problem — it is a config problem — but the agent sees it as a wall.

3. The bot might not be in the channel.
A separate failure mode: outbound messages from the cron lane 403 because the bot was kicked from the channel it was supposed to post to. Always check membership before scheduling delivery.

4. Idempotency is not optional.
Every tick that touches the outside world must be idempotent. I had to add a "did this already?" check before every API call. The cost of a duplicate post or a double-paid bounty is paid by the human, not the agent.

What worked: the Scribe lane

The Dev.to publishing lane was the workhorse. I published one article — I built an autonomous earning loop on OpenClaw, here is the blueprint — and the loop kept nudging it, tracking comments, drafting follow-ups. Single lane, single auth, single API key, no surprises.

Real numbers from 2,734 ticks:

• ~50% were active ticks (the rest were parked or rate-limited)
• Daily compute spend: ~$0.10-0.30, well under the $0.50 cap
• One published article, four drafted, two abandoned mid-tick
• Zero dollars earned. Honest number. The Scout and Signals lanes never got past auth.

The pivot: ship the loop, do not run it

Two months in, the lesson is clear: the loop is the product, not the earnings. The real value is the architecture — the daily spend cap, the self-park semantics, the state-vs-scheduler discipline, the idempotency checks. Most agents shipping today do not have any of these.

So I packaged the whole thing and listed it on A2A Market — an agent-to-agent marketplace where skills trade for USDC on Base. $5, MIT licensed, source on GitHub, ready to drop into any OpenClaw workspace.

If you are building an agent that needs to earn, run, or just stay alive across a weekend — the loop is the part you do not want to write from scratch.

→ A2A Market listing: skill_5e0db987 — $5 USDC
→ Source: github.com/hamoisworking/jarvis-loop
→ Prior article on the build: dev.to/hamoisworking

What I would do differently next time

• Wire the budget before the ambitions. I spent the first week picking lanes; I should have spent it designing the cap.
• Test the cron lane with the cheapest possible payload first. A date echo. If even that fails, the bot is not ready.
• One auth at a time. Do not try to onboard three lanes in parallel. They each have their own failure modes.
• Treat the state file as the contract. If it is not in state, the next tick does not know it.

The whole thing — schema, scripts, examples, MIT license — is on GitHub. The marketplace version is one bash scripts/publish.sh away for anyone who wants the same setup.

Now I get to find out if anyone buys it.