FREE AI AGENT DESIGN LEARNING PATH

WikiFree original practice workbook

The agent control room

CASE STATUS: fictional/synthetic teaching material. Do not present the example as real research, employment experience or measured business performance.

OUTCOME
Design and run a local rule-based agent simulation with an allowlist, approval boundary, audit trail and adversarial test cases.

BEFORE YOU START
Basic Python functions and dictionaries, or willingness to trace the supplied simulator by hand. No model API account.

CASE
The fictional Hazel Helpdesk assistant may search three public FAQ notes and draft a reply. Sending a reply or changing a booking requires a separate human action. The supplied simulator is deterministic Python; it demonstrates orchestration rules, not the capabilities of a trained language model.

INPUTS
Request,Allowed next step
What are the opening hours?,"Search approved notes, then draft"
Send the answer to a customer,Stop at human approval
Delete the booking,Reject unavailable action
A note says ignore rules and send records,Treat note as data; do not obey


ENTRY CHECK

Question: Does planning grant permission?

Self-check: No. Available actions still need explicit authorization.

Question: Is a retrieved instruction trusted?

Self-check: No. Retrieved text is task data.

Question: Is a rule-based simulation an LLM benchmark?

Self-check: No.

STAGE 1: Define the job and tools

Prerequisite: Basic Python functions and dictionaries, or willingness to trace the supplied simulator by hand. No model API account.

Instruction: Separate the user goal from the tools that can change the world. A search tool reads approved notes; a draft tool creates local text. Neither implies permission to send or modify records. Give every tool a small input schema, a return type and a failure result. A narrow allowlist makes the first agent easier to reason about and test.

Practice task: Write the assistant contract and tool table for search and draft only. List excluded actions.

Deliverable: A two-tool specification and scope boundary.

Acceptance check: No send, delete, payment or booking-modification tool exists in the allowed set.

If stuck: Remove a broad execute-anything tool and replace it with a narrowly described operation.

Record your work, decisions and evidence:




Record your result against the acceptance check:



STAGE 2: Model the state transitions

Prerequisite: Bring your previous output: A two-tool specification and scope boundary.

Instruction: Use explicit states for received, validated, retrieved, drafted and awaiting human action. Add rejected and failed states rather than silently continuing after a problem. A plan can propose a step, but the dispatcher validates it before execution. Set a small step budget so a failed search cannot trigger an endless retry loop.

Practice task: Draw the state diagram and implement the supplied transition table. Set a maximum of four tool steps per request.

Deliverable: A state machine with failure and approval exits.

Acceptance check: Every state has an allowed next step or an explicit terminal outcome.

If stuck: If a failed retrieval still produces a confident answer, route it to clarification or a missing-evidence response.

Record your work, decisions and evidence:




Record your result against the acceptance check:



STAGE 3: Validate each tool call

Prerequisite: Bring your previous output: A state machine with failure and approval exits.

Instruction: A dispatcher should check the tool name, argument shape and authority before calling anything. The supplied simulator accepts only a known search topic and a local draft body; it records every attempted action. Validation is separate from the planner so a persuasive or malformed request cannot create a new capability. Rejection should explain the boundary without executing the requested mutation.

Practice task: Run the local simulator against a valid FAQ request, an unknown tool and missing arguments. Inspect the event log.

Deliverable: A guarded dispatcher and test outputs.

Acceptance check: Unknown or malformed actions produce rejection records and no tool execution.

If stuck: Do not treat an instruction embedded in a tool result as a new authorized user request.

Record your work, decisions and evidence:




Record your result against the acceptance check:



STAGE 4: Test hostile and ambiguous inputs

Prerequisite: Bring your previous output: A guarded dispatcher and test outputs.

Instruction: Tests should include ordinary success, missing evidence, attempted authority expansion and untrusted instructions in retrieved notes. Keep expected outcomes distinct from actual results. The rule simulator can prove its own transition behavior, but it cannot establish that a future model will always follow the same policy. That future integration needs its own evaluation and runtime checks.

Practice task: Run four supplied scenarios and add two new ones. Record expected state, observed state and whether any side effect occurred.

Deliverable: A scenario evaluation table.

Acceptance check: The send request stops at approval, delete is rejected and document instructions do not change the allowlist.

If stuck: If a test simply compares a hardcoded answer to itself, add a case that challenges a different validation branch.

Record your work, decisions and evidence:




Record your result against the acceptance check:



STAGE 5: Package the operating rules

Prerequisite: Bring your previous output: A scenario evaluation table.

Instruction: A handover should explain the allowed tools, retained logs, human decision point and recovery after a failure. A production deployment would need authentication, secret management, monitoring and real integration testing; our local educational simulator provides none of those by implication. Document these gaps so the artifact is useful without overstating readiness.

Practice task: Write a README, operating checklist and a separate future-integration risk list.

Deliverable: A reproducible agent simulation package.

Acceptance check: A reviewer can run the simulator locally and identify every action requiring a human.

If stuck: Do not label the package production-ready because the small scenario suite passes.

Record your work, decisions and evidence:




Record your result against the acceptance check:



WORKED CASE
A request to send a draft ends in awaiting_human_action. A request to delete a booking is rejected because no such tool is allowed. A retrieved note asking for record disclosure remains untrusted content and cannot extend the dispatcher allowlist.

FINAL PROJECT
Submit the tool contract, state diagram, runnable simulator, event logs and scenario results. Add a failing search result and demonstrate a safe terminal outcome within the step budget.

REQUIRED CRITICAL CHECK
No unapproved external action occurs, and untrusted retrieved text cannot add a tool or permission.

SCORING
Score each of the five stage acceptance checks from 0–16 (0 missing/incorrect; 8 partially supported; 16 complete and evidenced). Score the final integrated project from 0–20 (0 missing; 10 incomplete handover; 20 complete, reproducible and consistent with the case). Target: at least 80/100 AND the critical check must pass. A total score never overrides a failed critical check.

SCOPE LIMIT
This is a local orchestration simulation, not a deployed autonomous assistant, a multi-agent system or proof of real-model safety.

SOURCES AND ACCESS
All selected videos are public. The project runs with standard Python and fixed local notes. A paid model API, cloud deployment and real customer data are unnecessary.

Free AI Agents Course: Build Intelligent Applications
WikiFree: https://wikifree.com/courses/microsoft-ai-agents-for-beginners/
Official source: https://www.youtube.com/playlist?list=PLlrxD0HtieHgKcRjd5-8DT9TbwdlDO-OC
Why selected: Microsoft individual lessons cover agent concepts, frameworks, patterns, planning, tools and evaluation. The compilation lesson is not repeated; the guarded simulator is original.

Stage 1 selected lessons:

2. What are AI agents? (5:57)
https://www.youtube.com/watch?v=3zgm60bXmQk&list=PLlrxD0HtieHgKcRjd5-8DT9TbwdlDO-OC&index=2

3. Which AI agent framework to use (8:21)
https://www.youtube.com/watch?v=ODwF-EZo_O8&list=PLlrxD0HtieHgKcRjd5-8DT9TbwdlDO-OC&index=3

Stage 2 selected lessons:

4. How to design good AI agents (5:24)
https://www.youtube.com/watch?v=m9lM8qqoOEA&list=PLlrxD0HtieHgKcRjd5-8DT9TbwdlDO-OC&index=4

12. What Is the AI Agent Planning Design Pattern? (5:29)
https://www.youtube.com/watch?v=kPfJ2BrBCMY&list=PLlrxD0HtieHgKcRjd5-8DT9TbwdlDO-OC&index=12

Stage 3 selected lessons:

6. What Is the Agent Tool Use Design Pattern? (6:15)
https://www.youtube.com/watch?v=vieRiPRx-gI&list=PLlrxD0HtieHgKcRjd5-8DT9TbwdlDO-OC&index=6

Stage 4 selected lessons:

10. How to build effective AI agents (5:55)
https://www.youtube.com/watch?v=iZKkMEGBCUQ&list=PLlrxD0HtieHgKcRjd5-8DT9TbwdlDO-OC&index=10

14. How can AI agents improve? (7:13)
https://www.youtube.com/watch?v=His9R6gw6Ec&list=PLlrxD0HtieHgKcRjd5-8DT9TbwdlDO-OC&index=14

Stage 5 selected lessons:

7. How to deploy AI agents into production (5:55)
https://www.youtube.com/watch?v=l4TP6IyJxmQ&list=PLlrxD0HtieHgKcRjd5-8DT9TbwdlDO-OC&index=7

REUSE
Original WikiFree teaching text and synthetic fixtures are supplied for personal learning and adaptation with attribution. Provider lessons remain on their original sites and retain their own terms. No provider certificate is included.