Agentic AI Course in Pune — Build Production AI Agents

The distinction the whole course rests on, made precise before any code. A chatbot answers. A workflow executes a sequence you wrote. An agent is given a goal and decides for itself what steps to take, which tools to call, and when it is done — and that autonomy is exactly what makes agents powerful, expensive, hard to test and occasionally dangerous.

You work through where each of the three is the right answer, using real business processes rather than toy examples: a support ticket triage, a lead qualification flow, a document review. The most valuable output of the week is the ability to say no — to recognise the large class of problems where a deterministic workflow with one LLM call is cheaper, faster and more reliable than an agent, which is the judgement that distinguishes an engineer from someone who has read the marketing.

The mental model shift. LLM APIs reframed not as text completers but as reasoning engines that can be steered to produce structured decisions. Tool / function calling fundamentals — the single most-important agent primitive — taught against both OpenAI and Anthropic SDKs so you understand the cross-vendor patterns. System prompts + behaviour shaping. Structured outputs (JSON mode, schema-constrained generation). Token economics + context-window strategy that actually maps to how you'll budget production agents. The most important Week 2 lesson: when an agent is the right tool vs when a simple workflow with one LLM call is better.

The anatomy of an agent, component by component, so that later framework code is recognisable rather than magical. An agent is a loop around five parts: a goal and its instructions, a context it can read, a set of tools it can call, a memory it can write to and read back, and a state that survives between steps. Take any one away and you get a different, usually worse, system.

You build a single-agent ReAct loop by hand — no framework — so the observe / think / act cycle, the stopping condition and the state object are code you wrote rather than abstractions you imported. This is the module students most often say made the frameworks in Week 3 click, because every LangGraph node afterwards maps to something they have already implemented themselves.

Tools are where an agent stops being a conversation and starts having effects, so they get a module of their own rather than a passing mention. You build the four families the job actually requires: API tools against a real third-party service with authentication and rate limits, database tools with parameterised queries, search and retrieval tools over a document set, and file or document tools that read and write real artefacts.

The engineering half is where the marks are. Tool schemas written so the model picks correctly rather than plausibly; input validation that assumes the model will pass something wrong, because it will; result handling that turns an API error into something the agent can recover from rather than a stack trace; idempotency so a retried call does not charge a customer twice. You also classify tools by risk — read-only, reversible write, irreversible action — which is the classification the security module later builds permissions on.

The framework tour, but with discipline. LangChain core — chains, runnables, the LangChain Expression Language — covered as the most-widely-deployed agent framework in 2026 but with explicit notes on its abstraction overhead. LangGraph — stateful agent graphs, the production default. OpenAI Assistants and the Agents SDK as the vendor-native alternative. Claude tool use + Computer Use API direct against the SDK so you know what the framework wrappers are hiding. CrewAI and AutoGen-style multi-agent frameworks covered for their role-based model.

Because you built a ReAct loop by hand in Week 2, you rebuild that same loop with LangGraph here and can state precisely what abstraction you bought and what it cost you in debuggability. The module closes on framework selection for a project — and on the case for no framework at all, which for a two-tool agent is often correct.

Most working agentic systems are not one clever autonomous agent; they are a small number of well-understood patterns composed together. This module names them so you can reach for the right one instead of reinventing it, and so you can recognise them in an architecture discussion at interview.

The router pattern classifies an incoming request and dispatches it. The sequential pattern runs deterministic steps with an LLM at each. The parallel pattern fans work out and merges results. The evaluator-optimiser pattern has one model produce and another critique until a quality bar is met. The supervisor-worker pattern delegates to specialists. Human-in-the-loop inserts an approval gate. For each you cover what it costs, how it fails and the size of problem it suits — and you implement two of them against the same task so the trade-off is something you have measured rather than read.

Where agent engineering gets hard. ReAct + reflection patterns — the agent observes its own output and decides whether to continue, replan, or finish. Plan-and-execute architectures (LangGraph's plan-and-execute primitive) for tasks that benefit from explicit upfront decomposition. Short-term vs long-term memory and the architectural patterns for each. Vector stores for episodic memory — Pinecone, Weaviate, pgvector — taught against the cost-and-latency trade-offs that matter in production. Conversation summarisation + context pruning when context windows fill. Error recovery + retry strategies (the most common production failure mode).

An agent that plans once and executes blindly fails on the first tool error. This module is about what happens after something goes wrong, which in production is most of the time. You cover task decomposition into steps small enough to verify, replanning when a step fails or returns something unexpected, and the difference between a retryable failure and one that should stop the run and ask a person.

Human-in-the-loop is treated as an architectural decision rather than a safety afterthought: where to put an approval checkpoint, what to show the reviewer so the decision takes seconds rather than minutes, how to hold agent state while waiting for a human who may not return for hours, and how to resume cleanly. You also cover controlling long-running tasks — step budgets, wall-clock limits, cost ceilings and cancellation — because an agent that loops without a bound is the single most expensive bug in this field.

Agents that answer from a knowledge base rather than from training data — the most commonly deployed agentic pattern in Indian enterprise work, because it is the one with an obvious business case. You start from a RAG refresher, then move to what makes retrieval agentic: the agent decides whether to retrieve at all, what to search for, whether the results were good enough, and whether to search again with a different query.

That decision loop is both the value and the risk. You cover source-grounded answering with citations, using retrieval to reduce rather than launder hallucination, retrieval as an input to a decision rather than just to a sentence, and knowledge-base maintenance — the unglamorous work of keeping an index current, which is where most deployed systems quietly decay. You finish by building a knowledge-base agent over a real document set with grounded, cited answers.

Several agents with distinct roles, coordinating on one task. Supervisor and worker as the default production pattern; role-based specialists such as researcher, writer, reviewer, coder and tester; debate and review patterns where one agent critiques another's output; and hierarchical and swarm arrangements with an honest account of where each stops working.

The module gives equal weight to the failure side, because multi-agent systems fail in ways single agents do not: cost multiplied by the number of participants, latency stacked serially, conflicting conclusions with no arbiter, agents talking past each other, and traces that no one can debug. The rule taught here is that a second agent must earn its place — if one agent with two tools does the job, that is the better system, and being able to argue that in a design review is worth more than being able to build a six-agent swarm.

The applied module, and the one that most directly maps to what Pune employers are actually buying. Business process automation with agents is where the current budget sits: support ticket triage and resolution, sales lead qualification and follow-up, resume screening and interview scheduling, email and communication handling, education and training assistants, and internal operations workflows.

For each you do the same exercise: take the existing manual process, break it into steps, mark which steps an agent can own outright, which need a tool, and which must stay with a person and why. The deliverable is an automation blueprint for one real workflow — the artefact that turns “I built an agent” into “I automated a process and can say what it saved”, which is the version that survives an interview follow-up question.

Evaluating an agent is genuinely harder than evaluating a model, and pretending otherwise is how unreliable systems reach production. There is no single correct output to compare against: two different tool sequences can both be right, and the same input can legitimately produce different runs. So evaluation moves to the things that can be measured — did the task succeed against a defined criterion, did the agent select the right tool, were the arguments correct, was the answer grounded in what was retrieved, how many steps and how much money did it take.

You build a scenario suite from real inputs, score runs on task success, tool-selection accuracy, groundedness, cost and latency, and wire it as a regression test so a prompt or model change that quietly breaks step four gets caught before a customer finds it. Human evaluation gets a rubric rather than a vibe, and you cover feedback loops that turn production failures back into test cases.

An agent with tools is an attack surface with a language model in front of it. Prompt injection matters more here than anywhere else in AI engineering, because the model does not just say something wrong — it calls a tool. You cover direct and indirect injection, injection arriving through retrieved documents and fetched web pages, and why filtering the input is not a fix.

The defences are architectural: permission boundaries per tool, approval required before any irreversible or sensitive action, least-privilege credentials so a compromised agent cannot exceed its remit, output validation before a result is acted on, and excessive-agency control — the OWASP category that names precisely this failure. Alongside: data privacy and access control over what an agent may read, unbounded token and cost control, system-prompt leakage, and audit logs detailed enough to reconstruct what an agent did and why. Framed against the OWASP Top 10 for LLM Applications, which is what an enterprise security review will hold you to.

The production handoff. Observability first, because a seven-step agent loop cannot be debugged from logs alone: tracing with LangSmith or Langfuse, span-level visibility into every model call and tool invocation, and instrumentation you add while building rather than after an incident.

Then the operational layer — deployment behind FastAPI with async workers and streaming, containerisation, background execution for long runs, error recovery and escalation paths, monitoring failed runs, alerting on cost and step-count anomalies, and versioning tools, prompts and workflows together so a rollback restores a known-good system rather than half of one. Caching and token budgeting close the cost loop. You finish against a production-readiness checklist covering the questions asked before an agent is allowed near real users.

Two weeks of full-time capstone work on a deployed agentic system, plus interview preparation calibrated to how agentic AI is actually assessed. You pick one capstone (see Capstone Projects), take it to a deployed, traced, evaluated state, and document the architecture with a diagram — because the interview question is never ‘did it work’, it is ‘why did you choose that pattern, and what did you do when a tool call failed’.

Mock rounds cover agent system design, tool-use and function-calling questions, memory and retrieval questions, multi-agent coordination, and security and responsible-AI questions. You rehearse explaining your own trace: walking a panel through a real run, naming the step that failed and the fix. Resume, LinkedIn and GitHub polish is included, aimed at the AI Engineer and Agentic AI Developer job descriptions Pune product companies are posting.