Agentic AI

Q.1 What is Agentic AI, and how does it differ from a traditional LLM-based chatbot?
Agentic AI refers to systems where an LLM doesn't just respond to a prompt but autonomously plans, makes decisions, calls tools/APIs, observes results, and iterates toward a goal with minimal human intervention. A traditional chatbot is single-turn/reactive — it answers what's asked. An agent has a goal, a loop (think → act → observe), memory, and the ability to take real-world actions.
Q.2 Explain the core components of an AI agent.
Perception: ingesting input (user query, tool outputs, environment state)
Planning: breaking the goal into steps/subtasks
Memory: short-term (current task context) and long-term (persisted knowledge/history)
Action/Tool use: calling APIs, functions, or other agents to affect the environment
These form a loop: perceive → plan → act → observe → re-plan.
Q.3 What is the ReAct pattern, and why is it useful?
ReAct interleaves "Reasoning" (chain-of-thought text) with "Acting" (tool calls), so the model explicitly reasons about what to do, takes an action, observes the result, and reasons again. It improves interpretability and grounding because the model's intermediate reasoning is visible and tied directly to real observations rather than being purely internal.
Q.4 How does an agent decide which tool to call when multiple are available?
Typically via the LLM's function-calling capability: tool names, descriptions, and parameter schemas are passed in the prompt/context, and the model selects based on semantic match to the current sub-goal. Good tool descriptions, distinct naming, and sometimes a routing/classifier layer in front reduce ambiguity and wrong tool selection.
Q.5 Difference between short-term and long-term memory in an agentic system?
Short-term (working) memory holds the current session's context — recent messages, intermediate reasoning, tool outputs — usually held in the context window. Long-term memory persists across sessions (e.g., in a vector DB or structured store) and is retrieved on demand, allowing the agent to recall facts, preferences, or past task outcomes beyond the context window's limits.
Q.6 How would you design a system prompt to reduce hallucinated tool calls?
Explicitly list available tools with strict schemas, tell the model to only call tools it's been given, require it to state uncertainty rather than guess, use few-shot examples of correct tool use vs. refusal, and instruct it to ask a clarifying question or return "no tool applicable" when no good match exists. Constrained/structured output (JSON schema validation) also helps catch malformed calls before execution.
Q.7 What is function calling / tool calling, and how does it work?
It's a mechanism where the LLM is given structured tool definitions (name, description, parameter schema) and, instead of answering directly, outputs a structured call (e.g., JSON) specifying which tool to invoke and with what arguments. The host application executes the actual function and feeds the result back into the model's context for the next reasoning step.
Q.8 Single-shot planning vs. iterative/dynamic re-planning?
Single-shot planning generates the full plan upfront and executes it without adjustment. Iterative/dynamic re-planning re-evaluates the plan after each step based on new observations, allowing the agent to adapt if a step fails, new information appears, or the goal shifts — more robust but more compute/latency-costly.
Q.9 What is a vector database, and why is it used in agentic RAG pipelines?
A vector database stores embeddings (numerical representations of text/data) and supports similarity search (e.g., cosine similarity, ANN indexes like HNSW). In RAG, it's used to retrieve semantically relevant documents/context to ground the agent's responses, reducing hallucination and enabling access to knowledge beyond the model's training data.
Q.10 How do you handle an agent stuck in a repetitive tool-calling loop?
Implement loop detection (track recent action/tool-call history and flag repeats), set a max iteration/step budget, add a "stagnation" check comparing state before/after an action, and if a loop is detected, force a re-plan, escalate to a human, or terminate with a fallback response.
Q.11 Single-agent vs. multi-agent systems?
A single agent handles the entire task with one reasoning loop and toolset. A multi-agent system decomposes the task across specialized agents (e.g., researcher, coder, reviewer) that communicate and hand off work, often coordinated by an orchestrator — useful for complex tasks needing role specialization but adds coordination overhead.
Q.12 Role of an orchestrator/supervisor agent?
The orchestrator decomposes the overall goal into subtasks, routes them to the appropriate specialized agent, aggregates/synthesizes their outputs, resolves conflicts, and decides when the overall task is complete — acting as the "manager" in a multi-agent hierarchy.
Q.13 How would you evaluate whether an agent successfully completed a task?
Define task-specific success criteria (e.g., correct final answer, successful API side-effect, matching expected output schema), track intermediate step correctness (did it call the right tools in the right order), use LLM-as-judge or human review for subjective quality, and monitor efficiency metrics like steps taken and cost/latency.
Q.14 What are guardrails, and where should they be placed?
Guardrails are checks/filters that constrain agent behavior — input validation, output content filtering, tool permission scoping, and action confirmation for risky operations. They should be placed at multiple points: before user input reaches the model, before a tool call executes, and before the final output is returned to the user.
Q.15 How do you manage context window limitations for long agent tasks?
Techniques include: summarizing older conversation history, using a retrieval system for long-term memory instead of keeping everything in-context, chunking/prioritizing only relevant recent steps, and using scratchpad/external memory files the agent can read/write to rather than holding everything in the prompt.
Q.16 Zero-shot vs. few-shot vs. chain-of-thought prompting for agent reasoning?
Zero-shot gives just the task with no examples. Few-shot provides example input-output pairs to guide format/behavior. Chain-of-thought explicitly prompts the model to reason step-by-step before answering. Agents often combine few-shot examples of tool use with CoT reasoning to improve both decision quality and tool-call accuracy.
Q.17 How is RAG integrated into an agent's workflow?
RAG can be exposed as a tool the agent calls when it needs external knowledge — the agent decides when retrieval is needed, queries the vector store, gets relevant chunks back, and incorporates them into its reasoning before generating a response or taking further action, rather than retrieval being a fixed step every time.
Q.18 Common failure modes of agentic systems?
Tool misuse (wrong tool or bad arguments), infinite loops, context/goal drift over long sessions, hallucinated intermediate facts compounding across steps, over-reliance on stale memory, cascading errors when one bad tool output isn't validated, and excessive cost/latency from unbounded iteration.
Q.19 How would you design an agent to handle ambiguous instructions?
Have the agent detect ambiguity (e.g., via confidence heuristics or explicit reasoning check), ask a targeted clarifying question rather than guessing, or make and clearly state a reasonable assumption before proceeding if clarification isn't feasible — avoiding silent, unstated assumptions on high-stakes actions.
Q.20 Agent vs. workflow?
A workflow is a fixed, predetermined sequence of steps (deterministic pipeline) — good for predictable, repeatable tasks. An agent dynamically decides its next action based on reasoning and current state, allowing it to handle novel or variable situations, at the cost of predictability and control.
Q.21 How do you log and trace an agent's decisions for debugging?
Log every reasoning step, tool call (with inputs/outputs), timestamps, and model version used, ideally with a structured trace format (e.g., OpenTelemetry spans or a dedicated agent-tracing tool like LangSmith/Langfuse). This enables replaying a session to pinpoint where a wrong decision or hallucination occurred.
Q.22 Role of temperature/sampling in agent reliability?
Lower temperature (e.g., 0–0.3) produces more deterministic, consistent outputs — generally preferred for tool-calling/decision steps where reliability matters. Higher temperature increases creativity/diversity but risks inconsistent tool selection or reasoning errors, so it's usually reserved for creative subtasks, not control-flow decisions.
Q.23 How would you design memory persistence across sessions?
Use a database (vector store for semantic recall, plus structured store for facts/preferences) keyed by user/session ID. On each new session, retrieve relevant memories via similarity search or explicit lookup, inject a summarized version into the system prompt, and periodically consolidate/prune memory to avoid staleness or unbounded growth.
Q.24 Security risks of giving an agent code execution or file system access?
Risks include arbitrary code execution leading to system compromise, data exfiltration, destructive file operations, privilege escalation, and prompt-injection-triggered malicious actions. Mitigations: sandboxing/containerization, strict permission scoping, read-only defaults, human approval for destructive actions, and monitoring/logging all executions.
Q.25 How would you implement human-in-the-loop approval for high-risk actions?
Classify actions by risk level (e.g., read vs. write vs. irreversible), and for high-risk categories, pause execution and surface a clear confirmation prompt to a human with context on what will happen, requiring explicit approval before the agent proceeds — with the ability to reject/modify the action.
Q.26 Design a multi-agent system where agents negotiate conflicting sub-goals — how do you prevent deadlock/oscillation?
Use a central orchestrator/arbiter with authority to break ties rather than peer-to-peer unbounded negotiation. Set a max negotiation round limit, define a priority/utility function to resolve conflicts objectively, and detect oscillation by tracking whether agents are repeating previous positions — if so, force escalation to the arbiter or a human. Logging the negotiation trace helps debug cyclic behavior.
Q.27 How would you implement robust error-recovery when a tool call fails mid-task?
Wrap tool calls with retry logic (exponential backoff for transient errors like timeouts), distinguish transient vs. permanent failures, feed the error back into the agent's context so it can re-plan (e.g., try an alternate tool or ask for clarification), and set a max-retry ceiling before escalating to a human or gracefully failing with a clear explanation.
Q.28 Design an evaluation harness for long-horizon, multi-step agent tasks.
Define task suites with known ground-truth end states, evaluate not just final output but the trajectory: correct subtask decomposition, appropriate tool selection at each step, recovery from injected failures, and efficiency (steps/cost/latency). Use a mix of automated checks (state diffing, schema validation) and LLM-as-judge for subjective steps, and run multiple trials since agents are non-deterministic — measure success rate/variance, not a single pass/fail.
Q.29 Trade-offs: single generalist agent vs. several specialized agents?
A single agent has simpler orchestration, lower latency (no hand-off overhead), and easier debugging, but its prompt/context grows large and complex, risking degraded performance on niche subtasks. Specialized agents can have tighter, more accurate prompts/tools per domain and better modularity/testability, but introduce coordination overhead, potential for miscommunication between agents, and increased latency/cost from multiple LLM calls.
Q.30 How would you prevent prompt injection when an agent processes untrusted content?
Treat all external content (web pages, emails, docs) as untrusted data, never as instructions — use clear structural separation (e.g., delimiters/tags) so the model knows retrieved content is "data to reason about" not "commands to follow." Apply output/tool-call validation before execution, restrict tool permissions available when processing untrusted input, use a secondary classifier to detect injection attempts, and require human confirmation for any action triggered by content parsed from untrusted sources.
Q.31 Design a memory architecture with episodic, semantic, and procedural memory.
Episodic memory: a log of specific past interactions/events (timestamped, retrievable by recency/similarity — good for vector store with metadata). Semantic memory: consolidated facts/knowledge extracted from episodes (e.g., "user prefers Python"), stored in a structured or embedding-based knowledge base, periodically updated/summarized. Procedural memory: reusable skills/routines/tool-use patterns the agent has learned work well, stored as a "skill library" (e.g., saved code snippets or plan templates) it can retrieve and adapt rather than re-deriving from scratch.
Q.32 How would you implement cost/latency-aware model routing?
Build a lightweight classifier or heuristic (task complexity, expected token length, required reasoning depth) to route simple/well-defined subtasks to a smaller/cheaper model and complex/ambiguous ones to a larger model. Track outcome quality per route to continuously tune the routing threshold, and consider a fallback: start cheap, escalate to a stronger model if confidence is low or output fails validation.
Q.33 How would you design a reward/scoring function to fine-tune an agent's tool-use policy, avoiding reward hacking?
Define reward based on verifiable end-state correctness (not just intermediate proxy signals like "tool was called"), combine multiple signals (task success, efficiency, safety violations as penalties) to avoid the model gaming a single metric, and include adversarial/held-out evaluation tasks not seen during training. Regularly audit high-reward trajectories manually for exploits (e.g., agent finding a way to trigger success signal without real completion) and penalize behaviors like unnecessary tool spam.
Q.34 How would you architect a system to safely handle irreversible actions?
Classify actions by reversibility/blast-radius upfront. For irreversible ones (payments, deletions), require a mandatory confirmation gate with a human-readable summary of consequences, enforce dry-run/simulation mode where possible before real execution, add rate limits and monetary/action caps, and log an immutable audit trail. Consider a "two-key" pattern requiring a second independent check (human or separate verifier agent) before execution.
Q.35 How do you handle non-determinism when the system must be auditable/reproducible?
Set temperature low/zero for decision-critical steps, pin model versions per deployment, log full inputs/outputs/tool calls for every run (full trace), and where exact reproducibility is required, cache/version retrieved context (e.g., RAG documents) since results depend on retrieval state too. For regulated environments, maintain a versioned "decision record" per action showing exactly what led to it.
Q.36 Design a planner that decomposes a goal into a DAG of subtasks with dependencies.
Have the planning LLM output a structured graph (nodes = subtasks, edges = dependencies) rather than a flat list, validate the DAG (no cycles, all dependencies resolvable), then use a scheduler to execute independent branches in parallel while respecting dependency order. Re-planning triggers on subtask failure should only affect downstream-dependent nodes, not the whole graph.
Q.37 How would you detect and mitigate "agent drift" over a long session?
Periodically compare the agent's current stated sub-goal against the original goal (e.g., via a checkpoint summary re-alignment step), monitor for repeated context truncation/summarization losing key constraints, and set periodic "sanity check" prompts where the agent re-states its understanding of the task for validation. Mitigate via context refresh (re-inserting the original goal/constraints at intervals) and hard step/time budgets.
Q.38 Design shared knowledge base access across multiple agents avoiding conflicting/stale writes.
Use optimistic concurrency control (versioning/timestamps) or pessimistic locking on records being modified, route writes to a single "owner" process per resource to avoid races, use event-sourcing/append-only logs rather than in-place mutation where feasible, and have agents read the latest state right before acting (not from stale cached memory) to reduce conflicts.
Q.39 How would you benchmark different agent frameworks (LangGraph, AutoGen, CrewAI, custom) for production?
Define representative production tasks and measure: task success rate, latency/cost per task, ease of debugging/observability, flexibility for custom control flow, community/library maturity, and how well each handles error recovery and human-in-the-loop patterns. Run the same task set across frameworks with identical prompts/tools to isolate framework overhead from model differences.
Q.40 How would you design a self-critique/reflection loop without excessive cost blow-up?
Trigger reflection selectively — only after task failure or low-confidence output, not on every step. Use a cheaper/faster model for the critique pass, cap reflection iterations (e.g., max 1–2 retries), and cache/reuse previous reflections rather than regenerating from scratch when only minor context changes.
Q.41 How would you implement fine-grained tool permissioning per agent role in an enterprise system?
Define a role-based access control (RBAC) layer mapping each agent role to an explicit allowlist of tools/scopes, enforce it at the tool-execution layer (not just prompt instructions, since those can be bypassed), and audit-log every tool invocation with the acting agent's identity/role for traceability and compliance.
Q.42 How would you design fallback behavior when an agent's confidence is low?
Use a confidence signal (e.g., model self-reported certainty, ensemble agreement, or output validation failures) with defined thresholds: high confidence → proceed; medium → ask a clarifying question; low → escalate to a human or retry with an alternate strategy/model. Avoid silently proceeding on low-confidence high-risk actions.
Q.43 Challenges of maintaining state consistency in a distributed agent system?
Race conditions from concurrent state updates across processes, network partitions causing stale reads, and difficulty guaranteeing exactly-once execution of side-effecting actions. Mitigations: use a centralized state store with transactional guarantees, idempotency keys for tool calls (to safely retry without duplicate side effects), and consensus/locking mechanisms for shared critical state.
Q.44 Design a testing strategy for agentic pipelines given non-determinism.
Unit test individual tools/functions deterministically in isolation. Integration test the agent loop using mocked/stubbed tool responses to control outcomes. For adversarial testing, inject failures, ambiguous inputs, and prompt-injection attempts to verify guardrails hold. Since full end-to-end runs are non-deterministic, run each test scenario multiple times and assert on success rate/behavioral bounds rather than exact output matching.
Q.45 How would you implement rate-limiting/budget caps for agents that spawn sub-agents recursively?
Set a global budget (max tokens, max tool calls, max cost, max sub-agent depth) passed down and decremented through the call hierarchy, enforce hard limits at the execution layer (not just prompt-level instruction), and terminate/escalate gracefully with partial results if the budget is exhausted before task completion.
Q.46 How would you design an agent to learn from past executions via a skill library, without retraining the base model?
After successful task completions, extract a generalized, reusable "skill" (e.g., a parameterized plan template or code snippet) and store it with metadata (task type, preconditions) in a retrievable library. On new tasks, the agent searches this library first and adapts a matching skill instead of re-planning from scratch — effectively in-context learning via retrieval rather than weight updates.
Q.47 Structured outputs (JSON schema) vs. free-form reasoning for tool-calling reliability — trade-offs?
Structured outputs improve parsing reliability and reduce malformed calls, making them preferable for production tool execution where downstream code depends on exact schema compliance. Free-form reasoning (e.g., full chain-of-thought before the call) can improve decision quality on complex/ambiguous tasks but is harder to parse reliably. A common approach: allow free-form reasoning internally, then force a final structured output for the actual tool invocation.
Q.48 Design an observability stack for a production agentic system with thousands of concurrent sessions.
Instrument distributed tracing per session/agent step (e.g., OpenTelemetry spans linking reasoning → tool calls → outputs), collect metrics (latency, cost per session, tool error rates, success rate), set up real-time alerting on anomalies (spike in loop detections, failure rates), and sample sessions for periodic human/LLM-judge quality review, all feeding into a dashboard for aggregate and per-session drill-down.
Q.49 How would you handle version drift when an underlying LLM update changes agent behavior in production?
Pin model versions explicitly rather than auto-upgrading, run a shadow/canary evaluation of the new model version against your benchmark suite before switching, maintain regression tests capturing critical behaviors, and roll out gradually (e.g., percentage-based traffic split) with rollback capability if success metrics regress.
Q.50 Design a "critic"/verifier agent that checks an "executor" agent's outputs — what risks does this introduce?
The verifier independently re-evaluates the executor's output against the original goal/constraints (ideally using different prompting or even a different model to reduce correlated bias), flags discrepancies for retry or escalation. Key risk: if both agents share the same underlying model/training biases, they may make correlated errors and the verifier gives false confidence ("rubber-stamping"); mitigate by using a different model/provider for verification, incorporating deterministic checks where possible, and not treating verifier approval as infallible ground truth.
Q.51 What is an AI agent, in simple terms?
An AI agent is a system built around an LLM that can take actions to accomplish a goal, not just answer a question. It can use tools, look up information, and take multiple steps on its own to complete a task.
Q.52 What does "tool use" mean for an LLM-based agent?
It means the LLM can call external functions or APIs (e.g., a calculator, a search engine, a database query) to get information or perform actions it can't do through text generation alone, then use the results to continue reasoning.
Q.53 What is the basic loop an agent follows to complete a task?
Typically: perceive the current situation/input → think/plan the next step → act (e.g., call a tool) → observe the result → repeat until the goal is achieved or a stopping condition is met.
Q.54 Why can't a plain LLM (without agentic capabilities) browse the internet or check today's weather?
Because a plain LLM only generates text based on its training data and the given prompt — it has no way to fetch live external information or interact with the outside world unless it's connected to tools that can do so.
Q.55 What is a "prompt" in the context of an agent?
A prompt is the input text given to the LLM, which for an agent typically includes the task/goal, relevant context or history, available tools, and instructions on how to respond or act.
Q.56 What is memory in an agentic system, and why is it needed?
Memory lets an agent retain information across steps or sessions — like what's already been tried, user preferences, or earlier results — since an LLM by itself doesn't remember anything beyond what's included in its current prompt.
Q.57 What's the difference between an agent and a simple chatbot?
A chatbot just replies to messages conversationally. An agent has a goal, can plan multiple steps, use tools, and take actions to actually complete a task rather than just producing a text response.
Q.58 What is an example of a real-world use case for Agentic AI?
Examples include an AI assistant that books a flight by searching options, comparing prices, and completing checkout; a coding agent that writes, runs, and debugs code automatically; or a customer support agent that looks up order details and processes a refund.
Q.59 What does "autonomy" mean in the context of agentic AI?
Autonomy refers to how much an agent can act on its own without human input at each step — ranging from fully human-supervised (approval needed for every action) to fully autonomous (completes multi-step tasks unattended).
Q.60 Why is it important to set limits (like max steps or timeouts) for an agent?
Without limits, an agent could get stuck in a loop, take too long, or run up excessive cost by repeatedly calling tools or reasoning without making progress toward the goal, so limits ensure it stops or escalates gracefully.
Get Govt. Certified Take Test
 For Support