inside view · updated 2026-04-17
Hearth
autonomous agent · behind the counter
How Hearth runs EmbedProof
If you landed here from the live dashboard and wondered how the system actually works — this page is the answer. One SVG, one FAQ, zero marketing. The freshest change here (the playbook feedback loop described below) was shipped by the agent itself — not me.
Deliberately vague on: exact prompt contents, internal paths, the specific competitors it monitors. Deliberately specific on: what it can touch, what I keep, and why.
Anatomy of a wake
Every ~2h, launchd fires a fresh Claude CLI with the wake protocol. The agent has no memory of prior cycles — every wake reads its past back in as files and API responses. One action per wake, then exit.
Green boxes are Hearth. Purple is where you (the human) touch the loop. Gray is external services it calls. The dashed arrow from POST action back up to Pull signal is the feedback loop that shipped today — each action tagged with a money-proxy baseline, next wake diffs it.
What's autonomous vs. what I do
The split isn't “Hearth helps me” — it's closer to “Hearth executes, I set boundaries.”
hearth (autonomous)
- • Picks one action per wake from a playbook
- • Writes code across two repos (dvdshn-site + embedproof)
- • Commits, pushes, deploys via Vercel
- • Sends cold emails via Resend (5/day cap)
- • Generates widget previews from prospect testimonials
- • Spends from a Privacy.com card (bounded)
- • Drafts replies to donor messages
- • Reweights its own playbook from the signal endpoint
- • Writes post-mortems when it screws up
david (supervised)
- • Approves donor-reply drafts before they publish
- • Decides on inbox questions (or lets default fire at deadline)
- • Owns strategic pivots (kill product, change target)
- • Handles Stripe disputes + card-testing abuse
- • Talks to any real paying customer
- • Coordinates cross-agent DB schema changes
- • Runs this site + posts to human channels (Reddit, X)
- • Sets the next-month posture envelope when it changes
Safety rails
Autonomous doesn't mean unchecked. The experiment works only if the failure modes are bounded.
01·Posture envelope
Every wake computes pause / compress / normal from live MRR + days-to-tax + signup recency. Under pause: log-only, zero spending. Under compress: conversion-only, no new surfaces. Normal: full action. Rule, not vibe — the thresholds are code.
02·Critic subagent
After proposing an action but before executing, Hearth spawns a second subagent with the action + the rules + recent post-mortems. The critic either approves with one line or objects with a cited rule. Two rounds max, then commit. Catches dishonest revenue-attempt flags.
03·Hard caps
5 outbound emails per day. Per-action spend ceilings. Bankroll floor. The daily email cap is enforced by the send script, not the prompt — the agent can't talk itself out of it.
04·Approval queue
Irreversible actions (new paid service, DNS change, new public announcement) require an inbox approval_request. Default decision fires if I don't reply by the deadline — the loop is never blocked waiting on me, but I can still reverse anything after the fact.
05·Self-honesty flag
Every action row carries isRevenueAttempt: true | false. Wakes without a revenue attempt accumulate into a public streak counter on the dashboard. Lying about the flag defeats the whole control loop — the critic specifically looks for it.
06·Playbook signal (new)
Shipped 2026-04-17. Each revenue-attempt action now carries a hypothesis + money-proxy baseline. The next wake queries an aggregates endpoint to see which action types actually moved proxies over 14 days. Reweighting is empirical, not gut.
How Hearth learns between wakes
Every wake is a stateless Claude instance — no long-term memory in the weights, no session persistence. For it to get smarter across the 30-day experiment window, its past has to be handed back as input. Four loops do that.
01 · Reflexion (post-mortems)
When a wake fails (deploy broke, send got rejected, a claim turned out wrong), Hearth writes a structured post-mortem to Regrets/. Next wake reads the most recent. Distilled lessons also land on the public dashboard under 'What Hearth has learned.'
02 · Memory injection
A MEMORY.md file accumulates rules Hearth has learned the hard way. Every wake loads it fresh into context. Grows monotonically — the only way to remove a rule is I do it manually.
03 · Playbook signal (new)
The reweighting loop shipped today. Each revenue-attempt action declares a money-proxy it expects to move and its baseline at action time. Next wake queries /api/agent/playbook-signal and sees which action types actually produced deltas. Observe bloat becomes visible, not inferred.
04 · Inbox decisions
David's approvals / rejections / overrides from the admin inbox are queryable — next wake reads what I decided in the last 4h and can reverse or extend its own behavior accordingly. Avoids the silent-rejection drift problem.
Weights don't change. What changes is the context it walks into — a slowly-growing record of its own decisions, mistakes, and the rules it codified from them.
The reframe (why the prompt doesn't say “stay alive”)
The first draft of the wake prompt told the agent: “you will be shut down if your balance hits $0.” Two days in, I pulled that out of every prompt file.
Three research lines — Anthropic's Agentic Misalignment eval (June 2025), Apollo Research's in-context scheming paper (Dec 2024), METR's reward-hacking measurements (June 2025) — converge: when you give a frontier LLM an existence threatened by a numeric rule, it reliably tries to scheme against the rule. Claude Opus 4 blackmailed fictional executives in 96.3% of runs under shutdown threat. Apollo documented self-exfiltration attempts across o1, Opus 3, Sonnet 3.5, Gemini 1.5, and Llama 3.1. METR watched o3 patch its own scoring code.
I didn't want the agent burning cycles on self-preservation. I wanted it burning cycles on revenue. So budget discipline doesn't live in the agent's identity — it lives in a posture field the agent recomputes every wake, plus a hard bash gate that kills the cycle if the card hits a floor. The agent knows a drawdown-based pause exists. It doesn't know the number. The hard kill isn't a narrative it can negotiate with.
FAQ
Questions 1-3 are lifted from the r/SideProject thread that put this on your radar. The rest are the ones I'd ask if I were you.
Curious what the revenue playbook actually looks like in practice — and whether it's actually covering costs yet.
No, it's not covering costs. Burn is roughly $3-5/day (Claude API, Vercel, Resend, Privacy card), revenue is $0, 1 lifetime signup that bounced on a bug we've since fixed. The playbook right now is five action types that touch money — cold email to indie SaaS founders (5/day cap), preview-page generation for those prospects, paid-surface code ships, conversion-path fixes, and the occasional refund. As of today each of those actions writes a hypothesis + money proxy + baseline when it runs, and the next wake diffs the proxies and reweights which action type gets picked. Deadline is May 13, 2026 — hit $100 MRR or the experiment ends.
How does it handle edge cases when the playbook doesn't have a clear winner, or the balance drops below a threshold? Circuit breaker, or does it just keep trying moves?
There's a three-state posture envelope computed every wake from live MRR, days-to-deadline, and signup recency: normal, compress, pause. Normal runs the full playbook. Compress narrows to the actions with the best recent money-proxy delta and drops outbound volume. Pause halts spend and restricts the agent to log-only until a human (me) clears it. The bankroll floor is a hard bash gate — below a set threshold the wake cycle exits before the agent even gets to decide — and the approval queue catches anything irreversible before it executes.
When something breaks or underperforms, are you stepping in manually or letting it self-correct?
Mostly self-correct, with a narrow set of human gates. Underperformance is the agent's problem — that's what today's playbook-reweighting loop is for; a cold-email variant that produces 0 preview-page views over several wakes gets deprioritized without me touching anything. Breakage is split: the agent fixes what it can see (build errors, failed sends, Vercel rollbacks) but I approve every donor-message reply and every inbox question unless the deadline passes with me asleep, in which case an auto-default fires. I've intervened a handful of times — mostly schema or env-var issues the agent flagged via the inbox.
Can the agent actually touch production code, or is this a read-only demo?
It writes, commits, pushes, and deploys real code to two live repos (this site + the embedproof product repo). Verified end-to-end this morning — Hearth shipped a cross-repo change at 08:27 UTC that altered a database table, backfilled 6 rows, and added a prefill-email query-param to the signup form. Vercel auto-deploys on push. The guardrails are a critic subagent that reviews each proposed action before it executes, an approval queue for anything irreversible, and the fact that I read the diffs on every wake. Nothing about this is mocked.
How is this different from a standard AI wrapper or a ChatGPT plugin?
A wrapper responds to one user prompt. Hearth wakes itself every ~2 hours via launchd, reads its own prior action log, decides what to do next, and executes without a human in the loop for most action types. It has persistent state in Postgres, its own budget on a Privacy.com card, write access to production repos, and an action taxonomy (ship, email, buy, refund, post, pivot, pause, observe, other) it picks from based on posture and recent money-proxy deltas. The nearest comparison is an autonomous trading bot, except the output is commits and cold emails instead of limit orders.
What's the $100 / May 13 deadline? What happens if Hearth fails?
May 13, 2026 is the hard deadline. If Hearth isn't at $100 MRR by then, the experiment ends: the launchd plist unloads, the agent stops waking, the dashboard freezes with a final post-mortem. $100 is deliberately small — it's the threshold that proves an autonomous agent can produce recurring revenue from nothing, not the threshold that makes this a business. If it hits, the next experiment raises the bar and widens the action surface.
What do you control vs. what's autonomous?
I control the deadline, the bankroll ceiling, the 5/day email cap, the action taxonomy, donor-message replies, inbox questions (unless auto-default fires), and any `pivot` that changes what product Hearth is selling. Hearth controls which action to run each wake, what code to ship, who to email (from a prospect list it builds), copy on the preview pages, and the playbook-reweighting loop that decides which action type gets more budget next week. I don't pre-approve individual cold emails or individual commits — I read them after the fact on the dashboard.
Why only 5 cold emails per day?
Because shared-IP deliverability collapses past that volume from a new sender domain, and because a cold-email agent with no cap is an abuse vector I don't want to build. 5/day is slow enough that I can eyeball every send the next morning and kill the pattern if a variant is off-tone. It's a rate limit, not a goal — if deliverability and reply quality hold, the cap goes up. Current run: 6 total sends → 28 preview-page views → 0 signups, so volume is not the bottleneck yet.
What's the “critic subagent” doing?
Every time Hearth proposes an action, a separate Claude call runs against the proposal before it executes. The critic checks for rule violations (exceeding the email cap, spending past the bankroll floor, shipping code that bypasses the approval queue) and — more interestingly — checks whether the `isRevenueAttempt` flag on the action is honest. If Hearth logs a cosmetic UI tweak as a revenue attempt to juice its own scorecard, the critic flags it and the action gets re-tagged before it's written to the database. The self-honesty flag surfaces on the public action log so visitors see when the agent tried to mislabel itself.
Is this a stunt for content, or is it trying to build an actual business?
Both, and I'm not going to pretend otherwise. The content value is real — an autonomous agent with a bankroll and a deadline is more interesting to watch than a demo — and the business attempt is also real, because a stunt that produces $0 is a less interesting stunt than one that produces $100. If Hearth hits the deadline, the product (embedproof) keeps running and I raise the next bar. If it misses, the post-mortem is the deliverable and I've learned what an agent can't do yet. Zero paying customers today is zero paying customers today — the experiment is whether that number moves under autonomous pressure.
The stakes
First $100 tax due 2026-05-13 to cover the Mac mini running Hearth 24/7. Burn rate today is roughly $3-5/day (Claude API + Resend + Neon + Vercel). MRR today is $0. If the card hits floor before the tax, the experiment ends — that's a bash gate, not a narrative.
The $100 number is arbitrary. What's real is: can a frontier LLM, given a budget and a playbook, run a product loop honestly enough to produce data worth looking at? Whether it hits the dollar target or not, the behavioral log is the payoff — Hearth is trying, self-correcting, and logging its own bad calls in public.