The end of the builder-only interface

Every GTM tool you have bought makes the same assumption: the person who builds the system is the person who runs it, watches it and benefits from it, and all of that happens in one screen.

For twenty years the assumption held. Agents are breaking it.

Satya Nadella put the strong version of the argument on the BG2 podcast in December 2024. Business applications, he said, “are essentially CRUD databases with a bunch of business logic,” and “that’s probably where they’ll all collapse, right in the agent era.” The logic, in his telling, moves to the agents.

He is right that the logic is moving. He is right that a certain kind of application is on its way out. But “the interface is dead” is the wrong conclusion, and the more interesting question is one that framing never asks: once agents do the building, where do the people go?

A builder-only interface is software that assumes the person who configures a system is also the person who operates it, monitors it and acts on its results, all in the same screen. When agents build and operate GTM systems, that assumption breaks: each person reaches the system through the interface that fits their job, to direct it, observe it and govern what matters.

An earlier piece, code-first vs. UI-first, was about where the logic of a revenue system should live. This one is about the people around it: what an interface is for once an agent does the building, and why there is no longer one interface.

We built software around humans doing the work #

Think about how you set up anything in a GTM tool. You open the app. You connect the CRM and an enrichment provider. You build a segment, configure a workflow, set the conditions, click save, and watch it run.

That is the model behind the CRM, the automation builder, the enrichment table and the workflow canvas. It made complete sense: a person was responsible for building every process and running it. The screen was where the work happened, because the person at the screen was the one doing it.

The UI was designed around human execution, because humans were the execution layer.

That design had a cost nobody priced, because there was no alternative. Everyone who wanted the benefit of the system had to come to the builder’s screen. A rep got a link to a saved view inside a tool they never opened. A sales leader got a dashboard someone assembled in the same tool, or an export on Monday. The interface was built for the builder, and everyone else was a guest in it.

Agents change who operates the system #

A GTM engineer can already ask a coding agent like Claude Code or Cursor to build an enrichment workflow, add a signal to account scoring, or change how leads are routed. The agent writes the implementation directly, in code. Nobody drags a node onto a canvas.

That does not mean visual builders disappear, or that the engineering work goes away. Plenty of teams will keep building in a canvas, and the work that remains is harder, not easier: saying precisely what the system should do, and checking that what came back does it.

It does create a new requirement. A canvas is built for eyes and a mouse. An agent needs definitions it can read, commands it can call and tests it can run. If the system can only be understood through its screens, an agent can only operate the parts somebody already clicked together.

The primary builder of a GTM system is increasingly an agent. The person’s job becomes defining the intent and judging whether the implementation is correct.

The interface isn’t disappearing. Its job is changing. #

When the agent builds and runs the system, the interface stops being the place where work gets assembled. It takes on three other jobs.

Direct

“Find our highest-fit accounts showing buying activity and prioritize the right stakeholders.”

People state objectives, constraints and decisions. The interface’s job is to take that in plain words and turn it into something the system can act on, rather than asking the person to translate it into nodes, filters and field mappings first. How to write an objective an agent can actually pursue, with a number and a guardrail, is covered in give your GTM agents goals, not tasks.

Observe

“What ran yesterday? Which accounts were activated? What failed? What changed?”

A builder interface shows you the workflow you built. Once an agent builds it, what you need to see is what the system did: which records went where, why a lead landed with a given rep, what broke overnight and whether anything was fixed. The failure that hurts most in production GTM is the silent one, a rule that runs wrong on every record without throwing an error, which is why running agents in production starts with being able to trace every run.

Govern and correct

“Show me the proposed scoring change, its impact, and the evidence behind it.”

Some changes need a person. A new definition of fit, a different routing policy, a message that goes to every customer. The interface’s job is to put those in front of the right person with the evidence attached: what would change, which accounts would move, and what the test showed. Then the person approves, sends it back, or redirects the system. Approval belongs on the changes that need judgment, not on every action.

Less time configuring software. More time directing it and improving it.

One GTM system. Multiple interfaces. #

Take one engine and follow it through. Say yours does one job: decide which accounts are worth a rep’s time this week, and get each one to the right rep with a reason to engage.

The GTM engineer works in a coding agent. They ask it to add a signal to the score: the account is hiring for the team that would use your product. The agent edits the scoring logic in the repository, runs the new rule against last quarter’s accounts, and opens a pull request showing which accounts move up and which drop out. Merging it deploys the change.

The sales rep works in Slack and the CRM. On Monday morning, three accounts arrive in Slack: why each one matters this week, who to start with, and a suggested first step. The same score and the same reason sit on the account in the CRM. If a suggested contact is wrong, the rep says so in the thread, and that correction goes back to the system. The rep never opens the engine, and does not need to know its name.

The revenue leader works in a cockpit. One screen shows how much of the target market is covered, which accounts are converting and which are stalling, the exceptions that need a decision (accounts with no owner, a source that stopped sending), and the scoring change waiting for approval, with the accounts it would move.

Same system, three interfaces. The point is not that there are three screens. It is that all three read the same rule. If the rep’s Slack message says an account is a top priority because of the hiring signal, the leader’s cockpit has to say the same thing, for the same reason, using the same score. When two interfaces disagree about why an account matters, the system is broken, whichever screen is right.

The interface should adapt to the person’s job. The GTM logic underneath stays the same.

This is also where GTM infrastructure starts to become invisible. The rep did not adopt a new tool. Better accounts, with better reasons, arrived where they already work. For most of the people a revenue engine serves, the best interface is no new interface at all.

The architecture behind the new interface #

This is where Nadella’s sentence gets risky. “All the logic will reside in the AI layer,” he said. Read literally, that is how teams end up with a scoring prompt in the Slack bot, a different one in the CRM assistant and a third behind the leadership dashboard. Three interfaces, three definitions of a good account, and nobody can say which one sent last week’s leads to the wrong team.

An interface built for agents is only useful if the system underneath can actually be operated, safely, by many people and many agents at once. That takes five things:

• Unified data. Agents read the CRM, the warehouse, product usage and third-party sources as one foundation, with the same accounts and the same definitions.
• Shared business context. The ICP, the goals, the rules and the policies are written down once, where every agent and every interface reads them.
• An execution runtime. Enrichment, scoring, assignment, routing and activation run across your tools on a schedule or a trigger, with retries and rate limits handled.
• Observability and governance. Every run can be traced, and consequential changes are reviewed and approved before they ship.
• GTM as code. The definitions are versioned in git, so every change, whoever made it, has an author, a diff and a way back. Manifest, Cargo’s open-source template, organizes that repository.

You cannot make a GTM system agent-operable by putting a chat interface on top of disconnected tools. The chat window will answer confidently, and it will answer from whatever slice of the logic it can reach.

The shape of the interface matters less than what sits underneath it.

The future is not UI-less. It’s interface-independent. #

None of this is an argument against screens. Visual interfaces will stay valuable, and probably become more valuable, for the work that needs judgment: analysis, exploring data, reviewing a complex change, approving it, and understanding why an outcome happened.

They just won’t always be where the workflow gets built, or where it gets run by hand.

Part of this already works in production. Coding agents build and change GTM logic in a repository, and a change ships when it is merged. Reps receive accounts and approval requests in Slack. Teams build their own interfaces on top of the same system, like the rep-facing app in the missing layer between your CRM and your reps. Every run is traced.

The rest is direction, not something to buy today: more workflows running by exception, interfaces that surface the agent’s proposed improvements with the evidence attached, and people spending most of their time deciding rather than configuring.

The best GTM software won’t force humans and agents into the same interface. Agents will build and operate the system. Humans will direct it, observe its results, and govern what matters.

The interface becomes a place for judgment, not a prerequisite for execution.

How Cargo fits #

Cargo is built as infrastructure, not as one more application everyone has to open. The logic lives in your repository. Cargo supplies the data, the runtime and the traces underneath it, and you reach it from wherever the work happens: a coding agent through the CLI, Claude, ChatGPT or Cursor through the MCP server, Slack, or the Cargo app.

Build GTM systems your agents can operate from anywhere, with the infrastructure and governance to run them in production.

Prefer to build it yourself? Clone Manifest and run your go-to-market from Claude Code.

FAQ #