The context graph and the semantic layer are the infrastructure every agent runs on. Build them and the
whole catalog opens up at once. Skip them and you get impressive demos that never survive contact with
your pipeline — and a team that concludes AI doesn't work here.
Presented byAnthony Enrico
&Jake Toepel
LeanScaleGo-to-market operations
Session45 minutes
What we'll cover
Forty-five minutes, five sections.
01
Why this is importantYou have already bought a go-to-market machine, and its entire output is two numbers.
What one point and one day are actually worth. No AI in this section at all.
02
What this actually isThe semantic layer and the context graph, defined properly. The architecture mistake almost
everyone makes — and an honest read on where you sit today.
03
The art of the possibleTwenty agents across sales, marketing, customer success and RevOps that become buildable once
those two layers exist. Eight of them run against our own book today.
04
How you deploy itTen weeks, five roles, thirty definitions — and the five ways this goes wrong, all of which
are avoidable.
05
A reminder why this is importantWhat the whole portfolio is worth in dollars, over three years — and the three things you can
start on Monday without budget.
↓
And a giveaway — stay for the last slide.
One QR code, five things, all free and none of it gated. Four you download, and one
we run with you at no charge through the Updata partnership.
This deckA metric definition worksheetTen prebuilt agentsA key to our knowledge baseA free GTM diagnostic
The question this deck is about
Which of my customers are likely to expand this quarter?
An ordinary question. Ask it in your business on Monday and see how long the answer takes,
who has to be involved, and whether two people give you the same one.
The picture to hold onto
More horsepower will not draw you a map.
What you rent
The model
A Formula One engine, improving every quarter on somebody else's roadmap.
You and your closest competitor rent the same one — and nobody here has a horsepower
problem.
What is missing
Your data model
The course, the corner ahead, the line that won the last ten races. Nobody sells you
this one — and without it the car simply reaches the same corner faster.
He cannot answer. Not because he isn't clever enough — because nothing in your business
is in a form he can read. He would need someone to tell him what qualified means here, which of
the six Acme records is the real one, and where the calls are kept.
Intelligence was never the bottleneck. Access was.
One more picture
Now picture a relay with two legs.
Leg one
The fastest runner alive
This is the model. Already world-class, already getting faster —
on somebody else's training plan, and your competitor has him too.
Leg two
A toddler
This is your data model. It decides the race — and it is the only leg on the
track you are allowed to coach.
Leg oneAlready solved
Leg two — where the entire race is decidedThe only leg you can coach
You do not win this by making the fast runner faster. You win it by addressing the toddler.
01
SECTION 01
Why this is important.
Start with what you're actually optimizing. You have already bought a go-to-market machine, and its
entire output is how often you win and how long it takes. Then the harder question:
why can't you simply buy an AI tool and move those two numbers? Because every one of them requires the
machine to know things about your business that it currently does not know in any addressable form.
The two numbersWhat one point is worthThe compounding gridOne of two thingsThe ceiling
The measurement
Yield has exactly two numbers.
Not pipeline coverage. Not activity. Not seats of anything. If go-to-market operations is
working, it shows up in two places and nowhere else — and both are measured on the same stage boundary:
SQL to Closed-Won.
Conversion rate
How often you win
The percentage of qualified opportunities that become customers. Moved by who you put in
front of reps, whether the right people are in the room, and whether anyone catches a deal
going sideways in time to act.
Time in stage
How long it takes
Days from qualification to signature. Moved by speed to first touch, how fast paper
moves, and how much of a rep's week is spent assembling context instead of selling.
Deliberately excluded — deal size. Packaging and market move ACV far more than operations does.
Let it flex and the model produces whatever answer you want.
Deliberately excluded — retention. Mostly product. And reporting it properly needs revenue
recognition infrastructure most companies at this stage don't have.
The unit economics of yield
On a $20M plan, this is what one unit is worth.
$1.0M
Per point of conversion rate
Moving SQL→Won from 20% to 21%, holding everything else constant. Five points is
$5M — on the pipeline you already generated.
$225K
Per day off the sales cycle
Taking the cycle from 90 days to 89. Ten days is $2.5M. A single week of
dead time in legal review is roughly $1.6M a year.
These are not efficiency numbers. Nobody's headcount changed, nobody's
price changed, and no additional pipeline was generated. This is the same machine, running at a higher
yield.
The compounding effect
Small movements, multiplied against each other.
Bookings on a $20M plan, starting from a 20% SQL→Won rate and a 90-day
cycle. Both levers are multipliers on the same base, so they don't add — they compound.
90-day cycle
85 days
80 days
75 days
20% win rate
$20.0Mtoday
$21.2M+1.2
$22.5M+2.5
$24.0M+4.0
21%
$21.0M+1.0
$22.2M+2.2
$23.6M+3.6
$25.2M+5.2
22%
$22.0M+2.0
$23.3M+3.3
$24.8M+4.8
$26.4M+6.4
23%
$23.0M+3.0
$24.4M+4.4
$25.9M+5.9
$27.6M+7.6
25%
$25.0M+5.0
$26.5M+6.5
$28.1M+8.1
$30.0M+10.0
+2 points and −10 days — changes most teams would call noise — is +$4.8M, a 24% lift.
Compounding is real: the two levers alone are worth $2.0M and $2.5M. Together they are worth
$4.8M, not $4.5M.
The filter
Your AI does one of two things. Or it isn't a GTM project.
Pillar one
Improve conversion rate
Better accounts in front of reps
The right people in the room
A slipping deal caught while it is still recoverable
$1.0M per pointOn a $20M plan
Pillar two
Reduce time in stage
Speed to first touch at the top
Context assembled, not reassembled
Paper that stops sitting still at the bottom
$225K per dayOn a $20M plan
The foundationGTM telemetry
Stage transitions system-stamped, one resolved account, one governed definition per metric.
Moves neither number by itself. Nothing above it is measurable without it — and unmeasured
improvement is indistinguishable from a good quarter.
Why AI projects stall
The model is not the constraint. It hasn't been for two years.
Commoditized
ReasoningYou and your closest competitor rent the same models. Zero durable advantage.
Yours alone
ContextYour accounts, your lost-deal objections, what qualified means here. Not for sale.
The actual gap
AddressabilityIt exists — in 30 systems, under 6 spellings, with a stage field three reps read differently.
02
SECTION 02
What this actually is.
Technical first principles, and the honest version of the stack. Two definitions, one worked example, the
architecture mistake everyone makes, what it actually costs to run, and an honest read on where you sit
today — because halfway up this curve buys you almost nothing.
Semantic layerContext graphThe anti-patternWhat it costsThe maturity curve
First principles · 01
The semantic layer
Technical definition
A declarative, versioned mapping between physical storage and business meaning — a set of
definitions over your data model that is compiled to SQL at query time, so that every consumer
resolves the same metric from the same source of definition.
It is not a dashboard, not a BI tool, and not a table. It is
the contract that sits between them and the warehouse.
EntitiesThe nouns and their grain — account, opportunity, contact, subscription
MeasuresAggregations defined as expressions, never as stored columns
RelationshipsHow entities join, at what grain, and which joins fan out
The four properties that make it real
One point of definitionA metric is code — versioned in git, owned by a
named human, changed by review. If it can be redefined in a dashboard, you don't have one.
Grain and fan-out awarenessThe layer knows which measures are additive
along which dimensions. This is what stops the double-count that hand-written SQL produces silently.
Time semanticsPeriod vs. as-of; event vs. snapshot. If it cannot express
"pipeline as of the first Monday of last quarter," you cannot restate history — and you will be
asked to.
Policy at the definitionRow- and column-level access attached to the
entity, not re-implemented in every dashboard and every agent.
First principles · 02
The context graph
Technical definition
A typed, entity-resolved, time-aware graph of your business objects, with unstructured artifacts
anchored to its nodes. Nodes are entities — accounts, people, opportunities, products,
tickets. Edges are typed and timestamped relationships — works_at, owns, attended,
mentioned_in, renewed_from.
Calls, emails, docs and tickets are chunked and embedded for retrieval by
meaning — but always anchored to a node, so retrieval can be scoped before it is searched.
NodesResolved entities, one per real-world thing, with a stable identifier
EdgesTyped relationships that carry a timestamp and a direction
ArtifactsTranscripts, threads, docs — chunked, embedded, anchored to a node
ProvenanceSource system, extraction time and confidence on every assertion
The four properties that make it real
Identity resolution is the hard partNot the graph. If Acme Corp,
Acme Inc., acme.com and CRM id 001xx are four nodes, everything built on top is
noise wearing a confident tone.
Edges carry time"Who is the champion" is a question with a date on it.
A graph without timestamps can tell you what is true and never what changed.
Retrieval is graph-scoped, not vector-scopedTraverse to the relevant
subgraph first, then search inside it. Searching the whole corpus is how an agent answers a
question about one account using a different account's call.
Provenance is not optionalEvery claim resolves to a source artifact. An
agent that cannot cite cannot be put in front of a customer, and will not be trusted internally.
Worked example
"Which deals are at risk?" — one question, two systems.
The most-asked question in every forecast call in this room. It cannot be answered by
either layer on its own, which is exactly why the tools that only have one of them keep disappointing you.
Semantic layer answers
Which ones, and how abnormal
The cohort: all open deals over $50k in Enterprise. The norm: median 34 days in
Technical Validation for deals that eventually won.
The outliers: 7 deals past the 80th percentile. The trend: this stage has stretched
11 days since Q1.
Deterministic. Reproducible. Auditable.
Context graph answers
Why, with receipts
For each of those 7: the last three calls, the objection that surfaced and never resolved, the
champion who stopped replying 19 days ago.
The security review thread nobody logged in the CRM. The fact that the economic buyer has
never been on a call.
Specific. Cited. Entity-scoped.
Together
Something a human acts on
"Acme is 22 days past the winning-cohort median in Technical Validation. Procurement raised SOC 2
scope on 14 July and it was never answered. The champion has gone quiet. No economic buyer has
attended a call."
Ranked against 59 other deals, produced nightly, before anyone opens the forecast sheet.
This is the entire thesis in one output.
The mistake to avoid
Never let the model author your business logic.
The obvious architecture — point a model at the warehouse and let it write SQL — is the one
that fails in production, and it fails silently, which is worse than failing loudly.
✕ Text-to-SQL
Question"What was Enterprise win rate last quarter?"
↓
Model writes SQL against raw tablesIt must now guess your grain, your join paths, your
stage definitions, and which of four amount columns you meant
↓
A numberPlausible, precise, and unverifiable
Every ambiguity in your schema becomes a silent guess. The model has no way to know it
guessed wrong, and neither do you — until the board asks why two decks disagree.
✓ Text-to-semantic-query
Question"What was Enterprise win rate last quarter?"
↓
Model selects from an approved menumeasure: win_rate · dimension:
segment=Enterprise · grain: fiscal quarter — it chooses, it does not invent
The same number the board deck showsWith the definition attached to it
The hard problem — what a metric means — is solved once by humans. The model is left with
the easy problem: which approved metric was being asked for.
Running cost · an opinion
The layers are cheap. The inference is what grows.
The infrastructure bill is small and flat. The number that scales with use is tokens — and
the architecture on the previous slide is what keeps it survivable. This is the second argument for
building the layers rather than renting them.
The flat part
What the layers cost
Ingest, warehouse, semantic layer, graph, activation. At Series A–C volumes it is a rounding
error against one fully loaded AE.
And it barely moves as you grow, because none of it is priced per question asked.
Real. Not the risk.
The variable part
What actually grows
Tokens. Every agent run, every re-embedding, and every retrieval that hands the model three
thousand pages so it can find the answer in two hundred.
Priced per unit, on someone else's roadmap — and the era of effectively free frontier capacity is
ending.
The line item to design against.
Lever one
Right-size the model to the task
Classification, extraction, routing and summarization are small-model work. Reserve the frontier
model for the step that genuinely reasons.
A cheaper model isn't a dumber model — it's a different tool. Most teams point the most expensive one at
everything, then conclude the pipeline is unaffordable.
An order of magnitude, on output nobody can tell apart.
Lever two · the maturity call
Index before you infer
At ~20 documents, hand them to the model raw. An index is pure overhead.
At ~200, index them — you are now paying to read two thousand pages to find the two hundred that
matter.
At ~2,000, you needed it a year ago.
Not a third layer. It's how the context graph stays affordable.
Own the pipeline and the model is a swappable part. Rent the pipeline, and someone else's
repricing is your problem.
Why "never buy the layers" is a cost argument as well as an accuracy one
Where you actually are
The maturity curve — and why halfway buys you nothing.
Value from AI does not accrue in a straight line as your data matures. It stays flat through
three levels and inflects at the fourth. Most companies are at Level 1, buying tools that require Level 3
— and concluding that AI doesn't work here.
Level 0
Reported
Numbers live in the CRM and in slide decks. Every new question costs a person most of a day.
The tell: "how many SQLs last quarter" lives in somebody's saved view.
Ceiling: a writing assistant.
Level 1
Centralized
A warehouse and BI on top. The data is in one place; the meaning still isn't. Two dashboards
disagree and both are defended.
The tell: everyone knows which dashboard to use in which meeting.
Ceiling: text-to-SQL, confidently wrong.
Level 2
Resolved
One account, one person, one crosswalk. Stage transitions system-stamped and backfilled. The
unglamorous level everyone skips.
The tell: you can answer "how long did that stage take" without a caveat.
Ceiling: counts you can trust. No narrative.
Level 3
Defined
20–30 metrics as versioned code, one named owner each. One definition served to BI, to apps and to
agents through the same interface.
The tell: a number in the board deck traces to a file with a name on it.
Ceiling: agents trusted with a number.
Level 4
Retrievable
A typed graph over the resolved spine, artifacts anchored and citable, with one MCP server exposing
both layers as tools.
The tell: an agent answers about one account and cites the call it came from.
Ceiling: agents that cite, rank and act.
Extra credit
Vectorized
The same corpus indexed by meaning, so retrieval narrows before the model reads. Not a new
class of answer — the answers you already get, faster and far cheaper.
The tell: you are paying to read 2,000 documents to find the 200 that matter.
Optional. Earn levels 3 and 4 first.
Buy point solutions on top of your layers. Never buy the layers. A platform that ships its own
semantic layer does not know what qualified means here.
03
SECTION 03
The art of the possible.
Before we get to how you build it — what you get. Everything here runs on the two layers from Section 2,
it is all buildable by a two-person team, and the marked ones are running against our own business
today, which is the only reason we'll claim they work.
Twenty agentsSales · marketing · CS · RevOpsTime to the next agent
The agent catalog · one set of layers, every function
Twenty agents. The same two layers underneath all of them.
Sales 5
Deal risk & slip detection
Live
Every open deal scored nightly against the winning cohort. Ranked, with evidence.
ConversionSemGraph
Pre-meeting brief
Live
Sixty seconds before the call: open objections, who went quiet, what was promised.
CycleGraph
Multithreading gap
Live
Contact coverage against your own closed-won pattern. Names the missing role.
ConversionSemGraph
Objection responder
How this exact objection was answered in deals that won — not a stale battlecard.
ConversionGraph
Quote & approval acceleration
Watches for paper sitting still and escalates on elapsed time, not on memory.
CycleSem
Marketing 5
Inbound enrichment & routing
Person → account → ICP tier → history, routed on fit in under sixty seconds.
CycleSemGraph
ICP drift detection
The accounts converting now versus the segment you are still paying to reach.
ConversionSem
Objection-driven content
What to write, ranked by objections in lost-deal calls and weighted by deal value.
ConversionGraph
Campaign → pipeline attribution
One definition of pipeline created, so the marketing deck and the board deck agree.
ConversionSem
Account intent triage
Usage, site behaviour and conversation signals joined at the account node. One list.
ConversionCycleGraph
Customer success 5
Renewal risk
Live
Usage trend, call sentiment and delivery evidence against what was promised at kickoff — cited,
not scored in a black box.
ConversionSemGraph
Escalation detection
Live
Sweeps channels, calls and delivery systems daily for next week's problem, and routes it tonight.
ConversionGraph
Expansion signal detection
Usage growth, new teams on calls and budget language, ranked against who expanded before.
ConversionSemGraph
QBR pack assembly
The account's quarter assembled from usage, delivery and the actual calls — every claim citable.
CycleSemGraph
Follow-up & gap capture
Drafts the recap from what was said and writes qualification gaps back as fields, for approval.
CycleGraph
RevOps 5
Pipeline hygiene
Live
Stage lies, stale close dates and impossible amounts, found before the forecast call.
ConversionCycleSem
Forecast-call prep
Live
The eight deals worth twenty minutes, with the reason each made the list.
ConversionSemGraph
Territory & account scoring
Scored on your closed-won pattern, not a vendor's fit model. Rebalances on capacity.
ConversionSem
Executive reporting
Live
The board pack assembles itself, every figure tracing back to a definition.
Sem
Definition-drift watchdog
Alerts when a definition changes, who changed it, and what moved as a result.
Sem
Conversion moves win rate
Cycle moves days
Sem / Graph layer required
Live running at LeanScale against our own book today
Effort, once the layers exist
The first agent costs ten weeks. The tenth costs an afternoon.
Build time for each successive agent, two people, on top of the layers in Section 2.
Agent one carries the entire cost of the infrastructure. Every agent after it pays only for itself —
which is the whole financial argument for building the layers first.
Deal risk · multithreading gap · renewal risk · ICP drift · objection-driven content. These need a
cohort baseline — a few weeks of history before "abnormal" means anything.
The highest-value tier.
A quarter
Ship deliberately
Anything that writes back. Not because the agent is harder, but because the approval queue,
audit trail and rollback path around it are.
Governance is the long pole, not the model.
04
SECTION 04
How you deploy it.
The engineering is thirty percent of the work. What makes this hard is that a semantic layer
forces your executive team to agree, in writing, on what your words mean — and most teams have never
had to. Here is the whole programme: where the time goes, the definitions, how it gets built, and by whom.
Where the time goesThirty definitionsHow it gets builtThe teamTen weeks
Where the ten weeks actually go
This is an alignment problem wearing an engineering costume.
Ten weeks, split by where the effort actually lands. Half of it is people agreeing on what
words mean — and the part everyone is excited about is the smallest slice on the screen.
10Weeks
50%
AlignmentDefinition working sessions, one named owner per metric, and the executive
arbitration for when the CRO and the CFO disagree — which they will.
30%
EngineeringStage instrumentation and backfill, the identity crosswalk, the models and
tests, the graph schema, the tool server. Well-trodden work. Never the long pole.
20%
Agent buildingTwo agents — prompt, tool scoping, evaluation, and an approval path for
anything that writes. On finished layers, an agent is days of work.
The alignment slice, itemised
Every team owns its words. One layer reconciles them.
The fight: what makes an opportunity qualified? Default: an observable
event, never a judgment — anything needing a rep's opinion drifts within a quarter.
Marketing definitions
LeadMQLSourceChannelCampaignSelf- vs. marketing-sourcedAttribution model
The fight: are source and channel one field or two? Most teams have one.
Default: two — source is immutable first touch, channel is mutable spend.
The reconcilerSemantic layer
Each definition as versioned code, with one named human on it — served to BI, to apps and to agents
through the same interface.
The fight: what counts as a customer, and who decides? Default: define it
on revenue, not on status — a status field is maintained by whoever remembers.
Company-wide definitions
AccountPersonParent / childSegment & ICP tierBookingsARR / MRR / TCVFiscal calendarAs-of vs. periodProduct line
The fight: whose definition of Enterprise wins? Default: one segment
field, computed from the resolved account — never a picklist three teams maintain differently.
Thirty is the ceiling, not the target. Past forty you are modelling the business instead of the
questions on your list.
One named human owns each one. Not a team. Two owners produce two definitions inside a quarter,
and then a standing agenda item about which is right.
Practically · 01
How the semantic layer actually gets built.
It is a git repository, not a platform. Text files, reviewed like code, compiled to SQL at
query time. If a definition can be changed without a pull request, you don't have one.
One repo, owned by the analytics engineer. CODEOWNERS is what turns
one named owner per metric from a slide into something the tooling enforces on every PR.
What one metric looks like
metric: win_rate
owner: "@j.chen"# one human. not a team.label: "SQL → Won win rate"description: >
Of opportunities that entered Sales
Qualified in the period, the share
that reached Closed Won.
entity: opportunity
grain: opportunity_id
filter: "entered_sql_at is not null"numerator: count(distinct if(is_won,id))
denominator: count(distinct id)
time:
column: entered_sql_at# cohort, not closetype: as_of
policy: { row_access: segment }
The owner and the plain-English description are not decoration — they are
what lets the definition survive the person who wrote it.
How it stays true
1
A change opens a PR.Nobody edits a definition inside a dashboard. There is no other door.
2
CI runs the tests.Fan-out assertions, row-count deltas, and a lineage diff naming every downstream model,
dashboard and agent the change touches.
3
The named owner reviews.Not the team — the one human in CODEOWNERS for that file.
4
Merge publishes everywhere.The same definition compiles to BI, to the app and to the MCP tool server. One change, one
place, one number.
5
The drift watchdog posts.What changed, who changed it and what moved — into the channel where the exec team already
argues about the number.
6
Thirty minutes, monthly.Every metric that moved more than expected, and every metric nobody queried at all.
A metric that lives in a dashboard is an opinion with good typography. A metric that lives in a
repository is a contract.
Why this is a version-control problem, not a BI problem
Practically · 02
How the context graph actually gets built.
Five tables in the Postgres your team already operates, plus a versioned type registry.
No graph database, and nothing here is novel — the discipline is all in what you refuse to write.
Where it lives
-- Postgres · schema gtm_graphnodes id · type · canonical_key
edges src · dst · type · valid_from
artifacts node_id · source · uri · at
chunks artifact_id · text ·
embedding vector(1536)crosswalk source_system · source_id
→ node_idgraph/
├─ types.yml node + edge registry
├─ migrations/ every change, versioned
├─ extractors/ one per source system
└─ eval/ 50 Qs · known-good docs
Same repo, same review process as the semantic layer. Move to Neo4j only when
your real questions need three or more hops — and add the vector index at roughly two hundred
artifacts, not twenty.
How one artifact lands
1
A webhook fires.Call ends, note saved, ticket closed. Event-driven, not nightly — the graph is the fresh half
of the stack.
2
Resolve before you write.The source id goes through the crosswalk to a node id. No match, no write — it lands in
quarantine and a human clears it.
3
Chunk and embed.~800-token chunks, speaker and timestamp retained, embedded once, with the embedding model
stamped on the row.
4
Anchor and timestamp.Every chunk hangs off a node; every edge carries valid_from. Provenance columns are
not null — enforced in the schema, not in a convention.
5
Traverse, then search.Retrieval scopes to the subgraph first and runs vector search inside it. Never the other
way round.
How it stays true
1
New edge types need a PR.Against types.yml. An untyped edge is how a graph quietly becomes a swamp.
2
Re-embedding is a versioned job.Change the model and you re-embed everything — or you have two vector spaces pretending to be
one.
3
Nightly orphan check.Artifacts anchored to nothing, nodes with no edges, edges pointing at merged nodes.
4
A retrieval eval set.Fifty real questions with known-correct source documents, run on every change. The only way to
know a change made retrieval worse.
5
Merges are events, not deletes.Keep both nodes and add a merged_into edge. Delete one and last quarter's number
silently changes.
Building the graph is the easy half. Deciding what you refuse to write into it is the job — and
it is why identity resolution comes first, every time.
Layer 4 before layer 6. The failure mode with no recovery
The team, honestly
Five roles. None of them optional.
This is the slide where everyone hopes we'll say "one smart RevOps person and an AI."That team ships a demo and stalls at week six.
Role 01
Executive sponsor
Owns the definitions — and the arbitration for when the CRO and the CFO disagree.
The one role that cannot be delegated.
Must be able toMake a call in the room and hold it for a quarter.
CEO or CRO · in seat
Role 02
RevOps owner
Owns the question inventory, the metric contracts, CRM instrumentation and
adoption. A product owner, not an admin.
Must be able toWrite a spec, run an exec session, read enough SQL to argue with the model.
Promote your best
Role 03
Analytics engineer
Owns the semantic layer — the warehouse models, the tests, the lineage. And says
no to a metric nobody owns.
Must be able toModel slowly-changing dimensions and spot a fan-out before it ships.
The one you hire
Role 04
Platform engineer
Owns the graph — ingest, identity resolution, the schema, embeddings and the
tool server. Part-time is fine.
Must be able toRun a webhook pipeline that has to be up during a sales meeting.
Borrow from product eng
Role 05
CRM admin
Owns the instrumentation — stage stamping, field governance, the write-back
approval queue. Changes the CRM without breaking a rep's week.
Must be able toRefuse the twelfth custom field for a report somebody reads once.
In seat
Three of the five you already pay for. They are simply pointed at this instead of at the next
dashboard request.
Add two weeks if your CRM doesn't system-stamp stage transitions. You cannot backfill a timestamp
that was never written.
Ten weeks, against a lever worth a million dollars a point. There is no other project on your
roadmap with that ratio.
The sequence
Five projects. Ten weeks to the first agent in production.
Sequenced by dependency, not by appetite. Two of them run in parallel, which is what makes
ten weeks realistic rather than optimistic.
Project
W1W2W3W4W5W6W7W8W9W10
0 · Question inventory3 days · the 20 questions + 10 agents
5 · Agent interface + first two agentsMCP server · one sales, one marketing
Week 10 output: conversion rate and time in stage measurable for the
first time, one governed definition of every metric that matters, an account-scoped graph an agent can
cite from — and two agents a human actually uses on a Monday. Not ten. Two.
Failure modes
Five ways this goes wrong. All of them are avoidable.
Failure 01
Modeling everything
A team decides to model the business rather than the questions. Eighteen months later there is a
beautiful warehouse and no agent. The scope must come from the question list.
Kill with Project 0.
Failure 02
No single owner per definition
Definitions owned by "the RevOps team" are owned by nobody. Within one quarter there are two versions
of win rate and a standing agenda item about which is right.
One human, named, per metric.
Failure 03
Graph before spine
Building the context graph before identity resolution is done. Every retrieval returns a plausible
answer about the wrong account, and trust never recovers after the first time.
Layer 4 before layer 6. Always.
Failure 04
Buying the platform first
The vendor demos on their data model and it looks extraordinary. On yours it is confidently wrong,
because it is running on their definitions, not yours.
Buy on top of your layers, never instead of them.
Failure 05
Ten agents at once
Ten half-built agents produce no adoption and no evidence. Two agents someone opens on Monday
produce a budget for the next six.
Two. Then earn the rest.
The tell
How to spot it early
At week 6, ask for one number, from the semantic layer, that contradicts something in your current
board deck.
If the project is real, there will be one — and finding it is the point. If everything matches
perfectly, nothing has actually been defined yet.
Best six-week checkpoint we know.
05
SECTION 05 · THE CLOSE
A reminder why this is important.
None of this was an AI project. Every agent on the previous two slides exists to move exactly one of two
numbers — how often you win, and how long it takes — on a machine you have already paid
for. Here is what that is worth in dollars.
Agents → the two numbersThree yearsBoth layers, plainlyMonday
Tying it back
Every agent maps to one of two numbers.
A deliberately conservative portfolio on a $20M plan · 20% SQL→Won · 90-day cycle.
No agent here is credited with more than two points or five days.
Agent
Number it moves
Conservative claim
Worth alone
Why it moves
Deal risk + pipeline hygiene
Conversion
+1 point · 20% → 21%
+$1.0M
Slipping deals are caught while they are still recoverable rather than at the quarter boundary.
Multithreading gap
Conversion
+1 point · 21% → 22%
+$1.0M
Single-threaded deals lose to no-decision. Naming the missing role is a coachable, measurable act.
Pre-meeting brief + follow-up
Cycle
−6 days · 90 → 84
+$1.4M
Reps stop reassembling context. Recaps go out same-day rather than two days later.
Inbound routing + quote acceleration
Cycle
−4 days · 84 → 80
+$0.9M
Speed to first touch at the top; paper that stops sitting still at the bottom.
Combined portfolio
Both
+2 points and −10 days
+$4.8M
Not $4.3M. The levers multiply against the same base, so the portfolio is worth more than the
sum of its parts — and the gap widens as you push further.
The part that actually compounds
It isn't a one-time gain. It's a permanent change in yield.
The same +2 points and −10 days, held flat, against a plan growing 40% a year.
The improvement doesn't repeat — it applies to a bigger base every year.
Year one
+$4.8M
On a $20M plan. The year you build it, you capture roughly two quarters of it.
Year two
+$6.7M
On a $28M plan. Same win rate, same cycle time — larger base.
Year three
+$9.3M
On a $39M plan. Nothing new was built; the machine simply still runs at the higher yield.
Three-year total
+$20.7M
From five roles, ten weeks, and software that costs less than one fully loaded AE.
And this is the conservative read.
Deliberately understated: the additional bookings are
not compounded back into the following year's base, and no credit is taken for retention, expansion,
or the second wave of agents the same layers make nearly free. The real figure is larger. We would rather
be doubted than discounted.
Both layers, in plain terms
Strip the jargon and this is all they are.
Layer one
Semantic layer
Writing down what your words mean. Once, in one place, with a name against each one —
and then never having that argument again.
Layer two
Context graph
Joining the dots. The same account, the same person, the same conversation — connected,
so a machine can walk from one to the next.
Neither one is exotic. Both of them start with a decision, not a purchase order.
The close
Three things to do Monday. None of them need budget.
1
Start writing down the definitions of your go-to-market.The twenty to thirty words every number you report depends on — qualified, customer, segment,
pipeline created, cycle time. You cannot govern a definition that has never been written down.
2
Name the owner of each definition.One human against each one. Not a team, not a function, not "RevOps."
A definition owned by a team is owned by nobody, and inside a quarter there will be two of it.
3
List the source of truth for each metric.For every metric on the list, write down where the number actually comes from today.
Be honest when the answer is a spreadsheet on somebody's laptop — that is the finding, not the failure.
All three are writing exercises. The whole first half of this programme is people agreeing on what
words mean — you can start that on Monday with the people already in the building.
Anthony Enrico · anthony@leanscale.team · Jake Toepel · jake@leanscale.team
The giveaway
One code. Everything behind this talk, free.
Four things you download — the deck, the worksheet, ten of the agents as
Claude Code plugins, a key to our knowledge base — and one we run with you:
a full GTM diagnostic, free through the Updata partnership.
↓
Five things behind the code
1This presentationThe full deck with speaker notes, plus a PDF. Nobody has to photograph a slide.
2The metric definition worksheetMonday's exercise as a printable sheet and a spreadsheet — every definition, its owner, and
its source of truth. Walk it round your own building.
3Ten prebuilt agentsClaude Code plugins, installed into your own Claude, pointed at your own Salesforce or
HubSpot. Read-only by default — nothing writes without your approval.
4A key to our MCPThirty seconds to connect. The delivery playbooks, the field studies and the case studies
inside your own Claude, answering with a citation.
5
Not a download — this one we run with you
A free GTM diagnosticWe walk your go-to-market end to end — telemetry, conversion rate, time in stage —
and hand back the specific projects that move those two numbers, graded and sequenced into a
90-day roadmap. Run it internally or engage us; the deliverable is the same either way.
Free to Updata portfolio companies.
Everything in one placeleanscale-updata.netlify.app
↗
Scan thisleanscale-updata.netlify.appBuilt for Updata portfolio companies. Nothing is gated — the only ask is that if it finds
something useful, tell us what it found.