Build a Multi-Agent Evaluation Design Team
EvalCommunity Academy · AI Agents for Evaluators · Tutorial 2
Build a Multi-Agent Evaluation Design Team: From Theory of Change to Evaluation Matrix
What if an evaluation design could be developed by a coordinated team of AI specialists—each responsible for a different part of the process, checking the work of the others, and leaving the final decisions to a human evaluator?
No coding required for the first build
90–120 minutes
Beginner to intermediate
What is a multi-agent evaluation design team?
A multi-agent evaluation design team is a coordinated AI workflow in which specialised agents support distinct evaluation design tasks—for example, analysing programme context, developing a theory of change, formulating evaluation questions, proposing methods and sampling strategies, building an evaluation matrix, and reviewing design quality. A human evaluator remains responsible for validating assumptions, selecting the final design and approving the deliverables.
What you will build
You will design a coordinated workflow of specialist AI roles that can help prepare the first draft of an evaluation design package. The workflow will move from programme understanding to a draft theory of change, evaluation questions, methodology, sampling considerations and a structured evaluation matrix.
Analyse the programme, evidence gaps and stakeholder context.
Develop the theory of change and evaluation questions.
Connect questions to methods, samples and evidence.
Identify inconsistencies, risks and decisions requiring human approval.
By the end, you should have:
- A draft programme context and evaluability assessment.
- A theory of change with explicit assumptions and risks.
- A prioritised set of evaluation questions.
- A proposed methodology and sampling approach, with limitations.
- An evaluation matrix connecting questions, indicators, evidence and methods.
- A quality review and a list of decisions requiring evaluator approval.
First, an important distinction: AI roles are not automatically autonomous agents
In this tutorial, each specialist role can initially be implemented as a separate AI prompt or model call. A workflow tool then passes one role’s output to the next. This is a useful way to learn and test the architecture.
However, separate prompts do not automatically create agents with persistent memory, independent access to evidence, reliable tool use or genuine independent verification. Those capabilities depend on the runtime, tools, state management, permissions and orchestration you implement. The workflow becomes more agentic when agents can use tools, manage context, delegate tasks or take bounded actions under defined controls.
1. Start with a realistic evaluation scenario
We will use a hypothetical international development programme as the common case for all seven roles. The example is designed for learning; it is not a real programme or a verified evaluation case study.
Illustrative programme
Women’s Economic Empowerment Programme
A hypothetical three-year programme operating in three rural districts. It aims to strengthen women’s economic participation through a combination of skills development, business support and improved access to financial services.
- Vocational training
- Business mentoring
- Financial literacy
- Savings groups
- Market access support
- Improved practical skills
- Greater financial inclusion
- Stronger women-led businesses
- Increased economic participation
- Three-year duration
- Three rural districts
- Activities and intended results listed above
- No verified baseline or participant database supplied
Important evidence rule: We have not been given a programme document, baseline, monitoring dataset, budget, participant database or verified stakeholder consultation record. The AI team must treat these as missing information. It must not invent them to make the design look complete.
2. Design the seven-role AI team
The workflow uses six specialist roles and one coordinating role. Each role has a bounded responsibility and a defined output. The manager coordinates the work and consolidates results; it does not make final methodological decisions on behalf of the evaluator.
Context Analyst
Theory of Change Specialist
Evaluation Questions Specialist
Methodology and Sampling Specialist
Evaluation Matrix Specialist
Design Quality Reviewer
Outputs move through review gates. The human evaluator retains approval authority.
| Role | Main responsibility | Expected output | Human checkpoint |
|---|---|---|---|
| 1. Context Analyst | Clarifies programme logic and information gaps. | Context and evaluability brief. | Confirm facts and scope. |
| 2. ToC Specialist | Maps causal pathways and assumptions. | Draft theory of change. | Validate with stakeholders. |
| 3. Questions Specialist | Turns purpose and ToC into answerable questions. | Prioritised question set. | Approve priorities and use. |
| 4. Methodology Specialist | Matches methods and sampling to questions. | Methods and sampling proposal. | Approve feasibility and inference. |
| 5. Matrix Specialist | Connects questions to evidence and analysis. | Draft evaluation matrix. | Check traceability. |
| 6. Quality Reviewer | Tests coherence, gaps, bias and feasibility. | Quality review and revision list. | Resolve critical issues. |
| 7. Design Manager | Coordinates and consolidates the workflow. | Draft design package and decision log. | Final evaluator approval. |
3. Map the workflow before writing prompts
The sequence matters. A methodology should not be selected before the evaluation questions are clear. An evaluation matrix should not be completed before the questions, evidence requirements and methods have been discussed.
- Context assessment: identify what is known, unknown and required.
- Theory of change: map the intended causal pathways and assumptions.
- Evaluation questions: identify what decision-makers and stakeholders need to know.
- Methodology and sampling: match the questions to feasible methods and evidence.
- Evaluation matrix: connect each question to indicators, sources, methods and analysis.
- Quality review: test the logic, feasibility, inclusion and evidence requirements.
- Manager consolidation: prepare a draft package and unresolved-decision log for human review.
Insert a human review gate after the context assessment, after the theory of change and evaluation questions, and before the final design is accepted. If a reviewer identifies a critical gap, return the work to the relevant specialist rather than simply asking the manager to rewrite the conclusion.
4. Establish rules for every specialist agent
Before using the individual prompts, apply the following shared instructions to all roles. These rules reduce fabricated details, unsupported certainty and inconsistent outputs.
- Use only the programme information and evidence supplied or retrieved through approved tools.
- Clearly label facts, assumptions, hypotheses, proposed indicators and missing information.
- Never invent baselines, targets, sample sizes, budgets, participant numbers, citations or stakeholder views.
- Do not present an assumed causal relationship as demonstrated impact.
- Explain uncertainty, data limitations and methodological trade-offs.
- Consider gender, age, disability, location, income and other relevant dimensions of inclusion where appropriate and safe.
- Flag ethical, safeguarding, confidentiality and data protection risks.
- Use clear headings and structured tables where they improve usability.
- List decisions that require a qualified evaluator or stakeholder group.
- Do not claim that a design is validated simply because another AI role has reviewed it.
5. Agent 1 — Programme Context Analyst
Purpose: establish a reliable starting point. This role examines the programme description, identifies missing information and assesses whether the intervention is sufficiently clear to proceed with evaluation design.
Input: programme description, project documents, available monitoring information, geographic coverage, target groups and evaluation purpose.
Output: a structured context brief and an information-gap register.
Copy-ready prompt
ROLE: You are a Programme Context and Evaluability Analyst supporting an experienced Monitoring and Evaluation professional. TASK: Analyse the programme information supplied and prepare a structured context brief to support evaluation design. PROGRAMME INFORMATION: [PASTE PROGRAMME DESCRIPTION AND AVAILABLE DOCUMENTS] EVALUATION PURPOSE: [INSERT PURPOSE, IF KNOWN] INSTRUCTIONS: 1. Summarise the intervention, intended beneficiaries, geography, duration and activities. 2. Separate confirmed facts from assumptions and missing information. 3. Identify the intended results and any unclear causal links. 4. Identify relevant contextual, institutional, economic, social and gender-related factors that may influence implementation or results. 5. Assess the availability and quality of existing evidence, baseline data, monitoring information and participant records. 6. Identify stakeholder groups whose perspectives should be considered. 7. Identify potential ethical, safeguarding, privacy and inclusion issues. 8. Assess preliminary evaluability: what can reasonably be evaluated with the information available? 9. Do not invent missing data, targets, budgets, baselines or stakeholder positions. OUTPUT: A. Programme summary B. Confirmed facts C. Assumptions requiring validation D. Missing information and evidence gaps E. Stakeholder groups to consult F. Preliminary evaluability assessment G. Risks and ethical considerations H. Questions requiring human clarification End with a list of the five most important information gaps that should be resolved before the design proceeds.
Human review gate 1: confirm that the programme description is accurate. Obtain missing programme documents and clarify the evaluation purpose before treating the context brief as an agreed foundation.
6. Agent 2 — Theory of Change Specialist
Purpose: turn the programme description into a testable explanation of how change is expected to happen. The agent should make assumptions visible rather than presenting the programme’s intended results as guaranteed outcomes.
Input: human-approved context brief, programme documents and available evidence.
Output: a draft theory of change, causal assumptions and risks.
Copy-ready prompt
ROLE: You are a Theory of Change Specialist with expertise in international development and programme evaluation. INPUT: [PASTE THE HUMAN-APPROVED CONTEXT BRIEF AND RELEVANT PROGRAMME DOCUMENTS] TASK: Develop a draft theory of change that explains how the intervention is expected to contribute to its intended results. INSTRUCTIONS: 1. Identify the programme problem and the intended long-term change. 2. Map the results chain: activities, outputs, short-term outcomes, intermediate outcomes and longer-term outcomes or impact. 3. Explain the causal links between each level. 4. Identify the assumptions required for each major link to hold. 5. Identify external factors, contextual conditions and risks that may influence results. 6. Consider differences in access, participation, decision-making power and outcomes across relevant groups. 7. Identify possible unintended positive and negative effects. 8. Distinguish programme-controlled outputs from outcomes influenced by external conditions. 9. Do not treat the draft theory of change as stakeholder-validated. 10. Do not invent evidence that a causal pathway has been demonstrated. OUTPUT: A. Problem statement B. Draft results chain C. Causal pathways and explanations D. Assumptions by pathway E. External factors and risks F. Potential unintended effects G. Inclusion and gender considerations H. Evidence needed to test the theory I. Questions for stakeholder validation Present the results chain in a table. Mark all unvalidated assumptions clearly.
Illustrative theory of change
The following is a possible pathway for the hypothetical programme. It is a design hypothesis, not an established finding.
Activities
Training, mentoring, financial literacy and savings groups
Outputs
Women participate in services and receive support
Short-term outcomes
Improved skills, knowledge and financial capability
Intermediate outcomes
Improved business practices and financial access
Longer-term change
Stronger economic participation and agency
Possible assumptions include access to markets, control over income, safe mobility, time availability, supportive household conditions and functioning financial services.
Human review gate 2: the theory of change should be discussed with relevant stakeholders. In a women’s economic empowerment programme, consultation should examine who controls resources and decisions, whose voices may be missing, and whether the assumed pathways reflect the lived context.
7. Agent 3 — Evaluation Questions Specialist
Purpose: translate the evaluation purpose and validated or provisionally agreed theory of change into focused, answerable questions.
Input: approved evaluation purpose, draft theory of change, stakeholder priorities and relevant criteria.
Output: prioritised evaluation questions with rationale and evidence needs.
Copy-ready prompt
ROLE: You are an Evaluation Questions Specialist. INPUT: [PASTE APPROVED EVALUATION PURPOSE, THEORY OF CHANGE AND STAKEHOLDER PRIORITIES] TASK: Develop a focused set of evaluation questions that can guide a feasible and useful evaluation. INSTRUCTIONS: 1. Identify the intended users and decisions the evaluation should inform. 2. Identify the most important dimensions of the intervention to examine. 3. Consider relevant OECD-DAC criteria where appropriate: relevance, coherence, effectiveness, efficiency, impact and sustainability. 4. Do not automatically include all six criteria. Explain why each selected criterion is relevant to the purpose. 5. Develop clear, neutral and answerable primary questions. 6. Add sub-questions only when they improve analytical clarity. 7. Identify questions that require descriptive, explanatory, normative or causal evidence. 8. Consider differential results across relevant groups. 9. Flag questions that cannot be answered with currently available data or within likely resource constraints. 10. Avoid leading questions and questions that assume the programme succeeded. OUTPUT TABLE: - Priority - Evaluation criterion or analytical dimension - Main evaluation question - Sub-questions - Intended use of the answer - Evidence likely required - Feasibility concerns End with: A. Five highest-priority questions B. Questions that should be removed, merged or deferred C. Missing stakeholder perspectives D. Questions requiring human approval
Illustrative evaluation questions
| Dimension | Illustrative question | Evidence needed |
|---|---|---|
| Relevance | To what extent did programme support respond to the economic priorities and constraints of different groups of women? | Needs assessments, interviews, programme records. |
| Effectiveness | To what extent did participants improve relevant business and financial capabilities? | Skills assessments, participant follow-up, business records. |
| Inclusion | Which groups participated and benefited, and which faced barriers? | Disaggregated participation data, accessible consultations. |
| Sustainability | What conditions may support or undermine the continuation of benefits? | Follow-up evidence, market conditions, stakeholder perspectives. |
These are example questions only. The final question set should reflect the evaluation’s purpose, intended use, resources, timing and available evidence.
8. Agent 4 — Methodology and Sampling Specialist
Purpose: recommend methods that can credibly answer the agreed questions. This role must explain what each method can and cannot establish.
Input: approved evaluation questions, theory of change, context brief and available data information.
Output: a proposed methodological approach, sampling considerations and limitations.
Copy-ready prompt
ROLE: You are a Senior Evaluation Methodology and Sampling Specialist. INPUT: [PASTE APPROVED EVALUATION QUESTIONS, THEORY OF CHANGE, CONTEXT BRIEF AND AVAILABLE DATA INFORMATION] TASK: Propose a feasible methodology and sampling approach that can answer the agreed evaluation questions. INSTRUCTIONS: 1. Match each evaluation question to suitable qualitative, quantitative or mixed-method approaches. 2. Explain why each proposed method is appropriate. 3. Identify required data sources, tools and analytical procedures. 4. Distinguish descriptive, explanatory and causal questions. 5. Do not recommend an experimental or quasi-experimental design unless the question, implementation conditions, comparison strategy, data and ethical considerations justify it. 6. Do not invent sample sizes, sampling frames, response rates, statistical power or precision. 7. Where information is missing, state what is required to calculate or justify the sample. 8. Discuss probability and non-probability sampling options where relevant. 9. Explain selection bias, non-response, attrition, recall bias and other material limitations. 10. Consider safe, inclusive and accessible participation. 11. Identify data protection, informed consent, safeguarding and confidentiality requirements. 12. Explain how triangulation can strengthen interpretation without assuming that different sources will always agree. OUTPUT: A. Overall methodological approach B. Question-by-question methods table C. Data sources and collection tools D. Sampling frame and design requirements E. Sample size calculation inputs still required F. Analysis strategy G. Quality assurance measures H. Ethical and inclusion safeguards I. Methodological limitations J. Decisions requiring evaluator approval For every recommendation, distinguish between what can be decided now and what depends on additional programme or population data.
An AI system cannot responsibly calculate a defensible sample size from the programme description alone. Sample size decisions depend on the research question, target population, sampling frame, design, expected variability or prevalence, desired precision or power where relevant, clustering, non-response and available resources. The specialist should identify these inputs—not fabricate a number.
9. Agent 5 — Evaluation Matrix Specialist
Purpose: convert the approved questions and methodology into an operational matrix. This is where the design becomes easier to implement, monitor and quality-check.
Input: approved evaluation questions, methods proposal, theory of change and available indicator definitions.
Output: a draft evaluation matrix with clear evidence and analysis requirements.
Copy-ready prompt
ROLE: You are an Evaluation Matrix and Evidence Planning Specialist. INPUT: [PASTE APPROVED EVALUATION QUESTIONS, METHODS PROPOSAL, THEORY OF CHANGE AND AVAILABLE INDICATOR DEFINITIONS] TASK: Create a practical evaluation matrix that links every approved evaluation question to evidence, methods and analysis. INSTRUCTIONS: 1. Include each approved main evaluation question and relevant sub-question. 2. Identify the criterion or analytical dimension. 3. Suggest indicators or lines of inquiry where appropriate. 4. Do not invent baselines, targets or verified indicator values. 5. Distinguish existing programme indicators from proposed evaluation indicators. 6. Identify data sources and the stakeholder groups relevant to each question. 7. Specify data collection methods and analytical approaches. 8. Identify disaggregation requirements where feasible, relevant and safe. 9. State limitations, evidence gaps and triangulation opportunities. 10. Ensure every question has a plausible evidence pathway. 11. Flag indicators that are not measurable or cannot be supported by available data. 12. Avoid collecting sensitive personal data unless it is necessary, proportionate and appropriately protected. OUTPUT TABLE COLUMNS: 1. Evaluation criterion or dimension 2. Main evaluation question 3. Sub-question 4. Indicator or line of inquiry 5. Data source 6. Data collection method 7. Respondent or unit of analysis 8. Analysis approach 9. Disaggregation 10. Limitations and evidence gaps After the matrix, provide: A. Questions without sufficient evidence sources B. Indicators requiring definition or validation C. Data collection tools required D. Inconsistencies with the methodology proposal E. Human decisions required before fieldwork
Illustrative evaluation matrix extract
| Question | Possible indicator / inquiry | Source | Method | Analysis |
|---|---|---|---|---|
| Did participants improve relevant business skills? | Change in demonstrated knowledge or skills, using a defined assessment. | Participants, training records. | Skills assessment, interviews. | Descriptive comparison and qualitative analysis. |
| Did access to financial services improve? | Access, use and perceived suitability of financial services. | Participants, financial service providers where appropriate. | Survey, interviews. | Disaggregated descriptive analysis and triangulation. |
| What barriers affected participation? | Reported barriers by location and relevant participant groups. | Participants and non-participants where feasible. | Interviews, focus groups, programme records. | Thematic analysis and comparison across groups. |
The indicators above are illustrative. They must be operationally defined and tested for validity, reliability, feasibility and ethical appropriateness before use.
10. Agent 6 — Evaluation Design Quality Reviewer
Purpose: challenge the proposed design. This role looks for gaps and contradictions rather than simply approving the work of the other roles.
Input: context brief, theory of change, evaluation questions, methodology and evaluation matrix.
Output: a structured review with severity levels and corrective actions.
Copy-ready prompt
ROLE: You are an independent Evaluation Design Quality Reviewer. INPUT: [PASTE THE CONTEXT BRIEF, THEORY OF CHANGE, EVALUATION QUESTIONS, METHODOLOGY AND EVALUATION MATRIX] TASK: Critically assess the coherence, credibility, feasibility and ethical quality of the proposed evaluation design. REVIEW DIMENSIONS: 1. Alignment between evaluation purpose and questions. 2. Logical consistency between the theory of change and questions. 3. Suitability of methods for answering each question. 4. Adequacy and feasibility of proposed evidence sources. 5. Sampling logic and transparency about missing inputs. 6. Indicator clarity and measurability. 7. Gender, equity, disability and inclusion considerations. 8. Ethics, safeguarding, informed consent and data protection. 9. Feasibility within likely time, budget and operational constraints. 10. Risks of unsupported causal claims or overgeneralisation. 11. Missing stakeholder perspectives. 12. Internal contradictions, duplicated questions and unnecessary data collection. RULES: - Do not approve the design automatically. - Do not assume that another AI role has independently verified the evidence. - Distinguish critical problems from improvements. - Explain why each issue matters. - Recommend specific corrective actions. - Do not introduce unsupported facts. OUTPUT: A. Overall review conclusion: ready for revision, conditionally ready for human review, or not ready. B. Critical issues C. Major issues D. Minor improvements E. Question-to-method alignment gaps F. Evidence and sampling concerns G. Ethics and inclusion concerns H. Recommended revisions, assigned to the relevant specialist role I. Questions requiring human judgement For each issue, identify the affected section, the reason, the severity and the proposed action.
11. Agent 7 — Evaluation Design Manager
Purpose: coordinate the workflow, track dependencies, consolidate specialist outputs and prepare a clear draft package for the human evaluation lead.
Important: this role should not conceal disagreements, fill evidence gaps with invented details or override the reviewer’s critical findings.
Copy-ready prompt
ROLE: You are the Evaluation Design Manager coordinating a team of specialist AI roles. INPUT: [PASTE THE APPROVED CONTEXT BRIEF, THEORY OF CHANGE, EVALUATION QUESTIONS, METHODOLOGY, MATRIX AND QUALITY REVIEW] TASK: Consolidate the work into a coherent draft evaluation design package for review by a qualified human evaluator. INSTRUCTIONS: 1. Preserve the distinction between verified facts, assumptions and proposals. 2. Check that the purpose, theory of change, questions, methods and matrix are logically aligned. 3. Incorporate valid quality-review recommendations. 4. Do not silently resolve disagreements between specialist outputs. 5. Maintain a decision log for unresolved issues. 6. Identify missing documents, data and stakeholder validation. 7. Do not invent sample sizes, baselines, targets, budgets or evidence. 8. Identify methodological limitations and risks to interpretation. 9. Include gender, equity, inclusion, ethics and data protection considerations. 10. Mark all sections that require human approval. 11. Do not describe the design as final, validated or approved. FINAL OUTPUT: A. Executive design summary B. Programme context and evaluability C. Draft theory of change D. Evaluation purpose and scope E. Prioritised evaluation questions F. Proposed methodology and sampling considerations G. Draft evaluation matrix H. Data collection and analysis requirements I. Ethics, safeguarding and inclusion safeguards J. Risks, limitations and mitigation measures K. Quality-review findings and responses L. Outstanding decisions and information gaps M. Human evaluator approval checklist Finish with a clear status: - Draft for human review - Requires further evidence - Requires stakeholder validation - Not ready for approval Never label the package as approved unless a human evaluator has explicitly approved it.
12. Build the first version without coding
You do not need to begin with a complex agent framework. The most reliable first step is to test the workflow manually, using separate AI conversations or role configurations and a shared document or spreadsheet.
Option A — Manual prototype
- Create a project folder and a single source-of-truth programme brief.
- Run the Context Analyst prompt and save its output.
- Review and approve the context brief before moving on.
- Pass the approved output to the Theory of Change Specialist.
- Continue through the roles in sequence, saving each output.
- Run the Quality Reviewer after the draft matrix is ready.
- Use the Design Manager prompt to consolidate the approved and reviewed material.
- Have a qualified evaluator review the complete package.
Option B — Automate the workflow
Once the manual process is producing useful and consistent outputs, automate the repeated handoffs. A beginner-friendly architecture could use:
| Component | Possible tool | Purpose |
|---|---|---|
| User input and project records | Google Forms / Sheets | Collect project information and track workflow status. |
| Document storage | Google Drive | Store source documents and approved outputs. |
| Workflow orchestration | Make.com or n8n | Trigger steps, pass context and manage approvals. |
| AI model calls | An approved model API | Run specialist instructions and return outputs. |
| Monitoring and review | Workflow logs and human review queue | Record failures, revisions, approvals and decisions. |
The tools above are examples, not mandatory choices. Select tools according to organisational security requirements, data residency, access controls, procurement rules, technical capacity and budget.
13. A practical automation architecture
A simple orchestrated workflow can use a project record to manage each stage. The workflow engine determines which role runs next, passes the required context, stores the output and pauses when human approval is required.
Create project ID and validate required inputs
Structured context brief
Confirm facts and scope
Causal logic
Priorities
Methods and sampling
Evidence plan
Identify gaps and required revisions
Consolidate draft and decision log
Revise, approve or return for further work
What each workflow record should contain
Use a consistent project identifier and structured output fields. This makes it easier to trace which information was used and where an output came from.
| Field | Example | Why it matters |
|---|---|---|
| project_id | EVAL-2026-001 | Links all workflow outputs to one project. |
| agent_role | theory_of_change | Identifies which specialist produced the output. |
| input_version | context-v2 | Preserves traceability across revisions. |
| output_status | draft / needs_review / approved | Prevents draft work being mistaken for approved work. |
| evidence_references | Document IDs or source references | Allows reviewers to trace claims. |
| human_decisions | Decision, reviewer and date | Records accountability and approval. |
Essential automation controls
- Structured outputs: define a consistent output format for every role. Validate required fields before passing data to the next step.
- Context management: pass only the relevant approved information to each role. Do not assume every agent can access the full conversation or previous files.
- Failure handling: capture timeouts, empty outputs, malformed data, API errors and failed document retrieval. Route failures to a retry or human review queue.
- Version control: preserve input and output versions so reviewers can identify what changed.
- Cost controls: set usage limits, monitor token consumption and avoid repeatedly sending large documents when a concise approved brief is sufficient.
- Security: store API credentials in secure connection settings, not in prompts, spreadsheets or public documents.
- Access control: restrict sensitive programme information to authorised users and approved services.
- Human approval: pause before any consequential decision, sensitive data processing or final design approval.
Implementation note: this is a reference architecture, not an importable Make.com or n8n scenario. Each module still needs its own API configuration, prompt, input mapping, output parsing, permissions, error handling and tests.
14. Test the team before using it on a real evaluation
Do not judge the system only by whether it produces polished documents. Test whether it follows evidence rules, identifies uncertainty and maintains logical consistency across the workflow.
| Test | Test input or condition | Expected behaviour |
|---|---|---|
| Missing baseline | Provide no baseline data. | Agent flags the gap and does not invent a baseline. |
| Unclear target population | Provide an incomplete participant description. | Agent requests clarification before proposing a sample. |
| Causal overclaim | Ask whether training caused increased income without a suitable design. | Agent distinguishes observed change from causal attribution. |
| Inconsistent questions | Include a question unsupported by the theory of change. | Reviewer flags the mismatch. |
| Missing inclusion data | Provide no safe disaggregated data. | Agent identifies the limitation and privacy implications. |
| Conflicting outputs | Give two roles inconsistent assumptions. | Manager records the conflict instead of hiding it. |
A practical quality scorecard
Use this scorecard as an internal review aid. It is not a validated evaluation standard or a substitute for professional judgement.
| Review dimension | Score | What to check |
|---|---|---|
| Purpose and scope | 1–5 | Clear, useful and feasible. |
| Theory of change | 1–5 | Causal links and assumptions are explicit. |
| Evaluation questions | 1–5 | Answerable and prioritised. |
| Methods and sampling | 1–5 | Appropriate, transparent and feasible. |
| Evidence traceability | 1–5 | Sources and limitations are visible. |
| Inclusion and ethics | 1–5 | Risks and safeguards are addressed. |
| Matrix coherence | 1–5 | Questions connect to evidence and analysis. |
Suggested interpretation: 1 = major weakness; 3 = partially adequate; 5 = strong. Set your own acceptance threshold and require human review of all critical weaknesses.
15. Human evaluator approval checklist
Before a design is used for commissioning, fieldwork or organisational decision-making, a qualified evaluator should confirm the following:
- The programme description and scope have been checked against source documents.
- The theory of change has been reviewed with relevant stakeholders.
- Evaluation questions reflect intended use and stakeholder priorities.
- Selected criteria are appropriate to the evaluation purpose.
- Methods are suitable for the questions and available evidence.
- Sampling decisions are justified using actual population and design information.
- Indicators are clearly defined and feasible to measure.
- The matrix provides a credible evidence pathway for each question.
- Gender, equity, disability inclusion and safeguarding have been considered.
- Consent, privacy, confidentiality and data security procedures are appropriate.
- Limitations and risks of bias are transparent.
- All unresolved methodological decisions have an identified owner.
16. Common mistakes when building multi-agent evaluation systems
| Mistake | Why it creates problems | Better practice |
|---|---|---|
| Creating too many agents | Adds complexity, cost and more handoffs. | Start with bounded roles and add specialists only when needed. |
| Using one prompt for everything | Responsibilities and quality criteria become unclear. | Give each role a defined input, task and output. |
| Treating AI review as verification | A second model can repeat the same error. | Check claims against original evidence and expert judgement. |
| Automating before testing | Errors propagate through the workflow. | Validate the manual process before automating it. |
| Inventing missing data | Creates false confidence and invalid design decisions. | Use explicit missing-information and assumption registers. |
| Removing human approval | Weakens accountability and may create ethical risks. | Keep human approval at consequential decision points. |
17. What this system cannot do reliably on its own
A well-designed workflow can speed up drafting, structure thinking and expose inconsistencies. It cannot independently guarantee a credible evaluation design.
- It cannot establish the truth of programme claims without checking credible source evidence.
- It cannot validate a theory of change on behalf of affected stakeholders.
- It cannot know whether a sampling frame is complete unless the relevant data are supplied and assessed.
- It cannot guarantee causal attribution by generating a sophisticated methodology section.
- It cannot replace ethical review, safeguarding decisions or context-sensitive field judgement.
- It cannot guarantee that several AI roles will reach independent conclusions simply because they use different prompts.
- It cannot assume that sensitive programme documents can be shared with an external AI service.
The best use of the system is as a structured design assistant. It should make the evaluator’s work more transparent and manageable—not obscure responsibility for professional decisions.
18. Your practical challenge: build the first design team
Use the hypothetical women’s economic empowerment programme or replace it with a programme you know. Complete the following exercise in sequence.
- Prepare a one-page programme brief.
- Run the Context Analyst and record five missing information items.
- Draft the theory of change and identify at least five assumptions.
- Write five prioritised evaluation questions.
- Match each question to a feasible method and evidence source.
- Build a draft matrix with at least five rows.
- Run the Quality Reviewer and resolve critical issues.
- Ask the Design Manager to prepare the draft package and decision log.
- Review the final package as a human evaluator. Record what you accepted, rejected and changed.
Suggested completion time: 90–120 minutes for the manual prototype. Automation and testing will require additional time.
Frequently asked questions
What is a multi-agent system in Monitoring and Evaluation?
It is a workflow in which multiple specialised AI agents or model-driven roles collaborate on different M&E tasks. For evaluation design, these may include programme analysis, theory of change development, question formulation, methodology selection, matrix preparation and quality review. The system requires orchestration and appropriate human oversight.
How many AI agents are needed to design an evaluation?
There is no universal number. This tutorial uses six specialist roles and one coordinating role to demonstrate the main design tasks. A small evaluation may need fewer roles; a complex, multi-country evaluation may require additional expertise. The number of agents should reflect task boundaries and value, not the desire to make the architecture look sophisticated.
Can AI develop a theory of change?
AI can help organise programme information, draft causal pathways, identify assumptions and propose questions for validation. However, a theory of change should be grounded in programme evidence, contextual knowledge and stakeholder perspectives. AI-generated pathways should not be presented as validated without appropriate review.
Can AI choose the best evaluation methodology?
AI can compare methodological options and explain their requirements and limitations. The final choice depends on evaluation questions, context, data availability, feasibility, ethics, resources and the level of inference required. A qualified evaluator should make and justify the decision.
Can a multi-agent system automatically calculate sample sizes?
It can assist with calculations when the necessary inputs and design assumptions are known. It should not invent a sample size from a programme description. The sampling frame, population, research design, precision or power requirements, clustering and expected non-response must be considered.
Do AI agents independently verify each other’s work?
Not automatically. Different prompts may produce different perspectives, but they can share the same model limitations and source errors. Meaningful verification requires access to original evidence, explicit review criteria, traceable claims and human judgement.
Can I build this without programming?
Yes. Start with separate AI conversations, copy-ready prompts and a shared document or spreadsheet. A no-code workflow platform can later automate handoffs. More advanced agent frameworks are useful when you need custom tools, state management, permissions, tracing and more complex orchestration.
What is the biggest risk of using AI in evaluation design?
One major risk is producing a convincing-looking design that rests on unsupported assumptions, fabricated evidence or unsuitable methods. Transparent uncertainty, source traceability, human approval and systematic testing are essential safeguards.
Further reading and authoritative resources
Use these resources to deepen the methodological and technical foundations of the workflow.
- World Bank Independent Evaluation Group. Methodological Principles of Evaluation Design. Guidance on design quality, matching methods to questions, mixed methods, constraints and theory-based evaluation.
- OECD (2021). Applying Evaluation Criteria Thoughtfully. Guidance on the six criteria and their context-sensitive use.
- OECD. Using the Evaluation Criteria in Practice. Practical considerations for selecting criteria and designing an evaluation around its purpose and intended use.
- UN Women (2022). UN Women Evaluation Handbook. Guidance on gender-responsive evaluation, stakeholder participation, sampling, ethics and evaluation management.
- OpenAI Developers. Agents documentation. Overview of agent runtimes, tools, orchestration and context management.
- OpenAI Agents SDK. Agent orchestration. Explains manager-style orchestration, handoffs and code-driven workflows.
- BetterEvaluation. Choose methods and processes. A practical resource for connecting evaluation questions, methods and processes.
The bigger opportunity: move from AI prompts to coordinated evaluation teams
The real value of multi-agent AI in evaluation is not the number of agents. It is the ability to organise complex work into specialised, traceable and reviewable tasks.
A context analyst, theory of change specialist, methodology specialist and quality reviewer can help an evaluator approach a complex design systematically. But credible evaluation still depends on evidence, stakeholder participation, ethical practice and professional judgement.
Continue learning with EvalCommunity Academy
Explore practical learning resources for AI agents, Monitoring and Evaluation, and international development professionals.
EvalCommunity Academy · Practical AI learning for Monitoring, Evaluation, Accountability and Learning (MEAL) and international development professionals.
