Your RevOps lead can build a routing workflow in an afternoon now. Your reps can build their own research agent from Slack. Not long ago, both meant a ticket in someone else’s queue.
Good. We don’t fight that shift. We built Cargo for it.
But there’s a question that comes right after the demo works, and almost nobody asks it in the room: who runs this on Monday? And the one right behind it: should that be us?
AI has made GTM systems cheap to build. It hasn’t made them cheap to run. Every workflow your team builds with Claude or Codex becomes something someone has to operate, monitor, maintain and improve, and the infrastructure underneath it is rarely the part that wins you deals.
I covered what production actually requires in AI agents in production. This piece is about the business decision: even if you can build everything yourself, should you?
Why does AI create more GTM infrastructure to run, not less? #
Because cheap building changes how much gets built.
When a workflow took an engineer two weeks, teams built the five that mattered. When it takes an afternoon, they build thirty. The rep who wants meeting prep builds an agent for it. RevOps builds the enrichment refresh, the routing rule, the stale-deal nudge. Someone wires a scoring model to the CRM “for now”.
Each one is useful. Each one is also a small production system:
- it holds credentials to your CRM and your data providers;
- it runs on a schedule or a trigger;
- it writes fields that other workflows read;
- it fails sometimes, mostly quietly.
Cheap to build ≠ cheap to own.
And they don’t stay separate. Thirty workflows read the same accounts and write the same CRM fields. The routing rule reads the score, the score reads the enrichment, the enrichment reads a provider. You didn’t build thirty workflows. You built one system, without ever deciding to.
Pause here, because this is the part the demo hides. The workflow is the visible part. Underneath it sits everything that has to stay true for it to keep working: connected tools and permissions, fresh data, a place to run that isn’t someone’s laptop, memory of what already ran, retries, monitoring, tests, versions, and someone to call when it breaks.
A working demo isn’t a production system. It’s a promise that someone will turn it into one.
What are the hidden costs of running your own GTM infrastructure? #
Four. None of them show up in the demo. All of them show up on your team’s calendar.
1. Time to production
Before a workflow delivers anything, someone has to connect the CRM, the warehouse, the data providers and the sequencer, get credentials and permissions right, decide where it runs and where it keeps what it knows.
The agent writes the workflow in an hour. The foundation under it usually takes longer, and most of it is the same foundation every company builds. Depending on your stack, that can be a long stretch of plumbing before the first account gets routed.
2. Reliability
Demos run once, on clean data. Production runs every day, on data that isn’t. Providers time out. Rate limits hit. A record arrives with no domain. A trigger fires on rows it should have skipped.
Failures are normal. The cost is everything you build so a failure becomes a ten-minute fix instead of a two-week mystery: retries that don’t write twice, a record of what each run did, a way to stop a runaway job, a way to replay the runs that broke.
And most GTM failures are quiet. Nothing turns red. The pipeline just gets a little worse, and nobody can say why.
3. Maintainability
Every workflow is a commitment to keep it right while the business moves. New segment, new territory, new product line, a new definition of a qualified account. The logic changes, and so does everything that reads it.
That’s manageable when the logic is readable, versioned and testable. It’s expensive when it’s spread across thirty workflows built by twelve people, each living in someone’s prompt history.
Agents don’t remove this cost. They hit a ceiling: an agent can improve a workflow inside the tools and permissions it was given. A new system, a new tool, a new scope is a change to the infrastructure, and someone on your team owns that change.
4. Opportunity cost and total cost of ownership
The real line item isn’t the model bill or the hosting. It’s whose week goes into keeping it running.
Your best RevOps person, the one who knows your ICP better than anyone, ends up debugging a sync. Your GTM engineer becomes on-call for a platform nobody planned to build. Aurélien’s calendar test in his build-vs-buy breakdown is the cleanest way I know to check: if most of the month went to upkeep, you didn’t build a GTM system. You staffed a platform team.
The real cost isn’t writing the first workflow. It’s everything your team becomes responsible for afterwards.
What does accumulated GTM infrastructure look like? #
Alma’s GTM orchestration was split across n8n, HubSpot workflows and CaptainData. When Eliott M’Barali, their AI-first GTM engineer, sat down to inventory it, the count was 40 n8n workflows, 120 HubSpot workflows and 4 to 5 CaptainData scenarios.
Nobody designed a 160-workflow system. It accumulated, one useful workflow at a time.
Alma kicked off the migration of those workflows to Cargo over a weekend, with a coding agent, and wrote it up publicly. The detail I’d underline: the agent could take on “the parts everyone on the team avoids touching”. Every stack has those parts. They are what maintenance looks like after a few years.
Now read the timeline the right way round. The coding agent made the start fast. The migration itself is scheduled through the end of 2026, because untangling what a stack has accumulated is the long part. Building was never the bottleneck.
When should you build your own GTM infrastructure? #
Sometimes, yes. I mean it.
I’ve spoken with teams that built almost their entire GTM infrastructure internally. Interestingly, their biggest challenge wasn’t building workflows. It was getting everything connected, maintaining data quality, and understanding what the agents should actually optimize for. Once that foundation was in place, they could iterate incredibly fast.
So DIY can absolutely work. Getting to that point is a serious investment. These are strong reasons to make it, and any one of them can be enough:
- Building is your culture or your product. If your company sells a builder, your team will build on it, and it should.
- Your requirements are genuinely unusual. Regulation, data residency, or an architecture no shared runtime supports.
- You already run the infrastructure. If a data platform team already runs orchestration, monitoring and on-call for other reasons, GTM is one more tenant.
- You have deep expertise, staffed for the long run. Someone whose job, not side project, is to run it.
- The economics favour it at your scale. For a single low-stakes workflow, a script may be all you need. At some volumes, owning is cheaper.
If none of these apply, ask the question that decides it: is running GTM infrastructure something you want to be better at than your competitors?
If yes, build it. If you’d rather be better at choosing accounts, qualifying them and closing them, that’s where your team’s time should go.
What should your team build, then? #
Your team should own what makes your GTM unique: your ICP, qualification logic, account intelligence, and sales strategy. Cargo handles the production infrastructure underneath, so your team can focus on improving the system rather than maintaining the plumbing.
Your GTM logic is yours. Your agents can build it. Cargo runs it.
Or our team can build and operate the systems with you.
What do you do with the time you get back? #
Improve the system. That’s the real prize, not a smaller infrastructure bill.
When the infrastructure is already there, your team’s questions change. Not “why did the sync break?” but:
- What did we learn from this month’s wins and losses?
- Which qualification rule should change?
- What should the agents do differently tomorrow?
- How fast can that change reach production, safely?
The teams that pull ahead answer those well, then get the answer into production quickly. Not the teams with the most automations. Good judgment, shipped fast: we call that System Improvement Velocity, how quickly outcomes become better GTM.
Anyone can ship version one now. The edge is how fast you get to version forty.
Build your GTM with Claude. Run it on Cargo.
See how Cargo can run your GTM infrastructure.
Prefer to build it yourself? Start with the Account Scoring cookbook: one command, cargo-ai project add cookbook/account-scoring, tiers every account against your ICP on a schedule and, if you turn it on, writes the tier back to HubSpot or Salesforce.
FAQ #
Writing the workflow is cheaper than ever. Running it is not free. An AI-built workflow still needs connected tools, credentials, a place to run, stored state, retries, monitoring, versioning and someone accountable when it fails. The fair comparison is the cost of operating the system for a year, including whose time it takes, not the cost of writing it.
Because cheaper building leads teams to build more workflows, and each one is another production system to operate, monitor, maintain and improve. Those workflows also share accounts and CRM fields, so a change in one can affect the others. The cost of building each workflow falls; the responsibility for running all of them stays with someone.
Access to the CRM, warehouse and data providers with the right permissions, fresh data, a schedule or trigger, state kept between runs, retries and rate-limit handling, a record of every run, a way to stop and replay runs, tests, and a reviewed path for changes. A demo needs none of these. A workflow reps depend on needs all of them.
When at least one strong reason applies: building software is the company’s culture or product, its requirements fit no shared runtime, it already runs the needed infrastructure for other teams, it has long-term in-house expertise to operate it, or owning is cheaper at its scale. The deciding question is whether operating GTM infrastructure is a competitive advantage for that company.
Cargo runs the production infrastructure: connectors, data storage, scheduling, execution with retries, run traces and versioned deploys from the team’s repository. The team keeps the GTM logic: the ICP, qualification and scoring rules, account context, routing and the sales motion, which its coding agents build and change. Cargo’s team can also build and operate the system with the customer.
