From a Question to a Repeatable Answer: How AIdeaBlocks Turns AI Conversations into Governed Business Outcomes

The problem with “ask AI and hope”

Ask an AI assistant “where are we leaking revenue?” today, and you’ll get a thoughtful, plausible-sounding answer — built fresh, from scratch, every time. Different prompt, different day, different analyst: different answer. For a one-off question, that’s fine. For a recurring business process that finance, sales ops, and leadership all rely on, it’s a liability. You can’t audit it, you can’t reproduce it, and you can’t hand it to a less senior teammate and trust the result.

The gap isn’t AI capability — it’s memory and structure. AI is brilliant at composing a solution in the moment, but has nowhere durable to put what it learned, and no shared map of how the pieces of your business actually connect.

AIdeaBlocks closes that gap. This post walks through one concrete story — revenue leakage detection — from the moment an idea takes shape in Claude, to a governed artifact graph, to a dashboard a business user opens every Monday morning.

Step 1: A domain taxonomy gives the AI a map

Before any analysis can be repeatable, the AI needs to know what things mean in your business — not just “a table called opp_amt” but “Salesforce Opportunity Amount, part of the Revenue domain, joins to ERP invoices on opportunity ID.” AIdeaBlocks’ domain taxonomy organizes the business into domains and groups (Revenue, CRM, Leads Intake, Finance, etc.), giving every artifact — every schema, policy, skill, dashboard — a place to live and a set of neighbors.

This isn’t documentation for humans. It’s the substrate that lets an AI reason about where a new artifact belongs and what it should connect to.

Step 2: Knowledge assets — the vocabulary of “what AI knows”

In AIdeaBlocks, everything the AI learns gets captured as a knowledge artifact:

  • Schema definitions — what an ERP Invoice record or a Salesforce Opportunity record actually looks like
  • Skills — reusable techniques, like “how to author a dashboard fragment”
  • Policies — the rules of the game: “Revenue Leakage Detection Policy” defines what counts as leakage, the thresholds, the logic
  • App views / dashboards (html_fragments) — the business-facing surface

Each of these is saved once, versioned, and reusable — not regenerated every time someone asks a question.

Step 3: The knowledge graph — relationships, not silos

Here’s where it gets interesting. A policy like “Revenue Leakage Detection Policy” doesn’t exist in isolation. It depends on the ERP Invoice Schema and the Salesforce Opportunity Schema to know what data it’s reasoning over. It depends on a “Dashboard Fragment Authoring Skill” to know how to render its findings. And it renders via a specific dashboard artifact that shows the leakage report to a human.

We recently added exactly this — a dependencies field on every artifact, capturing typed edges (depends_on_schema, depends_on_skill, renders_via, implements_policy, and more) with optional cross-domain links. The result is a living knowledge graph: pick any artifact, and you can see what it needs and what depends on it. Pull one node, and AIdeaBlocks can pull its whole supporting cast with it — schemas, skills, dashboards and all — when you export or share it.

This is the difference between “the AI happened to know about ERP invoices this one time” and “the policy formally requires the ERP Invoice Schema, and that requirement is visible, versioned, and enforceable.”

Step 4: MCP — Claude’s window into the graph

This is where Claude (or any MCP-compatible AI) enters the picture. Through the MCP connection, Claude can:

  • Read the existing graph — “what schemas and policies already exist for revenue analysis?”
  • Write new artifacts as it learns — capturing a new policy, schema, or dashboard the moment it’s designed
  • Traverse relationships — “this policy depends on these two schemas and a rendering skill; are they all present?”
  • Execute — run a flow, render a dashboard, populate it with live data

In other words, MCP turns AIdeaBlocks into Claude’s long-term memory and its hands. The AI isn’t reasoning in a vacuum each session — it’s reading the score, and it’s allowed to write new pages into it when it discovers something worth keeping.

Step 5: From design to deterministic, repeatable execution

Here’s the pivot that matters for the business: the first time someone asks Claude to investigate revenue leakage, Claude designs the approach — which data sources, what logic, what thresholds, how to present it. That design becomes artifacts: a policy, the schemas it depends on, a flow that joins CRM and ERP data, a dashboard fragment.

From that point on, the next run isn’t a fresh design exercise. It’s execution of a known, versioned flow — run_flow_by_name, governed by the policy, against current data. Same logic, same thresholds, same dashboard — just new numbers. The AI that runs it next week doesn’t need to “figure it out” again; it performs the score that was written.

That’s the determinism enterprises actually need: not “AI is creative every time,” but “AI is creative once, and then reliably repeats the validated approach” — until someone deliberately revises the policy, at which point the whole dependent graph can be reviewed for impact.

Why determinism actually holds: two layers, not one

It’s tempting to think “deterministic” just means “the flow runs the same way every time.” That’s true, but it’s the second of two layers — and the first is what makes the second trustworthy.

Layer 1 — consistent interpretation, via the dependency graph. When Claude encounters “revenue leakage” again — in a new session, a new conversation, maybe a different user — it doesn’t re-derive what that means from scratch. The dependency edges on the Revenue Leakage Detection Policy tell it: this concept depends on the ERP Invoice Schema, the Salesforce Opportunity Schema, and renders via this dashboard. The graph constrains interpretation. Claude isn’t free-associating about what “leakage” might mean this time — it’s reading the same definition every time, because the definition is the artifact, not a fresh inference.

Layer 2 — deterministic execution, via one-time validated generation. Once the interpretation is fixed, the pipeline logic (the flow) is generated once, validated, and saved. Every subsequent run reuses that validated flow rather than reinventing it. This is the “1 LLM call, 4 pre-generated steps” split in the Session Efficiency panel — the LLM call is the one-time composition; everything after is replay.

Put together: the dependency graph keeps what we mean stable, and the saved/validated flow keeps how we compute it stable. Determinism isn’t a property of the flow alone — it’s the flow sitting on top of a graph that already told Claude how to interpret the request the same way it did last time.

Step 6: Counting what you saved — the token economics of “ask once, run forever”

Every time an AI designs something from scratch — reasoning through what tables to join, what thresholds make sense, how to structure a dashboard — it burns tokens. A lot of them. Multiply that by every analyst, every Monday, every quarter, and “just ask the AI” gets expensive fast — in dollars, in latency, and in the inconsistency we talked about above.

The economics flip once the design becomes a governed artifact. Design happens once. Execution happens forever — and execution is mostly pre-generated, not re-reasoned. AIdeaBlocks’ Activity Monitor already tracks this, live, in the Session Efficiency panel:

  • Flows run — 13 this session, 13 success
  • Steps executed — 5, broken down into 1 LLM call vs 4 pre-generated steps
  • Tokens used — 7,695 (1,789 input / 773 output)
  • Est. cost — $0.0007, versus an estimated ~$0.0063 if a raw AI tool regenerated the same logic from scratch every time
  • $ saved / tokens saved — ~$0.0056 and ~4,000 tokens this session — an 80% savings vs. a raw AI tool

That 80% isn’t a one-time fluke — it’s structural. Most of a flow’s steps are pre-generated: they were designed once (the 1 LLM call), captured as a governed artifact, and every subsequent run replays that artifact instead of asking an LLM to rebuild it. The “Pipeline Forecasts” and “CRM Revenue Summary Week1” runs in the live feed are exactly this — deterministic executions against this week’s data, no redesign required.

Roll this up across a team — dozens of flows, hundreds of runs a week — and the savings become a real budget line, not a rounding error. And because it’s tracked per session and per org, it’s a number ops and finance leaders can point to directly: “this is what governed, reusable AI work costs us, versus what ad-hoc prompting would have cost.”

Step 7: App views and insight views — bringing it home

All of this — taxonomy, schemas, policies, the knowledge graph, MCP, flows — is plumbing. The business user never sees it. What they see is an app view or insight view: a dashboard that opens, shows this week’s revenue leakage findings, flags the opportunities and invoices that don’t reconcile, and ranks them by dollar impact.

That dashboard is renders_via the policy. The policy implements_policy against the rules finance agreed to. The data behind it flows through a governed, repeatable pipeline. If someone asks “why does this number say what it says,” the answer isn’t “the AI said so” — it’s “here’s the policy, here’s the schema it’s built on, here’s the flow that ran it, here’s when it last ran.”

The throughline

Domain taxonomy gives AI a map of the business. Knowledge assets give it a vocabulary. The dependency graph gives it relationships — what depends on what, and why, and ensures Claude interprets the same request the same way every time. MCP gives Claude (or any AI) the ability to read, extend, and execute against that graph. The flow, generated once and validated, turns that consistent interpretation into deterministic, repeatable execution. And app views/insight views give the business user the payoff: a trustworthy, repeatable answer to “where are we leaking revenue?” — one they can act on, audit, and trust to still be saying the same thing tomorrow.

We write the score. AI performs it.

Rehearsal is expensive — that’s where the thinking happens. Performance is cheap, fast, and exactly the same every time. The Session Efficiency panel is the receipt: 80% savings, because most of what runs today was already composed.