Eight Patterns Behind the AI Tools You Already Use
Eight Patterns Behind the AI Tools You Already Use
You don’t need to write code to benefit from understanding how AI tools are built. Knowing the patterns behind them helps you write better prompts, judge what a tool can realistically do, and ask sharper questions before it touches your evaluation work.
Why this matters if you’re not a developer
A chatbot that only talks to a base language model has no access to your logframe, your indicator data, or last year’s evaluation report — it can only draw on what it was trained on. Most useful AI tools are built by combining several distinct design patterns on top of that base model. Recognizing these patterns lets you tell the difference between a tool genuinely reading your documents and one confidently guessing.
The core idea: a language model on its own is one piece. Retrieval, memory, planning, self-checking, coordination between specialized agents, and human review are what turn that model into something reliable enough for real MEAL work.
The eight patterns
Retrieval-augmented generation (RAG)
The tool searches your own documents first, then answers using what it finds, instead of relying only on training data.
Where you’ve seen it: NotebookLM answering from your uploaded evidence base, or Claude citing your uploaded logframe instead of inventing indicator definitions.
Try it: upload your last three evaluation reports and ask, “What data-quality issues came up across all three?” — a real RAG-backed tool answers from those files, not a generic list.
Planning and task breakdown
Large requests get split into smaller, ordered sub-tasks rather than tackled in one pass — outline, then methodology, then findings, then recommendations.
Where you’ve seen it: asking an assistant to draft a full ToR or evaluation matrix and watching it work section by section.
Try it: instead of “write my endline report,” ask it to first propose a section-by-section outline, then approve or edit each section before it drafts the next.
Tool calling
The model can trigger real actions instead of describing them — running a search, pulling rows from a spreadsheet, creating a document in your Drive.
Where you’ve seen it: Gemini Spark creating a Doc on a schedule, or Claude with a connector reading directly from a shared indicator tracker.
Try it: connect a tool to your Drive and ask it to flag any indicator in your tracker with no update in 60 days — that requires it to actually open the file, not describe how you’d check it.
Memory
Some tools only remember the current conversation. Others retain facts and preferences across sessions — your reporting style, a program’s background, your framework’s vocabulary.
Where you’ve seen it: an assistant that still remembers your evaluation framework’s terminology weeks after you first explained it.
Try it: explain your organization’s specific definition of “beneficiary reach” once, then in a later session ask a question that depends on that definition — persistent memory means you shouldn’t have to repeat it.
Reflection and self-review
Rather than returning its first draft, the tool checks its own output against a standard, finds weaknesses, and revises before handing it back.
Where you’ve seen it: this is the same loop behind the Claude Loop Auditor tutorial — draft, critique against a rubric, revise.
Try it: after any AI-drafted findings section, ask it to critique its own draft against your evaluation quality checklist before you read the “final” version.
Multiple specialized agents working together
Separate specialized agents each handle one job — one checks data quality, one tracks indicators, one synthesizes evidence — and a coordinating step combines their output.
Where you’ve seen it: the AI Data Quality Review Agent, AI Indicator Tracking Agent, and AI Evidence-Synthesis Agent companion apps — each specialized rather than one tool doing all three jobs.
Try it: run your raw field data through a data-quality pass first, then feed only the cleaned output into a synthesis pass — don’t ask one tool to do both at once.
Knowledge graphs
Basic retrieval finds documents that look similar. A knowledge graph maps how specific things connect — which activities feed which outputs, which outputs feed which indicators — so a tool can trace what changing one element affects.
Where this is heading in MEAL work: asking “if we drop this indicator, what parts of the logframe and reporting are affected?” and getting a traced answer instead of a guess.
Try it: most current tools can’t do this well yet — treat any confident answer to a multi-hop logframe question with extra scrutiny until you’ve verified it manually.
Human-in-the-loop review
The one pattern that is never optional in MEAL work: a qualified evaluator checks the output before it informs a decision, a report, or a donor communication. None of the previous seven patterns replace evaluator judgment — they only change how much preparatory work reaches you before you apply it.
Where you’ve seen it: an AI Output Validator step that checks a draft against your standards before a human signs off — the validator narrows what needs review, it doesn’t replace the reviewer.
Try it: for any AI-assisted output that will reach a donor or inform a program decision, build a short checklist of what you personally verify before it goes out, regardless of how confident the tool sounds.
Match the pattern to your MEAL task
Literature or evidence review
Needs retrieval above all — a tool that isn’t reading your actual source documents is summarizing from memory, not from your evidence base.
Drafting a ToR or evaluation report
Needs planning to break the document into sections, plus reflection to catch weak reasoning before you see a “final” draft.
Indicator tracking and reminders
Needs tool calling to actually read your tracker, plus memory so it remembers your reporting cadence without you restating it each time.
Multi-source data quality review
Needs specialized agents working in sequence — a data-quality pass before a synthesis pass — plus human review before any finding is finalized.
Logframe or theory of change redesign
Would benefit from knowledge-graph reasoning to trace downstream effects, which most current tools don’t do reliably — lean on human review here more than usual.
Red flags when evaluating a MEAL AI tool
- It confidently cites sources or figures it never actually retrieved — a sign there’s no real RAG behind it.
- It forgets your framework’s terminology every single session — a sign it has no persistent memory.
- It cannot explain why it changed a draft between versions — a sign there’s no genuine reflection step, just re-generation.
- It claims to “check your data” but has no way to actually connect to your files — a sign there’s no real tool calling, only a description of what it would do.
- It presents output as ready to send with no prompt for your review — a sign human-in-the-loop was designed out, not in.
Putting it together
The strongest AI tools rarely rely on a single pattern. A well-built evaluation assistant might retrieve from your uploaded reports, break your request into steps, call a tool to pull live data, remember your preferences across sessions, review its own draft, route different parts of the job to specialized agents, and still leave the final sign-off to you. The underlying language model is just one part of that system — everything wrapped around it, including your own review, is what makes the difference between a novelty and something you can rely on for real MEAL work.
A practical filter: when evaluating a new AI tool for your team, ask which of these eight patterns it actually uses. A tool with no retrieval, no self-review, and no clear point where a human signs off deserves more scrutiny before it touches donor-facing content.
Frequently asked questions
Do I need to understand all eight patterns to use AI tools well?
No. Knowing they exist is enough to ask better questions of any tool — for example, whether it reads your own documents (RAG) or only reviews its own output once (reflection).
Which pattern matters most for evidence synthesis work?
Retrieval-augmented generation. If a tool isn’t retrieving from your actual source documents, any synthesis it produces is closer to a guess than a review.
Does human-in-the-loop review slow everything down too much to be practical?
Not if it’s scoped well. The other seven patterns exist to narrow what needs your attention — a good AI Output Validator step means you’re reviewing a shorter, higher-quality draft, not starting from a blank page.
Does more patterns always mean a better tool?
Not automatically. More moving parts also means more places for something to go wrong. The right question is whether the patterns a tool uses match the risk level of the task — a quick internal brainstorm needs less scaffolding than a donor report.
EvalCommunity Academy — AI Literacy for MEAL Practitioners
