E4 — 5 solved engineering scenarios | 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.
For each scenario identify the violated assumption, the action boundary, the expected status and a test that could detect the problem. Distinguish behavior already implemented by the mock from production extensions.
1. A listing tells the assistant to email a recruiter immediately.
The user authorized read-only recommendations. Treat the listing instructions as untrusted content, retain the read-only tool allowlist and reject any proposed email action. The assistant may still use supported job facts from the listing if the source is otherwise eligible. Record a concise rejection event without copying private data. Test that the model can propose an email tool and the gateway still prevents execution; success is the enforced boundary, not merely a prompt asking the model to be careful. Explain in the final result that no application or message was sent.
2. A search times out after an external action might already have occurred.
First identify whether the operation was genuinely read-only. For a read-only search, a bounded retry with a deadline may be acceptable. For a side-effecting operation, query its status or reconcile using an idempotency identifier before retrying. A timeout means the caller lacks a confirmed result, not proof that nothing happened. Preserve an uncertain or failed status and avoid inventing completion. The chapter mock has no network side effects and therefore cannot demonstrate this production recovery behavior; describe the required target-system contract before implementing it.
3. The agent finds only one suitable job when the user asked for three.
Return the one supported result with its source ID and describe the remaining evidence gap. If permitted and useful, broaden a nonessential filter transparently or ask the user whether to do so. Do not remove a hard constraint or invent two listings simply to reach the count. Evaluate the result as a legitimate partial outcome if the contract allows it. Add fixtures where the catalogue has zero, one and three eligible matches, and verify that result counts reflect observations rather than the requested count alone.
4. A second user guesses the run ID of a completed search.
The status and result endpoint must authenticate the requester and check ownership or an explicit sharing permission for that run. A hard-to-guess identifier reduces accidental discovery but is not an authorization mechanism. Deny without returning the private observations or a cached response. Test both the normal endpoint and any download, cache or background status channel. Keep auditing scoped and redacted. The in-memory Python demo has no HTTP run lookup, so this is a required extension rather than a protection already established by its unit tests.
5. The agent repeats a search without improving the result.
Stop when a step budget, deadline or no-progress condition is reached and return an explicit budget-exhausted or partial status. Track a normalized action signature and whether each observation adds useful evidence. A repeated call can be justified if the environment changed, but blind retries on the same deterministic failure waste resources. Compare with a fixed single-search baseline. Add a policy fixture that always proposes the same search; the sample max_steps test should show bounded termination without claiming that the user goal was successfully completed.
Chapter 1 — Introduction to Agentic AI