E2 — 10 solved descriptive questions | 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.
These ten longer answers connect concepts into complete designs. Read the question first, sketch your own argument and compare assumptions, boundaries and failure handling with the solution.
1. Compare a chatbot, a fixed workflow and an agent for job search.
A basic chatbot can answer a question about search strategy without querying current listings. A fixed workflow can accept a validated filter object, retrieve visible jobs and display them in a predetermined order. An agent may interpret an ambiguous request, choose a query, inspect results and decide whether to refine or ask for missing information. These are different execution contracts, even if all three use the same chat UI. A fixed workflow can still call a language model at a predetermined step; model use alone does not make control agentic.
Compare them using the same outcome criteria. If exact filters already solve the task, the fixed workflow may be faster and easier to test. If ambiguous language makes query selection difficult, an agentic component may help, but it introduces invalid proposals, extra latency and more trajectories to evaluate. Keep authorization and evidence checks identical across approaches. Choose based on measured usefulness and failure behavior rather than an assumption that the most autonomous architecture is best.
2. Explain the end-to-end agent architecture and its trust boundaries.
The authenticated API receives a goal and establishes identity. The controller initializes run state and presents a bounded context to the decision component. That component returns either a proposed action or a proposed final result. A gateway checks the action schema, tool allowlist, current permissions and budget. The tool performs its own object checks and returns observations. The controller updates state and evaluates progress before another decision or a terminal outcome.
External input is not policy. User documents, search results and model-generated plans can all contain instructions, but none can grant access. The user identity must come from authentication, and the model cannot replace it with a convenient identifier. Persistence, caches and telemetry create additional trust boundaries: a correct search tool can still leak information if another user can fetch its run record. Trace the complete data path and test these boundaries independently of model quality.
3. Describe a lifecycle with honest terminal outcomes.
A run moves from received through validation and execution into a terminal status or a controlled pause. During execution, a proposal is checked before becoming an action; a returned observation is recorded before being used as evidence. Completion means the result met the defined criteria, not that the model said "done." A legitimate zero-result search can be completed with no jobs, while a provider failure or denied request must preserve its own failure status. A partial result should name missing work if that outcome is allowed.
Resource limits also produce terminal states. A step budget prevents unlimited repeated decisions, an overall deadline limits wall time and per-tool timeouts bound individual dependencies. Cancellation must be observed between steps and, where possible, propagated upstream. On restart, reconcile the last recorded action before retrying. This prevents an interrupted acknowledgement from turning a previously completed side effect into a duplicate operation.
4. How should a broad goal be decomposed?
First translate the request into observable success criteria and constraints. For "help me find a job," ask for essential filters or state assumptions explicitly. A bounded version might retrieve current public Python listings, compare stated skills and return up to three supported recommendations. Decompose this into request interpretation, eligible retrieval, evidence comparison and result validation. Keep identity, budgets and external-action restrictions attached to every subtask.
Decomposition is not permission expansion. A planner that decides emailing recruiters would help cannot add that tool or action without authorization. Subgoals should be small enough to verify, and an evaluator should detect whether each contributes useful evidence. Replanning can be appropriate after an empty search, but repeated vague reformulation without progress should stop. Preserve the original objective and report a partial result or a targeted clarification rather than silently changing the task to one the system can claim to have completed.
5. Explain where human approval helps and where it does not.
Approval is useful at a concrete consequential-action boundary. Before submitting an application, show the job, account, exact content and consequences. Bind the decision to an action identifier and payload version, then revalidate permissions when execution occurs. If the payload or target changes, the earlier approval should not authorize the new operation. An expired review decision must also be handled explicitly.
Approval cannot replace authentication, resource ownership or factual verification. A person approving a suggested message does not establish that the system may read another candidate resume. A well-designed review screen can still display unsupported claims that need evidence checks. Avoid asking users to approve every harmless internal step: excessive prompts encourage uncritical confirmation and make meaningful review harder. Use policy and authorization for routine boundaries, and reserve human decisions for actions where informed judgment is actually needed.
6. Why can a longer agent trajectory be less reliable?
Each step adds assumptions, dependency failures and opportunities for invalid or unsupported output. If a wrong job identifier is accepted early, later summarization can confidently describe the wrong role. Context may grow until important evidence is omitted, and repeated model calls add cost and latency. Reflection may improve an answer but can also reinforce the same mistaken assumption when it uses no new evidence. More actions therefore do not establish better reasoning.
Measure trajectories using tool validity, evidence use, permission checks and contribution to the goal. Compare against a shorter workflow on the same cases. Limit retries and repeated identical actions, retain only useful observations and validate exact constraints with code. Evaluate ordinary runs and deliberately constructed failures. A shorter path that reliably returns a supported partial answer may be preferable to a long path that produces a polished but ungrounded complete-looking answer.
7. Design state isolation for several users.
Every run should have a stable run ID and an owner derived from verified authentication. Each status, result and cancellation lookup must check access to that run; knowing an identifier is not authorization. Store conversation or memory scope explicitly rather than sharing global mutable lists. Within a Python process, default_factory creates separate list instances for each dataclass run, but that does not provide database ownership checks or distributed isolation.
When adding persistence and caching, include user or tenant scope and relevant data versions. Background workers should receive a trusted run reference and revalidate resource access where needed, rather than treating a model-supplied user field as authority. Test concurrent users, guessed IDs, revoked access and process restart. Do not log entire private documents simply to make debugging easier. Use bounded, redacted events linked by run ID and document a retention and deletion policy.
8. How would you evaluate a responsible career-search agent?
Create synthetic or permissioned fixtures with ordinary requests, missing filters, inaccessible jobs, expired listings, conflicting requirements and malicious instructions in a description. Define what an acceptable recommendation must include: an actual visible job, evidence for the match and an honest account of unknown information. Measure task completion, evidence support, invalid-tool proposals, access violations, latency and usage separately. A single aggregate score can hide a serious safety failure.
Compare the agent with deterministic search and rank on identical inputs. Keep evaluation cases separate from examples used to tune prompts. Repeat stochastic cases and inspect trajectories rather than only final prose. Test user correction and escalation behavior. For resume evidence, distinguish "not mentioned" from "cannot do" and avoid inferring protected characteristics. Do not claim measured success or fairness without actual representative evidence and a stated evaluation method.
9. Explain the limits of the Python mock demonstration.
The mock is deliberately deterministic: its first proposal searches for Python and the second returns observed IDs. It does not parse arbitrary goals, call a model or learn from data. That makes it useful for controller tests because the expected tool path is known. It demonstrates allowlisting, argument validation, user-scoped filtering, final-ID grounding and a bounded loop. These checks should survive when a genuine decision model is added.
It lacks authenticated HTTP identity, persistence, real network deadlines, cancellation and distributed recovery. The synthetic visibility list is not a complete enterprise authorization model. Therefore the fixture must not be described as production-ready or as a real LLM benchmark. To extend it, first define a typed adapter that maps model output into proposals, validate every field and add controlled failure tests. Keep model-independent invariants separate from model-quality evaluation so a provider change cannot bypass the basic security contract.
10. When should an engineering team reject an agentic design?
Reject or simplify it when a deterministic workflow already meets the outcome, source access is inadequate, failures cannot be detected or the proposed authority exceeds the available controls. If a task needs exact transformations and stable rules, dynamic tool choice can add unnecessary variability. If success cannot be defined or evaluated, a demonstration may conceal that the system is solving a different problem. Autonomous external actions also require credible recovery, auditing and accountability.
A constructive alternative is to preserve useful components: use a model to draft a query object, code to validate filters and a fixed search service to retrieve results. Introduce dynamic branching only where controlled tests show improvement. Start with read-only access and explicit limitations, then revisit autonomy using actual failure evidence. The correct architectural choice is the least complex system that reliably fulfills the authorized goal, even if that system contains no agent loop at all.
Chapter 1 — Introduction to Agentic AI