AI Adoption · 2025

Quick Facts

• Industry: OneStream / EPM consulting practice
• Role: Manager + AI champion — owned internal AI adoption and PoC programme
• Timeline: Ongoing, 2024–present
• Team: Cross-functional — delivery engineers, sales, and practice leadership
• Impact: Reframed how the practice writes rules, triages logs, and pitches AI in pre-sales; gave junior engineers a memory-backed assistant that retains hard-won pattern knowledge across engagements.

---

Overview

AI in consulting only matters if it changes the delivery economics. A demo that doesn't show up in margin, throughput, or proposal win-rate is theatre — and most early LLM rollouts inside services firms were exactly that. This work was the opposite: pair Anthropic Claude with a local database-driven architecture so the model has durable memory of past engagements, point it at the highest-leverage daily tasks, and feed the capability back into both delivery and sales so the AI story stops being aspirational. The output isn't a single product — it's a stack of internal tooling, a PoC demo set, and a cross-functional cadence that keeps the work tied to real business goals.

The Problem

A specialist OneStream / EPM consulting practice has a particular shape of operating cost. Senior engineers are expensive, the work is pattern-rich, and the same problems get solved repeatedly across clients because institutional memory lives in people, not systems. Four things were compounding:

• Repetitive rule-writing was eating senior time. Most of what a delivery engineer types in a day is a variation of something the practice has shipped before. Seniors kept being pulled into work that wasn't senior-shaped because the shape of the work wasn't captured anywhere reusable.
• Tribal knowledge stalled juniors on already-solved problems. A junior hitting a familiar error had no first move other than pinging Slack and hoping a senior was free. The same error had been solved a dozen times, but the answer lived in chat scrollback and whoever had fixed it last.
• Sales conversations lacked AI differentiation. Clients increasingly opened discovery calls with "what's your AI story?" and the practice's answer was the same as every other EPM shop's: cautious, generic, no concrete artefacts. That was costing air-time and, in a few cases, shortlists.
• Off-the-shelf LLM access had no durable memory. The team had Claude.ai logins, useful for one-off questions, but every conversation started cold. Nothing learned in conversation N was available to conversation N+1, let alone to a different consultant on a different engagement.

The brief: make Claude useful at the practice level, not just the individual level. Give it memory of our work, point it at the highest-leverage tasks, and make sure whatever we built showed up in both delivery throughput and the sales pipeline.

Process

The work moved through three deliberate phases. None of them were "deploy a model and see what happens" — each had a hypothesis about where the leverage was and a way to check whether it had landed.

Phase 1 — pair Claude with a local DB so the AI has structured memory

The biggest weakness of stock LLM access is statelessness. Every conversation starts from zero; the model has no way to know the practice has solved this exact rule pattern a dozen times. So the first build was a local database-driven layer sitting beside Claude — a structured store for rule patterns, troubleshooting playbooks, log-signature → root-cause mappings, and sanitised notes from past engagements. When an engineer queries Claude through the internal tooling, the layer pulls relevant prior context out of the DB, hands it to the model as grounded reference, and returns a response anchored in our practice's history rather than the open internet's.

The DB is local on purpose. Client data hygiene matters in EPM, and a self-hosted store gives the practice a defensible boundary around what leaves the laptop. It also keeps operational cost predictable. This phase wasn't impressive on its own — it was plumbing — but it's the plumbing that made every downstream use case worth building.

Phase 2 — point AI-assisted workflows at the highest-leverage tasks

With memory in place, the next move was being picky about what the AI helped with. Most internal AI rollouts fail by trying to AI-ify everything; the durable ones pick three or four tasks where the leverage is obvious and ignore the rest. We targeted three:

• Rule generation. Engineers describe what they need in plain English; the tooling pulls similar patterns from the DB, prompts Claude with them as exemplars, and produces a candidate rule the engineer reviews. The AI proposes, the engineer disposes.
• Log triage. Most error signatures have appeared before. The tooling parses incoming logs, looks up signature matches in the DB, and asks Claude to summarise the likely root cause plus the historical fix. Juniors stopped staring at 400-line stack traces cold.
• Troubleshooting flow. When triage doesn't yield a definitive hit, the tooling falls back to a guided conversation — Claude walks the engineer through diagnostic questions seeded from how seniors approach the problem class. The resolved conversation is captured back into the DB as a new playbook.

Each targeted a real bottleneck. Rule generation removed the typing tax on seniors; log triage shortened the unblock loop for juniors; the troubleshooting flow captured tribal knowledge as a side-effect of using it.

Phase 3 — translate the capability into sales narrative + cross-functional alignment

The third phase is the one most internal AI programmes skip, and the one that determines whether the work survives a leadership change. With the tooling working, I built a set of proof-of-concept demos targeted explicitly at sales: short, runnable, scoped to scenarios a prospect would recognise. Not generic "look, AI" demos — demos that showed Claude doing EPM-shaped work with practice-grounded context, in a form a salesperson could walk through in a pitch without being a technical specialist.

In parallel, I set up a standing cadence with leadership, delivery, and sales to keep the work pointed at business outcomes. Each cycle reviewed what shipped, where it landed in delivery margin or sales conversations, and what to build next. That cadence kept the work from drifting into the "skunkworks experiment that never lands" pattern that kills similar initiatives at adjacent firms.

Solution

Four named components, three internal and one external-facing.

1. Claude + local-DB architecture (long-term memory)

A self-hosted local database holds structured records of rule patterns, log signatures, root-cause mappings, and sanitised engagement notes. A thin retrieval layer sits between the engineer's query and Claude — pulling relevant records into the prompt as grounded reference, and writing new patterns back when a conversation resolves. This is what turns "Claude has read the internet" into "Claude has read our internet".

2. AI-assisted dev workflows (rule gen, log triage, troubleshooting)

The three workflows from Phase 2, packaged so a delivery engineer can reach them from their normal working environment without a context switch. Rule generation produces candidate rules grounded in prior patterns. Log triage matches incoming error signatures against the DB and proposes a likely fix path. The troubleshooting flow handles the long tail where signature matching fails. All three keep a human in the loop on every output — the AI accelerates the work, it doesn't ship the work.

3. PoC demo set for sales

A library of short, runnable proof-of-concept demos built specifically for pre-sales. Each dramatises a single capability — Claude generating a rule from a plain-English brief, triaging a synthetic log and proposing the historical fix, walking a planner through a forecast-variance investigation. Small enough to run live in a 45-minute conversation, concrete enough that a prospect can imagine them in their own environment. Sales doesn't have to translate engineering jargon into client language at runtime; the demos do that work in advance.

4. Cross-functional alignment cadence

A standing rhythm between leadership, delivery, and sales that keeps the programme accountable to business outcomes rather than novelty. Each cycle: what shipped, what landed in delivery throughput, what landed in sales conversations, what the next bet is. Unglamorous, but it's why the work has compounded across quarters rather than peaking on a single demo day and decaying.

Results

| Metric | Before | After | Change | |---|---|---|---| | Routine task latency (rule gen, log triage, common troubleshooting) | high — senior-attention bound | low — AI-assisted, senior-reviewed | step-change | | Junior engineer unblock time on familiar errors | long — Slack-and-wait | short — DB-grounded fix proposal in seconds | materially faster | | Sales-conversation AI differentiation | none — generic AI talking-point | meaningful — runnable PoCs grounded in EPM scenarios | new pre-sales surface | | Operational cost on internal tooling | notable — repeated senior-led rework | reduced — pattern reuse via local DB | tangible saving |

Soft outcomes:

• Knowledge stays in the practice, not in people. When a senior engineer solves a novel problem, the resolved conversation flows back into the local DB and becomes available to whoever hits the same shape next month — including engineers who weren't on the original engagement.
• Delivery consistency improved across concurrent projects. Rule patterns and troubleshooting playbooks are reused rather than reinvented, which has tightened the variance in how the practice ships similar work across different clients.
• The AI conversation in sales feels grounded rather than aspirational. The PoC demos let salespeople answer "what's your AI story?" with something runnable instead of a slide, which has changed the temperature of those conversations.

Learnings

What worked. Investing in memory before features. The instinct in most AI rollouts is to ship a chatbot first and worry about grounding later; we did it the other way round, and every downstream workflow was better for it. Pattern reuse compounds — each engagement adds to the DB, which makes the next engagement's AI assistance sharper. Treating sales as a first-class consumer also mattered: most internal AI programmes are built for delivery and "shown to sales" as an afterthought; building demos for sales from the start changed how the programme was perceived and gave it air-cover that pure internal tooling rarely gets.

What I'd do differently. Stand up the cross-functional cadence in week one, not month three. Early on I treated alignment as something to do once we had something to show; having leadership, delivery, and sales in the room from the start would have shortened the feedback loop and made the eventual rollout less of a surprise. The cadence isn't a reporting overhead, it's part of the product.

Skill developed. Recognising the difference between "AI that makes an individual faster" and "AI that makes a practice faster". They look similar from outside but compound very differently. Individual-scoped AI peaks at the productivity of whoever is using it that day; practice-scoped AI — grounded in shared memory and woven into cross-functional cadences — keeps getting better as the firm does more work. That distinction is now how I scope every AI engagement, internal or client-facing.