The call ended. Now what?
Here is something product teams rarely talk about: the most expensive moment in a B2B sales cycle is not the failed cold email or the missed demo request. It is the 48 hours after a good call where nothing happens.
The rep hangs up. They have three more calls. The notes are rough. The CRM still says "Meeting held." The follow-up email goes out two days later, generic, rushed, missing the context that made the call valuable in the first place.
We built SpurIQ to fix that specific failure. Not by reminding reps to follow up. By building an AI agent that actually owns post-call execution, the moment the call ends to the moment the next committed step is confirmed.
This post walks through the architecture decisions we made, why we made them and what we learned building it.
What "owning execution" actually means in engineering terms
Before we get into the stack, it is worth being precise about what we mean by execution ownership, because it is easy to confuse this with automation.
Automation sends a follow-up. Execution ownership decides:
- What the follow-up should say based on what was actually discussed
- When it should go based on what was committed in the call
- Who it should come from based on deal structure
- What happens next if there is no response in a defined window
The difference is consequential. Automation is a trigger-action loop. Execution ownership is a decision-making agent that holds state across the lifecycle of a deal.
That distinction shaped every architecture decision we made.
The core architecture: Event-driven, not scheduled
Our first instinct was a cron-based system. Poll the CRM every 30 minutes, check for calls that ended, kick off a follow-up pipeline. Simple to build, easy to reason about.
We scrapped it for two reasons.
First: 30-minute polling means a 30-minute average lag from call end to action. In B2B sales, that is an eternity. A prospect who just had a strong 45-minute discovery call and then hears nothing for two hours has already started doubting the purchase.
Second: CRM polling is noisy. Every CRM mutation you do not care about (field edits, internal notes, task updates) fires your pipeline. You spend more time filtering events than processing them.
We moved to a fully event-driven architecture using webhook subscriptions from the CRM layer and call intelligence platforms. The moment a call recording is marked as processed, an event fires. Our orchestrator picks it up immediately.
[Call ends]
↓
[Call intelligence platform marks recording complete]
↓
[Webhook fires → Event queue (SQS)]
↓
[Orchestrator picks up event]
↓
[Post-call execution agent initializes]
Average latency from call end to agent initialization: under 90 seconds.
The agent architecture: Three layers, not one
We tried a single large agent first. One LLM prompt, full context, single output. It was brittle. The model could not reliably separate summarization from decision-making from drafting and when one step failed, the whole output failed.
We landed on a three-layer agent architecture:
Layer 1: Extraction Agent
This agent receives the raw call transcript and pulls structured information:
- Stakeholders identified on the call
- Pain points surfaced (verbatim, not paraphrased)
- Objections raised
- Next steps committed to by the rep
- Next steps committed to by the prospect
- Timeline signals ("we need this by Q3", "our budget cycle closes in April")
- Risk signals ("we're also talking to two other vendors")
This is a focused extraction task. The prompt is tight, the output schema is strict JSON and we validate every field before passing downstream.
python
extraction_schema = {
"stakeholders": List[str],
"pain_points": List[str],
"objections": List[str],
"rep_commitments": List[str],
"prospect_commitments": List[str],
"timeline_signals": List[str],
"risk_signals": List[str]
}
Why separate this from the drafting layer? Because extraction errors compound. If the extraction agent misses a key objection, every downstream agent working from that output will produce work that ignores it. Isolating extraction lets us validate before we spend tokens drafting.
Layer 2: Decision Agent
The decision agent takes the extraction output plus CRM context (deal stage, days since last activity, contact history, existing open tasks) and makes three decisions:
What actions are required? (Follow-up email, internal Slack summary, CRM field updates, task creation, risk flag)
What is the priority order? (What needs to happen in the next 2 hours vs. next 48 hours)
Are there any escalation triggers? (Deal has gone dark before, timeline is tight, multiple competitors mentioned)
This is where the revenue execution in B2B sales intelligence lives. The decision agent is not just routing tasks, it is applying deal context to determine what execution actually looks like for this specific call at this specific stage.
Layer 3: Execution Agent
The execution agent receives the action plan and executes each item:
- Drafts the follow-up email with full call context embedded
- Writes the internal deal summary for Slack or CRM
- Creates CRM tasks with specific next-step language (not "follow up", "Send security review docs before Friday per Priya's request")
- Updates deal fields (stage, next step, close date confidence)
- Flags risk in the pipeline view if escalation triggers fired
Context management: The hard part
Here is the thing nobody warns you about when building deal-aware agents: context gets expensive fast.
A single deal might have 12 call transcripts, 40 email threads, 6 months of CRM history and notes from three different reps. You cannot feed all of that into every agent call. But you also cannot ignore it, the agent making decisions about call number 12 needs to know what was said in calls 4, 7 and 9.
We built a context assembly layer that sits between the CRM/call store and the agent layer. Before any agent call, the context assembler:
- Retrieves the full deal history
- Scores each piece of context for relevance to the current call (using a smaller, cheaper model)
- Assembles a compressed context window: recent calls in full, older calls summarized to key facts
- Appends CRM state, open tasks and stakeholder map
The compressed context fits within token limits without losing decision-relevant history. The key design principle: recency gets full fidelity, history gets structured compression.
The CRM write problem
Writing back to CRM was harder than reading from it. Every CRM has its own field structure, validation logic and update rate limits. Salesforce behaves differently from HubSpot. HubSpot behaves differently from Pipedrive.
We built a CRM adapter layer that abstracts this:
python
class CRMAdapter:
def update_deal(self, deal_id, fields: dict) -> UpdateResult
def create_task(self, deal_id, task: Task) -> TaskResult
def log_activity(self, deal_id, activity: Activity) -> ActivityResult
def flag_risk(self, deal_id, risk: RiskFlag) -> FlagResult
Each CRM has its own implementation of this interface. The AI revenue orchestration layer never talks to a CRM directly, it only talks to the adapter. This was the right call. When Salesforce deprecated an API endpoint last year, we fixed one adapter, not twelve agent workflows.
What we got wrong the first time
We let the agent write directly to CRM without a review buffer: It was fast, but reps hated it. They felt the system was changing their deals without them. We added a "pending actions" queue, agents queue their writes, reps get a one-tap approval UI and unreviewed items auto-execute after 4 hours. Adoption tripled.
We over-indexed on transcript quality: Our extraction agent fell apart when call audio was poor or transcripts had errors. We added a confidence scoring layer, if extraction confidence falls below threshold, the agent flags for human review rather than proceeding with bad data.
We treated all deals the same: A $2,000 SMB deal and a $200,000 enterprise deal should not have the same execution protocol. We added deal-tier routing, larger deals get more conservative execution with more human checkpoints, smaller deals get more aggressive automation.
The outcome worth mentioning
When we look at deals where the agent executed vs. deals where it did not (early days, inconsistent coverage), the difference in 30-day progression rates is significant enough that we do not run the comparison casually in meetings anymore. It makes the case too loudly.
The point is not that AI replaces reps. The point is that execution should not depend on rep memory, bandwidth, or consistency. Post-call execution is a system design problem. We just built the system.
Curious about how we handle the follow-up drafting at scale with real CRM context? That's the next post.
