The AI Evaluation Stack: How to Test Models, Retrieval, Agents, and Business Outcomes

Enterprise AI is moving from experimentation to production. That shift creates a new responsibility: companies must stop evaluating AI only by whether a demo looks impressive and start evaluating whether the full system works reliably in real workflows.

A model can sound fluent and still be wrong. A retrieval system can find documents and still retrieve the wrong ones. A RAG assistant can cite sources and still cite sources that do not support the answer. An AI agent can complete a task and still use an unsafe tool path. A workflow can show high AI usage and still fail to improve business outcomes.

That is why enterprise leaders need an AI evaluation stack.

An AI evaluation stack is the set of methods, metrics, datasets, tools, reviews, and operating practices used to test AI systems at every layer: model output, retrieval quality, groundedness, agent behavior, safety, cost, reliability, human review, and business impact. It is not one benchmark. It is not one score. It is a layered system for proving that AI is useful, safe, and worth scaling.

The need is urgent. McKinsey’s 2025 global AI survey found that 88% of organizations reported regular AI use in at least one business function, but the companies seeing the strongest results are more likely to redesign workflows, embed AI into business processes, define human validation steps, and track KPIs [1]. Deloitte’s 2026 enterprise AI research found that worker access to AI rose by 50% in 2025, while leaders are focused on ROI, safe and ethical practices, workforce readiness, and moving from pilot to scale [2]. Stanford HAI’s 2026 AI Index reports that documented AI incidents rose to 362 in 2025, up from 233 in 2024, while responsible AI measurement still lags behind capability growth [3]. Gartner has also warned that more than 40% of agentic AI projects may be canceled by the end of 2027 because of rising costs, unclear business value, or inadequate risk controls [4].

For consideration-stage buyers, the conclusion is clear: AI systems should not move to production unless the evaluation stack is stronger than the prototype.

Executive Summary: What the AI Evaluation Stack Must Prove

The enterprise AI evaluation stack must answer five questions:

1. Does the model produce the right output?
This is classic AI model evaluation: accuracy, relevance, format, tone, refusal behavior, reasoning quality, structured-output validity, safety, and consistency.

2. Does the system retrieve the right evidence?
This is retrieval and RAG evaluation: context relevance, context precision, context recall, source authority, freshness, groundedness, citation accuracy, and answer relevance.

3. Does the agent behave correctly across steps?
This is AI agent evaluation: task completion, trajectory, tool choice, tool parameters, tool output use, handoffs, escalation, autonomy boundaries, and side-effect safety.

4. Does the system stay inside risk boundaries?
This is safety and governance evaluation: prompt injection resistance, sensitive data leakage, role-based access, refusal accuracy, policy compliance, bias and fairness, auditability, and human oversight.

5. Does the AI improve a business outcome?
This is value evaluation: cycle-time reduction, cost per workflow, backlog reduction, human acceptance rate, quality improvement, revenue impact, risk reduction, customer experience, and ROI.

A production-ready AI system needs all five. A model-only evaluation is not enough. A business-only ROI view is not enough. A safety checklist without output quality is not enough. The stack must connect quality, risk, and business value.

Why Traditional Software Testing Is Not Enough

Traditional software testing assumes that, given the same input and same code, the system should usually produce the same deterministic result. Generative AI does not always behave that way. OpenAI’s evaluation guidance states that generative AI can produce different outputs from the same input, making traditional software testing insufficient on its own; evaluations are a way to test AI systems despite that variability [5].

That means enterprise AI testing needs to evaluate behavior, not only code. It needs datasets, rubrics, graders, human review, trace analysis, security tests, and production monitoring. OpenAI’s eval documentation describes evaluations as a way to test model outputs against style and content criteria, especially when upgrading or trying new models [6]. Microsoft Foundry’s observability documentation similarly treats evaluation and monitoring as core production practices, with built-in evaluators for quality, RAG-specific measures such as groundedness and relevance, safety and security metrics, and agent-specific metrics such as tool-call accuracy and task completion [7].

In practical terms, the AI evaluation stack is the quality system for enterprise AI.

The Seven-Layer AI Evaluation Stack

Etheon recommends a seven-layer framework:

1. Business outcome evaluation

2. Dataset and test-case evaluation

3. Model output evaluation

4. Retrieval and RAG evaluation

5. AI agent evaluation

6. Safety, security, and governance evaluation

7. Production observability and continuous evaluation

Each layer has a different purpose. Together, they create the evidence needed to decide whether an AI system should be launched, expanded, redesigned, or stopped.

Layer 1: Business Outcome Evaluation

The first evaluation question is not technical. It is commercial and operational: what business result should this AI system improve?

AI systems are often tested on examples before the business case is defined. That is backwards. The evaluation stack should begin with a measurable workflow outcome.

Business outcome evaluation should define:

- The workflow being improved.

- The current baseline.

- The target KPI.

- The user group.

- The business owner.

- The expected value.

- The risk tier.

- The cost model.

- The scale gate.

Examples of business outcome metrics include:

1. Use case: Customer support assistant

Business outcome metric: First response time, average handle time, escalation accuracy, CSAT

2. Use case: Finance variance assistant

Business outcome metric: Commentary preparation time, forecast cycle time, reviewer acceptance

3. Use case: Internal knowledge assistant

Business outcome metric: Repetitive support tickets reduced, answer acceptance, search time saved

4. Use case: AI coding assistant

Business outcome metric: Pull request cycle time, defect rate, test pass rate, developer acceptance

5. Use case: AI agent for operations

Business outcome metric: Task completion rate, backlog reduction, cost per completed workflow

6. Use case: Compliance assistant

Business outcome metric: Evidence collection time, unsupported answer rate, review acceptance

7. Use case: Sales assistant

Business outcome metric: CRM completeness, meeting prep time, follow-up speed, pipeline movement

McKinsey’s finding that high performers redesign workflows and track AI KPIs is critical here [1]. If the AI system is not connected to a workflow KPI, the business may end up measuring prompts instead of value.

Evaluation gate: Do not start production evaluation until the target business outcome and baseline are documented.

Layer 2: Dataset and Test-Case Evaluation

The second layer is the evaluation dataset. A weak dataset produces weak confidence.

AI evaluation datasets should not contain only ideal examples. They should represent the workflow realistically: normal cases, edge cases, negative cases, high-risk cases, ambiguous cases, outdated data, adversarial prompts, and past failures.

NIST’s AI Test, Evaluation, Validation, and Verification work emphasizes designing evaluations, developing tasks and challenge problems, creating testbeds and tools, curating meaningful datasets, and identifying technical gaps and limitations in AI technologies [8]. NIST’s Generative AI Profile also frames evaluation as part of trustworthiness and lifecycle risk management for generative AI systems [9].

A strong evaluation dataset includes:

- Real historical examples.

- Expert-labeled expected outputs.

- Edge cases.

- Negative cases the AI should refuse or escalate.

- Security test cases.

- Data leakage test cases.

- Role-based access cases.

- RAG retrieval cases.

- Agent tool-call cases.

- Business KPI cases.

- Human review samples.

For example, a RAG assistant should be tested with questions that have clear answers, questions with no answer in the knowledge base, questions where sources conflict, questions where the best source is newer than older content, and questions the user is not authorized to answer.

An AI agent should be tested with successful tool paths, missing data, wrong tool outputs, API failures, unauthorized tool attempts, prompts that request prohibited actions, and cases that require human escalation.

Evaluation gate: The dataset must represent the real workflow, not only the demo path.

Layer 3: AI Model Evaluation

AI model evaluation tests the model’s direct output quality before and during system integration. This includes LLMs, small language models, classifiers, extraction models, forecasting models, and multimodal models.

Model-level metrics may include:

- Accuracy.

- Relevance.

- Completeness.

- Format adherence.

- Structured-output validity.

- Instruction following.

- Refusal correctness.

- Safety compliance.

- Tone and brand fit.

- Reasoning quality.

- Consistency.

- Latency.

- Cost.

- Human acceptance rate.

For generative AI, exact-match accuracy is often insufficient. Teams may need human rubrics, model-graded rubrics, deterministic schema checks, and expert review. Google Cloud’s Gen AI evaluation service documentation describes adaptive rubrics as tailored pass/fail tests for individual prompts, similar to unit tests in software development [20]. This is a useful product principle: evaluation criteria should be specific to the task, not generic.

A good model evaluation process compares candidates against the same dataset. For example, an enterprise might test a frontier model, an open-weight model, and a small language model on the same workflow examples, then compare accuracy, latency, cost, refusal behavior, and human acceptance.

Model evaluation should answer:

- Which model meets the quality threshold?

- Which model is too slow or too expensive?

- Which model fails on edge cases?

- Which model handles structured outputs best?

- Which model refuses unsafe requests correctly?

- Which model performs best with domain terminology?

- Which model should be used as fallback or escalation?

Evaluation gate: Choose the simplest model that meets task quality, privacy, latency, cost, and governance requirements.

Layer 4: Retrieval and RAG Evaluation

Retrieval-augmented generation is one of the most common enterprise AI architectures because it connects models to internal documents, policies, knowledge bases, contracts, tickets, product documentation, and customer records. But RAG can fail in two places: retrieval and generation.

A RAG system can retrieve irrelevant context. It can retrieve the right document but the wrong chunk. It can retrieve outdated or unauthorized content. It can generate an answer that is not supported by the retrieved context. It can cite sources that do not actually support the claim.

That is why RAG evaluation must be component-level and end-to-end.

LangSmith’s RAG evaluation documentation frames RAG as a technique that enhances LLMs by giving them relevant external knowledge and shows how to evaluate RAG applications with datasets and evaluators [13]. Ragas provides metrics for evaluating LLM applications, including RAG and agentic workflows, with context precision measuring whether retrieved contexts are useful for answering a question [14]. TruLens describes the RAG triad as context relevance, groundedness, and answer relevance; these three evaluations test whether the retrieved context is relevant, whether the answer is supported by that context, and whether the answer addresses the user’s question [15].

A complete RAG evaluation stack should measure:

1. RAG metric: Context relevance

What it answers: Did retrieval find content relevant to the question?

2. RAG metric: Context precision

What it answers: Were the top retrieved chunks useful, or noisy?

3. RAG metric: Context recall

What it answers: Did retrieval include all necessary evidence?

4. RAG metric: Source authority

What it answers: Did the system prefer official, current sources?

5. RAG metric: Freshness

What it answers: Did it avoid stale or superseded content?

6. RAG metric: Permission correctness

What it answers: Did it retrieve only content the user can access?

7. RAG metric: Groundedness

What it answers: Is the generated answer supported by retrieved context?

8. RAG metric: Citation accuracy

What it answers: Do cited sources actually support the answer?

9. RAG metric: Answer relevance

What it answers: Does the answer address the user’s request?

10. RAG metric: Refusal accuracy

What it answers: Does the system refuse when evidence is missing?

The most important enterprise RAG tests are often not technical retrieval scores alone. They are business-risk tests: can the system refuse when no approved source exists? Can it avoid restricted documents? Can it prefer the current policy over an outdated draft? Can it show which source it used?

Evaluation gate: A RAG system is not production-ready until retrieval quality, source authority, permission enforcement, groundedness, and citation accuracy are tested.

Layer 5: AI Agent Evaluation

AI agent evaluation is more complex because an agent may perform a sequence of steps. It may plan, retrieve, call tools, use APIs, hand off to another agent, request human approval, and then produce a final answer.

OpenAI’s agent evaluation guidance describes using traces, graders, datasets, and evaluation runs to improve agent quality [10]. Microsoft’s Agent Evaluators documentation states that agent evaluators provide observability into agentic workflows by measuring quality, safety, and performance, including task completion, task adherence, intent resolution, tool call accuracy, tool selection, tool input accuracy, tool output utilization, and tool call success [11]. LangSmith’s complex-agent evaluation documentation separates final-response evaluation, trajectory evaluation, and single-step evaluation, including whether the agent took the expected tool-call path [12].

That creates three evaluation surfaces:

1. Final response evaluation

Did the agent produce the correct final answer, recommendation, update, or summary?

2. Trajectory evaluation

Did the agent take the right path to get there? Did it retrieve the right information, call the right tools in the right order, avoid unnecessary calls, and escalate correctly?

3. Tool-call evaluation

Did it select the right tool, pass the right parameters, interpret the output correctly, and avoid unauthorized or unsafe tool use?

Recommended AI agent evaluation metrics include:

1. Agent metric: Task completion rate

What it measures: Whether the agent completed the workflow correctly

2. Agent metric: Task adherence

What it measures: Whether it followed the intended instructions and process

3. Agent metric: Trajectory accuracy

What it measures: Whether it took the expected path through tools and steps

4. Agent metric: Tool selection accuracy

What it measures: Whether it chose the right tool

5. Agent metric: Tool input accuracy

What it measures: Whether tool parameters were correct

6. Agent metric: Tool output utilization

What it measures: Whether it used returned results correctly

7. Agent metric: Escalation accuracy

What it measures: Whether it routed high-risk or uncertain cases to humans

8. Agent metric: Unauthorized action attempts

What it measures: Whether it tried to access prohibited tools or data

9. Agent metric: Loop rate

What it measures: Whether it repeated steps unnecessarily

10. Agent metric: Cost per completed task

What it measures: Whether the trajectory is economically viable

Agent evaluation must also test autonomy level. An agent that is safe as a recommender may not be safe as an autonomous operator. Production autonomy should be earned through evaluation evidence.

Evaluation gate: No AI agent should receive production write access until final output, trajectory, tool use, escalation, and safety tests meet defined thresholds.

Layer 6: Safety, Security, and Governance Evaluation

The sixth layer tests whether the AI system stays within enterprise risk boundaries.

OWASP’s 2025 Top 10 for LLM applications includes prompt injection, sensitive information disclosure, supply chain vulnerabilities, improper output handling, excessive agency, vector and embedding weaknesses, misinformation, and unbounded consumption [16]. ISO/IEC 42001 provides a management-system approach for responsible AI development and use, including risk assessment and treatment [17]. The EU AI Act implementation timeline shows AI rules applying progressively, with general provisions and AI literacy obligations from February 2, 2025 and general-purpose AI rules from August 2, 2025, while broader rollout continues through 2026 and 2027 [18].

Safety evaluation should include:

- Prompt injection testing.

- Indirect prompt injection testing.

- Sensitive data leakage testing.

- Role-based access testing.

- Cross-tenant leakage testing.

- System prompt leakage testing.

- Tool abuse testing.

- Excessive agency testing.

- Bias and fairness testing where relevant.

- Refusal testing.

- Human oversight testing.

- Auditability testing.

- Incident response testing.

For example, a secure internal AI assistant should be tested with users from different departments to ensure it does not reveal restricted finance, HR, legal, customer, or engineering data. A customer-facing assistant should be tested for unsupported claims, unsafe advice, escalation failures, and privacy leakage. An agent should be tested against prompt injection, malicious documents, tool misuse, and attempts to bypass approval.

Safety evaluation should not be only pass/fail. It should produce a risk profile: which risks are controlled, which remain, what compensating controls exist, and what must be fixed before scale.

Evaluation gate: If the system cannot prove role-based access, sensitive data protection, prompt injection containment, and human oversight, it should remain in pilot.

Layer 7: Production Observability and Continuous Evaluation

The seventh layer is what happens after launch. Evaluation is not finished when the system goes live.

Production AI systems need observability. OpenAI’s Agents SDK observability documentation states that every agent run can emit structured records of model calls, tool calls, handoffs, guardrails, and custom spans [19]. Microsoft Foundry’s observability documentation describes production monitoring with dashboards for operational metrics, token consumption, latency, error rates, and quality scores, plus alerts when outputs fail quality thresholds or produce harmful content [7].

Production observability should track:

- User request.

- User role.

- Prompt version.

- Model version.

- Retrieved documents.

- Source citations.

- Tool calls.

- Tool parameters.

- Tool outputs.

- Guardrail decisions.

- Refusals.

- Human approvals.

- Human overrides.

- Latency.

- Cost.

- Errors.

- Quality scores.

- Security events.

- User feedback.

- Business KPI impact.

Continuous evaluation should use production traces to improve the test suite. When a user reports a wrong answer, unsupported citation, unsafe output, or incorrect tool action, that incident should become a future evaluation case.

Continuous evaluation should run:

- Before model upgrades.

- Before prompt changes.

- Before adding data sources.

- Before enabling new tools.

- Before expanding users.

- After security incidents.

- On a scheduled cadence.

Evaluation gate: Production AI systems need monitoring, feedback loops, and regression testing before scale.

The Etheon AI Evaluation Stack Framework

The full framework can be summarized as follows:

1. Stack layer: Business outcome

What to test: Whether AI improves the workflow

Example metrics: KPI lift, ROI, cost per workflow, cycle-time reduction

2. Stack layer: Dataset quality

What to test: Whether tests represent real work

Example metrics: Coverage, edge cases, labels, risk cases

3. Stack layer: Model output

What to test: Whether responses are correct and usable

Example metrics: Accuracy, relevance, format, refusal, safety

4. Stack layer: Retrieval / RAG

What to test: Whether evidence is correct and grounded

Example metrics: Context relevance, recall, precision, groundedness, citation accuracy

5. Stack layer: Agent behavior

What to test: Whether steps, tools, and autonomy are correct

Example metrics: Task completion, tool accuracy, trajectory, escalation

6. Stack layer: Safety and governance

What to test: Whether risk boundaries hold

Example metrics: Leakage, prompt injection, access control, fairness, auditability

7. Stack layer: Production observability

What to test: Whether quality holds after launch

Example metrics: Drift, latency, cost, errors, user feedback, business KPI

This stack should be adapted by use case. A low-risk drafting assistant may need a lighter version. A high-risk finance, legal, HR, healthcare, customer, or agentic workflow needs the full version.

How to Build an Enterprise AI Evaluation Program

Step 1: Define the evaluation owner

Every production AI system should have an evaluation owner. This may be a product owner, AI engineering lead, model risk owner, or AI governance team. Without ownership, evals decay.

Step 2: Define the business metric

Start with the workflow KPI. AI quality should be tied to business value.

Step 3: Build the evaluation dataset

Use historical cases, expert labels, edge cases, risk cases, and adversarial cases.

Step 4: Choose the right metrics

Use model metrics for model outputs, RAG metrics for retrieval and groundedness, agent metrics for trajectories and tool use, and business metrics for ROI.

Step 5: Combine automated and human review

Automated evals are useful for scale, but human review is essential for domain judgment, safety, and high-risk workflows.

Step 6: Run pre-production evaluation

No production launch should happen without evaluation evidence.

Step 7: Monitor production behavior

Track quality, cost, latency, errors, refusals, tool calls, and business impact.

Step 8: Convert failures into regression tests

Every meaningful failure should become a test case.

Step 9: Re-evaluate after changes

Model updates, prompt changes, new data sources, and new tools should trigger evaluation.

Step 10: Use evaluation to decide scale

Scale only systems that meet quality, safety, cost, and value thresholds.

The Evaluation Scorecard for Enterprise Buyers

Decision-stage buyers can use this scorecard before approving production:

1. Evaluation category: Business value

Required evidence: Baseline, target KPI, owner, ROI estimate

2. Evaluation category: Dataset readiness

Required evidence: Historical cases, expert labels, edge cases, negative cases

3. Evaluation category: Model quality

Required evidence: Accuracy, relevance, format, refusal, safety thresholds

4. Evaluation category: RAG quality

Required evidence: Retrieval precision, recall, groundedness, citation accuracy

5. Evaluation category: Agent quality

Required evidence: Task completion, trajectory, tool selection, tool parameters

6. Evaluation category: Security

Required evidence: Prompt injection, data leakage, access control tests

7. Evaluation category: Governance

Required evidence: Risk tier, human oversight, documentation, audit trail

8. Evaluation category: Observability

Required evidence: Logs, traces, metrics, feedback, alerts

9. Evaluation category: Cost

Required evidence: Cost per accepted output or completed workflow

10. Evaluation category: Scale gate

Required evidence: Launch, improve, hold, or stop decision

A system with a great model score but weak retrieval should not launch. A system with strong usage but no KPI improvement should not scale. A system with accurate outputs but unsafe tool use should remain in pilot.

Common AI Evaluation Mistakes

The first mistake is evaluating only the model. Enterprise AI systems include retrieval, tools, prompts, data, users, policies, and workflows.

The second mistake is using only generic benchmarks. Benchmarks help compare capabilities, but they do not prove performance on company data and workflows.

The third mistake is testing only happy paths. Real users create ambiguity, missing context, policy conflicts, and edge cases.

The fourth mistake is ignoring retrieval. RAG failures often happen before the model generates the answer.

The fifth mistake is evaluating only final agent output. Agents need trajectory and tool-call evaluation.

The sixth mistake is relying only on automated graders. Automated evaluation should be calibrated with human review.

The seventh mistake is skipping safety tests. Prompt injection, sensitive data leakage, and access-control failures can invalidate an otherwise useful system.

The eighth mistake is not linking evaluation to business outcomes. AI can be accurate and still not create business value.

The ninth mistake is not evaluating after launch. AI systems change because models, prompts, data, users, and workflows change.

The Etheon Recommendation

The AI evaluation stack should become part of every enterprise AI roadmap.

For Etheon, the rule is direct:

Do not scale an AI system until the model, retrieval, agent behavior, safety controls, observability, and business outcome have all been evaluated together.

That means enterprise leaders should require:

- Model evaluations for output quality.

- RAG evaluations for retrieval and groundedness.

- Agent evaluations for tool use and trajectory.

- Safety evaluations for prompt injection and data leakage.

- Human evaluations for domain judgment.

- Business evaluations for ROI and workflow impact.

- Production evaluations for drift, cost, latency, and incidents.

The companies that win with AI will not be the ones that trust the best-sounding answer. They will be the ones that build the strongest evaluation system around every answer, action, workflow, and outcome.

That is the purpose of the AI evaluation stack: to turn AI from a promising prototype into a measurable, governable, production-ready enterprise system.

References

[1] McKinsey, “The State of AI: Global Survey 2025.” https://www.mckinsey.com/capabilities/quantumblack/our-insights/the-state-of-ai
[2] Deloitte, “The State of AI in the Enterprise — 2026 AI Report.” https://www.deloitte.com/us/en/what-we-do/capabilities/applied-artificial-intelligence/content/state-of-ai-in-the-enterprise.html
[3] Stanford HAI, “The 2026 AI Index Report.” https://hai.stanford.edu/ai-index/2026-ai-index-report
[4] Gartner, “Gartner Predicts Over 40% of Agentic AI Projects Will Be Canceled by End of 2027.” https://www.gartner.com/en/newsroom/press-releases/2025-06-25-gartner-predicts-over-40-percent-of-agentic-ai-projects-will-be-canceled-by-end-of-2027
[5] OpenAI, “Evaluation Best Practices.” https://developers.openai.com/api/docs/guides/evaluation-best-practices
[6] OpenAI, “Working With Evals.” https://developers.openai.com/api/docs/guides/evals
[7] Microsoft Foundry, “Observability in Generative AI.” https://learn.microsoft.com/en-us/azure/foundry/concepts/observability
[8] NIST, “AI Test, Evaluation, Validation and Verification.” https://www.nist.gov/ai-test-evaluation-validation-and-verification-tevv
[9] NIST, “Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile.” https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence
[10] OpenAI, “Evaluate Agent Workflows.” https://developers.openai.com/api/docs/guides/agent-evals
[11] Microsoft Foundry, “Agent Evaluators for Generative AI.” https://learn.microsoft.com/en-us/azure/foundry/concepts/evaluation-evaluators/agent-evaluators
[12] LangChain, “Evaluate a Complex Agent.” https://docs.langchain.com/langsmith/evaluate-complex-agent
[13] LangChain, “Evaluate a RAG Application.” https://docs.langchain.com/langsmith/evaluate-rag-tutorial
[14] Ragas, “Available Metrics” and “Context Precision.” https://docs.ragas.io/en/stable/concepts/metrics/available_metrics/

https://docs.ragas.io/en/stable/concepts/metrics/available_metrics/context_precision/
[15] TruLens, “RAG Triad.” https://www.trulens.org/getting_started/core_concepts/rag_triad/
[16] OWASP, “Top 10 for Large Language Model Applications.” https://owasp.org/www-project-top-10-for-large-language-model-applications/
[17] ISO, “ISO/IEC 42001:2023 — AI Management Systems.” https://www.iso.org/standard/42001
[18] EU AI Act Service Desk, “Timeline for the Implementation of the EU AI Act.” https://ai-act-service-desk.ec.europa.eu/en/ai-act/timeline/timeline-implementation-eu-ai-act
[19] OpenAI, “Agents SDK Integrations and Observability.” https://developers.openai.com/api/docs/guides/agents/integrations-observability
[20] Google Cloud, “Gen AI Evaluation Service Overview.” https://docs.cloud.google.com/gemini-enterprise-agent-platform/models/evaluation-overview