AI can act on more buyer signals than ever. That makes disconnected data a much
About 60 days after joining a new company, I asked one of our existing vendors to show me how we were using its product.
The customer success team scheduled what they assumed would be an onboarding call. That made sense based on the information directly in front of them: I was a new executive at an existing customer.
What they didn’t appear to know was that I had used the same product at two previous companies. At one, I had been an early champion. I spoke on the vendor’s webinars and served as a customer reference. Later, I became dissatisfied and made the decision to leave.
By the time I joined my new company, there was a meaningful history between me and that vendor. The team had several pieces of it somewhere: my job change, my previous relationship with the company, my advocacy, the prior churn, and the reasons behind it.
None of that made it into the conversation.
They came prepared to teach me the product. I came prepared to decide whether we should keep it.
This type of miss is often treated as a sales or customer success problem. I see it as a product and system design problem. The people on the call were working with the information available to them. The larger issue was that the company could identify a signal (a new executive had joined an account) without connecting it to the history that would explain not just what the signal meant, but what to do as a result.
That distinction matters more as AI becomes part of go-to-market work. AI gives teams the ability to process more signals and act on them faster than people ever could. But access to more information does not mean the system understands what that information means or what to do with it. Without the history and relationships around a signal, AI can turn incomplete understanding into action that looks far more certain than it should.
AI changes the cost of getting it wrong
Disconnected data is not a new problem. Marketing, sales, and customer success have worked from different systems for years.
The result is that marketing may see campaign engagement, but not the support history. Sales may know that an account is researching a topic, but not that its budget was recently cut. Customer success may see product adoption, but have no idea that the executive sponsor just left or that another division is evaluating a competing product.
People have always compensated for those disconnects by asking a colleague, searching the CRM, checking a spreadsheet, or relying on someone who remembers the account history.
That process is inefficient, but it sometimes creates a useful checkpoint. Someone notices that the information does not add up. They ask whether the account is really in market, whether the contact is still in the role or whether the recommended action makes sense given what happened six months earlier.
Once an agent can draft the email, add the contact to a campaign, and trigger a workflow in seconds, that checkpoint may disappear. The organization is then relying on the system to recognize what an experienced person might have questioned.
An agent can act on a job-change signal immediately and carry that decision into multiple systems. If the title is wrong, the relationship history is missing, or the person previously churned your product, the mistake will not necessarily remain confined to one poorly timed email.
The AI did not create the underlying mistake. It exposed how much the organization had been depending on people to fill in missing context.
Why adding another signal does not solve the problem
Most GTM teams do not lack data. They have CRM records, product usage, website activity, intent data, support tickets, campaign engagement, conversation intelligence, third-party enrichment, and information gathered directly by sellers and customer success managers.
The harder problem is determining when all of those records refer to the same company, person or buying group, and preserving that connection as information moves between systems.
In nearly every business I have worked in, teams have struggled to maintain a consistent customer identifier or even a consistent definition of the customer across platforms.
One system treats a subsidiary as its own account, while another rolls it into the parent company. One contact has changed jobs but remains attached to the former employer. Anonymous web activity sits apart from known engagement. Product, sales, and marketing each have a partial version of the relationship.
Adding more feeds to that environment can make the problem harder. The organization gains more facts but still cannot reliably determine which facts belong together.
That is why I do not define context as another enrichment field. Context comes from the relationships among the information:
- Who is this person?
- What role do they hold?
- Which account and buying group are they part of?
- What has the company already done with them?
- What changed recently?
- How have they responded in the past?
- What happened after the last action we took?
No single signal answers those questions. The meaning emerges when identity, history, engagement, and outcomes are connected.
The system should carry the history
I don’t think the solution is to force every GTM team into one application. It is also unrealistic to wait for a perfect, universal customer record before improving how decisions are made.
The more practical requirement is a shared identity and relationship layer that can move with the information into the systems where people and agents work.
Consider the vendor call I described earlier. The customer success team did not need every piece of data the company had ever collected about me. They needed a small number of connected facts:
- I had recently joined the account as the executive responsible for the product.
- I had been a customer and advocate at a previous company.
- I had later made the decision to churn.
- The reason for that decision was relevant to the current account.
With those facts, the call would have been completely different. The team could have acknowledged the history, asked what had changed, and addressed the issue that had caused the earlier relationship to fail. They might have identified a retention risk. They might also have found an expansion opportunity.
Instead, the context lived in separate places, so the team started from zero.
A well-designed system should reduce how often that happens. It should also let the user understand how it reached a conclusion.
If a system says an account is likely to buy, a seller should be able to see why. If it identifies a person as part of the buying group, the user should be able to understand the match. If an agent recommends an action, the organization should be able to trace which information shaped that recommendation.
That visibility is important because no system will be perfect. Trust does not mean assuming every output is correct. It means giving people enough information to evaluate the output, a clear way to intervene when the stakes justify it, and a record of how the system reached its decision.
Guardrails should match the consequence
Not every agent action needs the same level of autonomy, because not every mistake carries the same cost.
A recommendation to a seller (say, that an account is showing renewed intent) can move with very little friction. If it’s wrong, someone loses a few seconds. An action that reaches a customer, changes a system of record, or carries a financial consequence should meet a higher bar.
That may mean setting confidence thresholds so the agent acts independently only when the evidence is strong enough, and routes lower-confidence cases to a person. It may mean requiring approval before an email is sent, a contact is added to a campaign, or a case is escalated.
This is not very different from how a good manager develops a new rep. You allow more independence where the downside is small, and you stay closer to decisions where a bad call could damage a customer relationship, change important data, or cost the business money.
Earlier, I described the pauses people create today (checking the CRM, asking a colleague, questioning whether the recommended action makes sense) as inefficient but useful. Guardrails deliberately preserve some of that friction.
And that’s the point: keep the checkpoint where being wrong is expensive, without forcing the same process onto every low-stakes recommendation.
The audit log should explain the decision
Guardrails determine what an agent is allowed to do in the moment. The audit log answers the question afterward: Why did it do that?
If an agent decided I was a re-engagement opportunity rather than a churn risk, someone should be able to trace the information behind that choice. Which signals did it weigh? Which parts of my history did it use? What was missing?
That traceability is much easier and less expensive to build in from the start than to reconstruct after something has gone wrong. By then, a customer may be asking why they received a message, an executive may be questioning a recommendation, or an auditor may want to understand how a decision was made.
The onboarding call I described earlier illustrates the same cost asymmetry. The facts existed, but once the call went wrong, someone would have had to reconstruct what the team knew, what it missed, and why it treated me as a new user. That is slower and less reliable than preserving the information behind the decision from the start.
Logging should also reflect the consequence of the action. A recommendation that a seller may or may not review does not need the same decision record as an action that changes customer data or sends a message externally. Treating every action as equally consequential would recreate unnecessary friction in another form.
As an agent gains autonomy, its decision record should become more complete, especially when a mistake could affect a customer, alter important data, or cost the business money.
Start with the decisions, not the AI feature
That work begins with the decisions the organization wants AI to make. Before adding another agent or automating another workflow, leaders should choose a few important GTM decisions and trace what currently informs them.
Take a decision such as whether to pursue an account, expand a customer, or intervene in a renewal:
- Which systems contribute information?
- Where is identity resolved?
- Which team holds useful history that the others cannot see?
- What gets lost when the account moves from marketing to sales or from sales to
- customer success?
- Could a user explain why the system recommended the action?
That exercise usually reveals the same issue: the organization has collected plenty ofinformation, but the relationships among it were never designed to survive across the customer journey.
AI will make that design problem harder to ignore. As more actions happen automatically, companies will have fewer opportunities for an experienced person to notice that the story is incomplete.
AI will allow every GTM team to do more and move faster. The leadership question is whether the systems behind that work understand enough about the customer to choose the right action. Otherwise, organizations will automate decisions before they have earned the confidence with which those decisions are made.
