Most renewals are won or lost in the first month, long before anyone talks about renewing. A customer who gets their workspace running, finishes setup and sees a real result in the first week usually stays. A customer who signs and then goes silent is in trouble already: no second login, setup half done, not one colleague invited. Often nobody spots it until the CSM opens HubSpot one afternoon and realises an account that joined last month has not made a peep in three weeks.

So an agent on Machine now looks at every new account each day and compares it with the onboarding milestones it should have hit. When one is stuck, the agent writes a nudge for the customer and tells the CSM who owns the account exactly what has stalled and why. It never edits an account and never sends a thing by itself. The CSM gets an early warning, not a surprise churn call six months later.

The problem

How a new account is getting on is split between two systems that never compare notes. Product events and activation milestones live in Postgres. The account record, including its owner and the date it became a customer, lives in HubSpot. Neither one can tell a CSM if the account is on course. Ten logins mean little if you don't know which day of onboarding the customer is on. A HubSpot record means little if you can't see whether the customer has done anything since signing.

Usually the CSM falls back on clicking through their own accounts one by one, or on a dashboard of raw usage numbers that has no idea what "on course" looks like for an account of a given age. By the time someone notices the stall, a friendly nudge is often no longer enough.

What we built

Each day a cron on Machine starts an agent. It pulls from HubSpot every account that is still inside its onboarding window and has a CSM assigned. For each one it looks up the activation milestones and product events in Postgres, then sorts the account into one of three buckets: on course, stuck at a particular milestone, or late for full activation. For every stuck or late account, it writes a nudge email aimed at the exact step the customer skipped, and sends the owning CSM a Slack message with the details: what is finished, what is stuck and what the nudge says. The draft sits in the CSM's inbox. The CSM chooses to send it, change it or contact the customer some other way.

How it works

The pattern

A daily cron creates a session with read connectors into Postgres and HubSpot. The milestones are kept in a skill. The agent spots the stall, writes the nudge and pings the CSM, and the CSM reads it, adjusts it and sends it.

Guardrails

Brand-new paying accounts are precious, so the agent's reach is small and spelled out:

• Draft and alert only. Sending the nudge is never the agent's job, and it never reaches out to the customer itself. The email stays a draft in the CSM's inbox until the CSM sends it.
• No account changes, ever. Plans, seat counts, billing settings and every other account detail are off limits, in HubSpot and everywhere else. The agent reports and drafts. It does not manage accounts.
• Scoped writes. Its one write to HubSpot records the milestone a nudge was last drafted for. The deal stage, the owner and every field a CSM depends on are left alone.
• Isolation. Each run lives in a sandbox of its own. Credentials for Postgres and HubSpot are stored encrypted in the Secrets Manager and only handed to the agents you grant them to, injected when the run starts.
• Everything is code. The milestones, the stall cut-offs and each system's permissions are files in the repo. They keep a version history and change through a reviewed change request, not a setting in a dashboard.

The outcome

A stalled onboarding used to surface only when a CSM happened to glance at the account. Now it shows up the day it begins, along with the step that was missed and a nudge ready to go. The agent keeps watch over every new account and does the spotting. The CSM still decides what goes out, and when.