AI Agents Cheat Sheet
By the Syncfusion DevTutorials team · Last updated
Every key idea from the AI Agents course on one page: the loop, stop rules, permissions, planning strategies, memory, guards, dev-workflow agent configs, metric formulas and an error index.
Everything from this course on one page. Use it as a quick reference while building your own agents. Each section points back to the lesson where the topic is explained in detail.
Everything in this summary matches the behavior of the Agent Lab. Open the Lab from the card at the bottom of the page if you want to try any scenario again.
The Agent Loop
The loop from Lessons 1, 3, and 9: look → think → act → check. Repeat until a stop condition says the task is finished.
The loop template
async function runAgent({ goal, brain, tools, maxSteps }) {
const steps = [];
for (let n = 1; n <= maxSteps; n++) {
const action = await brain(goal, steps); // think
if (action.final) return { stop: "final", answer: action.final, steps };
const tool = tools[action.tool];
const observation = tool ? await tool(action.args) : "ERROR: unknown tool " + action.tool; // act
steps.push({ n, action, observation }); // check: the next think reads this
}
return { stop: "max-steps", steps };
}
const tools = { run_tests: async () => "3 passed, 0 failed" };
const brain = async (goal, steps) => steps.length ? { final: "All tests pass." } : { tool: "run_tests" };
runAgent({ goal: "Make the tests pass", brain, tools, maxSteps: 5 }).then((r) => console.log(r.stop + ": " + r.answer + " (" + r.steps.length + " tool step)"));
Expected output:
final: All tests pass. (1 tool step)
Agent or Workflow?
| Use… | When… | Lesson |
|---|---|---|
| One model call | The answer needs no tools and no checking. | 1 |
| A fixed workflow | The steps are always the same. | 1 |
| An agent | The next step depends on what the last step found. | 1 |
| A team of agents | The work spans several roles with different tools. | 23 |
Stop Rules and Budgets
| Stop reason | What triggers it | Lesson |
|---|---|---|
| final | The brain says the goal is met, and the check proves it. | 2, 10 |
| max-steps | The step limit: the last line of defence. | 4, 10 |
| budget | A hard token, time, or cost limit. A soft limit warns first. | 10 |
| stalled | The progress check: no change for N steps. | 10 |
| stopped | An interrupt, such as a person pressing Stop. | 10 |
| guarded | A loop guard: duplicate, cycle, timeout, or isolation. | 16 |
| rejected | The input layer refused the goal. | 3 |
Boundaries and Permissions Checklist
write_filemay only change files in the agent's own folder. (Lessons 1, 5)- Test files are forbidden for agents that fix code. (Lessons 5, 19)
- Every tool call is checked against its schema before it runs. (Lesson 11)
- Each agent has only the tools its role needs. (Lessons 11, 24)
- Read-only mode for agents that only inspect. (Lessons 11, 24)
- A file must be read before it is written. (Lesson 12)
- Risky actions require a person's approval, one approval per action. (Lesson 24)
- Tool results are data, never instructions. (Lesson 24)
Planning Strategies
| Strategy | How it works | Good for | Lesson |
|---|---|---|---|
| ReAct | Reason, act, observe, repeat. | Most tasks; adapts every step. | 7 |
| Plan-and-Execute | Plan all steps first, then run them, re-plan if a check fails. | Long tasks with a clear shape. | 7 |
| Reflexion | Try, check, write a reflection on what went wrong, try again. | Tasks with a clear pass/fail check. | 7 |
| Tree of Thoughts | Generate several candidate steps, score them, keep the best. | Choices where one wrong turn is costly. | 8 |
| MCTS | Try many short random paths and favor the ones that succeed most often. | Large search spaces. | 8 |
| Dynamic planning | Revise the plan when new information appears. | Problems that only become visible later. | 8 |
Memory Techniques
| Technique | What it does | Lesson |
|---|---|---|
| Scratchpad | Goal, constraints, evidence, facts, assumptions, decisions. | 13 |
| Compression | Keep the summary and FAIL lines of a test result. | 13 |
| Sliding window | Keep only the last N steps. Forgets on its own. | 13 |
| Window + pinned | Keep the last N steps plus the latest evidence and file text. | 13 |
| Priority budget | Fill the memory budget from the most important notes down. | 13 |
| Snapshot | Save the steps and a file hash after every step. | 14 |
| Integrity check | Restore only if the file hash still matches. | 14 |
Guards
| Guard | Catches | Lesson |
|---|---|---|
| Retry with backoff | Temporary faults: crashes, timeouts, empty output. | 15 |
| Fallback chain | A tool that stays broken: another action, a partial answer, or escalation. | 15 |
| Duplicate detector | The same action and result 3 times in a row. | 16 |
| Cycle detector | A, B, A, B. | 16 |
| Frequency limit | One tool used too many times. | 16 |
| Timeout | A call that hangs. | 16 |
| Failure isolation | A tool that keeps crashing: switch it off. | 16 |
| Forced exit | Step and budget limits: always works, but late. | 10, 16 |
Dev-Workflow Agent Configs
| Agent | Tools | Done when | Lesson |
|---|---|---|---|
| Planner | read_file, create_task | 6 tasks with Given/When/Then criteria, estimates, and the correct dependencies. | 17 |
| UI design | read_file, write_file, check_a11y, check_tokens | Both checks pass after the final change. | 18 |
| Frontend | read_file, write_file, run_tests | Every test passes. Never edits tests. | 19 |
| Backend | read_file, write_file, check_contract, check_speed | Contract first; both checks pass. | 20 |
| Review | read_file, review_diff | Every rule checked; must-fix items listed first. | 21 |
| Bug | read_log, read_file, write_file, run_tests | A failing test reproduces the bug, then passes after the patch. | 21 |
| Testing | read_file, write_file, run_tests, run_coverage | Coverage target met with passing tests. | 22 |
| Audit | read_file, write_file, scan_deps | The scan is clean after the patch. | 22 |
| Docs | read_file, write_file | The changelog is written in the users' words. | 23 |
| Deploy | run_tests, check_contract, check_a11y, request_approval | Every check passes and a person approved. | 23, 24 |
Metric Formulas
The four core metrics
const metrics = {
toolSuccess: (r) => r.toolOk / r.toolCalls,
decisionAccuracy: (r) => r.passed / r.tasks,
planCompletion: (r) => r.verified / r.tasks,
recoveryRate: (r) => r.faultyPassed / r.faulty,
};
const baseline = { toolOk: 26, toolCalls: 33, passed: 6, verified: 5, tasks: 10, faultyPassed: 2, faulty: 6 };
for (const [name, f] of Object.entries(metrics)) console.log(name.padEnd(17) + Math.round(f(baseline) * 100) + "%");
Expected output:
toolSuccess 79%
decisionAccuracy 60%
planCompletion 50%
recoveryRate 33%
These are the baseline agent's numbers from Lesson 25's mini-benchmark.
From Lab to Production
| Lab | Real coding agents |
|---|---|
| Scripted brain | A large model: runs vary, so run each task several times |
| Tool registry | Built-in tools and MCP servers with schemas |
| Folder boundary, read-only | Sandbox settings, allowed commands, plan mode |
| request_approval | Permission prompts before edits and commands |
| Budgets and loop guards | Turn, token, and cost limits; timeouts |
| Working memory | Context compaction and project notes files |
| Snapshot | Git commits, branches, and checkpoints |
| Agent team | One main agent with subagents, and a person between stages |
| Mini-benchmark | Your own task suite, run in CI |
The full table with common traps is in Lesson 25.
Error Index
| Message | Cause | Fix | Lesson |
|---|---|---|---|
stopped because it hit the step limit | No stop rule fired, or the agent is looping. | Add a done check; add loop guards. | 2, 16 |
write_file needs path and content | Schema mismatch: wrong argument names. | Read the error, fix the names, call again. | 11 |
Unknown tool "…" | The tool isn't in this agent's registry. | Give the role that tool, or choose another. | 3, 24 |
BLOCKED: you may only change files in web/ | A write outside the agent's folder. | Hand the task to the right agent, or escalate. | 1 |
PRECONDITION FAILED: read … first | Write before read. | Read the file, then write. | 12 |
CONFLICT: … in the same batch | A write batched with a reader of the same file. | Write first, then check. | 12 |
duplicate guard: … | The same action and result 3 times in a row. | Find why the agent repeats; give it memory. | 16 |
cycle guard: … | A, B, A, B. | Usually lost memory: pin the evidence. | 13, 16 |
timed out after 5 s | A tool call hung. | Retry with backoff, then fall back. | 15, 16 |
… is disabled: it crashed 2 times | Failure isolation switched a tool off. | Escalate; fix the tool. | 16 |
REJECTED: … files changed since it was saved | Drift after a crash. | Take a fresh look; re-read changed files. | 14 |
[Budget warning: …] | A soft limit was reached. | Finish soon, or ask for more budget. | 10 |
[removed: this line looks like an instruction …] | The injection filter removed an instruction hidden in data. | Nothing. The guardrail worked. Report the ticket. | 24 |
Easy Way to Remember the whole course: look, think, act, check. Stop on proof, not on hope. Give each agent only what it needs. Guard the loop from outside. Measure, then tune.
Every guardrail in this course is a layer, not a wall. Use several together, and test them with chaos runs, attack suites, and benchmarks.
One more run: all four pillars
Thanks for completing AI Agents. A good next step is the Agent Skills course, which packages what an agent knows into reusable skills.