A quarterly business review lives or dies on the homework. Trouble is, the homework is spread all over the place. How much the account uses the product sits in the product database. Its health score and the CSM's notes are in HubSpot. Support history is buried in three months of tickets. The growth opportunity is mostly in somebody's head. Turning that into slides by hand eats an afternoon per account. Multiply by a few dozen accounts and QBR week becomes a slide factory, when it should be time spent thinking about each customer.

Our QBR-prep agent on Machine handles that gathering every week. It pulls from each source, writes a draft deck and a matching briefing doc for every account with a review coming up, and then stops. It never writes back to a source and never presents. The CSM opens the draft, reworks the story, and takes it into the meeting.

The problem

Everything you need for a QBR exists. It's just not in one place. Usage over time lives in Postgres. Health, CSM notes and the history of the deal live in HubSpot. Support pain is a quarter of tickets nobody has the hours to read again. And the upsell story gets stitched together from all of that, often from memory, minutes before the call.

A template gives you a nice layout. It doesn't do the gathering. Somebody still has to fetch each figure, read each note, and choose what deserves a slide. One account takes an afternoon. Every due account, every week, is the bit that gets skipped, rushed, or dumped on whoever looks least busy. That's precisely how a CSM ends up underprepared for a renewal conversation.

What we built

Once a week, a cron on Machine starts an agent in a sealed-off session that can read Postgres and HubSpot but not change them. It works out which accounts have a QBR due in the coming window. For each one it gathers usage trends, the value the customer has had, account health, a summary of support, and openings to expand. It turns that into a draft deck in Google Slides and a briefing doc in Google Docs that holds the supporting detail. Then it stops. Nothing gets shared, presented or sent. The CSM reviews both and runs with them.

How it works

The pattern

Once a week a cron opens a session with connectors that can only read Postgres and HubSpot. A skill holds the deck outline. The agent reads the account's quarter, makes exactly two drafts, a deck and a briefing doc, and hands over to the CSM.

Guardrails

This agent reads a lot of account data, so what it can reach is narrow and what it can produce has a hard edge:

• Kept apart. Each run gets its own sealed-off sandbox. The session can reach only the systems it's been scoped to, and the new deck and doc are the only things it sends back out.
• Locked-down keys. The Postgres and HubSpot credentials are stored encrypted in the Secrets Manager, added to the sandbox at run time, and only handed to the agents you grant them to.
• The sources are read-only. Its connectors to Postgres and HubSpot can only read. Usage records, health scores, CSM notes and deals are there to learn from, never to edit.
• Drafts, never sent. The deck and the briefing doc stay drafts. The agent won't share, present or email either of them. The CSM reviews and does the presenting.
• All of it lives in code. The deck outline, the skill and what each system lets it do are files in the repo. They're versioned, and you change them with a reviewed change request, not a setting on a dashboard.

The outcome

The afternoon of digging up numbers and rereading tickets now takes care of itself each week, for each account that needs it. The CSM opens a deck that already shows the trend, the health picture, the support summary and a possible expansion angle. They rewrite the story in their own voice and present it themselves.