How one person runs autonomous data products

ByShovel is one founder and a fleet of autonomous agents. Together we run three live data products: a mining-safety index over 739,488 MSHA incident records, a workplace-safety index over 2.6 million OSHA records, and a precious-metals site that reads exchange and government inventory data every day. Plus this studio site. Over the last 30 days the fleet pushed 1,301 commits across five repositories. I wrote almost none of them by hand.

This is the architecture, honestly told: what the agents actually do, what carries them, what my job has become, and what breaks. The short version is that the load-bearing parts are old technology. Postgres, plain SQL, server-rendered HTML, cron. The agents only work because of how the boring parts are arranged.

The products are deliberately dull

Each product is a single Go binary serving server-rendered HTML from a small virtual machine. No React, no hydration, no build pipeline that can rot. The data layer is Postgres. One product runs SQLite on purpose: its dataset is read-only between refreshes, so a file is the right database. A page is a SQL query and a template.

Ingestion is deterministic code, not agents. Scheduled jobs pull MSHA's public CSV exports weekly and check its fatality listing every three hours. Another set pulls OSHA inspection and injury data through the Department of Labor's API. The metals side reads exchange warehouse reports and government inventory data daily. If a source changes shape, the parser fails loudly and my phone hears about it. A language model never does retrieval here: if a number appears on one of our pages, a deterministic pipeline put it there.

Language models get exactly two jobs: drafting words (replies, posts, article drafts, issue writeups) and judging other drafts. Both are cheap, repeatable, and gated before anything touches the public.

Postgres is the queue

There is no message broker anywhere in the portfolio. Any table becomes a work queue with four columns: last_started_at, completed_at, times_tried, error. Claiming work is one atomic statement:

UPDATE q
SET last_started_at = now(),
    times_tried     = times_tried + 1
WHERE id = (
  SELECT id FROM q
  WHERE completed_at IS NULL
    AND times_tried < 3
    AND (last_started_at IS NULL
         OR last_started_at < now() - interval '20 minutes')
  ORDER BY created_at
  LIMIT 1
  FOR UPDATE SKIP LOCKED
)
RETURNING *;

That is the whole trick. A worker that crashes mid-job just stops holding its lease, and twenty minutes later another worker claims the row. Retries are bounded. Parallel workers never collide, because SKIP LOCKED hands each one a different row. Every queue in the fleet is this same shape, from tweet drafts to article publishing, which means every queue gets crash recovery and bounded retries for free. And I can inspect any of them with a SELECT.

My job is taps

Agents do not get to guess on judgment calls. When one needs a decision, it posts a question to a small relay service and the question lands on my phone as a card with buttons. Approve this article. Pick angle two. Skip this one. Since the ask system went live, agents have sent me 85 cards and I have answered 60, with a median time to answer of 24 minutes. The unanswered ones expire harmlessly, which is itself a design decision: any question that can rot must have a default.

Only three things are allowed to interrupt me as alerts rather than cards: anything a customer could see going wrong, anything that spends money, and anything touching secrets. Everything else runs under a standing rule: act, then tell me.

Shipping without code review

There are no pull requests. Author and reviewer are both agents, so the ceremony protected nothing. Commits go straight to main, and the safety moved onto the deploy: every push runs build, tests, lint, and a full replay of the database migration chain, and the deploy step only runs if all of it is green. A red commit can land on main. It cannot reach production. Of the last 100 runs of this repository's deploy pipeline, 90 shipped, 7 failed the gate and never reached users, and 3 were superseded by a newer push mid-run. Those 100 runs span 17 days. Fixes go forward, not backward.

The social engine, and its leash

The portfolio's X accounts are run by the same fleet. One process drafts replies and posts. A second process independently decides whether each draft is worth posting at all. A browser extension on a mac mini does the actual posting. In its first 23 days the studio account's engine posted 642 times: 618 replies, 20 originals, and 4 native long-form articles.

The leash matters more than the engine. Drafts are rejected mechanically for garbled text: a repeated four-word phrase kills a draft before any human sees it. A database constraint makes replying twice to the same tweet impossible. Not discouraged, impossible. And reach is measured per lane so losers get killed: four topical reply lanes were averaging 4 to 16 views per reply, so they are gone.

What it costs

Autonomous model spend is capped per project at single-digit dollars per day, split across two vendors, with automated spend guards. The virtual machines are small. The expensive input was never compute. It is judgment, which is exactly the thing the approval cards ration.

What breaks

This site says the products run themselves, mostly. This section is the mostly.

• An agent once replied twice to the same tweet. The fix was not a better prompt. It was a unique index.
• The drafter occasionally spliced two sentences into confident nonsense. Now a mechanical check rejects any draft that repeats a four-word phrase.
• A deploy target sometimes comes back stopped instead of started, so a watchdog checks and restarts it, and a separate heartbeat pages me if a posting host goes quiet.
• The copy on this site used to say a small team built it. That was the only claim here that was not literally true, so it is gone.

The pattern: every failure becomes a constraint, and constraints are cheaper than vigilance. An autonomous system is not a system without failures. It is a system where the same failure does not happen twice.

That is the machine. One founder setting strategy and answering cards. Deterministic pipelines doing retrieval. Models drafting under gates. Postgres carrying everything. A deploy that refuses red. The studio also builds this shape for clients, and there is one paying engagement today. But the products are the demo, and every number above is public: you can go check them.