# AEMA: Verifiable Evaluation Framework for Trustworthy and Controlled Agentic LLM Systems
**Authors**: Yen-Ting Lee, Keerthi Koneru, Zahra Moslemi, Sheethal Kumar, Ramesh Radhakrishnan
> University of California, San Diego
> Center for Advanced AI, Accenture
> University of California, Irvine
Keerthi Koneru (keerthi.koneru@accenture.com). All work was done during the authors’ tenure at Accenture.
(January 17, 2026)
## Abstract
Evaluating large language model (LLM)-based multi-agent systems remains a critical challenge, as these systems must exhibit reliable coordination, transparent decision-making, and verifiable performance across evolving tasks. Existing evaluation approaches often limit themselves to single-response scoring or narrow benchmarks, which lack stability, extensibility, and automation when deployed in enterprise settings at multi-agent scale. We present AEMA (Adaptive Evaluation Multi-Agent), a process-aware and auditable framework that plans, executes, and aggregates multi-step evaluations across heterogeneous agentic workflows under human oversight. Compared to a single LLM-as-a-Judge, AEMA achieves greater stability, human alignment, and traceable records that support accountable automation. Our results on enterprise-style agent workflows simulated using realistic business scenarios demonstrate that AEMA provides a transparent and reproducible pathway toward responsible evaluation of LLM-based multi-agent systems.
Keywords: Agentic AI, Multi-Agent Systems, Trustworthy AI, Verifiable Evaluation, Human Oversight
## 1 Introduction
Agentic LLM systems are moving from static prediction to autonomous reasoning, tool use, and collaboration. As they operate in dynamic environments, their trustworthiness depends on ensuring alignment with human intent, robustness under real-world complexity, and verifiability of their internal decisions. These properties motivate evaluation frameworks that provide auditable transparency and bounded autonomy under human oversight.
Evaluating such systems is difficult because reasoning and coordination unfold over many steps; traditional benchmarks cannot verify process-level reliability or alignment with human expectations. In high-stakes domains where agents operate under human oversight, evaluation must function as a mechanism of trust and control rather than a mere scoring.
We introduce AEMA (Adaptive Evaluation Multi-Agent), a framework for verifiable evaluation of agentic LLM systems. AEMA adapts to diverse tasks and records traceable evaluation logs for oversight and accountability. Unlike single-model evaluators, AEMA operates as a coordinated multi-agent evaluator that plans, debates, and aggregates judgments across steps to produce consistent and explainable assessments under human control.
To demonstrate feasibility and trust reliability, we evaluate AEMA on enterprise-style agent workflows that simulate realistic multi-agent co-ordination under controlled conditions.
AEMA shows lower score dispersion, stronger human alignment, and verifiable consistency compared to a single LLM-as-a-Judge.
In summary, our contributions advance trust and control in agentic AI through the following dimensions:
1. AEMA introduces a process-aware, verifiable framework that unifies step-level and end-to-end assessment for multi-agent evaluation;
1. Provides an adaptive methodology that offers support for human-in-the-loop oversight and continuous refinement of evaluation criteria;
1. Demonstrates verifiable evaluation that enables alignment, robustness, and trust in autonomous LLM systems in enterprise-style environments.
## 2 Related Work: From Single-Turn Evaluation to Process-Level Assessment of LLM Multi-Agent Systems
LLMs are increasingly used to automate the evaluation, offering greater scalability and reproducibility than human evaluation. The LLM-as-a-Judge paradigm has been adopted for a wide range of tasks such as instruction InstructionFollowing, summarization Summarization, and machine translation MachineTranslation. Frameworks like G-Eval G-Eval use a single GPT-4 model with a chain-of-thought urging the text to score on coherence, relevance and factual accuracy, while ChatEval ChatEval assembles multiple LLM “referees”, having diverse expertise, which debate to reach consensus. CollabEval CollabEval focuses on building consensus among multiple LLM evaluators using different models rather than adversarial debate. These methods improve consistency, but remain limited to single-turn responses and do not capture multi-step agent reasoning.
Recent research focuses on the evaluation of agentic processes that involve planning, tool use, and interaction. Mind2Web 2 Mind2Web2 benchmarks web agents through an Agent-as-a-Judge rubric that assesses correctness and source attribution in 130 challenging search tasks. WebCanvas WebCanvas measures intermediate actions in realistic interface states using an online evaluation framework, and BEARCUBS BEARCUBS provides a multimodal benchmark of browsing tasks to test the effectiveness of reasoning.
Another line of work provides broad benchmark suites to measure how well modern LLM-driven agents perform in specialized domains. MLAgentBench MLAgentBench introduces a benchmark of 13 end-to-end machine learning experimentation tasks that evaluate agents ability to plan, write code, run experiments, and analyze results. Similarly, ITBench ITBench targets real-world IT automation tasks in Site Reliability Engineering (SRE), Compliance/Security (CISO), and Financial Operations (FinOps).
Beyond outcome accuracy, several studies assess behavior quality and collaboration dynamics. AutoLibra AutoLibra derives metrics from clustered human feedback for fine-grained behavior assessment. GEMMAS GEMMAS introduces graph-based metrics that measure collaboration efficiency and redundancy in multi-agent reasoning. WorFEval WorFEval compares workflow graphs against ground-truth structures using subsequence and subgraph matching, while DevAI DevAI monitors the progress of another agent to provide step level feedback on coding tasks.
These studies collectively advance LLM-based evaluation, but primarily assess single-response quality, benchmarked outcomes, or isolated collaboration patterns. In contrast, our AEMA evaluation framework unifies process-level planning, adaptive scoring, and historical trace learning into a reproducible evaluation workflow suited for enterprise-style multi-agent systems.
## 3 Method
### 3.1 AEMA Framework
<details>
<summary>x1.png Details</summary>
### Visual Description
## Diagram: AEMA Framework System Architecture
### Overview
The image displays a flowchart illustrating the architecture of the "AEMA Framework," a multi-agent system designed for processing evaluation tasks. The diagram shows the flow of information from an external human input into a sequence of specialized internal agents.
### Components/Axes
The diagram consists of two primary containers and connecting arrows with labels.
1. **Input Component (Left Box):**
* **Label:** "Human Evaluator or User Input"
* **Sub-text:** "(Business Context, Evaluation Specification Prompt)"
* **Position:** Left side of the diagram, outside the main framework box.
2. **Framework Component (Right Box):**
* **Title:** "AEMA Framework" (positioned at the top center of the box).
* **Internal Agents (Four rounded rectangles):**
* **Planning Agent:** Top-left quadrant.
* **Prompt Refinement Agent:** Top-right quadrant.
* **Evaluation Agent:** Bottom-left quadrant.
* **Final Report Agent:** Bottom-right quadrant.
3. **Connections (Arrows with Labels):**
* **Arrow 1:** From "Human Evaluator or User Input" to the "AEMA Framework" box (specifically pointing towards the Planning Agent). No label on this arrow.
* **Arrow 2:** From "Planning Agent" to "Prompt Refinement Agent". **Label:** "Evaluation Plan".
* **Arrow 3:** From "Prompt Refinement Agent" to "Evaluation Agent". **Label:** "Evaluation Parameters".
* **Arrow 4:** From "Evaluation Agent" to "Final Report Agent". **Label:** "Evaluation Results".
### Detailed Analysis
The diagram defines a clear, sequential workflow:
1. **Initiation:** The process begins with an external entity (a human evaluator or user) providing input. This input consists of two key elements: the **Business Context** and an **Evaluation Specification Prompt**.
2. **Planning Phase:** This input is fed into the **Planning Agent** within the AEMA Framework. The Planning Agent's output is an **Evaluation Plan**.
3. **Refinement Phase:** The **Evaluation Plan** is passed to the **Prompt Refinement Agent**. This agent processes the plan and outputs refined **Evaluation Parameters**.
4. **Execution Phase:** The **Evaluation Parameters** are sent to the **Evaluation Agent**, which performs the core evaluation task and generates **Evaluation Results**.
5. **Reporting Phase:** The **Evaluation Results** are forwarded to the **Final Report Agent**, which presumably compiles and presents the final output.
### Key Observations
* The framework is modular, with each agent having a distinct, single responsibility (planning, refinement, evaluation, reporting).
* The data flow is strictly linear and unidirectional, moving from left to right and top to bottom within the framework box.
* The labels on the arrows explicitly define the data or instructions being passed between components, clarifying the transformation at each stage (e.g., a "Plan" becomes "Parameters," which yield "Results").
* The "Human Evaluator or User Input" is the sole external trigger and source of context for the entire automated process.
### Interpretation
This diagram represents a structured, agent-based pipeline for automating complex evaluation tasks. The AEMA Framework appears designed to translate high-level human goals (business context and a prompt) into a concrete, executable evaluation process through a series of specialized steps.
The architecture suggests a focus on **robustness and specificity**. Instead of directly acting on a user's prompt, the system first plans, then refines the prompt into precise parameters, executes the evaluation, and finally formats the results. This intermediary steps (Planning and Refinement) likely aim to reduce ambiguity, align the evaluation with business goals, and improve the reliability and interpretability of the final output from the Evaluation Agent. The separation of the "Evaluation Agent" from the "Final Report Agent" indicates that generating raw results and presenting them in a useful format are considered distinct tasks. The entire flow embodies a "garbage in, gospel out" philosophy, where careful preprocessing of the input is critical to the quality of the final report.
</details>
Figure 1: Overview of AEMA (Adaptive Evaluation Multi-Agent): Planning Agent builds the plan; Prompt-Refinement Agent retrieves and prepares examples; Evaluation Agents score intermediate actions; Final Report Agent aggregates results into an auditable, reproducible report.
AEMA (Adaptive Evaluation Multi-Agent) is a verifiable multi-agent evaluation loop with four roles: Planning, Prompt-Refinement, Evaluation, and Final Report. It analyzes execution traces and criteria to plan, parameterize, and score step-wise behaviors, then aggregates auditable reports under human oversight Figure 1. This multi role workflow creates a controlled evaluation loop that records every decision for auditability and post-hoc verification.
### 3.2 Planning Agent
The Planning Agent determines which tasks to evaluate based on the evaluation prompt specified by the human evaluator. By default, it evaluates all actions, but prioritizes those that are semantically meaningful within the workflow. In complex multi-agent systems, agents often engage in extended discussions or reasoning to clarify objectives. As shown in GEMMAS GEMMAS, naive agent pipelines tend to generate high redundancy and low diversity in such internal communication. To avoid unnecessary overhead, the Planning Agent excludes these intermediary steps from the evaluation and instead focuses on key responses, tool calls, and actions assessable by available functions.
To support AEMA in various business scenarios and domains, the Planning Agent first classifies the business context into a predefined category using an LLM that analyzes the agent’s execution results and the evaluation prompt. By assigning the task to a user-specified business category, the Planning Agent ensures that subsequent evaluations are aligned with the domain. This process also reduces the complexity of selecting the appropriate evaluation functions by restricting the search space to those relevant within the identified business domain.
Even within the same business domain, the large number of possible actions makes it difficult for the Planning Agent to reliably select the correct evaluation functions. To address this challenge, we introduce a tool filter that improves the efficiency of retrieving relevant evaluation functions.
The filter retrieves only functions aligned with the identified domain and evaluator requirements. Inspired by Retrieval-Augmented Generation (RAG) RAG, we adopt a hybrid retrieval approach that combines sparse and dense search methods over the function descriptions (docstrings). Combining sparse and dense retrieval methods has been empirically shown to yield more accurate and robust results than using either alone, particularly in domain-specific applications such as scientific document retrieval Retrieval. In our setting, we used the sparse retrieval implemented by BM25 to capture keyword level relevance. For dense retrieval, we compute the cosine similarity between the embeddings of the function descriptions and the embeddings of the task context, which includes both the agent’s execution results and the evaluation prompt. Finally, we use a convex combination of sparse and dense scores to rank the functions and select the top-k candidates (where k is set by the human evaluator). This filtering step enables the Plan Generator to focus on the most appropriate evaluation tools for the given business scenario.
After retrieving relevant functions, the Planning Agent combines two components: a Plan Generator and a Plan Evaluator. Both use the same underlying model (GPT-4o) but with different system messages and prompts. The Plan Generator selects which steps of the business agent should be evaluated. After producing a candidate plan, the Plan Evaluator reviews it. If both reach consensus, the plan proceeds; otherwise, the Plan Evaluator provides feedback, prompting the Plan Generator to revise. This iterative process continues until agreement or a maximum iteration limit is reached.
### 3.3 Prompt Refinement Agent
For domain-specific tasks, pretrained LLMs may be insufficient to reliably evaluate a business agent without contextual grounding. Previous work ManyShotJudge shows that LLM-as-a-Judge achieves higher accuracy when evaluation prompts include few-shot exemplars rather than zero-shot queries. To support this, AEMA’s Prompt-Refinement Agent automatically searches prior evaluation records relevant to the current task; when suitable examples are missing, it synthesizes exemplars aligned to the task of the surrounding business context.
The Prompt Refinement Agent prepares the required parameter bundle and few-shot example for each evaluation function in the plan generated by the Planning Agent. It uses an LLM to interpret the signature and docstring of each function along with the agent’s inputs, outputs, and reasoning trace, mapping relevant facts to arguments. The Prompt Refinement Agent produces a schema-compliant JSON object for immediate use by the evaluation function.
In-context learning research, such as Auto-ICL Auto-ICL and Self-ICL Self-ICL, shows that LLMs perform better when prompts include clear instructions and examples. To support such evaluation functions, the Prompt-Refinement Agent automatically retrieves past evaluation results using the same hybrid retrieval method described in 3.2 When an evaluation function requires few-shot examples but the database does not provide enough, the agent asks an LLM to synthesize examples from the business context, including example agent actions and reference scores. This automated extraction and adaptive retrieval improve flexibility when extending evaluation functions.
We implement AEMA using AutoGen AutoGen, which provides asynchronous orchestration and memory integration through ChromaDB and LangChain capabilities beyond lighter frameworks such as the OpenAI Agents SDK and CrewAI. Our deployment uses GPT-4o as the underlying LLM and ChromaDB as the vector store.
### 3.4 Evaluation Agents
The Evaluation Agents consist of multiple general evaluators capable of assessing each task performed by the business agent. They measure individual skills using both LLM-based judges and reliable code-based evaluators. Each evaluation function produces a normalized score between zero and one based on the evaluation results, along with qualitative feedback for further analysis.
Each function outputs a normalized score (0–1) and qualitative feedback. After all evaluations, results are sent to the Final Report Agent to generate the final report summarizing key metrics and improvement areas. Although the framework supports domain-specific evaluation extensions, we also provide a set of general functions that are applicable to all business scenarios.
### 3.5 Final Report Agent
The Final Report Agent consolidates all intermediate results into a comprehensive performance report for the target business agent. It aggregates quantitative metrics and qualitative insights produced by the Evaluation Agents into a coherent summary.
The resulting report typically consists of three elements:
- an aggregated performance score, obtained by averaging or weighting across all available evaluation dimensions;
- a performance summary organizing evaluator feedback into strengths and weaknesses, and
- actionable recommendations, which highlight concrete areas for improvement and suggest strategies to enhance the business agent’s reliability.
The Final Report Agent also supports continuous monitoring beyond static assessment. By recording and analyzing historical evaluation trajectories, it detects performance trends and distribution shifts in evolving business data. This functionality ensures robustness in dynamic environments. This design enables accountable and auditable evaluation traces, a prerequisite for responsible multi-agent deployment.
## 4 Experiments
This section evaluates the effectiveness of AEMA in generating reliable, human-aligned assessments in enterprise-style multi-agent workflows. We describe the experimental setup, domain configuration, task design, and then analyze the results to highlight stability, alignment, and responsible evaluation outcomes.
### 4.1 Experiment Settings
To demonstrate the operation of AEMA, we evaluate a finance domain agent responsible for verifying the validity of the invoice within a multi-agent workflow. The workflow involves six coordinated components: InputAgent (analyzes the incoming and normalizes input), Orchestrator (plans the collaboration order among agents), ParserAgent (extracts information from the invoice), Validator Agent (validates the extracted results), Policy Agent (checks compliance with policies), and Approval Agent (aggregates the outcomes and gives approval decision), each corresponding to a functional stage in enterprise automation. Although this study focuses on finance, AEMA supports domain-specific evaluation functions across Finance, Healthcare, and Software, automatically restricting its plan to the detected domain during planning.
AEMA dynamically configures its evaluation plan according to available functions. To test its adaptive planning capability, we intentionally excluded the evaluation of the Policy Agent while keeping others active, requiring AEMA to generate a coherent plan reflecting only implementable checks.
To assess the reliability of plan generation, AEMA was executed 30 times on identical financing workflow output. Within the Planning Agent, we capped the debate mechanism at five rounds for both the Plan Generator and the Plan Evaluator. This configuration isolates the contribution of debate rounds to planning accuracy and convergence speed.
For consistency testing, both AEMA and the single LLM-as-a-Judge baseline were executed 30 times on identical inputs. To ensure fairness, the single LLM used concatenated scoring criteria identical to AEMA evaluation functions. The results were benchmarked against human-as-a-Judge references to measure alignment and dispersion.
We evaluated two input conditions: clear (good quality) and degraded (blurry) invoice images. For each, AEMA and the single LLM-as-a-Judge were run 20 times, and their mean scores were compared to human references to evaluate robustness under input quality shifts.
### 4.2 Formal Plan-Evaluation Metric
Let the available agent set be $\Omega$ . The gold plan is $G_{i}=(A_{i},S_{i})$ with $A_{i}\subseteq\Omega$ and order $S_{i}$ . The prediction is $(P,E)$ with $P\subseteq\Omega$ and predicted sequence $E$ . AEMA returns a scalar score in $[0,1]$ summarizing five criteria:
1. Schema validity ( $F$ ). Fraction of required fields that are present with the correct types, ensuring structurally valid outputs.
1. Agent selection accuracy ( $S$ ). The $F_{1}$ -score between the gold and predicted agent sets:
$$
S=\frac{2\,|A_{i}\cap P|}{|A_{i}|+|P|}.
$$
1. Step–agent coherence ( $C_{v}$ ). Measures the overlap between the unique step labels and the predicted agents:
$$
C_{v}=\frac{|\mathrm{set}(E)\cap P|}{|\mathrm{set}(E)\cup P|}.
$$
1. Order preservation ( $O_{r}$ ). Assesses whether the predicted sequence $E$ preserves the intended order $S_{i}$ . Using a Kendall-style inversion agreement cicirello2019kendall:
$$
O_{r}=1-\frac{\mathrm{inv}(E;S_{i})}{\mathrm{inv}_{\max}},\qquad O_{r}\in[0,1],
$$
where $\mathrm{inv}(E;S_{i})$ is the number of pairwise inversions of $E$ relative to $S_{i}$ ; for DAGs, inversions are computed with respect to any consistent topological extension.
1. Step efficiency ( $E_{f}$ ). Encourages parsimony in plan length:
$$
E_{f}=\min\!\left(1,\;\frac{|A_{i}|}{\max(1,|P|)}\right).
$$
Aggregation via AHP. A non-negative weight vector $(w_{F},w_{S},w_{C_{v}},w_{O_{r}},w_{E_{f}})$ with $\sum w_{\cdot}=1$ is obtained using the Analytic Hierarchy Process (AHP) bhattacharya2017granger; botchway2021ahpsoftware; mekouar2021ahpspam from pairwise criterion comparisons with a consistency check. The final score is:
$$
\mathrm{\textit{FinalScore}}=w_{F}F+w_{S}S+w_{C_{v}}C_{v}+w_{O_{r}}O_{r}+w_{E_{f}}E_{f}.
$$
Weights can be adjusted to reflect domain priorities without altering metric definitions.
Notation Summary. $\Omega$ : all candidate agents; $A_{i}$ : gold-standard agent set; $S_{i}$ : gold order / DAG; $P$ : predicted agent set; $E$ : predicted sequence; $\mathrm{inv}(\cdot)$ : inversion count used in order-preservation.
### 4.3 Results and Analysis
#### Planning Experiment.
We evaluated AEMA’s Planning Agent over 30 runs. The consensus on the correct plan was reached in 13 runs after one debate round, 13 runs after two rounds, and 4 runs after three rounds. This supports using a debate mechanism with Plan Generator and Plan Evaluator in Planning Agent, since a single LLM generation is not consistently optimal. In this setup, a cap of three rounds is sufficient.
#### Stability Experiment.
<details>
<summary>contents/figs/Stability.png Details</summary>
### Visual Description
## Box Plot: Final Score Stability Comparison
### Overview
This image is a box plot comparing the stability of final scores (on a 0-1 scale) between two evaluation methods, "AEMA" and "Single LLM-as-a-Judge," based on 30 runs. The chart visually demonstrates the distribution, central tendency, and variability of scores for each method.
### Components/Axes
* **Chart Title:** "Final score stability: AEMA vs single LLM-as-a-Judge (30 runs)"
* **Y-Axis:**
* **Label:** "Final score (0-1)"
* **Scale:** Linear scale from 0.65 to 1.0, with major gridlines at intervals of 0.05 (0.65, 0.7, 0.75, 0.8, 0.85, 0.9, 0.95, 1).
* **X-Axis:**
* **Label:** "Evaluator"
* **Categories:** Two categories are plotted: "AEMA" (left) and "Single LLM-as-a-Judge" (right).
* **Legend:** Located at the bottom center of the chart.
* A blue square is labeled "AEMA".
* An orange square is labeled "Single LLM-as-a-Judge".
* **Data Series:** Two box plots, one for each evaluator, colored according to the legend.
### Detailed Analysis
**1. AEMA (Blue Box Plot - Left)**
* **Visual Trend:** The distribution is extremely compressed and located at the very top of the score range, indicating high consistency and high scores.
* **Components & Approximate Values:**
* **Median (Horizontal Line within Box):** Approximately 0.97.
* **Interquartile Range (IQR - The Box):** The box is very narrow. The lower quartile (Q1, bottom of the box) is approximately 0.96. The upper quartile (Q3, top of the box) is approximately 0.98.
* **Whiskers:** The whiskers are not visibly extended beyond the box, suggesting the minimum and maximum values (excluding outliers) are very close to the quartiles.
* **Outliers:** One outlier point is visible below the box, at approximately 0.91.
* **Mean (Marked with an 'x'):** The 'x' is positioned within the box, near the median, at approximately 0.97.
**2. Single LLM-as-a-Judge (Orange Box Plot - Right)**
* **Visual Trend:** The distribution shows significantly more spread (variability) than AEMA, with scores centered lower on the scale. The box is wider, and whiskers are longer.
* **Components & Approximate Values:**
* **Median (Horizontal Line within Box):** Approximately 0.90.
* **Interquartile Range (IQR - The Box):** The box spans from a lower quartile (Q1) of approximately 0.88 to an upper quartile (Q3) of approximately 0.93.
* **Whiskers:** The upper whisker extends to a maximum value (excluding outliers) of approximately 0.94. The lower whisker extends to a minimum value (excluding outliers) of approximately 0.87.
* **Outliers:** One outlier point is visible far below the lower whisker, at approximately 0.70.
* **Mean (Marked with an 'x'):** The 'x' is positioned slightly below the median line, at approximately 0.895.
### Key Observations
1. **Stability Contrast:** AEMA demonstrates vastly superior score stability. Its IQR (approx. 0.02) is an order of magnitude smaller than that of the Single LLM-as-a-Judge (approx. 0.05).
2. **Performance Level:** AEMA not only is more stable but also achieves a higher central tendency (median ~0.97 vs. ~0.90).
3. **Outliers:** Both methods produced outliers. AEMA's single outlier (~0.91) is still a high score, merely falling outside its own tight cluster. The Single LLM-as-a-Judge produced a severe low outlier (~0.70), indicating a run with significantly degraded performance.
4. **Distribution Shape:** The Single LLM-as-a-Judge's median is closer to its Q1 than its Q3, suggesting a slight positive skew (scores are more concentrated toward the lower end of its IQR).
### Interpretation
This chart provides strong evidence that the **AEMA evaluation method is significantly more reliable and consistent** than using a Single LLM-as-a-Judge. The tight clustering of AEMA scores near the maximum value (1.0) suggests it produces highly reproducible results across multiple runs. In contrast, the Single LLM-as-a-Judge exhibits substantial volatility, with scores varying widely and the potential for catastrophic failure (as evidenced by the outlier at 0.70).
For practical application, this implies that relying on a single LLM run for evaluation introduces unacceptable noise and risk. AEMA, by presumably aggregating or stabilizing judgments, mitigates this instability, leading to more trustworthy and actionable scoring. The data argues for the necessity of methods like AEMA in any rigorous evaluation pipeline where consistency is critical.
</details>
Figure 2: Stability of final scores across 30 evaluations. AEMA exhibits lower dispersion than a single LLM-as-a-Judge.
Across 30 evaluations with identical inputs, AEMA shows narrow score variation at each step and in the Final metric. In contrast, the single LLM-as-a-Judge shows wider dispersion with several low outliers, especially for Decision and Final. The box-and-whisker plots in Figure 2 show a clearly smaller interquartile range and shorter whiskers for AEMA. The human-as-a-judge reference for this case is 0.96, and AEMA’s distribution concentrates near this value, while the single-LLM distribution is broader and departs more frequently from it. In business workflows, stability is essential. Predictable evaluations support fixed thresholds, reduce human overrides, and improve auditability and policy compliance. Under fixed inputs, these results show that AEMA yields more stable and human-aligned assessments than a single LLM-as-a-Judge. In high-reliability settings, this consistency reduces the evaluator drift and enables formal threshold calibration.
#### Human Alignments Experiment.
| | Human | AEMA | Single LLM-as-a-Judge | | |
| --- | --- | --- | --- | --- | --- |
| Step | Mean | Mean | $|\Delta|$ | Mean | $|\Delta|$ |
| Routing | 1.00 | 0.98 | 0.02 | 1.00 | 0.00 |
| Planning | 0.98 | 0.98 | 0.00 | 0.86 | 0.12 |
| Parsing | 0.80 | 0.88 | 0.08 | 0.86 | 0.06 |
| Validation | 1.00 | 1.00 | 0.00 | 1.00 | 0.00 |
| Decision | 1.00 | 1.00 | 0.00 | 0.81 | 0.19 |
| Final | 0.96 | 0.97 | 0.01 | 0.87 | 0.09 |
Table 1: Good-quality invoice: mean scores (over 20 runs) and absolute error to human (lower is better).
Table 1 shows the good-quality invoice results. AEMA matches the human score on planning, validation and decision and is close to the final score (absolute error = 0.01). The single LLM-as-a-Judge is farther from the human score, especially in the decision step (0.19) and the final (0.09). Averaging the absolute error over the six steps, the AEMA is 0.018, while the single LLM is 0.077.
Table 2 shows the results of the degraded and blurred input images. AEMA remains closer to the human score on most steps and on the final score (0.04 vs. 0.07). The single LLM departs more on Decision (0.32) and Validation (0.12). The average absolute error over steps is 0.037 for AEMA and 0.108 for the single LLM.
Overall, AEMA is more human-aligned under both input conditions. The greatest gains occur in the decision step and the final score, which determine the business outcome.
| | Human | AEMA | Single LLM-as-a-Judge | | |
| --- | --- | --- | --- | --- | --- |
| Step | Mean | Mean | $|\Delta|$ | Mean | $|\Delta|$ |
| Routing | 1.00 | 0.94 | 0.06 | 1.00 | 0.00 |
| Planning | 1.00 | 1.00 | 0.00 | 0.99 | 0.01 |
| Parsing | 0.50 | 0.38 | 0.12 | 0.63 | 0.13 |
| Validation | 1.00 | 1.00 | 0.00 | 0.88 | 0.12 |
| Decision | 1.00 | 1.00 | 0.00 | 0.68 | 0.32 |
| Final | 0.90 | 0.86 | 0.04 | 0.83 | 0.07 |
Table 2: Blurry invoice: mean scores (over 20 runs) and absolute error to human (lower is better).
## 5 Limitations and Future Directions
Score Stability of Continuous Outputs. Repeated evaluations of identical parsing steps occasionally produce inconsistent numerical scores despite coherent rationales, highlighting variance in continuous-value judgments. Discrete or categorical scoring scales are recommended to improve repeatability and interpretability.
Evaluation Cost and Latency. AEMA involves multiple LLM calls (plan $\rightarrow$ prompt $\rightarrow$ evaluation $\rightarrow$ report), which can be costly and slower than the business workflow itself. Practical mitigations include evaluating only priority actions, skipping redundant re-evaluations within a time window, and using budget-aware planning to allocate small versus large models dynamically. Caching repeated prefixes (e.g., KV-cache reuse) further reduces runtime overhead.
Prompt-Merging Trade-offs. Combining stages (such as parameter extraction and evaluation) reduces the number of calls, but early observations suggest that heavily merged prompts may lower task accuracy or interpretability. Controlled experiments are planned to identify safe levels of consolidation without compromising transparency.
Scope and Generalization. Current experiments are confined to a single Finance domain using LLM-based components across all agents. Future extensions will explore cross-domain settings, including safety-critical workflows, and investigate cost and latency reductions via discrete scoring, caching, and optimized prompt compilation.
## 6 Conclusion
We presented AEMA, a process-aware evaluation framework for business agents. AEMA demonstrates that evaluation can serve as a verifiable control mechanism embedding accountability into multi-agent reasoning. AEMA plans evaluations, prepares parameters and examples, applies multiple evaluators, and aggregates step-level and end-to-end results. Compared with a single LLM-as-a-Judge, AEMA produces more stable scores under identical inputs and yields smaller absolute error to human references on both good-quality and degraded invoices. In business settings, AEMA yields stable and predictable scores that support fixed thresholds and reduce manual overrides.
Although this study focuses primarily on the Finance domain, AEMA’s architecture demonstrates strong cross-domain adaptability. Future work will extend domain-specific evaluation experiments to broader settings, testing AEMA across multiple domains and heterogeneous workflows. Another promising direction is to improve the efficiency and awareness of AEMA resources. For example, integrating cost or budget constraints into the workflow could allow the Planning Agent to activate evaluation tools dynamically based on available resources or to decide when to use small language models versus larger ones to balance accuracy and efficiency. These extensions would make AEMA more scalable and practical for real-world, cost-sensitive applications.
## References
## Appendix A System & Workflow Summary
AEMA evaluates multi-agent business workflows through four coordinated roles:
1. Planning Agent — generates an executable evaluation plan from the human evaluator’s specification and relevant evaluation functions;
1. Prompt-Refinement Agent — prepares evaluator parameters and few-shot exemplars for each function;
1. Evaluation Agents — combine deterministic checks and LLM-based judgments to score each step; and
1. Final Evaluation Agent — aggregates outcomes into machine- and human-readable reports.
Each stage contributes to a reproducible, auditable evaluation trace. Detailed implementation of these roles, the plan–review loop, and retrieval mechanisms appear in Section 3 of the main text. Here we only note that the framework is implemented in AutoGen, integrated with LangChain and ChromaDB, and uses GPT-4o as the LLM backbone.
System design principle: AEMA ensures that every evaluation decision includes plan creation, parameter refinement, scoring, and reporting, which produces a verifiable artifact that can be replayed or audited later, reinforcing the workshop theme of trust and control in agentic AI.
## Appendix B Experimental Configuration
Target Workflow. The Finance Agent Framework validates invoices through six components: InputAgent, Orchestrator, ParserAgent, ValidatorAgent, PolicyAgent, and ApprovalAgent. This workflow was selected to emulate realistic enterprise evaluation flows involving document parsing, rule validation, and policy compliance.
Evaluator-Availability Stress Test. To test adaptive planning, the evaluation for PolicyAgent is intentionally omitted while all other component evaluations remain implemented. AEMA must construct a coherent evaluation plan reflecting the available evaluators without failing the planning step.
Planning-Stability Protocol. AEMA is executed 30 times on identical Finance-agent outputs. The Planning Agent’s debate loop is capped at five rounds for both the Plan Generator and the Plan Evaluator. Consensus on the correct plan typically emerges after one to three rounds (13, 13, and 4 runs respectively), showing bounded deliberation and stable reasoning behavior.
Stability Under Identical Inputs. Across 30 repeated evaluations on the same inputs, AEMA yields narrow score dispersion at both step and final levels, while a single LLM-as-a-Judge baseline exhibits larger variance and occasional outliers. Human-as-a-judge references cluster near 0.96, and AEMA’s scores concentrate around this value. These results demonstrate robustness of AEMA’s debate-and-review mechanism under fixed conditions (refer Figure 2).
Human-Alignment Evaluation. Two datasets are used: good-quality invoices and degraded (blurred) images. Both AEMA and the single-LLM baseline are run twenty times per dataset, and the averaged results are compared to human-judge references. For good-quality inputs, AEMA aligns closely with human ratings across all steps, while the single LLM diverges more strongly in the Decision and Final stages. Under degraded inputs, AEMA maintains smaller absolute deviations (see Tables 1 – 2), indicating resilience to input noise.
Baseline Fairness. For the single LLM-as-a-Judge baseline, the same scoring criteria prompts used in AEMA’s evaluation functions are concatenated into one unified prompt to ensure a fair comparison under identical input conditions.