The easiest response to an AI system that is not delivering enough value is often to add something: a newer model, another agent framework, a vector database, a different observability product, or another governance layer.

Sometimes the missing capability really is the problem. But platform leaders should first answer a more basic question:

What evidence shows that the current system is constrained by missing tooling?

If that cannot be answered, adding another product may increase architecture surface area without improving the outcome.

Measure the outcome, not the presence of AI

Start with the business or operational result the system exists to improve: task completion, decision quality, cycle time, rework, accepted outputs, successful user outcomes, time returned to employees, or qualified customer progression.

Token volume, agent runs, tool calls, model invocations, and generated artifacts can explain system behavior. They do not by themselves demonstrate value.

INFERENCE: if AI activity cannot be connected to the intended outcome, there is not yet enough evidence to conclude that another AI tool will improve that outcome.

Measure quality with workload-specific evaluations

Generative systems are variable. Traditional deterministic tests remain necessary, but they are not sufficient for every model-mediated behavior.

OpenAI's current evaluation guidance treats evals as structured tests for model/system performance and uses traces and graders for agent workflows. NIST's AI RMF Measure function calls for assessment, benchmarking and monitoring, including testing before deployment and regularly during operation.

Define representative tasks, define a good result, retain failure cases, test changes against the same workload, and monitor regressions.

For agents, inspect whether the system chose the correct tool, respected boundaries, handed work off correctly, stopped when required, and left evidence another actor can verify.

VERIFIED FACT: NIST's AI RMF Measure function explicitly includes quantitative, qualitative, or mixed-method assessment and regular operational testing.

INFERENCE: expand tooling after evidence shows a material evaluation failure that the proposed tool can plausibly address.

Measure reliability as a service property

An AI workflow is still a production system. Track availability, latency, error and timeout rate, capacity, dependency failures, recovery behavior, retries, and successful completion.

Google SRE treats availability, latency, performance, and capacity as core operational concerns and uses SLO/error-budget practices to make reliability tradeoffs explicit.

AI adds provider limits, context failures, tool-call errors, retrieval misses, policy denials, malformed outputs, and nondeterministic behavior. It does not make conventional reliability engineering obsolete.

A second model provider does not solve an unclear SLO. A new agent framework does not solve an unknown failure rate.

Measure unit economics at the useful-outcome level

AI cost is larger than model price. Include model/API consumption, inference infrastructure, retrieval/data services, orchestration, observability/security, engineering labor, human review, retries, and failed runs.

FinOps Foundation guidance includes normalized unit-economics measures and AI-relevant measures such as cost per API call.

HYPOTHESIS: for many enterprise AI systems, cost per useful or accepted outcome will be more decision-relevant than cost per token. The correct denominator must be tested against the actual workload.

Measure authority and governance failures

For agentic systems, measure what the system was allowed to do, not only what it completed.

Track denied tool calls, attempted out-of-scope actions, approval requests, policy violations, permission failures, sensitive-data access, escalation frequency, and actions that cannot be reconstructed afterward.

NIST's AI RMF organizes risk work around Govern, Map, Measure, and Manage and includes accountability, transparency, security, resilience, privacy, and other trustworthiness characteristics.

INFERENCE: if authority failures cannot be observed, the organization cannot reliably determine whether a new capability increases controlled value or merely increases reachable action surface.

Measure actual usage and abandonment

Track who uses the system, which workflows recur, repeat use, abandonment, human overrides, rework, rarely used capabilities, and workarounds outside the platform.

Low adoption does not automatically mean the platform needs more features. It may indicate poor workflow fit, trust problems, insufficient quality, missing integration, unclear ownership, or a problem that was never important enough to automate.

The expansion test

Before approving another AI tool, complete this sentence:

We measured [blank]. The current system misses [blank]. Evidence indicates the constraint is [blank]. The proposed tool changes that constraint by [blank]. We will know it worked when [blank] changes without unacceptable regression in [blank].

If those blanks cannot be filled with evidence, the architecture decision is premature.

The purpose of measurement is not to prevent experimentation. It is to make experimentation cumulative.

Before asking “What should we add?”, ask:

“What does the evidence say is limiting us now?”

That question turns an AI toolchain from a collection of products into an architecture that can be managed.

Source lineage and claim discipline

CTA

Subscribe to Decision Crafters for practical architecture notes on building, measuring, and governing AI systems before complexity becomes the operating model.