AI agents and tool use

In short

An AI agent is a system that perceives its environment, decides what to do and acts through actuators or software tools to reach a goal. Classical AI (AICTE/CBCS "Artificial Intelligence" and GATE DA/CS syllabi) defines agents formally — PEAS, agent types, rationality — while modern practice builds agents on large language models that call external tools such as search, SQL, calculators and company APIs. The two views are examined together: theory questions on agent architectures and environment properties, and practical questions on function calling, the ReAct loop, memory and failure modes. Indian employers (TCS, Infosys, Wipro, Accenture, Fractal, Sprinklr, Zoho, Freshworks, Razorpay, Jio, startups building copilots) now hire specifically for "agentic AI" roles, so this topic appears in both exam papers and placement technical rounds.

Explained

Classical agent theory (what exams define)

• Agent: anything that perceives its environment through sensors and acts on it through actuators. Formally an agent function f maps a percept sequence to an action: f: P* → A. The agent program is the concrete implementation of f.
• Rational agent: for every percept sequence, selects the action expected to maximise its performance measure, given its built-in knowledge and the evidence so far. Rationality is not omniscience and not perfection — it is expected-value maximisation under limited information.
• PEAS description — the standard way to specify an agent task: Performance measure, Environment, Actuators, Sensors. Example for a railway-enquiry chatbot: P = query resolved without escalation; E = passengers, IRCTC APIs; A = replies, API calls; S = text input, API responses.
• Agent types (increasing sophistication):
  1. Simple reflex agent — acts only on the current percept using condition-action rules; fails when the world is partially observable.
  2. Model-based reflex agent — keeps an internal state that models the unobserved part of the world.
  3. Goal-based agent — searches/plans over actions to reach a goal state.
  4. Utility-based agent — maximises a utility function, so it can trade off conflicting goals and handle uncertainty.
  5. Learning agent — has four components: performance element (acts), critic (gives feedback against a standard), learning element (improves the performance element), problem generator (suggests exploratory actions).
• Environment properties (standard exam list): fully vs partially observable; deterministic vs stochastic; episodic vs sequential; static vs dynamic; discrete vs continuous; single-agent vs multi-agent; known vs unknown. A web-browsing LLM agent is partially observable, stochastic, sequential, dynamic, discrete and multi-agent — the hardest combination.
• Architectures: reactive (subsumption), deliberative (BDI — Belief, Desire, Intention), and hybrid layered architectures (reactive layer for fast responses, deliberative layer for planning).

LLM-based agents: anatomy

• An LLM agent = model (the reasoning engine) + tools + memory + planner + an orchestration loop that runs until a stopping condition.
• Tool (function): a described, callable capability outside the model — search, SQL query, calculator, file read, HTTP POST, code execution, sending email. The model never executes code itself; it emits a structured request, the surrounding program executes it and returns the result.
• Tool schema: name, natural-language description, and a JSON Schema of parameters. The description is part of the prompt, so vague descriptions are the single biggest cause of wrong tool choice.
• Memory: short-term = the context window (current conversation + scratchpad); long-term = external store (vector DB, SQL, key-value) written and read via tools. Episodic memory = past runs; semantic memory = facts; procedural = instructions/skills.
• Planner: decides the sequence of steps. Styles — plan-and-execute (make a full plan first, then run steps), interleaved (decide one step at a time, as in ReAct), tree/graph search over candidate actions.
• Reflection / self-critique: the agent inspects its own output or the tool error and retries (Reflexion-style). Improves reliability on multi-step tasks but multiplies token cost.
• Agency spectrum: prompt → chain (fixed sequence) → router (model picks a branch) → agent (model controls the loop) → multi-agent. Choose the least agency that solves the problem; agency buys flexibility and costs determinism.

The agent loop and prompting patterns

• ReAct (Reason + Act) — the canonical loop: Thought → Action → Action Input → Observation, repeated, then Final Answer. Reasoning text makes tool choice explicit and debuggable.
• Function calling / tool calling — the production mechanism: tool schemas are passed with the request; the model returns a tool call with JSON arguments; the program runs it and appends a tool result message; the model continues. Parallel tool calling returns several calls in one turn.
• Step-by-step execution:
  1. Receive user goal; load system prompt, tool schemas and relevant memory.
  2. Model emits either a final answer or one/more tool calls.
  3. Validate arguments against the schema; apply permissions and rate limits.
  4. Execute the tool; capture result, truncate or summarise large outputs.
  5. Append the observation to the context; increment the step counter.
  6. Repeat until the final answer, a max-step limit, a token/₹ budget or a timeout is hit.
• Stopping conditions are mandatory — max steps, max tokens, wall-clock timeout, repeated-action detector. Without them an agent loops on a failing tool indefinitely.
• Other patterns: ReWOO (plan all tool calls without interleaving observations, to save tokens), Toolformer (model trained to insert API calls), Chain-of-Thought (reasoning only, no tools), Program-Aided LM / PAL (write code, execute it, use the output).
• Model Context Protocol (MCP) — an open protocol (introduced by Anthropic, late 2024, now broadly adopted) that standardises how agents connect to tools, resources and prompts from external servers, so the same tool server works across clients. Treat version details as fast-moving.

Multi-agent systems

• Why: separation of concerns, specialised prompts/tools per role, parallelism, and independent context windows that avoid one overflowing prompt.
• Topologies: supervisor/orchestrator-worker (one planner delegates; most common in production), pipeline/sequential handoff, debate/critic (one proposes, another critiques), blackboard (shared state), swarm/peer handoff.
• Communication: structured messages (JSON), shared memory, or a message bus; classical MAS uses FIPA-ACL speech acts and the contract-net protocol for task allocation by bidding.
• Coordination problems: credit assignment, deadlock/livelock, infinite agent-to-agent chatter, cost explosion (every hop is a fresh LLM call), and error compounding — if each of 5 steps is 90% reliable, end-to-end ≈ 59%.
• Game-theoretic framing (asked in GATE-style theory): agents as players, Nash equilibrium, cooperative vs competitive settings, auctions for resource allocation.

Evaluation, reliability and cost

• Metrics: task success rate (pass@1), tool-call accuracy (right tool, right arguments), step efficiency (steps or tokens per solved task), latency (p50/p95), cost per task in ₹, hallucination rate, and human-escalation rate.
• Benchmarks: ToolBench / API-Bank / BFCL (function-calling accuracy), WebArena and GAIA (web and general assistant tasks), SWE-bench (software agents), τ-bench (tool-agent-user interaction). Scores change rapidly — quote them as "as reported" only.
• Tracing/observability is non-negotiable: log every prompt, tool call, arguments, observation, latency and token count; replay failures. Tools: LangSmith, OpenTelemetry GenAI conventions, Langfuse.
• Reliability techniques: strict schema validation, idempotent tools, retries with exponential backoff, deterministic sub-steps in code rather than in the model, human-in-the-loop approval for irreversible actions (payments, deletions, emails), sandboxing code execution, and allow-lists for network access.
• Security: prompt injection is the defining risk — untrusted text fetched by a tool can carry instructions. Mitigations: treat tool output as data not instructions, least-privilege credentials per tool, output filtering, separate planning context from untrusted content, and confirmation gates. Also guard against tool-poisoning (malicious MCP server), excessive agency and data exfiltration (OWASP Top 10 for LLM Applications lists these).
• Limitations: no guarantee of termination or correctness, long-horizon planning is weak, context-window limits force summarisation (losing detail), cost and latency scale with steps, non-determinism makes testing hard, and attribution of liability is unsettled.

Indian context, law and practice

• DPDP Act, 2023 (Digital Personal Data Protection Act) governs personal data an agent reads or writes: purpose limitation, consent, data-principal rights, breach notification, and obligations of the data fiduciary. Rules under the Act have been notified in 2025 with phased implementation — check the current MeitY notification for applicable dates before relying on a compliance deadline.
• IT Act, 2000 with the Intermediary Guidelines and Digital Media Ethics Code Rules, 2021 (as amended) covers due diligence and takedown for platforms deploying agents; advisories on AI-generated content and labelling have been issued by MeitY and are evolving.
• Sectoral limits: RBI directions on outsourcing and IT governance restrict what an autonomous agent may do in lending/payments; SEBI governs algo and advisory automation; DPDP plus data-localisation directions affect where tool calls may send data.
• Standards and policy: IndiaAI Mission (MeitY) funds compute and applications; BIS has an AI standardisation committee (LITD 30) aligned with ISO/IEC JTC 1/SC 42, and ISO/IEC 42001:2023 is the AI management-system standard referenced in enterprise audits; NITI Aayog's Responsible AI principles are widely cited in Indian RFPs.
• Practice: agents in India are usually deployed on bounded, auditable tasks — ticket triage, document extraction, SQL analytics, KYC checks, field-force assistants — with human approval before any money moves or any customer-facing commitment.

Key points

• Agent - perceives via sensors, acts via actuators; agent function maps percept sequences to actions.
• Rational agent - maximises expected performance measure, not guaranteed success.
• PEAS - Performance, Environment, Actuators, Sensors: the standard task specification.
• Agent types - simple reflex, model-based reflex, goal-based, utility-based, learning.
• Learning agent parts - performance element, critic, learning element, problem generator.
• Environment axes - observable, deterministic, episodic, static, discrete, single-agent, known.
• Tool use - the model emits a structured call; the host program executes it and returns an observation.
• Tool schema - name + description + JSON Schema; the description drives selection accuracy.
• ReAct - Thought → Action → Observation loop until Final Answer; the interleaved planning pattern.
• Plan-and-execute vs interleaved - full plan first (cheaper, brittle) vs step-by-step (adaptive, costlier).
• Memory - short-term context window; long-term external store accessed as a tool.
• Reflection - self-critique and retry after an error; improves success, multiplies cost.
• Stopping conditions - max steps, token/₹ budget, timeout, loop detection; mandatory in production.
• Multi-agent topologies - supervisor-worker, pipeline, debate, blackboard, swarm.
• Error compounding - per-step reliability multiplies, so step count must be minimised.
• Prompt injection - untrusted tool output carrying instructions; the top agent security risk.
• Human-in-the-loop - required gate before irreversible or financial actions.
• MCP - open protocol standardising agent-to-tool connections across clients.
• Indian law - DPDP Act 2023 for personal data; IT Act 2000 and 2021 Rules for platforms; RBI/SEBI limits in finance.

Formulas and examples

Example 1 — Error compounding and where to spend effort. A document-processing agent has 4 steps with reliabilities 0.95, 0.90, 0.98, 0.92.

• S = 0.95 × 0.90 = 0.855; × 0.98 = 0.8379; × 0.92 = 0.7709 ≈ 77.1%.
• Raise only the weakest step (0.90 → 0.97): S = 0.95 × 0.97 × 0.98 × 0.92 = 0.8309 ≈ 83.1%, a gain of 6.0 percentage points.
• Adding a 5th step at 0.95 instead: 0.7709 × 0.95 = 73.2% — every extra step costs reliability. Conclusion: fix the weakest link, do not add steps.

Example 2 — Retries on a flaky tool. A tool succeeds with p = 0.7 per attempt; the agent allows k = 3 attempts.

• P(success) = 1 − (1 − 0.7)³ = 1 − 0.027 = 0.973.
• Expected attempts (truncated) = 1 + 0.3 + 0.09 = 1.39 attempts.
• If each attempt costs 1,500 tokens, expected tokens on this tool = 1.39 × 1,500 ≈ 2,085 tokens.

Example 3 — Token growth and cost of an agent run. System prompt + tool schemas = 1,200 tokens. History grows by 400 tokens per step (model text + observation). The agent runs 6 steps and generates 150 output tokens per step.

• Input tokens at step i = 1,200 + 400(i − 1): 1,200; 1,600; 2,000; 2,400; 2,800; 3,200 → total input = 13,200 tokens.
• Output = 6 × 150 = 900 tokens.
• At rates of USD 3 per MTok input and USD 15 per MTok output: input cost = 13,200/1,000,000 × 3 = USD 0.0396; output = 900/1,000,000 × 15 = USD 0.0135; total ≈ USD 0.0531.
• At ₹88 per USD (illustrative; use the day's rate) ≈ ₹4.67 per task. For 20,000 tasks/month ≈ ₹93,400/month.
• A single-shot prompt of 1,500 input + 300 output tokens would cost 1,500/1e6×3 + 300/1e6×15 = USD 0.009 ≈ ₹0.79 — about 6 times cheaper, which is why agency is used only where it is needed.

Example 4 — Latency: sequential vs parallel tool calls. Model latency 1.2 s per step; three independent API tools take 0.8 s, 1.5 s and 0.6 s.

• Sequential (one tool per step, 3 tool steps + 1 final step = 4 model calls): T = 4 × 1.2 + (0.8 + 1.5 + 0.6) = 4.8 + 2.9 = 7.7 s.
• Parallel tool calling (1 planning call + 1 final call): T = 2 × 1.2 + max(0.8, 1.5, 0.6) = 2.4 + 1.5 = 3.9 s — a 49.4% reduction.

Example 5 — ReAct trace for a GST query (tool-use pattern).

User: What is the total GST on our three largest October invoices?

Thought: I need the invoice amounts first. Use sql_query.
Action: sql_query
Action Input: {"q":"SELECT id, amount, gst_rate FROM invoices
               WHERE month='2026-10' ORDER BY amount DESC LIMIT 3"}
Observation: [{id:4471, amount:250000, gst_rate:18},
              {id:4458, amount:180000, gst_rate:5},
              {id:4440, amount:120000, gst_rate:18}]

Thought: Compute GST per invoice and sum. Use calculator (do not do arithmetic in my head).
Action: calculator
Action Input: {"expr":"250000*0.18 + 180000*0.05 + 120000*0.18"}
Observation: 75600

Final Answer: Total GST = 45,000 + 9,000 + 21,600 = Rs 75,600.

(Check: 250000×0.18 = 45,000; 180000×0.05 = 9,000; 120000×0.18 = 21,600; sum = ₹75,600. Slabs 5%/18%/40% apply from 22 September 2025.)

Where it is used

• IT services and GCCs (TCS, Infosys, Wipro, HCLTech, Accenture, Cognizant): agentic ticket triage, code migration and test-generation agents; roles titled AI engineer, LLM application engineer, prompt/agent engineer.
• Product and SaaS (Zoho, Freshworks, Sprinklr, Chargebee, Postman): support copilots that call CRM/ticketing APIs with human approval before customer replies.
• BFSI (HDFC, ICICI, Razorpay, PhonePe, Paytm, Jupiter): KYC document checks, reconciliation, collections assistants — always with human-in-the-loop and RBI-compliant audit trails; agents read but rarely move money autonomously.
• E-commerce and logistics (Flipkart, Meesho, Delhivery, Zomato, Swiggy): catalogue enrichment, seller-support agents, route and exception-handling assistants calling internal microservices.
• Government and public digital (IndiaAI, Bhashini, DigiLocker/UMANG integrations): multilingual citizen-service assistants that call scheme-eligibility and document APIs.
• Robotics and embedded (classical agents): warehouse AMRs, agri-drones and autonomous ground vehicles, where PEAS, sensing, planning and control are the examined form of the same ideas.

Interview questions

• Q: What is the difference between an AI agent and a plain LLM call? A: A plain call maps one prompt to one response; an agent runs a loop in which the model observes results, decides the next action and calls tools until a goal or stopping condition is reached.
• Q: Define rationality for an agent. A: For each percept sequence, choosing the action that maximises the expected value of the performance measure given the agent's prior knowledge and the percepts so far — not the action with the best outcome in hindsight.
• Q: Write the PEAS for a resume-screening agent. A: P = precision/recall of shortlists and time per CV; E = CVs, ATS, recruiters; A = score, shortlist, reject, request clarification; S = parsed CV text, job description, recruiter feedback.
• Q: How does function calling actually work? A: Tool schemas are sent with the request; the model returns a structured call with JSON arguments; the application validates and executes it and appends the result as a tool message so the model can continue reasoning.
• Q: Explain the ReAct loop. A: The model alternates Thought (reasoning), Action plus Action Input (tool call) and Observation (tool result), repeating until it emits a Final Answer; the explicit reasoning improves tool choice and makes traces debuggable.
• Q: Why does the model not run the tool itself? A: It only generates text; execution happens in the host program, which is also where validation, permissions, rate limits and sandboxing must be enforced.
• Q: What is prompt injection in an agent, and how do you defend against it? A: Untrusted content returned by a tool contains instructions the model follows; defend with least-privilege credentials, treating tool output as data, separating untrusted content from the planning context, output filtering and human confirmation for risky actions.
• Q: When would you choose a fixed workflow over an agent? A: When the process is known and repeatable — a fixed chain is cheaper, faster, deterministic and testable; agency is only worth its cost when the control flow genuinely cannot be written in advance.
• Q: A 6-step agent has 90% per-step reliability. What is end-to-end success? A: 0.9⁶ ≈ 0.531, about 53% — which is why step count is reduced, deterministic steps are moved into code and retries plus validation are added.
• Q: How do you stop an agent looping forever? A: Hard caps on steps, tokens and wall-clock time, duplicate-action detection, a cost budget per task, and a fallback to escalate to a human when the cap is hit.
• Q: Difference between short-term and long-term memory in an agent? A: Short-term is the context window of the current run (volatile, size-limited); long-term is an external store — vector DB, SQL or files — read and written through tools and persisting across runs.
• Q: What does MCP solve? A: It standardises the interface between agents and tool/data servers so the same server can be reused by different clients, instead of every application writing bespoke tool adapters.
• Q: Which Indian law most affects an agent that reads customer records? A: The DPDP Act, 2023 — consent, purpose limitation, data-principal rights and breach obligations (in force from 13 May 2027 under the DPDP Rules 2025; until then IT Act s.43A and the SPDI Rules 2011 apply); with the IT Act, 2000 and the 2021 Intermediary Rules for platform duties, and RBI/SEBI directions in finance.

Common mistakes

• Confusing the agent function (mathematical mapping) with the agent program (bounded implementation) in theory answers.
• Saying a rational agent always succeeds, or that rationality requires omniscience — it is expected-utility maximisation under uncertainty.
• Claiming the LLM "executes" the tool; the model only emits a structured call that the host program runs.
• Building an agent where a fixed chain or a single RAG call would do — paying several times the cost and losing determinism.
• Forgetting stopping conditions and budget caps, so a failing tool produces an infinite, expensive loop.
• Ignoring that history is re-sent at every step, then being surprised by token cost and latency growing faster than the step count.
• Writing vague tool descriptions or loose schemas, then blaming the model for picking the wrong tool or malformed arguments.
• Letting the agent take irreversible actions (payments, deletions, outbound email) without a human approval gate or audit log.

Related topics

Large language models and prompt engineering · Retrieval-augmented generation and vector databases · Text embeddings and semantic search · Natural language processing basics · Reinforcement learning and Markov decision processes · Search and planning algorithms in AI