F — 15 practical exercises and solutions | Agentic AI — Chapter 1: Introduction and Foundations
Detailed Chapter 1 of the Agentic AI learning track: all 15 foundation topics, architecture diagrams, runnable Python, Java and React examples, solved questions, 15 exercises, a complete mini-project, interview preparation and revision. Chapters 2–20 are upcoming.
Prerequisites: Beginner-friendly theory. Basic familiarity with functions helps for the Python lab; the runnable example uses only the standard library. No provider credentials are required. This is Chapter 1 of a planned 20-chapter track, not a completion claim for the entire course.
Section F — Practical Exercises
Complete the five beginner exercises before the intermediate set, then use the advanced set to design extensions. Each exercise includes an expected result and solution approach. Record your own implementation evidence; the academy stores work for self-review and does not execute or automatically grade submitted code.
1. Beginner: Classify five product features
Label an exact location filter, a generated cover letter, an image classifier, a fixed search pipeline and a dynamically refining job search. Explain which are AI, generation, workflow or agentic behavior. Categories can overlap.
Expected result and solution: The filter is deterministic, the letter is generation, the classifier is learned prediction, the fixed pipeline is a workflow and dynamic selection can be agentic. Explain behavior rather than assigning labels solely from the UI.
2. Beginner: Rewrite a vague goal
Replace "help me get hired" with an observable read-only job-search objective. Include source scope, result count and a restriction on applications.
Expected result and solution: A valid answer is "return up to three currently visible Python jobs in a specified location, cite their IDs and do not apply." Unknown essential filters should trigger a question rather than an unsupported assumption.
3. Beginner: Trace a normal run
Write the sequence from the mock first proposal to its final result. Name what changes in RunState at each point.
Expected result and solution: The first policy proposal searches Python; the tool returns job-1 for learner; events records search_jobs; the second proposal returns job-1; final validation succeeds and status becomes completed.
4. Beginner: Identify components
Draw boxes for the user, controller, policy, tool registry, catalogue and evaluator. Mark where user identity enters and where untrusted text is handled.
Expected result and solution: Identity enters at the authenticated application boundary, and the controller passes it to tools. The policy proposes actions without setting identity. Tool output is observation data, and final results are checked against it.
5. Beginner: Run and inspect the fixture
Save the two Python files from Section D, run the program and tests locally, and record actual output. If no interpreter is available, provide a clearly labeled manual trace.
Expected result and solution: A local normal run should show completed with job-1. Test output must be the actual local result; a manual walkthrough is not evidence that code executed. No model provider is involved.
6. Intermediate: Add a query-boundary test
Call search_jobs with an empty query, an extra key and a non-string value. Explain why the policy should not handle these cases alone.
Expected result and solution: Each invalid argument object raises ValueError before catalogue filtering. The tool boundary independently enforces its contract even if a model generates malformed arguments.
7. Intermediate: Test visibility isolation
Run the fixture with learner and other. Compare results and confirm that visibility metadata is not included in returned records.
Expected result and solution: learner sees job-1, and other sees job-2 for the fixed Python query. Returned dictionaries contain id and title only. This tests the synthetic rule, not a full production authorization system.
8. Intermediate: Reject invented results
Write a policy that returns final_ids containing an unknown ID. Add a test and compare failure with a valid empty final result.
Expected result and solution: An unknown ID causes failed. An empty list is permitted as a completed empty result by this sample contract. If a product requires a nonempty result, encode that requirement explicitly rather than assuming it.
9. Intermediate: Compare workflow and agent designs
Design a fixed one-search service and a bounded model-selected search loop for the same user request. List measurements that could justify the second design.
Expected result and solution: Measure supported task completion, invalid proposals, latency, usage and permission violations on identical fixtures. Additional query flexibility must deliver a useful benefit without hiding higher failure rates.
10. Intermediate: Define structured activity events
Replace plain event names in your own extension with run ID, step number, tool name, outcome and duration. Explain fields you deliberately exclude.
Expected result and solution: Events should link actual actions and outcomes without logging credentials or full resumes. A rejected proposal is labeled rejected, not executed; durations are measured locally rather than invented.
11. Advanced: Add cancellation boundaries
Design a cancellation flag checked before policy invocation, before tool execution and after a response. State what cancellation cannot guarantee after a side effect.
Expected result and solution: The controller stops starting new work and records cancelled. Network cancellation is best effort unless the dependency guarantees it. An already accepted external operation may need reconciliation rather than a claim that it never happened.
12. Advanced: Design durable recovery
Propose a run/action schema and a crash-recovery procedure for a future side-effecting tool. Include an idempotency key and an uncertain-outcome state.
Expected result and solution: Persist action intent and identity, use target-supported idempotency and reconcile status after restart. A database row alone cannot guarantee exactly-once effects in an unrelated remote system.
13. Advanced: Design payload-bound review
Describe a review object for a future application action, including target, payload version, owner, expiry and decision. Test a changed payload after approval.
Expected result and solution: Changed content or target invalidates the old review. Authorization is checked again at execution. Do not implement real submission in the Chapter 1 read-only prototype.
14. Advanced: Build an evaluation matrix
Specify ten fixtures spanning normal results, missing filters, malicious listings, wrong IDs, denied tools and dependency failures. Define expected outcomes before running them.
Expected result and solution: The matrix must distinguish task completion, grounding and access violations. A denial case should not be counted as a successful job match, and an expected empty catalogue should not be mislabeled a provider failure.
15. Advanced: Analyze context and cache isolation
Describe how adding long-term memory and a shared result cache could break a correct search tool. Propose a scope and invalidation strategy.
Expected result and solution: Bind stored state and cache keys to verified owner/tenant, source versions and permissions; recheck access and invalidate revoked data. A search-layer check is insufficient if private results can later leak through a shared cache.
Chapter 1 — Introduction to Agentic AI