Demos · in plain English

Five everyday situations,
five clear calls.

Anyone running an AI product will recognize these. Each ends in a one-line recommendation — and there is no math on screen. Real evaluations run underneath; a translator turns each result into the decision you actually need.

Reproduce it: bash examples/business-cases/run.sh

STORY 1

The support bot that got a little worse every week

A support team lets its AI ticket-router “self-improve” each week. Every Monday it ships a tweak, and every Monday the tweak passes the weekly test. So everyone is happy. Are they right to be?

the weekly rollout — every week is green
  Week 1 — first version            → passed its test at 100% quality ✓
  Week 2 — 'streamline billing'     → passed its test at 90%  quality ✓
  Week 3 — 'catch more tech'        → passed its test at 80%  quality ✓
  Week 4 — 'simplify the rules'     → passed its test at 70%  quality ✓
  Week 5 — 'clean up'               → passed its test at 60%  quality ✓

$ agentvcs price   # now ask about the WHOLE story, not one week
🚨 BOTTOM LINE — the self-updates are BACKFIRING.

Left to keep editing itself, the agent is getting WORSE over time, not
better. Each weekly update passed its own test, so nothing looked wrong
week to week — the decline only shows up across the whole history.

→ Roll back to the best version and stop the unsupervised self-editing.

The aha: five green checkmarks hid a slow slide from 100% to 60%. No single week looked wrong — only the lineage did.

STORY 2

The same bot, run the smart way

Rewind. This time the team doesn’t let the bot rewrite itself in place. Each week it tries a couple of options and keeps the one that actually tests best.

try a few, keep the winner
  Start — modest baseline            60%
  Option A                           80%   Option B  70%   # A wins
  A, improved  90%   A, improved further  100%

$ agentvcs price
✅ BOTTOM LINE — the agent is genuinely improving.

Trying a few versions and keeping the best one is paying off: quality is
trending UP across the history, not just on any single test. Safe to continue.

Same effort, opposite outcome. The fix for a rotting loop isn’t more editing — it’s branch, test, and keep the winner.

STORY 3

The custom version for a big client that nobody merged back

For one important customer, the team forked a special version of the agent and kept patching it on the side for months, separate from the main product.

a fork drifting on its own
  Main product  100%
  BigClient patch 1..5   90% 80% 70% 60% 60%   # sliding, alone

$ agentvcs branch
  BigClient  ⚠ ratchet
* main
⚠️  BOTTOM LINE — the 'BigClient' version has drifted on its own too long.

It has been patched in isolation for several releases and its quality is
sliding. Versions maintained alone tend to rot — small mistakes pile up
with nothing to correct them.

→ Merge it back into the main product before it drifts further.

Isolated forks decay. agentvcs flags the one that has gone it alone too long and tells you to fold it back in.

STORY 4

Paying to stuff the prompt with context that changes nothing

An assistant reads a huge pile of company documents on every single question. It is slow and expensive. Is all that reading actually helping it answer?

a lot of reading, almost always the same move
$ agentvcs infobits
💸 BOTTOM LINE — you're paying for context the agent barely uses.

The agent reads a large amount of material on every request but almost
always does the same thing regardless. That context is hardly changing its
decisions — so you can trim it to cut cost and speed things up, with little
to no quality loss.

A quantified license to compress: if the context barely moves the decision, trimming it saves money and latency without hurting quality.

STORY 5

One wrong “fact” poisoned the whole fleet

A fleet of customer-facing agents shares a memory of things they’ve “learned”. One of them saves a wrong fact. Does it fade away — or spread to the others?

shared memory across a fleet
$ agentvcs contain
🦠 BOTTOM LINE — one bad memory entry will SPREAD across the fleet.

At the current fleet size and error rate, a single wrong 'fact' saved to the
shared memory gets read and re-used by other agents faster than it dies out.

→ Double-check at least 58% of what agents read from memory — or run a
  smaller fleet — to keep a mistake from snowballing.

$ agentvcs contain --fanout 2   # a smaller team
✅ BOTTOM LINE — a bad memory entry fades out on its own here.

A concrete safety knob: the verification rate that keeps a shared-memory mistake from snowballing — or just run a smaller fleet.

The takeaway

The value of agentvcs isn’t the equations — it’s the calls above. It watches your agents’ whole history and tells you, in plain terms: stop, this is getting worse · keep going, this is working · merge that fork back · cut this context · your shared memory can spread a mistake. The math is real (see the technical companion) — the decision-maker never has to see it.