As I keep working through agent workflows, I am realizing that adding context is only half the problem.
The other half is deciding what the system should ignore.
That sounds less exciting than giving an agent another tool, another source, or another action it can take. But once a GTM system starts pulling from CRM data, call notes, Slack context, enrichment, warehouse fields, product usage, and source documents, the risk changes. The agent does not just need access to more information. It needs a way to know which changes deserve attention.
The judgment layer handled the action question: should the agent answer, suggest, escalate, act, or stop?
Novelty handles the attention question: what changed enough to be worth looking at before any of those decisions happen?
More signals do not automatically create better judgment. They create more places for attention to get spent.
The problem is not signal volume
A modern GTM stack can produce constant movement. A champion stops replying. Product usage drops. A hiring signal appears. A field sync changes source.
None of those changes matter equally.
A usage drop on a dormant account may be worth logging and leaving alone. The same drop on a late-stage enterprise opportunity may need review. A champion going quiet during procurement changes the operating picture immediately.
This is where the system needs an attentional layer. Not because agents are unable to read every record, but because reading every record is often the wrong operating model.
The useful agent is not the one that scans everything. It is the one that knows where the review surface should point next.
Novelty is not the same as anomaly
Anomaly usually means something is unusually far from the baseline. That matters in fraud, security, infrastructure, and many parts of data operations.
Novelty is a little different. A novel signal is not always bad. It is different enough from the expected pattern that the system should reconsider the account, opportunity, person, or workflow.
A prospect hiring a new VP of Sales might be a positive novelty. A renewal account with lower usage and unresolved support activity is a risk novelty. A CRM field that starts changing from a different sync source is an operating novelty. A competitor appearing in call notes is a positioning novelty.
The shared question is not: is something broken?
The better question is: did something change enough that the system should re-evaluate what this record means?
What changed, what matters, what can wait
A useful novelty layer has to answer three questions in order.
First: what changed? This is the raw movement across systems. A field changed, a call note was added, a score moved, a company announced funding, a contact changed roles, or an account crossed an activity threshold.
Second: does it matter in context? This is where the baseline matters. The same change has different meaning depending on segment, deal stage, account size, renewal timing, owner, product usage, and current workflow.
Third: can it wait? Some changes should be logged and watched. Some should enter a review queue. Some should escalate. Some should trigger the judgment layer because the next action may affect revenue timing, ownership, or customer communication.
That ordering matters. If the system jumps from signal to action, it skips the layer that decides whether the signal deserves attention at all.
How this changes GTM agents
A pipeline agent should not wake up every morning and reread the whole pipeline. It should ask what changed since the last review and which changes are material enough to inspect.
A renewal agent should not treat every account the same. It should watch for change patterns that alter the renewal picture: product usage down, sponsor change, unresolved support issue, pricing concern in notes, or a sudden drop in engagement before a key date.
A prospecting agent should not only run static ICP filters. It should notice when a company becomes newly relevant: hiring, funding, a leadership change, a new market expansion, or a public signal that changes the timing of outreach.
A RevOps agent should not wait for a quarterly cleanup to inspect operating drift. It can watch for sync changes, ownership changes, schema changes, permission changes, and field behavior that no longer matches the expected baseline.
The agent becomes less like a broad reader and more like an editor. It does not try to process the entire book of business. It looks for the pages that changed enough to deserve another pass.
What RevOps can build first
The first version does not need to be a complex machine-learning system. It can start as a small novelty register for the parts of the GTM motion where attention is expensive.
Pick a few entities: account, opportunity, contact, renewal, and workflow. For each one, define the baseline. What does normal movement look like? What changes are expected? Which changes are unusual but harmless? Which changes should create a review item?
Then define the routes. Ignore, watch, review, escalate. Those routes should be separate from action. A novelty score should not automatically update the CRM or trigger outreach. It should decide where attention goes next.
Over time, the rules can become more sophisticated. Thresholds can become learned. Baselines can become account-specific. Review outcomes can tune what the system treats as meaningful. But the operating principle stays the same: attention before judgment, judgment before action.
Where this goes next
The deeper I get into these builds, the more I think attention is the under-discussed constraint.
Everyone wants better context. But better context without attention routing can turn into another review burden. The system gets more capable, but the human still has to decide what matters.
Novelty detection is one way to narrow that surface. It gives the agent a reason to look. It gives the human a reason to review. And it gives the judgment layer a cleaner starting point.
The next layer is the review queue: how those novelty events become a practical operating surface for managers, RevOps, account owners, and agents without turning into another inbox.
The system should not just ask what happened. It should ask what changed enough to deserve attention.