AI agents in production: who runs your GTM while you're on vacation?

Some of the most advanced GTM builders we talk to run their revenue engine from a Mac mini under a desk.

Twenty-odd agents. A coding agent in the terminal, the warehouse and the CRM on the other end, a Slack ping when an account gets interesting. It works. It produces real pipeline. Not long ago, a system like that took a data team and several months.

Then come the questions nobody asked while building it. What happens when someone knocks the box off the desk? When the person who built it changes jobs? When they’re on vacation and one of the twenty agents starts failing on day three?

That isn’t a criticism of the builder. Building got fast. Everything after it didn’t.

Your coding agent built it in 20 minutes. Production is everything after minute 21.

A GTM workflow is in production when it keeps running correctly without the person or the session that built it: it starts when it should without anyone launching it, uses credentials the company owns, stays inside rate limits and budgets, leaves a trace of every run, and changes in a way the team can review and undo.

Building is no longer the main bottleneck for many GTM workflows. Claude Code, Codex or Cursor will write a scoring workflow or an enrichment flow in an afternoon (here’s the setup). Complex systems still need real engineering judgment. What changed is that a first working version doesn’t. This piece is about minute 21 onwards: why agent-built workflows fail in production, the four things that keep them running, and two real failures from our own engine.

Why do AI agents fail in production? #

Your agent built it. What happens tomorrow?

Almost never the logic. The workflow does exactly what it was written to do. It fails on everything around it, in three ways.

It lives in one head. The prompts, the reasons behind each rule and the exceptions sit in one person’s sessions. When they’re away, nobody else can say what the workflow is supposed to do, so nobody can tell when it stops doing it. We covered why that happens in stop rebuilding, start improving.

It runs on a laptop. Who starts it at 7am when the lid is closed? Whose API key is it using: the builder’s personal CRM token, the one security revokes the day they leave? What happens at account 4,000 when the data provider starts refusing requests: does it wait, skip, or stop halfway with half your accounts updated? And when it retries, does it write the same row twice, or email the same person twice?

It fails silently. Someone renames a column in a table. The step that writes to it starts failing on every run. The workflow keeps running, the scoring keeps scoring on data that stopped updating, and nothing pings anyone. The error is recorded somewhere. Nobody is reading it.

None of these are build problems. They’re running problems, and a better model doesn’t fix any of them.

What does it take to run AI agents in production? #

Four foundations. Each one answers a question the team will ask on day two, whether or not anyone planned for it.

1. A definition the team can read

The rules, the context and the reasons need to live somewhere versioned that someone other than the builder can read, and that the next agent session can start from. A repository is the best home we know for it. The full argument, including what stays out of Git, is in why your GTM belongs in Git.

2. A runtime

This is the part every team underestimates, because none of it shows up in a demo. A production runtime for GTM has to:

• Start without anyone. On a schedule, or on an event: a new signup, a CRM change, a reply.
• Use the company’s credentials, not a person’s. The CRM and every data provider are connected once, for the company, with the right permissions. Nobody’s personal key sits in a config file.
• Respect limits and budgets. Every provider has rate limits and daily quotas, and every enrichment costs money. A workflow should slow down when it hits a limit, not stop halfway through a list.
• Retry without doubling. A retried step has to have the same effect as one successful attempt. One row, one email, one CRM update.
• Remember what it already did. The second run shouldn’t re-enrich and re-pay for the 10,000 accounts the first run finished.
• Send with guardrails. Suppression lists, unsubscribes and daily send limits apply to every email, whichever agent wrote it.

None of this is the interesting part of your GTM. All of it decides whether the interesting part runs on Tuesday.

3. How do you monitor AI agents in production?

Monitor the steps and the outputs, not just the runs.

Start with a trace of every run: each step, what it received, what it returned, what it wrote, what it cost. That’s what turns “the scoring looks off” into a question with an answer.

Then alert on the right thing. “Did the workflow run?” is the wrong question, because a run can finish while a step inside it failed. In the 30 days to 2026-10-20, about 3,300 of the roughly 545,000 successful runs in our own workspace had a failed step inside. Only 12 of those runs had a failed write: a lead that couldn’t be pushed to outreach because it had no email. In the rest, the failed step was an enrichment lookup that came back empty or got an incomplete input, which is normal for enrichment.

That’s the line to alert on. A lookup that finds nothing is expected. A write that fails means data isn’t landing. Alert on failed writes, the steps that save data or send something, when they fail more than once on the same step.

Some failures produce no error at all, so also check the outputs: the things that should exist every week, and the counts that should never be zero.

Finally, keep each run’s inputs and results. When something does break, you want to replay the failed runs from where they stopped, not re-run the whole workflow and pay every provider again.

The next step is an agent that reads the failing trace, fixes the workflow and opens a pull request for a human to review. Aurélien wrote up how that loop works in your coding agent fixes your revenue engine before you notice it broke.

4. How do you secure AI agents in production?

Control who can change what, and how much a change can touch.

• Credentials the company owns. If access to your CRM depends on one employee’s token, so does your GTM.
• Scoped permissions. Security teams won’t hand API keys to people who aren’t engineers, and they shouldn’t. The people closest to the problem should be able to run approved workflows without holding the keys.
• Review in proportion to risk. Fixing a renamed column and changing who counts as a target account are different decisions, and they deserve different reviews. Put human approval where judgment is needed, and loosen it only for workflows with a clean record. Test what you can before it ships: here’s how to evaluate an agent’s prompt before production.
• A preview of the blast radius. Before a change ships or a trigger is switched on, know how many records it will touch. Switch on a trigger that fires on new rows in a table that already holds 100,000, and the platform may treat every one of them as new.
• A way to stop it. One action that halts a runaway workflow, which anyone on call can find at 2am.

What do production failures actually look like? #

Here are two from our own engine. We found both in the same audit, on 2026-10-17. They don’t prove that our engine is reliable. They show what failure looks like once the workflow is real, and what makes it cheap to recover.

The failure nobody watched. One of our workflows detects people who just joined a target account. From 2026-08-16, the step that saves each detected hire was writing to column names that didn’t match the table. Every run failed at that step for eight weeks: 1,546 runs. Every failure was recorded, with its error, in the run history. Nobody was looking at it, and no alert covered that step. A person found it while auditing the engine.

The recovery was the cheap part. Every run had kept its inputs and the work it had already done, so we rebuilt all 1,546 missing rows from the saved runs in one evening, without re-running a single enrichment or spending a credit.

The lesson isn’t “add an alert”, though we did. Traced isn’t the same as watched. The trace made the failure cheap to repair. Only something reading the trace every day would have made it short.

The failure with no error. Another workflow qualified every new product signup and passed it to outreach. It never wrote the signup event our scoring reads. Zero signup events, ever. Every run succeeded, so the traces were clean, and signups quietly scored nothing. No trace can show a step that doesn’t exist. What catches this is a check on the output: a weekly count of signup events that should never be zero.

Neither failure was a build problem. The code did what it was told, every time.

Build the logic. Don’t rebuild the infrastructure. #

Any coding agent can deploy code to a server. Hosting isn’t the hard part. The hard part is the list above, specific to GTM, assembled once, kept current as every provider changes its API and limits, and watched every day.

That’s what we built Cargo for. Your coding agent writes the logic in a repository you own. Cargo connects it to your CRM and data providers with the company’s credentials, runs it on schedules and triggers with rate limits and retries handled, sends from managed mailboxes with suppression lists, keeps every run and every step traced, and lets you put alerts on the failures that matter: failed writes, sudden spikes in runs, outputs that stop arriving. Your coding agent builds on Cargo, or our team builds the first production system with you.

Should you build that layer yourself instead? Some teams should, and the trade-off deserves more than a paragraph. We wrote it up in your agents can build your GTM: should you run the infrastructure too?

Would your GTM keep running while you’re on vacation? #

Here’s the test we use. The person who built your workflows is away for two weeks, fully offline. Can the rest of the team say what ran yesterday, what failed and since when, what it cost, what it sent and to whom, and who can stop it?

If the answer to any of those is “ask them when they’re back”, the workflow isn’t in production yet. It’s on loan.

See how your coding agents can build GTM systems that Cargo runs in production.

Prefer to start on your own? Set up Claude Code or Codex, Cursor and OpenCode and run a first job in a few minutes.

FAQ #