One reason AI coding works so well is that code has a built-in feedback loop.

Does it compile? Do the tests pass? Did the change do what you wanted?

The answer is not always perfect, but it is usually available quickly enough to steer the next step. AI systems improve fastest when there is a way to verify the work.

That is one of the harder problems in applying AI to go-to-market.

Revenue work looks fuzzy from the outside: calls, emails, CRM updates, handoffs, forecasts, coaching, and renewal risk. It is much more stochastic than code because it involves people. The same action produces different outcomes depending on timing, trust, budget, politics, competition, and variables you cannot observe, let alone control.

The signal is noisier. But noisy is not the same as unmeasurable.

The evidence is usually somewhere: what was said on the call, what changed in CRM, whether the buyer replied, whether the deal moved, whether the forecast improved, and whether the customer eventually renewed.

Two things make the feedback loop genuinely difficult.

First, you rarely get the counterfactual. In code, a passing test tells you that this version satisfies a defined condition. You cannot run the same deal twice, once with an intervention and once without it. A renewal eleven months from now may have been affected by fifty actions, and the customer might have renewed anyway.

Connecting an action to an outcome is therefore not only a data-plumbing problem. It is a causal one.

Second, there is not one feedback loop. There are several, operating at different speeds.

The fast signals are useful but weak: did the buyer reply, did they accept the meeting, did the next call improve? Stronger signals arrive slowly: did they sign, renew, or expand? The real design problem is reconciling fast-but-noisy evidence with slow-but-true outcomes.

This is how we think about the problem at Airspeed.

The interesting question is no longer whether AI can summarize a sales call. It can. The transformative system can say:

  • here is the evidence I used
  • here is the action I took
  • here is what happened afterward
  • here is what I learned

That is the loop.

The outcome also has to be something the system cannot quietly game. A stage change triggered by the agent is not evidence that the deal genuinely progressed. More CRM activity is not proof of more revenue. If an agent is evaluated on the proxy, it will learn the proxy.

GTM AI becomes genuinely useful when this loop is designed in from the start rather than reconstructed afterward in a dashboard. The agent needs evidence before acting, observable execution, multiple time horizons of feedback, and evaluation against an outcome that matters.

AI coding had decades of engineering infrastructure waiting for it. GTM agents need their equivalent of tests, CI, observability, and production metrics.

Building that evaluation environment may turn out to be harder, and more valuable, than building the agent itself.