6 AI Agent Design Patterns and Why You Should Design Evals First
Has your team decided to build an AI agent, picked a model and tools, and then realized nobody knows how to tell whether it works? An agent built without success criteria can look great in a demo, yet when it goes into real work, it's hard to see where it fails.
The daglo team put this together from an agents session we attended at OpenAI Builder Bootcamp Seoul on October 27, 2026. Below, we explain the six AI agent patterns presented in the session using everyday team workflows, then cover why and how to design evaluation before you build.
What is an AI agent, and what should you decide first?
An AI agent is a system that chooses and carries out the actions needed to complete a task. It isn't just a model: it combines a workflow, the tools it can use, and the instructions it follows.
The session flagged questions you hit as soon as you start building:
- Where to store state that changes mid-task, and when the task should end
- How to combine tools and other agents
- How much autonomy to allow: if a person must approve every action, doing it by hand may be easier
- How to handle the security and safety risks that grow with more permissions
6 AI agent patterns explained as team workflows
The six AI agent patterns presented in the session are chaining, triage and handoff, parallel execution, retry and fallback, evaluator-optimizer loops, and sandboxed agents. They're easiest to grasp when you picture a team of people at work.
| Pattern | Team analogy | Example from the session |
|---|---|---|
| Workflow chaining | A relay race: each runner passes the result to the next | A planner, a researcher, and a report writer in sequence |
| Triage and handoff | A front desk routing each request to the right department | Detect the language and hand off to that language's translator |
| Parallel execution | Several people draft at once and a lead picks the best | Generate several translations at once, then choose one |
| Retry and fallback | If a call fails, try again later; if it keeps failing, call someone else | Retry temporary errors with a set limit and wait time |
| Evaluator-optimizer | Draft, review, revise until it's approved | A writing agent paired with a reviewing agent |
| Sandboxed agent | Work only inside a designated workroom | Run code in an isolated environment with only the files it needs |
The six can be combined. The first five shape the order and branching of work, while the sandbox decides where that work runs and with what permissions. A few things are easy to miss in production:
- Evaluator-optimizer loops can run forever unless you set a stop rule, such as a maximum number of rounds or a cost cap.
- Retries on actions that change state, like payments, must not process the same thing twice.
- Triage needs its own check: was the request sent to the right agent, apart from how good each agent's answer is?
Why you should design evals before you build
As coding agents cut build time, checking that your agent actually does the intended job matters more. That's why the session recommended defining success criteria and evaluation methods before implementation.
With evals in place first, you can rerun the same test after every change and see its effect. An eval needs four things:
- Dataset: real task examples and the results you expect
- Agent and tools: what you're testing
- Graders: rules, models, or people who judge the output
- Metrics: what graders look at, such as accuracy, format, cost, and latency
Rules, models, or people: how to grade
Choose the grader by the nature of the task. Use rules for formats with a clear right answer, models or people for meaning and tone, and people for complex processes that are hard to judge automatically.
| Grader | Best for | Example |
|---|---|---|
| Rules (code) | Clear-cut formats | Is the JSON valid? Are required fields present? |
| Model | Meaning and tone that need judgment | Does the translation keep the original meaning? |
| People | Hard-to-automate processes and high-stakes cases | Complex app or browser flows, real phone handoffs |
Checking only the final answer isn't enough. The session used the example of asking for Canada's population. If the agent searched for fresh data, you should check, separately from whether the final answer is right, whether it picked the right search tool, whether the tool worked, whether the results were relevant, and whether it used them correctly.
For qualities like tone that aren't simply right or wrong, use a rubric: a scoring sheet that rates several angles, such as accuracy, staying in character, and natural language. For a store's returns agent, you'd score whether the order lookup and refund were correct separately from whether the message to the customer was polite. Domain experts should help build both the dataset and the criteria.
For a step-by-step way to compare prompts before and after a change, read What Are AI Evals?
Record, summarize, report: a chain you already use
Turning a meeting into a report follows the same chaining pattern. Recording, transcribing, summarizing, and drafting a report each feed the next step.
daglo keeps that chain in one place. Record a meeting or upload a file and you get a transcript that shows who's talking. Save your preferred summary format in My Templates, and daglo remembers it and summarizes every recording that way automatically. From there, ask Board Chat to "turn the decisions into a report outline," or build a deck with AI Slides. Every step links back to the original transcript, so you can check intermediate results too.
The better the first step, the more accurate everything after it. Speaker ID remembers the voices of the people in your meeting and fills in their real names instead of "Speaker 1" from the next recording on. daglo is the first in Korea to offer this to every user. With the right names in the record, summaries and reports don't mix up who owns what. Learn more about Speaker ID
#AIAgents #AgentPatterns #AIEvals #Rubric #WorkflowAutomation #OpenAI #AgentDesign #daglo
Where talk becomes work.
Get started with 1,000 credits a month — no credit card required.