Agentic AI Engineer interview questions

I would use a graph when the task has required stages, bounded branches, or side effects that must be audited.

• Nodes would separate classification, account lookup, policy checks, response drafting, and escalation, with typed state passed between them.
• The LLM can still choose among allowed transitions, but retry limits and terminal states belong to deterministic orchestration.
• I would keep a free loop only for low-risk exploration where the next useful action cannot be enumerated and repeated work is cheap.

I would treat the plan as an untrusted request for authority, not as a credential carrier.

• The planner receives read-only capability metadata and redacted resource descriptors, then emits a typed DAG whose nodes request specific operations and argument bounds.
• A trusted compiler intersects each request with the authenticated user's grant, task policy, and dependency outputs to produce a per-node authority manifest.
• The scheduler binds that manifest to a just-in-time executor credential; an executor cannot inspect sibling credentials, widen its rights, or alter the manifest.
• Tools enforce the manifest, and any replan that changes resources or operations requires recompilation, with unavailable authority causing a block or explicit approval.

I would require a typed dependency DAG whose edges describe data and completion contracts, not just an ordered list.

• Each step would declare required inputs, producing step IDs, expected outputs, preconditions, and an acceptance test.
• The runtime would schedule only ready steps, preserve immutable outputs by reference, and join branches only when their required evidence is present.
• A failed dependency would mark downstream steps blocked and trigger a bounded repair or replan without rerunning independent completed work.

Replanning should follow material changes to assumptions, feasibility, or required outcomes, not every imperfect observation.

• Valid triggers include a failed dependency, a tool reporting stale data, a newly discovered constraint, or two retries exhausting the current approach.
• The replan request should include completed steps and immutable user constraints so the planner does not discard valid work.
• A low confidence score alone should first cause clarification or a targeted verification step, because repeated global replans can livelock.

I would choose ReAct for short exploratory tasks and plan-execute for longer work with dependencies, budgets, or approval points.

• ReAct adapts after every observation and works well for two or three uncertain searches, but its implicit plan is hard to inspect or resume.
• Plan-execute exposes dependencies and progress, making parallelism, approvals, and recovery easier at the cost of an extra planning pass.
• I would compare both on per-run task success, repeated tool calls, p95 latency, and cost rather than prompt quality alone.

Validation, authorization, state transitions, and side-effect execution should be deterministic even when an LLM proposes the action.

• A model may select refund_order, but code must validate the schema, amount, order ownership, and policy limit before execution.
• Retries, timeout handling, deduplication, and terminal-state checks should not depend on another model judgment.
• LLM nodes are best used where semantic interpretation or option ranking is needed, with their outputs constrained to typed choices.

I would persist one canonical append log and derive typed workflow checkpoints from committed events.

• A node commit records its input version, output, transition, and outbox intent atomically, or the checkpoint, event, and outbox are written in one database transaction.
• A new worker resumes from the latest committed sequence and rebuilds projections deterministically instead of trusting two independently written stores.
• External effects remain at least once: they need stable idempotency keys, an effect ledger, and reconciliation for ambiguous outcomes rather than an exactly-once claim.
• Model prompts, tool schemas, and workflow definitions carry version IDs so old runs are resumed or migrated under explicit contracts.

I would assign each business side effect a stable idempotency key within its authorization scope and record its status before retries.

• The key would derive from tenant, operation type, and a caller-visible business operation ID, so a recreated run cannot issue the same intended ticket again.
• A hash of canonical arguments is stored separately; reuse of the key with a different payload is rejected instead of becoming a new operation.
• The ledger tracks proposed, authorized, started, succeeded, and uncertain states together with the external resource ID.
• After an uncertain timeout, the agent queries the provider by key or reconciles externally rather than issuing a blind duplicate call.

I would model each booking as a committed step with a named compensating action and execute compensations in reverse dependency order.

• The ledger stores reservation IDs, cancellation deadlines, fees, and compensation status for every successful tool call.
• A car failure could trigger hotel and flight cancellation, but a nonrefundable flight may require human review rather than pretending rollback is complete.
• Compensation calls also need idempotency keys and retries because the recovery path can fail independently.

The registry should expose machine-readable contracts for discovery, authorization, routing, and operations.

• Each capability needs an input and output schema, version, side-effect class, required scopes, owner, timeout, and idempotency behavior.
• Runtime health, region, rate limit, data classification, and deprecation status let the orchestrator select a usable endpoint.
• Agents receive a task-specific filtered view of the registry instead of the organization's complete tool catalog.

I would make initialization, transport liveness, reconnect policy, and shutdown explicit runtime states.

• The client completes MCP initialization, records the selected protocol version and server identity, and builds its registry only from capabilities the server declared.
• MCP ping requests, transport deadlines, and bounded reconnect backoff distinguish a failed connection from a slow tool without creating reconnect storms.
• Reconnection does not prove an in-flight call stopped or failed, so the workflow waits, queries application state, or retries only under the tool's idempotency contract.
• After session loss, the client initializes again and refreshes capability lists before scheduling new calls.

Initialization selects a protocol version and exchanges asymmetric client and server declarations rather than intersecting one shared feature list.

• The client sends protocolVersion, clientInfo, and client capabilities; the server returns its selected protocolVersion, serverInfo, and server capabilities, then the client sends the initialized notification.
• The runtime exposes only declared server surfaces such as tools, resources, or prompts and enables client behavior only where the corresponding declaration permits it.
• Tool list changes require the server capability tools.listChanged, while resource subscriptions and list changes require resources.subscribe and resources.listChanged respectively. Cancellation is not an initialization capability.
• Unknown optional fields remain forward compatible, while an unsupported protocol version fails initialization explicitly.

I would treat the MCP server as an OAuth protected resource and follow discovery instead of forwarding an existing bearer token.

• The client discovers Protected Resource Metadata and its authorization servers, then uses Authorization Server Metadata to locate supported authorization endpoints.
• For an authorization-code flow, the client uses PKCE and requests a token bound to the MCP resource through the resource indicator and appropriate scopes.
• An insufficient-scope challenge can trigger explicit step-up consent, while refresh tokens stay in the client credential store and are never exposed to the model or tool arguments.
• Token passthrough to another MCP server is forbidden; any internal token exchange is a separate delegation design and must issue a new audience-bound token.

I would map the long-running MCP request to one durable workflow operation with separate protocol and effect states.

• When the caller supplies a progress token, MCP progress notifications update monotonic completed work and optional total, but they do not commit the tool result.
• User cancellation sends an MCP cancelled notification for the request and marks cancellation requested; the receiver may already have performed work, so the runtime does not report stopped until it has evidence.
• A workflow timeout closes local waiting and triggers bounded transport cleanup, but disconnecting the client is not proof that server processing or an external side effect stopped.
• Without cancellation, a final result or error completes the protocol request; after cancellation, the workflow expects no result and reconciles unknown effects through an application-specific status or idempotency interface.

I would mint a short-lived token that grants only the exact operations and resources required for that task.

• The token could allow reading free-busy for named attendees and creating one event in a specific calendar, while denying event deletion and contact export.
• Resource IDs, time bounds, maximum uses, audience, and run ID should be cryptographically bound to the token.
• Child agents receive attenuated tokens with equal or narrower rights, never a copy of the supervisor's broader credential.

The policy engine should evaluate the authenticated actor, task intent, proposed capability, arguments, current state, and data sensitivity.

• A deterministic rule can allow read-only CRM lookup but require approval for exports over 100 records or any account deletion.
• Policy uses server-derived tenant and ownership facts, because model-provided fields are untrusted input.
• The result should be allow, deny, or require approval with a reason code recorded before the side-effect ledger advances.

I would prefer DOM or accessibility-tree control for structured web interfaces and use vision when semantic elements are unavailable or the target is graphical.

• DOM APIs expose elements, attributes, text, and input values; accessibility locators expose computed roles and accessible names, making both easier to verify than pixel coordinates.
• Vision is necessary for canvas apps, remote desktops, and visual layout cues, but needs screenshot freshness checks and coordinate normalization.
• A hybrid controller can ground a visual target, map it to a DOM element when possible, and verify the resulting state through both channels.

I would represent browser state as a versioned snapshot tied to the current tab, document, and interaction epoch.

• The snapshot includes URL, tab and frame IDs, navigation ID, DOM or accessibility-tree digest, visible dialogs, and relevant cookies or storage references.
• Every proposed action cites the snapshot version it was grounded against, and the controller rejects it after navigation or material DOM change.
• Postconditions such as a changed URL, confirmation text, or disabled submit button must be observed before the action is marked successful.

I would run each task in an ephemeral sandbox with no ambient host credentials and deny network access by default.

• A container or microVM gets a read-only source mount, writable scratch volume, unprivileged user, syscall restrictions, and CPU, memory, process, and wall-time limits.
• Network egress is allowed only through an audited proxy to named destinations, while secrets are injected per command and never written to the workspace.
• Artifacts crossing the boundary are size-limited and scanned, and the sandbox is destroyed after the task rather than reused across tenants.

I would consolidate after a task boundary or when context pressure rises, using evidence-backed extraction rather than copying the whole transcript.

• The consolidator selects stable user preferences, verified facts, unresolved commitments, and reusable procedures while discarding transient reasoning.
• Each memory stores provenance, confidence, scope, and expiry, and high-impact claims require confirmation or repeated evidence.
• Consolidation should be evaluated by future task success and false-memory rate, not by how much text it saves.