Designing Agentic Systems

Work through nine headings, in this order:

• Requirements: what it must do, for whom, at what volume, speed and cost; and what it must never do.
• Architecture: the simplest shape that meets them: workflow, single agent, or several.
• Tools: the few task-shaped tools, each marked read or write.
• Memory: what is kept within a task, and across tasks.
• Planning: how the work is decomposed and tracked.
• Guardrails: the worst case, and the code that prevents it.
• Evaluation: how you will know it works, before and after launch.
• Scalability: the bottleneck, and the plan for it.
• Failure handling: what happens when a step, a tool or the model fails.

The order matters.

• Requirements first, because 'should this be an agent at all?' is answered there.
• Tools and guardrails before prompts, because they decide what is possible and what is safe.
• Evaluation before launch, because without it no later change can be trusted.
• The same template works on a whiteboard in forty minutes and in a design document over a week.

A user asks an open question ('how are grocery delivery firms handling returns?') and wants a cited report in minutes. Requirements:

• searches the web and reads many sources;
• every claim carries a source that supports it;
• conflicting sources are reported, not smoothed over;
• finishes within a cost and time budget, and says what it could not find;
• must never invent a citation or follow instructions found on a web page.

Three decisions define it.

• Parallel sub-agents: sources are independent, so one sub-agent per sub-question reads and returns a short brief. The lead's context holds briefs, not web pages.
• Verification as a separate step: a checker confirms each claim appears in its cited source, because the writer will otherwise cite plausibly and wrongly.
• Untrusted input everywhere: every page is hostile until proven otherwise, so the reading agents have no private data and no tools that act.

Kirana Kart's agent resolves order problems in chat. Requirements:

• answers policy questions and resolves refunds, cancellations and rescheduling;
• first response within two seconds; most tasks done in under fifteen;
• sees only the signed-in customer's data;
• refunds within policy, capped, with large ones approved by a person;
• must never refund twice, act on another customer's order, or promise what it has not done.

This is the design where money moves, so the tool layer is the centre.

• A workflow with one agent step: route, verify, decide and act are fixed stages; the model has freedom inside the investigation stage only.
• Enforcement in tools: identity from the session, caps and eligibility checked in code against the real order, idempotency keys on every write.
• A clear path to a human, with a summary, because knowing when to stop is part of resolving.

A developer describes a change ('add retry with backoff to the payment client') and the agent makes it in the repository. Requirements:

• finds the relevant code in a large repository;
• edits files, runs the tests, and fixes what fails;
• produces a reviewable change with an explanation;
• works for minutes to hours, and can be interrupted and resumed;
• must never push to the main branch, leak secrets, or run destructive commands outside its workspace.

Coding agents work because the feedback is strong, so the design protects that loop.

• Tests as ground truth: the agent's 'done' is a passing test run, not its own opinion.
• A sandbox: it runs arbitrary commands, so it works in an isolated copy with no production credentials and restricted network.
• Context management is the hard part: a repository does not fit in a context, so it searches and reads on demand, keeps a plan file, and compacts its history.

A user says 'four days in Jaipur in March for two, under ₹40,000' and wants an itinerary they can book. Requirements:

• searches flights, trains, hotels and activities against dates, budget and preferences;
• respects hard constraints (budget, dates) and soft ones (prefers mornings, vegetarian);
• presents options and books only what the user confirms;
• prices and availability must be current at the moment of booking;
• must never pay without explicit confirmation of the exact itinerary and total.

It is a planning problem with a payment at the end.

• Plan with dependencies: dates fix flights; flights fix hotel nights; searches for each are independent and run in parallel.
• Constraints checked in code: the budget total is arithmetic, not a model's judgement.
• Stale data is the trap: a price seen in the search may be gone at booking, so every booking re-checks, and a failed leg triggers compensation for those already booked.

Employees ask questions across the company's wikis, documents, tickets and chat. Requirements:

• answers from internal sources with citations;
• each employee sees only what they are permitted to see in the source systems;
• handles questions that span several systems;
• says when it does not know, and when sources disagree or are out of date;
• must never reveal a document to someone without access to it.

The hard part is permissions, not retrieval.

• Access control at retrieval time: every search is filtered by the asking employee's rights, enforced in the store, never by the model.
• Agentic retrieval: source selection, query rewriting, multi-hop look-ups and a support check, because enterprise questions rarely live in one document.
• Freshness and ownership: every answer shows its sources and their dates, so a wrong one can be traced to a stale page and fixed at the source.

An analyst asks 'why did orders drop last week?' and the agent investigates the data warehouse. Requirements:

• finds the right tables, writes and runs queries, and analyses results with code;
• produces charts and a written explanation with the queries shown;
• respects each user's data access;
• results are reproducible: the same question and data give the same numbers;
• must never modify data, run unbounded queries, or present a guess as a finding.

It writes and runs code against real data, so containment and verifiability come first.

• Read-only by construction: a read-only database role with row-level security, and a sandbox for Python with no network.
• Schema retrieval: a warehouse has thousands of tables; the agent searches a catalogue of table descriptions instead of being shown them all.
• Show the work: every number in the answer traces to a query that can be re-run, because a plausible wrong number is the main risk.

The same questions asked of all six systems. Reading across a row shows how one concern is solved differently; reading down a column gives one system's character at a glance.

Comparison turns six examples into a method.

• The shape follows the task's structure: independent strands fan out, money moves through fixed stages, exploration uses a loop.
• The 'must never' decides the main guardrail in every case.
• The check on success is always something outside the model: tests, a ledger, a source, a query.
• In an interview, the fastest route to a good answer is to say which of these six the new problem most resembles, and what differs.

The questions interviewers ask about designing agentic systems, from the first screening call to the senior round. Cover the answer, say yours aloud, then compare.

Reading an idea and explaining it are different skills.

• Each answer below is the two or three sentences an interviewer is listening for.
• The reasoning behind each one is in the cards above. If an answer surprises you, go back to that card.

A short build that uses this module's ideas. Write it yourself before looking anything up; the checks at the end tell you whether it works.

An idea you have only read fades in a week.

• Building it once, even in fifty lines, is what makes it yours.
• Interviewers can tell the difference between someone who has read about a loop and someone who has debugged one.