Case Study
Agent 14 · AI Use Case ROI Estimator
How a four-block output schema — verdict, scored dimensions, risks, and next steps — turns a free-text use case description into a structured business case that stakeholders can act on without technical translation.
The Problem
AI use cases rarely fail because the technology doesn't work. They fail because the business case was never made clearly enough to survive procurement, prioritisation, or the first uncomfortable question from a CFO. Product managers and business analysts can describe what an AI use case would do — but translating that into a credible effort-versus-impact framing, with explicit risks and a sequenced path forward, is slow and inconsistent work.
The default approach is a spreadsheet or a slide deck assembled by someone with partial information, anchored to optimistic assumptions, and missing the risk factors that will surface six months into delivery. The result is either stalled investment or poorly scoped projects that hit avoidable problems.
Design Approach
Agent 14 is stateless by design — one use case description in, one complete ROI report out. The architecture is identical in principle to Agent 13: a single API call, a structured output schema parsed by the frontend, and distinct UI components for each output block. What differs is the output domain. Review analysis produces sentiment and themes. ROI estimation produces scores, risks, and a directional verdict.
The core design decision was to split the output into four distinct blocks: an OVERVIEW with a binary verdict and three scored dimensions, a SCORES block with human-readable labels for each dimension, a RISKS block with specific mitigations, and a NEXTSTEPS block written for business stakeholders. Each block answers a different question a decision-maker would ask when evaluating an AI investment.
The verdict field is constrained to three values: Strong ROI, Moderate ROI, or Low ROI. This forces the model to commit to a directional assessment rather than hedging, and it maps directly to a colour-coded pill in the UI — green, amber, or red — giving stakeholders an immediate signal before reading the detail.
The input is a textarea to match the multi-line nature of use case descriptions. The send button is labelled "Estimate" rather than "Send" or "Analyse" — a deliberate word choice that signals quantification, not just comprehension.
System Prompt Architecture
The system prompt defines four delimiter blocks — ===OVERVIEW===, ===SCORES===, ===RISKS===, and ===NEXTSTEPS=== — each parsed independently by the frontend. The OVERVIEW and SCORES blocks are tightly coupled: OVERVIEW carries the machine-readable integers; SCORES carries the matching prose labels. The frontend renders both together as a single score card per dimension.
Overview Block
VERDICT plus three integer scores (EFFICIENCY, COMPLEXITY, SPEED) and a single-sentence HEADLINE that commits to an assessment. No hedging language is permitted — the prompt instructs the model to state a position, not a possibility.
Scores Block
Three label fields — EFFICIENCY_LABEL, COMPLEXITY_LABEL, SPEED_LABEL — each carrying a human-readable interpretation of the integer score. This is the translation layer between bar-chart logic and business comprehension.
Risks Block
2–3 bullet points capped at 25 words each. Each risk must name a category, describe the specific risk for this use case, and state the mitigation. Generic AI risk boilerplate is explicitly prohibited in the prompt.
Next Steps Block
2–3 actions written for a business stakeholder, each achievable within 30 days, each starting with a verb and stating the decision or output it unlocks. Avoids technical implementation steps — this is a business case tool, not an engineering spec.
What I Learned
Verdicts require explicit constraints. Without constraining the VERDICT field to three specific values, the model produces qualitative prose — "this use case shows promise but has meaningful risks" — which cannot be mapped to a UI component or parsed reliably. The three-value constraint eliminates ambiguity and forces a decision, which is exactly what stakeholders need.
Numeric and prose fields must be separate. The most important structural lesson from building Agent 14 is that a field used for display logic (a bar chart width) and a field used for human reading (a label) cannot be the same field. They require different formats, different constraints, and different parsing logic. Keeping them in separate blocks eliminates format collisions.
Risk quality is the hardest prompt constraint to enforce. Generic risk bullets — "AI models can hallucinate," "change management is important" — are the default without explicit instruction. The 25-word cap, the category-naming requirement, and the prohibition on boilerplate together push the model toward use-case-specific risks. It still requires the most prompt iteration of any block.
The audience for next steps is not the builder. Early testing produced next steps written for an engineering team — "stand up a vector database," "evaluate embedding models." The prompt was revised to explicitly target a business stakeholder and specify a 30-day execution window. The output shifted immediately to procurement decisions, stakeholder workshops, and pilot scoping — which is where business cases actually live.
Typical Token Profile
A single use case description estimated in one API call typically produces: