Build an AI Sales Research Agent: Architecture, Freshness Strategy and Cost Per Brief (2026)

What is an AI sales research agent, architecturally?

A planner, a parallel fan-out over six to ten sources behind a per-source freshness cache, a conflict-reconciliation step, and a citation-checked brief generator. It is a retrieval and verification system with a little agency at the front, not a conversational agent. Building it as a chat loop is the most common way teams make it slow, expensive and wrong.

The product is narrow and that is its strength. Thirty minutes before a discovery call, a rep receives a one-page brief: what the company does, what changed in the last ninety days, who is on the call and what they own, what our CRM already knows about this account, what the product telemetry says if they are an existing customer, and three talking points explicitly marked as inference rather than fact. That is the whole surface area.

This is a reference design: how I would build it and what the arithmetic says it costs. It draws on architecting AccioMatrix, an event-driven platform orchestrating multiple LLMs, agents and MCP tooling for 20+ enterprise clients, but I have not shipped a sales research agent in production, and nothing below is an invoice. It is a model with its inputs printed.

The architectural shape differs from a support agent in one decisive way. A support agent is sequential because each tool result changes what it should do next. A research agent is overwhelmingly parallel: it knows on turn one which sources it wants, and it should hit all of them at once. Getting that right takes a nine-source brief from roughly 45 seconds to roughly 9, and the cost is identical. Anyone building this as a sequential agent loop is paying a latency tax for no benefit.

The second difference: freshness is a first-class architectural concern, not a caching optimisation. In support, a document is either current or it is not. In sales research, every fact has its own half-life. A company's headquarters is stable for years, its headcount for a quarter, its funding status for hours after an announcement. A single TTL cannot serve them all, and the table that assigns a TTL per source matters more to output quality than any model choice you will make.

What does the full architecture look like?

Twelve components in four columns: triggers and resolution, planning and parallel fan-out, the MCP tool surface, and reconciliation, synthesis and delivery. The freshness cache sits underneath the fan-out rather than beside it, because every source call goes through it and roughly 57% of them never leave the building.

Start at the trigger, because it determines your latency budget and therefore your whole design. A calendar-driven brief fires thirty minutes before a meeting and can take three minutes to build, so you can be thorough, use slower sources and retry generously. A rep clicking research this account in the CRM is waiting, and the budget is under twelve seconds. Same components, different systems. Build the scheduled one first: it is more useful, cheaper per brief because it can batch, and far easier to get right.

Account resolution carries the most risk per line of code. Domain-to-CRM matching is deterministic and correct. Falling back to a model to disambiguate two similarly named companies is where briefs go catastrophically wrong, because every subsequent fact is confidently about the wrong organisation and nothing downstream catches it. On ambiguity, stop and ask. The engineering is a confidence score with a refusal threshold. A research agent that refuses one brief in fifty is a good research agent.

The fan-out layer is where the parallelism lives and where per-source timeouts are non-negotiable. Nine sources called concurrently with a four-second timeout each produce a brief in about nine seconds with occasional gaps. Nine with no timeout produce a brief whose latency equals the slowest external service on the internet that day. Mark missing sources explicitly. A brief that says no recent news found, checked at 09:14 is honest and useful; one that quietly omits the section teaches the rep nothing about what was not checked.

The MCP surface splits into three groups with very different trust properties. CRM and product telemetry are yours: authoritative, cheap, safe to trust. Enrichment APIs are commercial data of variable accuracy. Clearbit's standalone product no longer exists as such, folded into HubSpot as Breeze Intelligence, itself a lesson about depending on a single enrichment vendor. Web content is untrusted input that reaches your model, so prompt-injection defence at ingestion is a requirement, not a nicety. The gateway pattern that handles all three is in MCP in production.

What happens when one brief is generated, end to end?

Trigger, resolve, plan, nine parallel source calls of which five hit cache, extract and summarise the fresh pages, reconcile conflicts, synthesise a typed brief, verify every claim against its source, deliver. About nine seconds wall clock on the parallel path, four model calls, 22.6 cents cold.

The step to watch is extraction. Twelve fetched pages at roughly 2,000 tokens each is 24,000 tokens, and dumping all of it into the synthesis context is the naive design that makes this product expensive and worse. Map-reduce instead: summarise each page independently on a cheap model against the specific question the plan assigned it, then synthesise from the summaries. That turns 24,000 tokens of raw page content into about 3,000 tokens of targeted summary for roughly 2.9 cents, and it improves the output because synthesis is no longer reading boilerplate navigation menus.

The synthesis call is the only expensive model call in the pipeline, at 4.5 cents of a 22.6-cent brief. Spend model quality here and nowhere else. Extraction, verification and reconciliation all run acceptably on a Haiku- or Flash-class model. The step that has to hold nine sources in mind, notice that two disagree and write something a human will act on is the one that justifies a Sonnet-class model. That asymmetry is the whole routing policy, and the general machinery is in LLM routing and caching, cost per request.

Verification runs after synthesis and is allowed to delete. A claim whose quoted span cannot be found in the fetched source text is removed, and the brief notes that a claim was dropped. It is tempting to soften instead, to rewrite the claim as reportedly or according to some sources, and that is precisely wrong, because a hedged sentence in a sales brief still ends up in the rep's mouth on the call. Drop it.

How do you keep the brief fresh without paying for every fact every time?

With a TTL per source rather than a TTL per cache. Firmographics are true for thirty days. A tech-stack signal is true for fourteen. Job postings shift weekly. Funding announcements and executive changes are wrong within hours of breaking. One table assigning a half-life to each source is the difference between a 9.8-cent brief and a 22.6-cent one, and between a fresh brief and an embarrassing one.

The mechanism is simple and the discipline is not. Cache the value with the timestamp it was retrieved at and the source it came from, then let each source declare its own TTL. On a cache hit, the brief still prints the retrieval date next to the fact (as of 12 August, headcount was approximately 340), which converts a staleness risk into an honest statement. A rep who can see a number is twelve days old handles it correctly. A rep reading an undated number will not.

Two refinements earn their keep quickly. First, event-driven invalidation: if a news search returns a funding or acquisition story for an entity, invalidate that entity's firmographic cache immediately rather than waiting thirty days, because headcount and valuation just changed. Second, a warm-ahead job: for accounts with a meeting in the next seven days, refresh the slow, expensive sources overnight in batch, so the T-30 brief is nearly all cache hits. Batch inference bills at roughly half interactive rates on the major providers, which makes warm-ahead cheaper per fact as well as faster.

The chart below is the argument for doing this properly. Sweeping a single global TTL from one hour to ninety days moves cost per brief from about 22.6 cents to about 9.5 cents while the modelled stale-fact rate rises from well under 1% to roughly 26%. No setting on that curve is right for all sources, which is exactly why the per-source table exists. You want one-hour behaviour for funding news and thirty-day behaviour for headquarters, and a global setting forces you to pick one and be wrong about the other.

One caveat about the stale-fact curve: those percentages are a model, derived from plausible change rates per source class, not a measurement. The shape is robust (fast-moving sources decay quickly, slow ones do not) but the exact numbers depend on your account mix. An agent researching Series A startups faces a much steeper curve than one researching listed enterprises. Measure your own before quoting anyone else's.

export type SourceId =
  | "crm.account"
  | "crm.notes"
  | "product.telemetry"
  | "billing.state"
  | "enrich.firmographics"
  | "enrich.techstack"
  | "web.news"
  | "web.funding"
  | "web.jobs"
  | "web.exec_changes";

type SourcePolicy = {
  ttlSeconds: number;
  /** higher wins when two sources disagree about the same field */
  precedence: number;
  /** roughly what one cold call costs, in USD */
  coldCostUsd: number;
  /** other caches to blow away when this source returns a hit */
  invalidatesOnEvent?: SourceId[];
};

const HOUR = 3600;
const DAY = 24 * HOUR;

export const SOURCE_POLICY: Record<SourceId, SourcePolicy> = {
  "crm.account":          { ttlSeconds: 5 * 60,  precedence: 100, coldCostUsd: 0.0000 },
  "crm.notes":            { ttlSeconds: 5 * 60,  precedence: 100, coldCostUsd: 0.0000 },
  "product.telemetry":    { ttlSeconds: 1 * HOUR, precedence: 100, coldCostUsd: 0.0000 },
  "billing.state":        { ttlSeconds: 15 * 60, precedence: 100, coldCostUsd: 0.0000 },
  "enrich.firmographics": { ttlSeconds: 30 * DAY, precedence: 60,  coldCostUsd: 0.0800 },
  "enrich.techstack":     { ttlSeconds: 14 * DAY, precedence: 50,  coldCostUsd: 0.0000 },
  "web.news":             { ttlSeconds: 6 * HOUR, precedence: 70,  coldCostUsd: 0.0140 },
  "web.funding":          { ttlSeconds: 2 * HOUR, precedence: 80,  coldCostUsd: 0.0140,
                            invalidatesOnEvent: ["enrich.firmographics"] },
  "web.jobs":             { ttlSeconds: 7 * DAY,  precedence: 40,  coldCostUsd: 0.0070 },
  "web.exec_changes":     { ttlSeconds: 12 * HOUR, precedence: 75, coldCostUsd: 0.0140,
                            invalidatesOnEvent: ["crm.notes"] },
};

export type Cached<T> = { value: T; retrievedAt: string; source: SourceId };

export function isFresh(entry: Cached<unknown>, now = Date.now()): boolean {
  const age = (now - Date.parse(entry.retrievedAt)) / 1000;
  return age < SOURCE_POLICY[entry.source].ttlSeconds;
}

/** Facts are always rendered with their age. Never print an undated number. */
export function renderFact(label: string, value: string, e: Cached<unknown>): string {
  const days = Math.floor((Date.now() - Date.parse(e.retrievedAt)) / 86400000);
  const age = days === 0 ? "today" : days === 1 ? "yesterday" : days + " days ago";
  return label + ": " + value + " (source: " + e.source + ", checked " + age + ")";
}

How do you stop the brief from making things up?

By making the brief a typed data structure rather than prose, requiring every claim to carry a source URL, a retrieval timestamp and a quoted span, and deleting any claim whose span cannot be found in the fetched source. Inference is allowed but must be labelled as inference and must reference the claims it rests on.

The structural decision does the work. If the output is a paragraph, there is nothing to verify; you would be grading prose with prose. If the output is a list of claims, each with a field pointing at the exact sentence in the exact document that supports it, verification becomes a substring match: deterministic, free and impossible to argue with. Same discipline as citation-span validation in a support answer, applied to a document with twenty-four claims instead of three.

Separating fact from inference is the second half. A brief is genuinely more useful when it says they posted eight SRE roles in the last month and are likely investing in reliability, but those are two different kinds of sentence. The first is a claim with a URL. The second is an inference with no source, and it must render differently so a rep never reads an inference aloud as a fact. Enforce it in the schema, not the prompt: inferences live in a different array with a different required shape and a mandatory list of the claim ids they depend on.

The third mechanism is a refusal path with teeth. If fewer than a threshold number of claims survive verification, do not deliver a brief. Deliver a note: the agent could not find enough verifiable information about this account, here is what it checked, and here are the two questions worth asking on the call. Reps trust that behaviour and it is cheap to build. What destroys trust permanently is a brief that pads a thin account with generic industry commentary, because the rep discovers the padding on the call.

None of this requires a smarter model. It requires an output schema, a substring matcher and the discipline to delete. That is roughly 300 lines of code, and it is the difference between a research agent and an expensive text generator.

import { z } from "zod";

export const ClaimSchema = z.object({
  id: z.string(),
  text: z.string().min(1),
  source_url: z.string().url(),
  source_id: z.string(),
  retrieved_at: z.string().datetime(),
  quoted_span: z.string().min(20),
  category: z.enum([
    "company", "funding", "people", "hiring",
    "tech", "usage", "relationship", "news",
  ]),
});

export const InferenceSchema = z.object({
  text: z.string().min(1),
  confidence: z.enum(["low", "medium", "high"]),
  /** an inference with no supporting claims is not shippable */
  based_on: z.array(z.string()).min(1),
});

export const BriefSchema = z.object({
  account_id: z.string(),
  generated_at: z.string().datetime(),
  claims: z.array(ClaimSchema),
  inferences: z.array(InferenceSchema),
  open_questions: z.array(z.string()).max(5),
  sources_checked: z.array(z.object({
    source_id: z.string(),
    status: z.enum(["hit", "miss", "timeout", "error", "cached"]),
    checked_at: z.string().datetime(),
  })),
});

export type Brief = z.infer<typeof BriefSchema>;

const MIN_VERIFIED_CLAIMS = 6;

export function verifyBrief(
  brief: Brief,
  sourceText: Map<string, string>,
): { brief: Brief; dropped: string[]; deliverable: boolean } {
  const dropped: string[] = [];

  const claims = brief.claims.filter((c) => {
    const body = sourceText.get(c.source_id);
    if (!body) { dropped.push(c.id); return false; }
    const ok = norm(body).includes(norm(c.quoted_span));
    if (!ok) dropped.push(c.id);
    return ok;
  });

  const keptIds = new Set(claims.map((c) => c.id));
  // an inference loses its support when the claim under it is dropped
  const inferences = brief.inferences.filter(
    (i) => i.based_on.every((id) => keptIds.has(id)),
  );

  return {
    brief: { ...brief, claims, inferences },
    dropped,
    deliverable: claims.length >= MIN_VERIFIED_CLAIMS,
  };
}

function norm(s: string): string {
  return s.toLowerCase().replace(/[^a-z0-9 ]+/g, " ").replace(/\s+/g, " ").trim();
}

What does one brief cost?

About 22.6 cents cold and 9.8 cents warm, against roughly $11 of account executive time it displaces. At 500 briefs a month with 55% warm, the running cost is under $80. This is the rare AI product where the unit economics are not the interesting problem, which is precisely why the engineering attention belongs on freshness and verification instead.

The composition is worth internalising because it is unlike the support agent. There, 90% of the cost was agent turns. Here, the single synthesis call is 20% of the bill, the enrichment API call is 35%, search and extraction together are 31%, and everything else is noise. The dominant line is a third-party API, not a model, so the cost lever is the cache TTL table, not model selection. Halving the enrichment call rate with a thirty-day firmographic TTL saves more than switching the synthesis model to a cheaper tier, and it does not degrade the output.

The comparison that actually gets this funded is the human one. A rep doing thorough pre-call research on an unfamiliar account spends fifteen to thirty minutes across a CRM, a website, LinkedIn and a news search. Model that at 25 minutes and $45/hour fully loaded and it is $18.75 of time, of which a good brief plausibly displaces 15 minutes, or about $11.25. At 500 briefs a month that is roughly $5,600 of recovered selling time against under $80 of running cost.

Be careful with that number in front of a CFO, because recovered time is not recovered money unless the rep does something else with it. The brief converts unstructured preparation into structured preparation, and its real effect shows up as more calls prepared for at all, not as headcount reduction. Reps skip preparation under pipeline pressure; a brief that arrives automatically is prepared-for by default. That is the actual value, and it is harder to put on a slide.

Build cost is roughly six engineer-weeks for a two-person team, which at typical blended rates is the dominant number in the first year. The running cost is a rounding error against it. The break-even question is not build-versus-buy but build-versus-nothing, and it turns on whether your reps would actually read the brief. Ship it into Slack thirty minutes before the meeting, measure the open rate for two weeks, and let that decide.

What breaks in production, and how would you know?

Nine things, and the worst is the quietest. An agent that resolves acme.io to the wrong Acme produces a fluent, well-cited, entirely irrelevant brief, and every downstream check passes because the claims genuinely are supported by their sources. They are just sources about a different company. No error rate moves. A rep finds out live.

That failure has a specific fix and it is not a better model. It is a confidence score on resolution with a refusal threshold, plus one deterministic cross-check: the resolved entity's domain must appear in the CRM record, or the run stops. Cross-checking the resolved company name against the meeting attendees' email domains catches almost all the rest for free.

The second-worst is staleness, and it is hard because it is invisible in every offline eval. A brief generated from a thirty-day-old cache passes verification perfectly, because the quoted spans really do appear in the sources fetched a month ago. The only defence is printing the age of every fact and alerting on the age distribution. If the median fact age in delivered briefs drifts above a threshold, your warm-ahead job is broken or your TTLs are too generous.

Then two failure modes that are legal, not technical. Scraping profile data from platforms whose terms prohibit it is a real risk that teams route around with a commercial enrichment vendor, which moves the liability but does not remove the obligation to know what you store. And processing personal data about EU individuals for sales outreach requires a lawful basis and, in practice, a defensible retention policy. Neither is a reason not to build this. Both are reasons to have the conversation before the pipeline is written, not after a request arrives.

Four signals catch most of the rest: resolution confidence distribution, median fact age in delivered briefs, claim drop rate at verification, and the rep-facing was-this-useful signal. The last is the only direct measure of whether the product works and it costs one button. A brief nobody opens is a brief that failed, and open rate is available on day one without any eval infrastructure.

“A brief that says I could not confirm enough about this account, here are the two questions worth asking is worth more than a confident brief about the wrong company, and costs a fraction of a cent instead of twenty-three.”— The design principle the refusal path exists to enforce

What does it take to build, and what should you skip?

About six engineer-weeks for a two-person team to a production v1, plus two engineer-days a month of maintenance. Skip the planner, skip multi-agent, skip a vector database, and skip anything that reads a platform's data against its terms. What you cannot skip is the resolver, the TTL table and the verifier.

Week one is the resolver and the journal, and the resolver deserves a full week on its own. Deterministic domain matching, CRM lookup, a confidence score, the refusal path, and a test set of genuinely hard cases: subsidiaries, rebrands, companies with the same name in different countries, and the personal-email attendee whose domain tells you nothing. Every hour here pays back in the failure mode no downstream check catches.

Weeks two and three are the source adapters and the freshness cache. Nine adapters behind one interface, each declaring its TTL, precedence and cold cost, the cache storing values alongside retrieval timestamps. Build the four internal adapters first even though they are less exciting: CRM, notes, telemetry and billing are free, authoritative and the only sources your competitor cannot also buy. Week four is fan-out with per-source timeouts and partial results, plus the map-reduce extraction step.

Week five is synthesis and verification: the typed brief schema, span matching, the fact-versus-inference split and the refusal threshold. Week six is delivery, feedback instrumentation and the warm-ahead batch job. That last item is a half-day that halves your cost per brief and takes several seconds off the p99, and it is nearly always deferred because it does not appear in the demo.

On skipping: the planner is the easiest cut. A fixed plan (always hit these nine sources, always ask these questions) produces briefs almost as good as a planned run, removes a model call and removes an entire class of failure where the planner decides not to check something important. Add planning when you have evidence that different account types need genuinely different research, a real thing but not a v1 thing. Multi-agent is the second cut, for the reasons in multi-agent versus single agent: parallel fan-out over typed adapters is not multi-agent and does not need an agent framework. And for the general pattern for compressing a build like this, building an MVP in days with AI covers the scoping discipline; the ongoing architecture work is what AI product development is for.