← Notes

Field note · ·3 min read

An agent with a sign-off beats a custom backend

Most internal tools don't need a database, an API and an admin panel. They need a loop that does the work and waits for a person to say yes. Pinedaily runs that way.

12345678910111213141516171819202122232425262728submitted → approved
IL-03 · Pinedaily

Here’s a common request: a website needs a way for the public to submit things. Events, lost and found, corrections. The usual answer is a small app, with a form, a database, an admin screen to review submissions, logins for the reviewers, and something to publish approved items.

That’s a lot of software to own for “a person should look at this before it goes live.”

Pinedaily, a daily guide to Pinedale, Wyoming, is built the other way.

The loop

  • Submissions arrive as email. Every form on the site sends to an inbox. Each form has its own address tag, so the agent knows which kind of thing it’s looking at.
  • An agent reads the inbox once or twice a day. For each submission, it drafts the exact change: the new event page, the lost-and-found entry, the corrected hours.
  • A person approves each change. The agent asks for sign-off on GitHub, and the notification lands on a phone. One tap per item.
  • Approved changes ship together. The day’s approvals are batched into one or two pull requests, not one per item, so the history stays readable.

The site itself is files in a repository. There’s no database and no admin backend.

What you get for free

The pieces that would normally be custom software already exist:

  • An audit trail. Every change is a commit, with who approved it and when. Nobody had to build logging.
  • Undo. A bad change is a revert.
  • Access control. Whoever can approve pull requests can approve submissions. No separate user system.
  • A review screen. A diff is a better review screen than most admin panels.

What it costs

It isn’t free. It’s worth being clear about the trade-offs:

  • It’s not instant. Changes go live after the next agent run and the next approval, not the moment someone hits submit. For a town guide, a few hours is fine. For a checkout page, it wouldn’t be.
  • The person is the bottleneck, deliberately. If nobody approves, nothing ships. That’s the point. It does mean the approval step has to be quick, or it gets skipped.
  • The agent has to be boxed in. It drafts changes. It doesn’t merge them, touch settings or email anyone. The narrower its job, the easier each approval is.

Where it fits

The pattern works when three things are true. The work repeats. Each item can be checked in seconds. And a mistake is embarrassing but not dangerous. That covers a surprising amount of what small teams build internal tools for: intake forms, content updates, record cleanup, routine replies.

When a mistake would be dangerous, the same shape still works with more gates in front of the approval, like hard limits the agent can’t talk its way around. That’s how the trading work here is set up.

Status

The site is live, and the loop has been handling real submissions since late September. A later note will cover what broke once it met them.