---
title: You connected your stack to Claude and wrote the skills.
description: "Most revenue teams stop there. FLiiP did too. What happened next follows four stages, and the last two are the hard part. This is the climb, stage by stage, and how FLiiP reached the top with Vasco. "
canonical: "https://vasco.app/case-studies/warehouse-is-not-a-brain"
---

# You connected your stack to Claude and wrote the skills. So why are your agents still guessing?

*Field notes 02: the four stages, with FLiiP. Co-authored by Marceau Boulenger (FLiiP) and Guillaume Jacquet (Vasco). October 2026, 12 min read. Marceau tells the FLiiP story through stages 1 to 3. Guillaume shows what Vasco does at stage 4.*

Most revenue teams stop there. FLiiP did too. What happened next follows four stages, and the last two are the hard part. This is the climb, stage by stage, and how FLiiP reached the top with Vasco.

## The climb, in four stages

1. **The chatbot.** Copy-paste your context. Memory you cannot see or control.
2. **Connect everything.** Access to everything, understanding of none. This is where most teams are.
3. **Explain it in markdown.** Definitions the AI can read. Works, until you scale.
4. **One context layer.** Systems, processes and definitions, resolved once. Where FLiiP is now, with Vasco.

## Stage 1: Copy, paste, and hope

You copy and paste your context, your links, your documents into a chat.

- **What you get:** a smart assistant. The latest models even keep some memory between chats.
- **What you lack:** control. You never know what is stored, what is kept, or how well.

Then you realize two things. The AI should be connected to your tools, like your CRM. And it should be connected to your Drive and shared folders. So you connect everything.

**Takeaway:** a chatbot remembers bits of you. It does not understand your business, and you cannot see what it kept.

## Stage 2: Connect everything. Understand nothing.

Direct access to your data and all of your company's documentation. Now you have added so much context that it becomes unmanageable.

Your Google Drive, as the agent sees it: "Town hall deck v20", "Strategy_FINAL_v3", "SOP (2021, nobody follows)", "Strategy_FINAL_v4", "Pricing (copy)", "Town hall deck v20 (1)", "QBR template OLD", "Comp plan DRAFT". It is full of SOPs nobody follows anymore, anyone can edit any doc, and there are 20 versions of the town hall deck and of the strategy. How do you expect your AI to understand this mess?

The research agrees:

- **18 of 18** frontier models degrade as input length grows, including on trivial retrieval tasks (Chroma, 2025).
- **1M+ tokens** are now advertised per context window. Anthropic's own guidance: attention is a finite budget, every token spends some of it, and returns diminish as you fill it (Anthropic Engineering).
- **21.3%** is the best agent success rate on real enterprise text-to-SQL, against 91.2% on the academic benchmark (Spider 2.0, ICLR 2025).

More context makes models worse, and this is measured now. The culprit is distractors: text that only looks relevant. A go-to-market stack is full of them, like four hundred rows that all look like a meeting happened.

The models solve complex math. So why do they fail when you ask if we are on track to hit the month?

### Think of it in human terms

Good analysts are smart, and above all they connected the dots. They knew what each thing meant in the systems and the processes. A good analyst also digs: the transcripts, the whole account, and the same company under a slightly different name in another system, because nothing shares a key.

Picture a new RevOps hire in week one, with full access and no onboarding. Would they get the custom formula field that calculates MRR the way your business does? Would they get how your sales stages work across accounts and deals? Would they know ACME 123 and Acme Holdings are the same customer? Most likely not. So why expect your AI to?

**Takeaway:** access is not understanding. Give your AI what you would give a new hire: explain the whole thing, and make it remember what means what.

## Stage 3: A definition in a markdown file is a suggestion

> I had to give my AI an easy way to understand the business. Markdown files: easy, readable by humans and AI, portable. It worked remarkably well, which surprised me. But it stopped being efficient as we scaled, for two reasons. — Marceau Boulenger, FLiiP

### Reason 1: You are running your ETL through an LLM, every single time

Ask how many MQLs you got last week, and on every question the agent reads the CRM, extracts the data, reads the markdown, writes the query, filters, and hands you a number. Mostly right, most of the time. Slow and very expensive. Switch models and its reading of the markdown can change with it, and you would not notice.

> "It was fun, but you ask the agents for a dashboard and the dashboard is not up to date. You have to ask the agent to rebuild the whole thing again. It has to redo the ETL every single time, even though I gave it the right definitions." — Marceau, on the FLiiP stack

**Definitions in a file vs definitions in a metric layer.** With a `definitions.md` file, the definition is advisory and loaded into every window, relevant or not. Each agent rediscovers the schema and rewrites the SQL, so three agents asked for win rate return 24%, 19% and 31%, and all three cite the definition. With a metric layer (`metric: win_rate`), the definition is enforced and computed once, deterministically. Every agent gets the same number: 24%.

### Reason 2: Maintenance. The build ends. The operation keeps going.

AI shifted the balance between buy and build: why pay when I can build it myself? But the old costs are still there, and maintenance is the biggest one. HubSpot adds a field or someone renames the stages, and the formula breaks. It became a real problem once I took on Marketing and had to focus on more strategic work.

> "Now that I am taking on marketing, I do not really have time for that maintenance any more. That is the thing, is this buy versus build?" — Marceau, on maintenance

- **Markdown is for judgment:** how to score a discovery call, what our positioning says. My skills are markdown in GitHub, reviewed and versioned like code. I still write markdown every day.
- **The metric layer is for numbers:** computed once, the same number for every agent. A definition the model reinterprets on every question will drift.

**Hard rule:** no metric formula or SQL in a skill. The validator fails any skill that contains one.

**Takeaway:** markdown for judgment, a metric layer for numbers. A definition the model reinterprets on every question will drift.

## Stage 4: Getting to stage 4

One central place that makes sense of your systems and processes. It is the hard part. Stage 4 needs:

1. **One central place** that makes sense of your systems and processes, turns raw data into information, and uses standard definitions that fit your business.
2. **Access to that layer** from the tools you already use, like Claude or your favorite AI assistant.
3. **Accepting that less context often works better.**

### How FLiiP got to stage 4: at FLiiP, that layer is Vasco

Vasco is the GTM brain for AI agents: the revenue context layer that lets go-to-market agents run in production. FLiiP's answer to stage 4 was Vasco: one context graph and metric layer, built once on top of HubSpot, so the agents read resolved answers instead of rebuilding the ETL on every question.

1. One central place that makes sense of your systems → a context graph on top of HubSpot, with the metric layer for definitions.
2. Access from the tools you already use → available over MCP, where Marceau's skills live too.
3. Less context works better → agents get only the 6 to 20 nodes that matter.

**Marceau's team still owns** the agents, the prompts, and the skills: markdown in his GitHub repo, pushed to Vasco over MCP. Five in his first fortnight. **Vasco owns** extraction, identity, timelines, definitions and sync: the four jobs below, kept running as HubSpot changes.

### 4.1 Extract: the transcript is mostly noise, and the noise is the expensive part

The biggest lever in the whole piece: giving the model less makes it more correct.

A one-hour discovery call is roughly 9,000 to 11,000 words. Most of it is scheduling, small talk and goodbyes. Our working estimate: about one word in ten would change a decision. What matters in that hour: two pain points, one competitor, a champion, an economic buyer, the incumbent process, a timeline, one objection, a next step. Typed, with a link back to the sentence that produced each one, that is roughly 400 tokens.

A raw one-hour transcript is about 13,000 tokens, of which only about 10% (about 1,300 tokens) is signal-bearing; the rest is intro, logistics, tangents, repetition, demo setup and goodbyes. Extracted once, at ingestion, it becomes about 10 typed nodes per call (pain, competitor, champion, economic buyer, status quo, requirement, risk, next step), each with an evidence quote, a timestamp and the stage at utterance: about 400 tokens.

Net: about 30× fewer tokens per call in the agent's context, about 8× if every evidence quote travels with its node. And higher accuracy, because you removed distractors.

- One account, 12 calls: 156,000 raw tokens → about 5,000 in typed nodes.
- One book, 400 accounts: about 62M raw tokens → about 2M.
- One question: 156,000 tokens for the whole account raw → under 1,000 for the 6 to 20 nodes that bear on it.

Estimate: about 10,000 words per hour at 1.3 tokens per word, one word in ten signal-bearing, about 10 nodes per call. Rounded.

### 4.2 Resolve identity: four records, one customer

Four systems, four keys, no shared identifier. The agent sees four fragments and answers about one of them with full confidence. The CRM says "ACME 123", the call recorder says "Acme", billing says "ACME Holdings", and Slack says "#acme-eu". Resolved, they become one account, Acme Holdings (`acct_0042`), with four aliases linked.

What people think identity resolution is: a dedup script, a fuzzy match on company name, one afternoon. What it actually is: a scored match, merges you can undo, a record of why each merge was made, and the whole thing re-run every time new data lands. Forever.

An agent with unresolved identity answers about a fragment and calls it the account.

### 4.3 Reconstruct the account timeline: the same sentence means three different things

Take one line out of a transcript: "budget is a challenge". Placed on the account journey for acme.com (built from CRMs, conversations, and billing and support), it means three different things depending on when it was said: at MQL it is a qualification signal, at negotiation it is a deal risk, and at renewal it is a churn signal. Every signal, transcript and message is placed in the stage it was said.

Most stacks cannot rebuild that. A CRM stores where the deal is today. It forgets when it got there and whether it moved backwards. And it matters: on Google's Test of Time benchmark, accuracy swung from about 15% to 89% depending only on how the same dated facts were arranged. Best result: grouped by entity, sorted by time. That is an account timeline.

Then decay. A competitor mention from last Tuesday outweighs one from fourteen months ago.

### 4.4 Define once, compute once

You saw the problem at stage 3. The fix is a metric layer: win rate defined once, computed once, handed to every agent as a finished number.

Pointing an agent at a raw warehouse is asking it to run the 21% task from stage 2 on your revenue numbers, from scratch, every time. The model stops deriving the number and starts receiving it.

Not a `definitions.md` file ("Won deals over closed deals. Count duplicates? By close date or create date, or maybe the CRM report…"), where each agent reads it, writes its own SQL and gets its own number. Instead, a semantic layer in Vasco, versioned and locked:

- **metric:** `win_rate`
- **formula:** won ÷ (won + lost), by close date
- **sources:** HubSpot deals, resolved accounts
- **excludes:** open deals, duplicates, test deals
- **group by:** segment, motion, lead source, rep
- **computed:** once, on every sync

Claude, the dashboard and your own tools all read 24%. One win rate definition, one number, every agent.

**Takeaway:** do the hard work once, when data lands: extract, resolve, place in time, define. Then every agent reads the same truth.

## The superpower: your AI connects the dots

Remember the analyst who connected the dots? Stage 4 gives your AI the same skill. Ask it one question and watch it walk the context graph.

Asked "Why did Acme stall?", the agent walks from the resolved account (Acme, 4 sources) to the proposal on 21 March (stalled, 19 days of silence), then back to a Slack signal on 15 March that the champion went quiet, a call on 14 March where a competitor entered, and a call the same day revealing a budget freeze until April. Answer: a competitor entered and budget froze the week before. (Illustrative account.)

What that traversal gives you:

- **Root cause becomes a path:** 6 nodes read, 0 transcripts.
- **Same number, every agent:** win rate 24%, three times out of three.
- **A fraction of the tokens:** 156,000 → under 1,000 per question.
- **Every answer traceable:** each edge keeps its source quote.

**Takeaway:** your AI stops rereading and starts traversing. That is what makes it fast, cheap and auditable, like your best analyst.

## The second question: trust

Same number for every agent tells you the answer is consistent. It does not tell you when an agent stops deserving your trust. Everyone is racing to ship revenue agents. Almost nobody asks the two questions that matter: can we trust them, and how would we know?

- **The brain:** what agents know: the plan, the context and the numbers, resolved once.
- **The harness:** how agents are allowed to act: every agent runs inside it, owns an outcome, and answers for every number it acts on.

The GTM brain answers both. Autonomy is a scale:

1. **Advisor:** suggests. A human acts.
2. **Approver:** drafts the action. A human signs off.
3. **Supervised:** acts. A human reviews after.
4. **Autonomous:** acts and reports.

A clean record moves an agent up. A rising intervention rate moves it down.

## Build or buy: what stage 4 takes to build, and to keep

Not our cost. Yours, if you build it.

| The work | Scoped as | Actually is |
| --- | --- | --- |
| Identity | A dedup script | Scored matching, reversible merges, evidence trails, re-run on every sync |
| Timeline | A date column | Reconstructed stage transitions across systems, with decay weighting on signals |
| Definitions | A markdown file | Enforced metric layer returning the same number to every agent |
| Transcripts | Dump to the warehouse | Typed extraction when data lands, names reconciled at write, evidence attached |
| Freshness | A nightly job | Per-tenant incremental sync, monitored, with reprocessing when a definition changes |

Gartner expects over 40% of agentic AI projects cancelled by end of 2027, on cost, unclear value and weak risk controls. Model capability is not on that list. Control is.

That split is what FLiiP did. Marceau kept building the intelligence: the agents, the prompts, the skills. The substrate he handed to Vasco, because nobody has ever been promoted for building identity resolution twice.

**Takeaway:** buy the GTM brain, so you never rebuild the plumbing. Build what is yours on top of it. Structure is ours, shape is yours: we hold that a definition exists and is enforced; you decide what it says.

| | The substrate (from Vasco): the GTM brain | The intelligence (unique to you): your definitions, ICP, plan, agents |
| --- | --- | --- |
| What it is | The context graph: identity, timelines, signal extraction, the metric layer and sync. The same plumbing every go-to-market team needs. | Your definitions, ICP, plan, scoring, prompts, skills and agents. |
| Uptime | Around the clock. An alert fires on it. | Changes when your business changes. |
| Who keeps it running | Vasco, as your systems change. | You. It is entirely yours. |
| What you get back | The team that would have maintained it. | Every hour compounds. |
| Verdict | **Buy** | **Build** |

## Your turn: five questions that tell you which stage you are at

Run these before your next agent project:

1. **Where are you on the maturity curve? Did you just plug your AI chat into all your tools and call your team AI-enabled?** If so, you are at stage 2. You gave the model more context, not more understanding.
2. **Ask two different agents for the same metric. Do you get the same number?** If not, you do not have a definition layer. You have documents.
3. **Pick one logo. Can you pull its full timeline across every system, with stage transitions, in one call?** Or does a human have to assemble it first?
4. **Take a signal from a call eight months ago. Does your system know what stage the account was in when it was said?** If not, every signal weighs the same, which means none of them mean anything.
5. **What does it cost you in tokens to answer "how is Acme doing"?** If nobody knows, that is the answer.

The models are good enough. What is missing is whether anyone made your revenue data mean something before the model read it. Answered no to two or more? The missing piece is not a better agent. It is the layer underneath it: the context your agents read, and the harness they run inside.

— Marceau & Guillaume

**Get to stage 4 without building it twice.** [Run the five questions](https://vasco.app/ai-readiness-assessment) or [talk to sales](https://vasco.app/request-demo).

## Sources

- Hong, Troynikov & Huber, *Context Rot: How Increasing Input Tokens Impacts LLM Performance*, Chroma, 2025
- Anthropic, *Effective context engineering for AI agents*
- Lei et al., *Spider 2.0: Evaluating Language Models on Real-World Enterprise Text-to-SQL Workflows*, ICLR 2025
- Fatemi et al., *Test of Time*, Google Research, ICLR 2025 (Table 11, Timeline row)
- Gartner, June 2025
- Liu et al., *Lost in the Middle*, TACL 2024
- Ryseff & Narayanan, RAND, on AI project failure rates
- MarketingSherpa / HubSpot data decay benchmark
- Salesforce CRM data quality research