Building an AI Agent That Owns Post-Call Execution: Architecture Decisions

SpurIQ Engineering — Wed, 29 Apr 2026 19:43:19 +0000

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.

DEV Community: SpurIQ Engineering