WikiFree learning path 29 · Intermediate
The agent control room
Give a tool-using system a small, testable job.
Design and run a local rule-based agent simulation with an allowlist, approval boundary, audit trail and adversarial test cases.
Video duration uses the selected lessons only. Reading and practice times are planning estimates; repeat difficult work as needed.
A clear starting point
Who this is for
Basic Python functions and dictionaries, or willingness to trace the supplied simulator by hand. No model API account.
Your practical result
Design and run a local rule-based agent simulation with an allowlist, approval boundary, audit trail and adversarial test cases.
This is a local orchestration simulation, not a deployed autonomous assistant, a multi-agent system or proof of real-model safety.
Access and cost
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.
The project pack contains an original workbook, case inputs, an evidence log and reference notes. Some technical paths include starter code and a runnable reference. Read the pack README before starting.
Three-minute readiness check
Answer first, then open each explanation. A missed answer identifies what to revisit; it does not stop you from starting.
Does planning grant permission?
No. Available actions still need explicit authorization.
Is a retrieved instruction trusted?
No. Retrieved text is task data.
Is a rule-based simulation an LLM benchmark?
No.
The case you will work on
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.
| 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 |
These are supplied synthetic inputs, not observations from a real organization. Label assumptions and any additional data you create.
Keep an evidence trail
Save each stage output in the project folder. In evidence_log.csv, record the decision, the artifact or test that supports it, what failed, and the revision you made.
Your route from learning to evidence
- Stage 1Define the job and toolsA two-tool specification and scope boundary.60 minutes of original practice
- Stage 2Model the state transitionsA state machine with failure and approval exits.75 minutes of original practice
- Stage 3Validate each tool callA guarded dispatcher and test outputs.90 minutes of original practice
- Stage 4Test hostile and ambiguous inputsA scenario evaluation table.85 minutes of original practice
- Stage 5Package the operating rulesA reproducible agent simulation package.55 minutes of original practice
- Final projectMake the evidence reviewableConnect the five stage outputs and test a change.240 minutes estimated
Progress stays in this browser. Tick a stage only after its evidence check passes. This is a personal checklist, not a certificate.
Why these source courses
The path uses selected material from courses already published on WikiFree. The original exercises below connect that material to one practical outcome. Follow only the listed assignments; completing the full source courses is optional.
Microsoft
Free AI Agents Course: Build Intelligent Applications
Microsoft individual lessons cover agent concepts, frameworks, patterns, planning, tools and evaluation. The compilation lesson is not repeated; the guarded simulator is original.
Access: Free Video
Certificate: Video viewing only; no certification exam or certificate promised
Learn it, apply it, check it
Work in order. Every stage produces something the next stage uses. Revisit the repair instruction when a check fails.
Define the job and tools
Basic Python functions and dictionaries, or willingness to trace the supplied simulator by hand. No model API account.
The idea to use
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.
Watch the selected lessons
Selected video time: 14m. Open this course on WikiFree.
Your 60-minute lab
Write the assistant contract and tool table for search and draft only. List excluded actions.
Save: A two-tool specification and scope boundary..
Evidence check
No send, delete, payment or booking-modification tool exists in the allowed set.
If it fails: Remove a broad execute-anything tool and replace it with a narrowly described operation.
Model the state transitions
Bring your previous output: A two-tool specification and scope boundary.
The idea to use
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.
Watch the selected lessons
Selected video time: 11m. Open this course on WikiFree.
Your 75-minute lab
Draw the state diagram and implement the supplied transition table. Set a maximum of four tool steps per request.
Save: A state machine with failure and approval exits..
Evidence check
Every state has an allowed next step or an explicit terminal outcome.
If it fails: If a failed retrieval still produces a confident answer, route it to clarification or a missing-evidence response.
Validate each tool call
Bring your previous output: A state machine with failure and approval exits.
The idea to use
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.
Watch the selected lessons
Selected video time: 6m. Open this course on WikiFree.
Your 90-minute lab
Run the local simulator against a valid FAQ request, an unknown tool and missing arguments. Inspect the event log.
Save: A guarded dispatcher and test outputs..
Evidence check
Unknown or malformed actions produce rejection records and no tool execution.
If it fails: Do not treat an instruction embedded in a tool result as a new authorized user request.
Test hostile and ambiguous inputs
Bring your previous output: A guarded dispatcher and test outputs.
The idea to use
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.
Watch the selected lessons
Selected video time: 13m. Open this course on WikiFree.
Your 85-minute lab
Run four supplied scenarios and add two new ones. Record expected state, observed state and whether any side effect occurred.
Save: A scenario evaluation table..
Evidence check
The send request stops at approval, delete is rejected and document instructions do not change the allowlist.
If it fails: If a test simply compares a hardcoded answer to itself, add a case that challenges a different validation branch.
Package the operating rules
Bring your previous output: A scenario evaluation table.
The idea to use
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.
Watch the selected lessons
Selected video time: 6m. Open this course on WikiFree.
Your 55-minute lab
Write a README, operating checklist and a separate future-integration risk list.
Save: A reproducible agent simulation package..
Evidence check
A reviewer can run the simulator locally and identify every action requiring a human.
If it fails: Do not label the package production-ready because the small scenario suite passes.
A worked reference to compare
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.
Compare your reasoning as well as the result. If your answer differs, state the assumption or input that explains the difference. Reference notes are for checking after an attempt; copying them is not evidence of independent work.
Your final project
Your brief
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.
Time box: 4h 00m estimated. Extend it if a gate needs repair.
Hand in these artifacts
- A two-tool specification and scope boundary.
- A state machine with failure and approval exits.
- A guarded dispatcher and test outputs.
- A scenario evaluation table.
- A reproducible agent simulation package.
- A short README: outcome, how to inspect or run the work, assumptions and limitations.
- A before-and-after change test and the completed evidence log.
Run a final review
- Use the supplied reference to reconcile the baseline result.
- Choose one relevant input or constraint to change. Write your expected effect before testing it.
- Run the calculation, walkthrough or test again and save the actual result.
- Ask a peer to inspect the evidence, or perform a separate self-review. Label which review you used.
- Score the work using the rubric and repair every critical failure.
Review rubric · 100 points
| Criterion | Points | Evidence to inspect |
|---|---|---|
| Practical outcome and case reasoning | 25 | Design and run a local rule-based agent simulation with an allowlist, approval boundary, audit trail and adversarial test cases. |
| Five stage checks | 30 | Award 6 points for each stage only when its stated gate is demonstrably met. |
| Traceable evidence | 20 | Artifacts, inputs and calculations or tests are reproducible; synthetic and simulated evidence is labelled. |
| Revision after a changed condition | 15 | Change one input or constraint, predict the effect, test it and record the result. |
| Handoff quality | 10 | A reviewer can find the files, follow the instructions and understand the remaining limitations. |
Completion target: at least 80/100, all five stage gates passed, and every critical issue below corrected. This is a learning benchmark, not an accredited qualification.
Critical issue: No unapproved external action occurs, and untrusted retrieved text cannot add a tool or permission.
Before you go further
What will I be able to produce?
Design and run a local rule-based agent simulation with an allowlist, approval boundary, audit trail and adversarial test cases.
Is the whole path free?
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.
Do I need to finish every source course?
No. Follow the selected assignments at each stage. Source courses provide context, while the original case, labs and final review build the practical result. Extra study is optional.
What counts as completion?
Complete all five stage checks, earn at least 80/100 on the final rubric and correct every critical issue. This is a local orchestration simulation, not a deployed autonomous assistant, a multi-agent system or proof of real-model safety.
Questions & discussion
Share a useful question or correction. Comments appear after moderation. Please avoid personal or sensitive information.