The harness around the foundation model: what it takes to make it work for revenue teams.
1. Premise: Same model. Different harness.
A foundation model is general-purpose by construction. To make it productive at a specific kind of work, you build an effective harness around it: tools, orchestration, context, memory, skills, permissions. The harness is what turns a model into a working agent for a specific domain.
Building a harness for revenue is structurally harder than building one for software. Code is structured, deterministic, and lives in a single repository. Revenue is none of those. The signals that matter most live in calls, emails, threads, and meetings: whether the champion is engaged, whether the competitor is in the deal, whether a pricing objection is resolved or only deferred. The data is spread across a dozen disconnected systems. And the basic definitions ("ARR", "qualified", "churn") vary by organization.
What follows is the architecture built around foundation models to make them work for revenue teams.
2. Architecture: How the agent works
3. Intelligence Layer: What the agent knows about the organization
A foundation model knows what ARR means in general. It doesn't know which field stores ARR in your CRM, that your fiscal year starts in February, or that the same account appears under different names across Salesforce, Gong, and email. It doesn't know what happened on a specific deal last quarter, which of your accounts is at risk now, or how your CRO wants forecasts presented. The intelligence layer is where Von keeps the organization-specific knowledge the model can't infer from training. It has five stores of knowledge plus the retrieval pipeline that reaches them.
Knowledge graph. A canonical entity layer across systems. "Acme Corp" in Salesforce, acme.com in Gong, and "Sarah at Acme" in an email thread resolve to the same entity. The graph holds accounts, contacts, opportunities, users, aliases, and the relationships between them. It is the cross-system glue. The agent navigates within a single system directly, but only the graph ties the systems together.
Semantic layer. Organization-specific business definitions: ARR is field X, the fiscal year starts in February, "qualified" means past stage 3, "active deal" excludes certain record types. Structured facts the agent reads before generating a query. Without them, the agent writes confident SQL against the wrong fields.
Context graph. Per-deal and per-account timelines (events, trace segments, and causal links) built from calls, emails, meetings, and CRM changes. When the agent needs to know what changed between two stages or why a deal slipped, it reads the trace, not the raw transcripts.
Deal intelligence. Pre-computed insights per deal (risk signals, champion status, competitive presence, objection state, engagement trajectory) materialized as columns on the opportunity table. Behind those columns: ML-based deal-risk and churn-risk scoring models trained on historical outcomes, plus pattern mining across won-vs-lost cohorts to surface what separates the two. When a manager asks "which of my 200 accounts are at risk?", the agent reads pre-computed columns instead of reanalyzing thousands of transcripts on the fly.
Memory. Preferences, soft knowledge, and workflows that accumulate over time, scoped at the org, team, or user level. How this customer wants results presented. The way RevOps defines "pipeline coverage." A five-step workflow a manager always runs before a forecast call. Memory feeds corrections back into the rest of the intelligence layer.
Multi-stage retrieval. When the agent needs to pull specific passages from unstructured content (transcripts, emails, notes), a hybrid pipeline runs parallel text search and semantic search over indexed sources, then reranks the results with a cross-encoder for final ordering. The model sees only the relevant slice rather than every document on a deal.
4. Rebuild cost: What it would take to build this from scratch
The intelligence layer above describes what gets stored and how the agent reaches it. The engineering is everything that puts the data there and keeps it current: entity and relationship ingestion across a dozen source systems with no shared schema, per-org ontology learning, identity resolution, cross-deal pattern mining, ML scoring training and refresh, and indexing for retrieval. Around it sits durable execution, sandboxed code, and governed actions on customer systems. Each non-trivial. Each load-bearing. None of it exists in a general-purpose agent (Claude Code or Claude Cowork).
Even in the AI era, rebuilding this would still take ~6 senior engineers working full-time for 8–10 months, and that assumes the team knows exactly what to build.
5. Close: Build what differentiates
A foundation model is a general-purpose reasoning engine. Claude Code is the harness built around it for software engineering. Von is the harness built around it for revenue. The harness is real engineering work, months of it, and it does not transfer between domains.
