April 10, 2026 • 6 min read
There is a question that every AI-powered CRM has to answer before it writes a single line of code: when should the AI think?
The industry's answer, almost universally, is: when the salesperson does something. Rep updates a deal stage? Run AI to suggest next steps. Rep sends an email? Run AI to draft a follow-up. Rep logs a call? Run AI to summarize it. Rep clicks "Analyze"? Run AI on demand.
We built Slokoto the other way around. Our AI triggers when the customer does something. Not the rep. This is the opposite approach, and it changes everything about cost, quality, and what the AI actually tells you.
The Action-Driven Trap
Think about what happens when AI triggers on rep actions.
A rep updates a deal from "Demo" to "Proposal." The CRM fires an AI call to suggest what the rep should do next. But the rep already knows what to do next - they just moved the deal to Proposal because they're about to send one. The AI is telling them what they already decided. It's a mirror, not a window.
A rep sends a follow-up email. The CRM fires an AI call to analyze the thread and recommend timing for the next touch. But the rep just wrote the email. They know what it says. They know why they sent it. The AI is summarizing the rep's own work back to them, at the cost of a credit and two seconds of latency.
A rep logs a phone call. The CRM fires an AI call to extract key points. The rep was on the call. They know the key points. They lived them.
This is like hiring an analyst to read your own memos back to you. The information is real, but the insight is zero. You already had it. You just paid someone to agree with you.
The core problem is that rep actions don't contain new information. They contain decisions - decisions the rep already made, based on information they already have. Running AI on top of a decision the human already made is the most expensive form of rubber-stamping in enterprise software.
Signals, Not Actions
Early in building Slokoto, we drew a hard line in the codebase. We defined a concept called a Signal, and we gave it a strict rule: a Signal represents something happening on the customer side. Not our actions.
This is not a guideline or a best practice. It's a type constraint. The system literally cannot classify rep behavior as a signal.
Here's what counts as a signal:
An inbound message - the customer replied to your email. Now there is genuinely new information. What did they say? What do they want? Are they interested or pushing back? This is ambiguous. This requires interpretation. This is what AI is good at.
An inbound call or a missed call - the customer picked up the phone or tried to reach you. Something changed on their end. They have a question, a concern, or a decision.
A form submission - a prospect filled out a contact form on your website. A new person just raised their hand.
A page view or a link click - behavioral signals showing where the customer's attention is going. They looked at pricing. They downloaded the spec sheet. These are intent signals that the rep doesn't have visibility into.
Here's what is explicitly not a signal:
An outbound message - the rep sent an email. They know what it says. Deprecated as a signal type in our codebase.
An outbound call - the rep made the call. They were on it. Deprecated.
A CRM field update by a rep - the rep changed a dropdown. They know the new value.
None of these generate AI events. None of them cost credits. None of them add latency. The system sees them, logs them for context, and moves on.
Why This Is the Right Default
Three reasons.
AI's job is to interpret the unknown. When a customer sends an email, you need to decode their intent. Are they interested? Stalling? Ready to buy? Raising an objection disguised as a question? This is genuinely hard. A language model reading the thread can surface patterns and implications that a busy rep might miss. That's real value.
When a rep sends an email, there is nothing to decode. The rep wrote it. They know the intent. It's their intent. Running AI on the rep's own output is solving a problem that doesn't exist.
Fresh input produces better output. Every AI call in Slokoto is triggered by new customer data. The model is never re-analyzing stale information or rubber-stamping a decision the rep already made. This is why the recommendations feel sharp - they're always responding to the latest thing the customer did. The signal is fresh. The analysis is relevant. The suggested action maps to the current state of the conversation, not the state from three days ago when the rep last clicked a button.
The customer is the bottleneck, not the rep. Sales velocity is determined by how fast the customer moves through their buying process. How quickly they reply. Whether they engage with your proposal. If they show up to the demo. Triggering AI on rep actions optimizes the wrong side of the equation - it's like speeding up the pitcher when the batter hasn't stepped up to the plate. Triggering AI on customer signals means the system is always focused on the constraint that actually matters: what the buyer is doing, thinking, and signaling.
In Practice
Here's how this plays out with email, the most common signal source.
Gmail sync runs continuously in the background. When it picks up new messages on a thread, it checks one thing: who sent the last message?
If the customer sent the last message, the lead gets flagged as "inbound pending" and an AI event is enqueued at priority one. This is the highest priority in the system. A customer just said something. The AI needs to read it, understand it, and recommend what the rep should do.
If the rep sent the last message, the system notes it for thread context but does not trigger AI reasoning. The rep knows what they said. No analysis needed. The lead stays in its current state - usually "waiting for reply" with a follow-up timer ticking.
The event queue deduplicates per lead, so if a customer fires off three emails in quick succession, the AI processes them as a single batch. No wasted calls on intermediate messages that will be superseded by the next one.
In a previous post, we covered the five gates that filter leads before AI runs - acknowledgment detection, thread caching, CRM webhook filtering, bounce handling, and deterministic timing. But those gates only matter because of a more fundamental decision: AI only fires when the customer does something. The gates are the implementation. The signal architecture is the philosophy.
The Numbers
Based on our production data, signal-driven architecture combined with the filtering gates eliminates 40-60% of AI calls that a traditional action-driven system would make. Each eliminated call saves two to four seconds of processing latency and a credit.
But the real story isn't cost savings. It's quality.
When every AI credit goes toward analyzing genuine new customer information, the output is better. The recommendations are more relevant. The draft replies actually respond to what the customer said, not to what the rep did three hours ago. The urgency signals reflect the customer's behavior, not the rep's CRM hygiene.
You don't get better AI by calling it more. You get better AI by calling it on the right inputs. Customer signals are the right inputs. Everything else is noise you're paying to process.
The next time your CRM charges you a credit because your rep updated a dropdown, ask yourself: who was that AI call for?
The rep already knew the answer. The AI just agreed with them. Expensively.
Customer signals are the only source of genuinely new information in a sales process. Build your AI around them, or build a very expensive echo chamber.
This is part of a series on building AI-native sales software. Previously: The AI That Knows When to Shut Up - the five gates that filter leads before AI runs. Also: AI Credits: The Greatest Markup Since Movie Theater Popcorn - why your CRM charges 400x the actual cost of an AI call.