Agentic AI Engineer interview questions

A chatbot mainly produces conversational replies, while an agent can choose actions and use tools to pursue a task.

• A support chatbot may explain a refund policy; an agent may also look up the order and submit an approved refund.
• The agent keeps task state across several steps and uses tool observations to decide what to do next.
• Tool access creates real failure and safety risks, so an agent needs permissions, budgets, and stop conditions.

A run should use explicit statuses such as queued, running, waiting, succeeded, failed, and canceled, with one defined meaning for each.

• Queued means accepted but not started, while running means work may still produce actions and events.
• Waiting is nonterminal and must record what can resume the run, such as user input, approval, or a scheduled retry.
• Only the runtime should apply validated status transitions, and terminal statuses must record the reason and completion time.

An autonomy boundary states which decisions and actions the agent may take without human approval.

• A travel agent may search and draft an itinerary but require approval before spending money or booking a nonrefundable ticket.
• The boundary should name allowed tools, data scopes, monetary limits, and actions that always escalate.
• Enforcement belongs in application code and permissions, not only in a prompt the model can ignore.

A proposal is inert data describing what the model wants to do, while dispatch is the trusted step that may change an external system.

• Store the exact operation, target, arguments, and proposal version before any policy or approval decision.
• Authorization must bind the principal, permitted action, proposal version, and expiry so a changed proposal needs a new decision.
• Only the dispatcher executes, and it must reject missing, stale, or mismatched authorization even if the model asks confidently.

ReAct interleaves reasoning about the next step, an action, and the resulting observation so the agent can adjust from evidence.

• A research agent may record a short plan to verify a claim, call search, and use the returned sources to choose a narrower query.
• I would trace tool names, validated arguments, observations, and concise decision summaries that explain observable choices.
• I would never request or store private chain-of-thought because short plans and decision summaries provide useful debugging evidence without hidden reasoning.

A stable run ID identifies one execution of one task, while user and session IDs identify an actor or conversation that may contain many runs.

• Pauses, resumes, and step retries keep the same run ID, while a new independent task receives a new one.
• Each child step or delegated task gets its own ID linked to the parent run, preventing its state and results from being attached to another run.
• These IDs establish ownership and lineage, not authority, so every action still needs a separate permission check for the acting principal and scope.

A state machine makes the agent's allowed stages and transitions explicit instead of leaving the whole flow to free-form generation.

• A support task can move through identify customer, inspect order, propose action, await approval, and complete.
• Invalid transitions, such as refund before identity verification, can be rejected by code.
• Explicit states make retries, tests, and recovery easier because each run has a known current position.

An observation is model-facing context about what appeared to happen, while a durable receipt is authoritative evidence recorded by the executor or external service.

• A receipt should identify the run, logical action, idempotency key, outcome, timestamp, and external operation ID when available.
• Tool text, streamed progress, or a model summary can be incomplete and must not replace that receipt in operational state.
• Recovery should read the receipt or query the external operation before deciding whether to retry a side effect.

State-dependent exposure limits the model to capabilities that are valid for the run's verified stage instead of advertising every tool throughout the task.

• Before identity verification, a support agent may see verification tools but not refund or account-change tools.
• After a state transition, the runtime recomputes the active tool set and removes capabilities whose approval or temporary scope has expired.
• Remembering a hidden tool name grants nothing because the dispatcher still checks current state and authority.

Pydantic converts untrusted model output into typed Python data or rejects it with structured validation errors.

• A Pydantic model can require customer_id as a UUID and quantity as an integer greater than zero.
• Field validators can normalize accepted input, while forbidden extra fields catch invented arguments.
• A ValidationError should become a concise correction signal or a failed call, never be bypassed with raw input.

Preconditions are facts that must hold immediately before dispatch, while postconditions are facts or receipts that prove the intended effect afterward.

• A refund can require a verified customer, a refundable order version, and valid approval before execution.
• Its postconditions can require a refund receipt with the expected order, amount, currency, and accepted status.
• If a postcondition cannot be confirmed, the runtime should mark the effect unknown and reconcile it rather than assume success or safe rollback.

The runtime should inspect dependencies and side effects before deciding whether the calls may run in parallel or must be ordered.

• Independent read-only calls can run concurrently when each has its own call ID, timeout, and result slot.
• Calls that mutate shared state or depend on another result should be serialized in an explicit order rather than launched together.
• Every result or error must return under the matching call ID, and one failed call must not make the agent assume the others failed or succeeded.

A parent should delegate a reserved subset of its remaining budget, and the child must never create or exceed additional capacity.

• The assignment can cap model tokens, tool calls, cost, elapsed time, and delegation depth for that child.
• Child usage must debit the parent budget atomically, while parallel reservations prevent several children from overspending the same remainder.
• Unused reservation can return to the parent, but exhaustion makes the child return a partial result and stop further work.

The agent should classify the error, preserve task state, and choose a bounded recovery path instead of pretending the call succeeded.

• A validation error can trigger one corrected call using the returned field details.
• A permission error should stop or escalate because changing arguments must not bypass authorization.
• A transient timeout can be retried under policy, while an unknown server error should be logged with a trace ID and surfaced safely.

Bounded retries let an agent recover from temporary failures without entering an expensive or harmful loop.

• Retry only errors marked transient, such as a 503 or timeout, not invalid credentials or a rejected payment.
• Use a small limit such as three attempts with exponential backoff and jitter.
• Record the attempt count in task state, then stop or escalate when the limit is reached.

An idempotency key lets repeated requests represent one logical operation, preventing duplicate side effects after retries.

• Before creating a payment, the agent runtime can derive or store one key for that task and action.
• The service records the first result and returns it when the same key arrives again instead of charging twice.
• The key must remain stable across retries but differ for a genuinely new user-approved operation.

Read-only tools observe data, while side-effecting tools change external state and therefore need stricter controls.

• Searching a catalog can often run automatically, but sending email, deleting a file, or charging a card changes the world.
• Side-effecting calls need explicit permissions, validated targets, audit records, and often user approval.
• A dry-run or preview can show the proposed change before the committing tool is called.

Least privilege gives an agent only the tools and data scopes required for its current role and task.

• A scheduling agent may read free-busy slots without permission to read email bodies or delete calendar events.
• Use scoped credentials and per-tool authorization instead of one broad service token shared by every agent.
• Remove temporary access when the run ends and audit denied calls to find overly broad plans or attacks.

An approval gate should precede irreversible, costly, sensitive, or policy-significant actions.

• Before sending a contract, the UI should show the exact recipient, attachment, and message the agent intends to use.
• Approval must bind to that specific action payload so later model changes cannot alter it silently.
• Rejection should return the task to a safe state where the user can edit, cancel, or provide a new instruction.

Terminal accounting must classify every action intent so the final status does not hide work that is still pending or has an unknown external effect.

• Record which actions were never dispatched, which have durable success or failure receipts, and which remain pending or unknown.
• Mark a run succeeded only when all required effects are confirmed; a failed or canceled run may still need reconciliation for uncertain effects.
• The final report should separate confirmed outcomes, skipped work, and unresolved effects with their operation IDs and owners.