How Boy Hijnen Turned a 127-Metric Consulting Framework Into a Running AI Agent

It's late December 2025. You're a consultant with fifteen years of experience — relationship manager at Citibank, COO at a wealth-tech startup, team lead at an accountancy firm. You've built a methodology that actually works: 127 metrics, 13 drivers, three client-growth outcomes you can trace to real revenue. Your peers respect it. Your posts get engagement. And it lives entirely in your head, in a dozen spreadsheets, and in the conversations you have on client calls. You want to productize it. You are not a technical person.

That's the message Boy Hijnen sent me at the end of last December. Three months later, this Tuesday in office hours, he demoed the result on camera: Sentinel — a running agent that ingests a B2B company's billing, CRM, survey, sales, usage, and support data, calculates all 127 of his metrics deterministically, interprets them against his methodology stored in a Neo4j graph, and returns specific client-by-client recommendations. On his demo data — a 150-client SaaS with ~$1.5M ARR — it surfaced almost $70,000 in expansion opportunities in a single run.

This post is the story of how we packaged Boy's framework — the architecture decisions that made it possible, what most consultants try and why it fails, and the three-step way to do this for your own practice.

What most consultants try (and why it fails)

Most consultants in Boy's position reach for one of four options:

• Custom GPTs or Claude Projects. Paste the methodology into a system prompt. Hope the model doesn't drift. It will — an LLM on its own invents metrics, hallucinates thresholds, and gives confident answers that don't match your framework.
• A voice-clone product like Delphi.ai or Coachvox. These clone your voice, not your methodology. Your agent sounds like you but computes like a generic LLM.
• Notion AI or Mem.ai on top of your notes. Great for retrieval, blind to calculation. It can summarize your methodology; it can't run it against a client's data.
• Spin up a custom SaaS. Six to twelve months, fifty to a hundred thousand dollars, a product team you don't have. By the time V1 ships, the market has moved.

The trap underneath all four is the same: treating a consulting framework as a document. Boy's methodology isn't a document. It's formulas (127 of them), plus the relationships between metrics (which ones roll up to which drivers), plus the interpretation rules (what a given metric movement means for expansion, retention, or referral). Three different kinds of knowledge. You cannot stuff them into an LLM and expect it to keep them straight.

Why it fails technically

Three failure modes kill the "paste it into an LLM" approach:

1. LLMs drift on math. Ask Claude to apply a formula across 150 clients and you'll get three of them subtly wrong. Ask it again tomorrow, you'll get a different three wrong. For a methodology that's meant to be deterministic — where 91% retention means something different than 93% — drift is a killer.
2. LLMs don't respect hierarchies unless they're structured. Boy's framework is a real graph: 127 metrics roll up into 13 drivers, which roll up into three outcomes. If you describe this in a system prompt, the model will sometimes traverse the hierarchy correctly and sometimes shortcut through it. A Neo4j graph doesn't have that problem — the traversal rules are enforced by the database, not by a probabilistic model.
3. Context window churn. A 15-year methodology is bigger than any context window. Stuffing it all in every call is expensive and lossy. Retrieving the relevant subgraph per query is cheap and correct. (This is the same memory-vs-methodology split we covered in the AI agent guardrails post — you don't want your agent's judgment to live in a system prompt. You want it in a structure the agent has to read before it answers.)

The BrainGraph approach: three layers, one agent

When Boy and I mapped out the build, we landed on a three-layer architecture that separates what belongs in each system:

• Deterministic layer — Python engine. All 127 metric formulas. Billing, CRM, survey, sales, product usage, support. Given the CSV inputs, the engine produces a number. Same inputs, same number. No LLM anywhere in this layer.
• Methodology layer — Neo4j knowledge graph (the "brain"). The 13 drivers, the 3 outcomes, the roll-up rules, the interpretation logic, the industry benchmarks. This is where Boy's fifteen years of expertise lives. It's queryable by the agent, editable by Boy, and versionable the same way code is.
• Interpretation layer — Claude Opus. Two narrow jobs: (1) map a messy incoming CSV to the engine's expected schema, and (2) read the deterministic results against the methodology graph and generate the specific recommendation. Claude Sonnet handles the chat layer once the report is produced, because it's fast and the heavy lifting is already done.

The key insight — the one that took us a few iterations to land — is that the consultant's expertise isn't one thing. It's math, structure, and judgment, and they each belong in a different place. When we got that split right, drift disappeared. When we were sloppy about it, drift came back.

This is what "package expertise for AI" actually means in practice. Not "feed your framework into a chatbot." Separate the layers, give each one to the system that's best at it, and let the LLM do the narrow job it's good at.

Mini case study — Boy Hijnen, Client Yield

Boy runs Vantum Group, a consultancy focused on client yield — the discipline of maximizing retention, expansion, and referrals inside an existing client base instead of paying to replace churned logos with new ones. His thesis, which he's been posting about for years: most businesses treat existing clients ad-hoc. Customer success manages retention, sales is pushed toward new logos for expansion, and referrals — the highest-quality, cheapest-acquisition channel — are barely managed at all. Run all three as a system and growth compounds. Don't, and you pay to grow.

His methodology encodes this:

• 127 metrics pulled from seven standard data sources (billing, CRM, survey, sales, product usage, support tickets, plus company-specific "what good looks like" inputs).
• 13 drivers that aggregate those metrics into leading indicators.
• 3 outcomes: expansion lift, referral yield, retention lift. The formula of client yield.

The three-month build followed our standard sprint arc:

• Weeks 1–2 — Map the methodology. Boy and I traced every metric into a node, every driver as a parent node, every outcome as a root. Neo4j ingestion. No code yet, just the graph.
• Weeks 3–6 — Build the deterministic engine. Python, one formula at a time. Test data first, then messy real CSVs.
• Weeks 7–9 — Wire Claude. Two API calls, narrow prompts, tight boundaries. Sonnet for the conversational layer.
• Weeks 10–12 — Iterate against real scenarios. Boy ran pilot assessments, flagged drift, we tightened the prompts and graph traversals. Every sprint produced a working system, not a plan.

Boy built it. I consulted at each step. He owns it. That was the deal from week one — it had to be his agent, not a consultancy's black box he couldn't maintain. Three months in, he's demoed it three times on camera and can run Sentinel as a service under Vantum Group's brand.

The demo in office hours this Tuesday ran on real-looking synthetic data for a 150-client SaaS at $1.5M ARR — six CSVs, messy date ranges (some 14 months, some 8), exactly what a real client would upload. Sentinel ran all 127 metrics, flagged one client whose product usage had spiked from 40% to 99% of seat capacity as an expansion conversation, pulled out almost $70K of opportunity across the base, and generated talk-tracks for each outreach. Two API calls, ninety seconds, one report Boy could walk into a client meeting with.

📺 Watch the full conversation: Boy walks through Sentinel end-to-end, uploads the six CSVs live, and explains the client-yield methodology in his own words. Full office hours recording on YouTube →

How to start — three steps

If you're a consultant sitting on a methodology you want to productize, here's the sprint shape that works:

1. Diagram your methodology before you touch code. Metrics at the leaves, drivers in the middle, outcomes at the root. If it doesn't diagram cleanly in an afternoon, it's not yet a productizable framework — and no amount of AI will paper over that.
2. Separate the deterministic from the interpretive. Formulas and thresholds go into code (Python, Typescript, whatever you already know). Judgment about what the numbers mean goes into a knowledge graph that the LLM has to read before it answers. Don't mix the two.
3. Run one three-month sprint, not a twelve-month SaaS project. A working V1 that one real client uses in month three will teach you more than a perfect V3 that never ships. Boy's Sentinel works now. V2 will work better because V1 is already running.

What this unlocks

Two things shift when a consultant has a running agent backed by their own methodology:

• The consultant becomes leveraged. Boy can now deliver Sentinel-driven assessments to ten clients in the time he used to deliver one. His retainer shape changes — less "hours of my time," more "the system plus quarterly strategy calls." Vantum Group goes from a one-person consultancy to a productized service.
• The client gets something they can't get from a generic LLM. ChatGPT doesn't know Boy's 127 metrics. Claude Projects doesn't know Boy's thresholds. Notion AI can't run Boy's formulas. Sentinel does all three — and does them the same way every time.

That's the Expertise-as-a-Product thesis. The consulting expertise doesn't disappear; it gets a second delivery channel.

Start today

If you have a methodology that works and you want to see what the first sprint looks like for your own practice, two ways in:

• Join the next office hours session — we demo one client build each week, and the schedule for the next four is already posted.
• Book a 30-minute conversation with me — I'll tell you in thirty minutes whether your framework is ready to productize, and if so what the three-month shape would look like for your practice.

Boy did it in three months without being technical. The stack exists, the pattern is repeatable, and the first sprint is the one that tells you whether it's worth doing the second.