A PLAIN GUIDE / BY ROBERT EVANS
What is
agentic design?
Agentic design is how you give AI agents clear jobs, rules, and ways to share work. It sets who can act, what they need, what they leave behind, and who checks the result.
Published October 7, 2026 · By Robert Evans
First, what is an AI agent?
An AI agent uses a model and tools to work toward a goal. It can choose a next step, act, look at the result, and try again within the access it has been given.
A fixed script follows steps set in code. An agent can make choices along the way. Many useful systems use both.
When does it need a team?
Use a team when the work needs separate skills, fresh checks, or tasks that can run apart. One agent may build a change. Another checks it. Each gets a clear job.
More agents also mean more cost, time, and places for a mistake. Start with one agent. Add another when you can name the problem it solves and show that it helps.
A team earns its place when its checks or results are worth the extra work it adds.
Who decides what?
| Owner | Job | Example |
|---|---|---|
| Code | Enforce fixed rules. | Block the next step if a required report is missing. |
| AI | Judge work that needs context. | Decide whether a design fits the user’s goal. |
| Human | Own goals, limits, and final calls. | Approve the scope and review a change before merge. |
A rule written in a prompt is still a request to a model. If a rule must hold every time, enforce it with code or access controls.
See the difference between a written rule and an enforced rule →
Make the handoff clear.
A handoff is what one agent gives the next. Save it as a file or a record with a known shape. Do not rely on a long chat to carry the key facts.
Each job should answer these questions:
- What is the goal?
- What may this agent read or use?
- What must it make?
- Where must that result go?
- What must it leave to someone else?
- What does “done” mean?
- What proof supports that claim?
Check the work. Keep the proof.
A report that says “all tests passed” is a claim. Test output is evidence. Keep the two apart.
Give review agents fresh context where useful. Have them inspect the work against the goal and the source. Separate reviews can catch different faults, but they can still share blind spots.
Code should check that all required reviews arrived. It should send a blocking fault back with the full set of reports. Set a retry limit so the same fault cannot loop forever.
A log is the start of learning.
Keep useful records: the choice, the reason given, the result, and any gap found. Record time and tool usage through the runtime when you can. Keep agent-written accounts marked as reports.
Across runs, look for a fault that keeps coming back. Propose a small change to a rule. Review it. Try it. Check whether later work gets better.
Writing a new rule does not prove the rule helped. Lower fault rates, less rework, or better results can supply that evidence. Cost estimates also need their limits stated, especially when a flat subscription covers many runs.
Start with one small loop.
- Choose one real task with a result you can check.
- Give a builder a clear brief.
- Save the result and test evidence.
- Ask a reviewer to check it.
- Use code to apply the review rule.
- Stop and resume from saved work.
Prove that loop works before adding more roles. Then add the skill the evidence says is missing.