H — 30 answered interview 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.
Section H — Interview Preparation
Practice explaining the reasoning behind each answer with a concrete example. The ten beginner questions establish vocabulary, the ten intermediate questions connect contracts and testing, and the ten advanced questions address distributed state and operational limits. These are study answers rather than claims that one architecture fits every product.
1. Beginner: Can an agent exist without a chat window?
Yes. Chat describes an interface, while an agent describes a goal-driven control pattern. A bounded background research task can use an agent loop without conversation. Conversely, a chat window may contain only a fixed-response system. Explain the execution behavior rather than judging the interface.
2. Beginner: Does every agent require a large language model?
No. A decision policy can be rule-based, learned or hybrid. Modern LLM agents use a language model for some choices, but tools, state and control code remain separate. The chapter mock demonstrates the surrounding contract without claiming to implement natural-language reasoning.
3. Beginner: What makes a tool different from generated text?
A tool is executable application behavior with a defined contract and permissions. Generated text can propose a tool call, but execution happens only after validation and authorization. A sentence saying an action completed is not evidence that its tool actually ran.
4. Beginner: Why store source IDs in recommendations?
IDs link recommendations to observed records and allow validation and review. They do not by themselves prove that a listing supports every claim. Check both that the ID is authorized and that the explanation accurately reflects its evidence.
5. Beginner: What should an agent do with a missing required filter?
Ask a targeted question or use an explicitly permitted assumption and disclose it. Do not silently invent a hard constraint. The response contract should specify whether partial results are allowed and what information is needed before execution.
6. Beginner: What is the difference between a model output and a tool observation?
A model output is a proposal or generated response; a tool observation reports what an operation returned. Neither is automatically trusted policy. Keeping them distinct makes it possible to reject invented results and trace where an unsupported claim entered the run.
7. Beginner: Why are read-only tools a good first project?
They let learners test selection, validation and grounding with simpler recovery requirements. They still need access checks and resource limits because reading can leak data or cause cost. Read-only does not mean unrestricted access or zero operational risk.
8. Beginner: What is a useful stop condition besides a step cap?
A validated result, cancellation, an overall deadline, repeated lack of progress or a denied action can terminate a run. Different conditions need explicit statuses. A step cap alone cannot interrupt a slow dependency already running inside one step.
9. Beginner: Does saving memory mean the model learned new weights?
Not necessarily. Stored conversation or preferences can be retrieved into future context without training the model. Explain which persistence mechanism exists, its owner and retention behavior. Model parameter updates and application memory updates are different operations.
10. Beginner: What does the sample mock policy actually understand?
It understands no arbitrary natural-language goal. It follows a fixed search-then-final pattern for Python. This limitation is deliberate so controller tests are repeatable. A later model adapter can improve interpretation while preserving the same execution checks.
11. Intermediate: How would you validate a proposed tool call?
Check exact allowed fields, the tool allowlist, argument types and ranges, verified user permissions, resource access and remaining budget. Reject unknown fields when the contract requires it. Validation is application behavior and must also survive malicious or malformed model output.
12. Intermediate: What information belongs in a run event?
Use run ID, step, action name, outcome, measured duration and relevant source references. Exclude credentials and minimize personal content. Distinguish proposed, rejected, started and completed actions so the UI and audit trail cannot misrepresent execution.
13. Intermediate: How do you test an agent without a provider account?
Inject a scripted decision policy and synthetic tool adapters to produce known trajectories, invalid calls and failures. Test invariants independently of generation quality. Label these as mocks; they establish controller behavior and cannot be reported as actual model performance.
14. Intermediate: How should a final-answer validator work for job search?
Ensure every referenced ID came from permitted observations, then check important claims against the associated fields. Enforce result-count and filter constraints and distinguish missing evidence from negative evidence. Source validity alone does not prove claim support.
15. Intermediate: How do you choose between asking a question and searching?
Make required inputs explicit. If missing information prevents a valid query, ask for it. If a useful partial search is authorized, state the assumption and limitations. Evaluate the choice using fixtures that include ambiguity rather than relying on a prompt to guess user preferences.
16. Intermediate: What is a retry budget?
It is a bound on repeated attempts, ideally within an overall time and usage budget. Retry only appropriate transient failures and account for side effects. Repeated authorization denial or invalid arguments should not trigger blind identical retries.
17. Intermediate: How can the UI show progress honestly?
Render events from actual run transitions and tools. Show running, paused, completed, partial, cancelled or failed as defined by the backend contract. Avoid claiming an external action happened from a model-generated sentence or a timer animation.
18. Intermediate: How do you compare agent and baseline performance?
Use the same inputs, source permissions and expected outcomes. Report supported task completion, access violations, invalid calls, latency and usage separately. Repeat stochastic cases when relevant. Keep actual measurements distinct from estimated budgets or illustrative outputs.
19. Intermediate: Why is final output shape not enough?
Valid JSON can contain unauthorized identifiers, false statements or incorrect business decisions. Syntax parsing, schema validation, authorization and grounding answer different questions. A secure pipeline must check each relevant property rather than treat successful parsing as success.
20. Intermediate: What happens if a plan becomes invalid after the first tool?
Update state using the observation and re-evaluate the next step within the original goal and permissions. Replanning cannot create new authority. If no useful permitted route remains, stop with a partial or failed result rather than making unsupported progress claims.
21. Advanced: How would you recover after a crash during a side effect?
Persist intent and an action identifier before execution, use target-supported idempotency where possible and reconcile remote status after restart. An interrupted response can leave the outcome uncertain. A local transaction cannot guarantee exactly-once behavior in an unrelated external system.
22. Advanced: How do you bind approval to execution?
Persist a reviewed payload version, target, owner, expiry and decision. At execution, compare them with the current proposed action and recheck authorization. A changed target or payload requires a new valid decision; a broad previous approval cannot be silently extended.
23. Advanced: Can a correct search tool still participate in a data leak?
Yes. A status endpoint, shared cache, log sink or memory retriever may expose its private result to another user. Model safety does not repair those application bugs. Test the entire path from retrieval through storage, display, export and deletion.
24. Advanced: How would you evaluate a no-progress detector?
Construct repeated identical calls, repeated failures, legitimate polling and useful query refinement. Define when new evidence counts as progress. The detector should bound waste without prematurely stopping a valid workflow, and its decisions should be visible in the trajectory.
25. Advanced: What should remain outside model control?
Identity, permissions, secret access, tool registration, enforced budgets and invariants must remain application-owned. A model may suggest a plan or request an operation, but it must not edit the policy that determines whether that request is allowed.
26. Advanced: How would you add durable state safely?
Use stable run IDs, ownership fields, versioned transitions and transactional updates appropriate to the store. Protect status and mutation endpoints and manage concurrent workers. Persist sufficient recovery information while minimizing sensitive context and defining retention and deletion behavior.
27. Advanced: What are the limits of reflection-based correction?
A model reviewing its own response may notice inconsistencies, but it can repeat the same unsupported assumption. Use independent evidence and deterministic checks for exact constraints. Evaluate whether reflection adds useful corrections relative to its extra cost and latency.
28. Advanced: How do permissions affect context assembly?
Filter records using verified identity before they enter the model context, then preserve source provenance and current access restrictions. Summaries and caches also require scope because they may retain restricted facts after the original document is removed or access changes.
29. Advanced: How would you roll out more autonomy?
Start with measured read-only behavior, explicit limits and reliable recovery. Increase one action scope at a time only after relevant tests and operational review. Monitor violations and define rollback criteria. A larger model alone is not evidence that broader authority is justified.
30. Advanced: What does responsible ownership of an agent failure require?
Define who reviews incidents, how users can correct records, which actions can be reversed and what evidence is retained. Separate factual errors, access violations and operational outages. Honest status and documented escalation are necessary even when no model can guarantee perfect performance.
Chapter 1 — Introduction to Agentic AI