How do agents use tool-calling and what can go wrong?

### What this tests This tests your practical experience building with LLMs beyond single API calls. The interviewer wants to see if you understand the architectural distinction between predictable systems (workflows) and dynamic systems (agents), and if you're aware of the real-world failure modes related to complexity, debugging, and cost.

### A good answer covers * **Distinguishing Architectures:** Start by clarifying the two main types of "agentic systems." **Workflows** use predefined code paths to orchestrate LLM and tool calls, offering predictability. **Agents** let the LLM dynamically direct its own process and tool usage, offering flexibility. * **The Core Mechanism:** Explain that the fundamental building block is an "augmented LLM" given access to tools. The model is prompted to decide *if* a tool is needed, *which* tool to use, and *what* parameters to pass, typically by outputting a structured format like JSON. * **Failure Mode 1: Framework Obfuscation:** Many agent frameworks add layers of abstraction that hide the underlying prompts and model responses. This makes debugging incredibly difficult when the agent misbehaves, as you can't see the exact input/output that caused the error. Starting with direct API calls is often better. * **Failure Mode 2: Unnecessary Complexity & Cost:** Agentic systems trade higher latency and cost for better performance on complex tasks. A common mistake is building a multi-step agent when a single, well-prompted LLM call with retrieval-augmented generation (RAG) would have been sufficient, faster, and cheaper. Each "step" or tool call is another LLM inference, adding seconds of latency and multiplying costs. * **Failure Mode 3: Architectural Mismatch:** Using a flexible agent for a task that requires high reliability and predictability (e.g., processing a payment). A rigid, gated workflow is safer. Conversely, using a rigid workflow for an open-ended research task will be too restrictive.

### Common wrong answers * Only talking about a specific framework (e.g., "In LangChain, you create an agent executor...") without discussing the architectural principles or trade-offs. * Ignoring the significant latency and cost implications. A 3-step agent can easily take 5-10 seconds and cost 3x a single call. * Failing to mention debugging complexity. This is a huge real-world problem that senior engineers should be acutely aware of.

### Follow-up the interviewer might ask * "Describe a scenario where a predefined workflow is clearly superior to a dynamic agent, and why." * "How would you design a system to debug an agent that's getting stuck in a loop or consistently choosing the wrong tool?"

### One concrete example "For an e-commerce 'order status' feature, a **workflow** is best. The path is fixed: 1. Get order ID from user. 2. Call `getOrderStatus(order_id)` tool. 3. Format the tool's output for the user. It's predictable and reliable. For a 'help me plan a marketing campaign' feature, a dynamic **agent** might be better. It could use tools like `get_audience_demographics`, `search_competitor_ads`, and `draft_ad_copy` in a flexible sequence. The risk is it might go off-track, but the task's ambiguity requires that flexibility."