> ## Documentation Index
> Fetch the complete documentation index at: https://docs.minoa.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Update Your Value Framework with Your AI Agent

> Add use cases, tune calculations, and publish changes to your value framework from a chat with your own AI assistant

Your value framework is the engine behind every business case your team builds. It's also the thing that quietly goes stale — a benchmark from two years ago, a use case nobody sells anymore, a calculation that never quite matched how the win actually happened.

Keeping it current used to mean setting aside an afternoon for the builder. Now you can just describe what you want in Claude (or whichever assistant your team uses), and your agent does the work. Nothing goes live until you've seen the numbers and said yes.

<Info>
  You'll need a connected MCP client and admin access to your Minoa workspace. If you haven't connected yet, start
  with the [Minoa MCP Server](/pages/integrations/mcp) page — it takes a couple of minutes and works with
  [Claude](/pages/integrations/ai-assistants/claude), [Glean](/pages/integrations/ai-assistants/glean),
  [Dust](/pages/integrations/ai-assistants/dust), and others.
</Info>

## Draft, review, publish

Before the steps, it's worth knowing how this is wired — because it's the reason you can hand real work to an agent without holding your breath.

Your agent never edits the live library. Every change lands in your own private draft, which nobody else on your team sees. When you're ready, you ask for a review: your agent shows you what changed **and** what each calculation now produces on its default values. Only after you approve, naming the use cases you want, does anything reach sellers.

<Tip>
  Your drafts show up in the web app too, under **Value Framework → Reviews**. Start in chat, finish in the UI, or the
  other way round — it's the same staging area.
</Tip>

<Steps>
  <Step title="See what you already have">Ask your agent to browse the library so you don't rebuild something that exists.</Step>
  <Step title="Describe the value story">Create the use case in plain language — the outcome, not the feature.</Step>
  <Step title="Build the calculation">Hand over the inputs and the logic, and let your agent assemble it.</Step>
  <Step title="Add industry-specific defaults">Give sellers preset options when the right number depends on the customer.</Step>
  <Step title="Write an internal note">Leave enablement guidance for the sellers who'll pick this up.</Step>
  <Step title="Reuse shared numbers">Link inputs to global inputs so assumptions stay consistent.</Step>
  <Step title="Review the numbers">Check the math before anyone sees it.</Step>
  <Step title="Publish">Approve by name and push it live.</Step>
</Steps>

## Step 1: See what you already have

Start by asking what's in the library. Most "we need a new use case" conversations end with a small edit to one that already exists.

> "What use cases do we have in our value framework? Anything already covering accounts payable or invoice handling?"

If something looks close, pull it up in full:

> "Show me the full detail of Reduce Manual Invoice Processing — inputs, formulas, defaults, and the internal notes."

Your agent can also tell you what's actually working, which is the better place to start than a gut feel:

> "Which of our use cases show up most often in won deals, and which have the highest ROI?"

<Tip>
  A library of 12 sharp use cases beats one of 40 that sellers scroll past. Before you add, check whether you should
  be editing instead.
</Tip>

## Step 2: Describe the value story

Nothing here is a form. Describe the outcome the way you'd describe it to a buyer, and your agent turns it into a use case in your draft.

> "Create a use case called 'Reduce Time Spent on Manual Invoice Processing'. The story: finance teams process invoices by hand, it takes about 12 minutes each, and our automation handles the routine ones end to end. Write a description that speaks to a VP Finance, not to an engineer."

Name it for the outcome, not the feature. "Reduce Time Spent on Manual Invoice Processing" lands with a buyer. "Invoice Automation Module" doesn't. If you want the full reasoning, [Use Cases](/pages/value-framework/use-cases) covers it.

## Step 3: Build the calculation

This is where most of the time normally goes, and where handing it over pays off most. Give your agent the inputs, the logic, and — critically — where the numbers come from.

> "Build a cost reduction calculation on it. Inputs: number of invoices per month, average minutes per invoice, and loaded hourly cost of a finance analyst. Default the minutes to 12 — that's from the Northwind rollout last year. Add a highlighted input for the automation rate, defaulting to 60%. Show me current annual cost versus projected annual cost."

A few things worth knowing as you write that prompt:

| Shape of calculation | What it shows                              | Reach for it when                                 |
| :------------------- | :----------------------------------------- | :------------------------------------------------ |
| **Cost reduction**   | Current costs next to projected costs      | Time saved, headcount avoided, tools consolidated |
| **Revenue uplift**   | Current revenue next to projected revenue  | Faster cycles, better win rates, more upsell      |
| **Non-monetary**     | A quantified outcome with no dollar figure | Hours returned, errors avoided, risk reduced      |
| **Custom**           | A single net benefit                       | Anything that doesn't fit the shapes above        |

<Warning>
  Tell your agent where every default comes from. Left to guess, an agent will produce a number that looks plausible
  and falls apart the moment a CFO asks about it. Anchor defaults to a real customer result, an analyst figure, or
  your own use case analytics — and say so in the prompt, so the source gets recorded on the input.
</Warning>

Prefer to build this one by hand? The [Create a Custom Calculation](/pages/recipes/create-custom-calculation) recipe walks through the same structure in the UI.

## Step 4: Add industry-specific defaults

Some numbers genuinely change by customer. An automation rate that's realistic in retail may be optimistic in financial services, where more invoices need a human eye.

For those, ask for preset options on a highlighted input. Sellers then pick the one that fits their deal instead of guessing.

> "On the automation rate input, add presets: Retail 70%, Manufacturing 65%, Financial Services 45%. Make Manufacturing the default — that's where most of our pipeline sits."

<Tip>
  Presets are a scalpel, not a default setting. One well-researched number beats three invented options. Use them only
  when the right value genuinely depends on something a seller knows up front, like industry or company size.
</Tip>

<Warning>
  Presets are edited as a complete set. If you ask to change one option, your agent resends all of them — so glance at
  the full list in the review before you publish.
</Warning>

## Step 5: Write an internal note

This is the step people skip, and the one that makes the difference between a use case sellers trust and one they avoid.

Internal notes are seller-facing only. Your buyer never sees them. Use them for the context that doesn't belong in a customer-facing description:

> "Add an internal note: strongest with ops and finance leaders who've already centralized AP. Skip it if they're running a shared services center — the baseline is too low to be compelling. The 12-minute figure comes from the Northwind rollout; ask about invoice volume in discovery before you commit to it."

That's the difference between a seller using this well and a seller quoting a number they can't defend.

## Step 6: Reuse shared numbers

Half your use cases probably need a loaded hourly cost. When each one carries its own copy, updating a benchmark means hunting through the library.

Global inputs solve that. Ask your agent to point an input at one that already exists:

> "Link the loaded hourly cost input to our existing Loaded Hourly Cost global input."

Your agent will match by type and unit, and refuse the link if they don't line up — which is exactly what you want, since a mismatched link quietly corrupts the benchmark for everyone. Creating new global inputs is still a job for the app; see [Working with Global Inputs](/pages/business-case/global-inputs).

## Step 7: Review the numbers

Now the important part. Ask for a review before anything goes live.

> "Walk me through my draft — what changed, and what does the calculation produce on the default values?"

You'll get two things back: a summary of what changed, and the computed result of every calculation you touched, evaluated on its defaults.

<Warning>
  Read the numbers, not just the list of changes. A misplaced decimal is obvious from "\$4.2M a year for a 40-person
  finance team" and completely invisible in a list of edited fields.
</Warning>

Run through this quickly:

* **Is the magnitude believable?** Say the result out loud to an imaginary CFO. If you'd hedge, fix it now.
* **Is the direction right?** Projected costs should land below current costs. Projected revenue above current revenue.
* **Do the defaults describe a real customer?** Not the best one you ever had, and not a hypothetical.
* **Do the presets hold up?** The review shows the default option's math — sanity-check the others yourself.

Anything off, say so in plain language. Your agent fixes it in the draft and re-runs the review.

> "The projected cost looks too low. We're claiming we automate away the review step entirely, and we don't — assume analysts still spot-check about 15% of invoices."

## Step 8: Publish

When the numbers hold up, approve by name.

> "Publish Reduce Time Spent on Manual Invoice Processing."

Naming the use case is deliberate. There's no publish-everything shortcut, so a half-finished draft sitting in your staging area can't ride along with a change you meant to ship.

<Check>
  Your use case is live. Sellers will see it the next time they build a business case — existing business cases stay
  untouched, so nothing in flight shifts under a deal you're working.
</Check>

Two things to know about what happens here. If a draft conflicts with a change someone else published, it gets skipped and reported back rather than overwriting their work — your draft stays put so you can re-apply it. And if you staged a deletion, publishing makes it permanent.

<Tip>
  New use cases can sit hidden in the library while you build them out. When you want sellers to actually see this
  one, say so: "make it visible in the library."
</Tip>

## More you can ask for

Same conversation, same draft-review-publish safety net:

* **Fix a calculation** — "The hourly rate default is stale. Bump it to \$58 and note that it's from the 2026 comp bands."
* **Repair a formula** — "The annual hours subtotal is multiplying by 12 twice. Fix it and show me the new numbers."
* **Rename things in buyer language** — "Rename '# of Invoices' to 'Monthly Invoice Volume'."
* **Hunt by industry** — "Which use cases are tagged Manufacturing, and which of those have real customer proof behind them?"
* **Retire what's dead** — "Archive the legacy onboarding use case. Nobody's used it in a year."
* **Start over** — "Discard my draft." That's irreversible for your staged work, though the published version is untouched.

## What still lives in the web app

Your agent covers use cases and calculations. A few things are still UI work:

* **Resources and proof points** — case studies, whitepapers, and links live in the **Resources** tab. Your agent can help you decide *which* proof point a use case needs; attaching it is a manual step for now.
* **Properties and tags** — your agent can read them, so it can find every use case tagged Healthcare. Setting them is done in the app. See [Properties](/pages/value-framework/properties).
* **Company context, slide templates, and milestone templates** — all UI.
* **Creating new global inputs** — your agent links to existing ones; new ones are created in the app.

We're steadily widening what your agent can reach, so expect this list to get shorter.

## Value Agent, or your own assistant?

Both exist, and they write to the same drafts.

The [Value Agent](/pages/value-framework/value-framework-copilot-beta) is built into the Value Framework screen. It sees what you're looking at, and it handles properties and global inputs, which the MCP tools don't.

Your own assistant is the better choice when the work starts outside Minoa — a spreadsheet of benchmarks from your product team, a competitor's ROI model, notes from a customer QBR, research you want your agent to do first. It brings that context with it and turns it straight into use cases.

<Info>
  One person editing at a time is the safe habit either way. Two people staging changes to the same use case will
  conflict, and the loser's draft gets skipped at publish.
</Info>

## Key takeaways

* **Nothing goes live by accident.** Every change stages in your private draft until you approve it by name.
* **Review the computed numbers, not the diff.** A wrong magnitude shows up in the result, never in a field list.
* **Ground every default in something real.** Tell your agent the source and it gets recorded on the input.
* **Internal notes are where enablement happens.** A number without context is a number sellers won't defend.
* **Start by reading the library.** The best value framework edits are usually edits, not additions.