Every founder knows the monthly investor update. It's not a big job, but it keeps coming back, and it always takes longer than it should. The figures are spread over a few systems. Each one needs comparing with the previous month and with the plan. Then it all has to be written up the same way as last time. None of that is difficult. It's simply an hour or two of collecting and tidying, every single month.

So we let an agent on Machine do the collecting and write the first version. Here's how we produce our own update, with the connections and limits that make it safe.

The problem

Each month you need MRR and revenue from Stripe, active accounts and growth from the product database, and burn and runway from the finance figures. Every one of those then gets lined up against last month and against plan. The data lives in separate places, the comparisons happen by hand, and the finished write-up has to look the way investors expect.

The standard fixes only get you part of the way. A BI dashboard shows today's numbers, but it won't write the story or measure anything against plan. A saved template still leaves someone typing in every figure. Doing it all yourself works, but it means a founder's time goes on gathering and formatting instead of the commentary investors actually read the update for.

What we built

Once a month a schedule starts an agent on Machine. It gets its own isolated session, a cloud sandbox, that can read the product database, Stripe and the previous update but cannot change them. The agent collects the key metrics (MRR, growth, burn, runway and active accounts), sets them against last month and against plan, and writes the update as a document in our usual layout. A founder edits it and sends it.

How it works

The pattern

Every month a cron opens a session with read-only connectors to Postgres, Stripe and the previous update. Our layout and how we define each metric live in skills and memory. The agent writes the draft; a founder polishes it and sends it.

Guardrails

The agent reads revenue and product figures to write a document, so its access is narrow and contained:

• Isolation. Each run takes place in its own sealed sandbox, set up for that one task. The session reads only the systems it's allowed to, and the draft document is the only thing that comes back out.
• Scoped secrets. Postgres and Stripe credentials are stored encrypted in the Secrets Manager and only handed to the agents you grant them to.
• Read-only. It reads from every source and writes to none. The draft is its only output, and it never sends anything. Sending belongs to a founder.
• Everything is code. The agent's setup, skills and per-system permissions are files in the repo. They're versioned and only change through a reviewed change request, not a setting in a dashboard.

The outcome

Our monthly update now turns up as a draft with the figures collected, the comparisons made and the story written in our layout. The founder's time goes on the commentary and the decision to send, not on chasing numbers and fixing formatting. And the data is only ever read, never touched.