Advanced Agentic Architecture practice questions

Increase the maximum token output limit for the model.

Why it fails: Increasing token limits provides more space for the agent to continue its current trajectory, which does nothing to interrupt a logical loop. If the model is stuck in a cycle, more tokens simply allow the cycle to repeat more times, increasing costs without solving the underlying planning failure.

Use a secondary model to validate every tool output.

Why it fails: Validating output with a secondary model adds significant latency and cost overhead. While it can catch malformed data, it does not inherently understand the agent's goal-seeking state or the history of failed attempts, making it an inefficient solution for preventing logical loops in agentic workflows.

Lower the temperature parameter to zero for all calls.

Why it fails: Lowering temperature reduces stochasticity, but it does not resolve logic errors or infinite loops. If the model determines that a specific tool call is the correct next step, it will continue to make that same call consistently, regardless of how deterministic the output generation is.

Provide minimal, concise tool descriptions to reduce token usage.

Why it fails: Minimal descriptions often lead to model confusion, especially with overlapping tool functionality. Anthropic models perform significantly better when provided with rich, explicit examples and clear definitions. Cutting tokens here trades off accuracy for negligible cost savings, which is counterproductive for reliable agentic systems.

Randomize tool order in the prompt to prevent bias.

Why it fails: Randomizing tool order does not improve reliability; in fact, it can disrupt the model's ability to maintain context-dependent associations. Models generally handle consistent, well-structured tool definitions much better than shifting schemas, which can confuse the agent's planning process and lead to unpredictable tool selection behaviors.

Rely on the model to infer missing parameters automatically.

Why it fails: Relying on inference for missing parameters is a high-risk strategy that introduces non-determinism. In a production environment, missing parameters should be caught by an explicit validation layer rather than left to chance. Allowing the model to guess often results in incorrect API calls and system-wide downtime.

Hard-code the timeout to 5000 in the tool definition.

Why it fails: Hard-coding parameters bypasses the agent's intelligence and ignores the context of the user request. This creates brittle systems that cannot scale or adapt to varying query complexities, eventually leading to performance bottlenecks when the hard-coded limit is no longer appropriate for specific, larger database operations.

Force the user to manually input the timeout value every time.

Why it fails: Requiring manual input destroys the agent's autonomy and increases the cognitive load on the user. The primary value of an agentic system is its ability to handle technical configuration tasks. Shifting this burden back to the user is a failure of system architecture and design.

Remove the timeout parameter from the tool schema.

Why it fails: Removing the timeout parameter exposes the system to potential deadlocks or long-running processes that could exhaust compute resources. A safe agentic architecture must always include constraints to ensure that no single process can consume infinite resources, regardless of the reliability of the underlying database query.

Increase the number of retrieved chunks to maximize data input.

Why it fails: Adding more chunks increases the risk of including noisy or irrelevant data, which can confuse the model. This is known as the 'lost in the middle' phenomenon, where the model ignores critical info hidden in the middle of long contexts, potentially leading to lower quality responses.

Use a smaller, faster model to minimize hallucination surface area.

Why it fails: Smaller models typically have lower reasoning capabilities and are actually more prone to hallucination when processing complex, unstructured data. They lack the nuanced ability to distinguish between fact and fiction that larger, more sophisticated models possess, making them a poor choice for high-accuracy RAG workflows.

Force the model to always answer using a summary of retrieved documents.

Why it fails: Forcing a summary approach limits the agent's ability to reason over specific data points. If the retrieved documents do not contain the answer, the model will try to summarize irrelevant info, which leads to misleading content rather than a helpful indication that the requested information is absent.

Enable direct agent access to the entire internal service mesh.

Why it fails: Granting an agent broad access is a massive security risk. Agents should always operate behind a principle-of-least-privilege gateway, where the agent only interacts with specific, sanitized tool interfaces. Direct access allows an agent to potentially be manipulated into performing unauthorized actions across the entire network architecture.

Allow the agent to generate and execute its own shell scripts.

Why it fails: Allowing an agent to execute raw shell scripts is extremely dangerous, as it grants the model command-line control over the execution environment. This provides an easy vector for remote code execution if the agent is tricked by a malicious input, making it a critical vulnerability for production.

Performing all actions in parallel to maximize throughput.

Why it fails: Parallel action execution is a performance optimization, not a reasoning pattern. ReAct specifically focuses on sequential reasoning and action, which is incompatible with blind parallel execution. Parallelizing actions without reasoning between them often leads to race conditions and incorrect tool ordering in complex agentic workflows.

Using a fine-tuned model that skips thought processes entirely.

Why it fails: Skipping reasoning processes makes the agent a 'black box' and removes its ability to correct errors. While faster, it sacrifices the planning depth that ReAct provides, making the agent highly unreliable for multi-step tasks where the result of one step dictates the necessity of the next.

Automatically repeating tool calls until a success code is returned.

Why it fails: Blindly repeating tool calls is a rudimentary retry mechanism, not a reasoning pattern. ReAct implies a deliberate, cognitive process where the agent updates its internal mental state based on the success or failure of previous actions, rather than just blindly looping until a desired status is reached.

The tool schema is too large, causing truncation.

Why it fails: Truncation typically causes parsing errors or context window limit errors, not specific 'tool not found' messages. If the schema were truncated, the API would likely return a generic JSON parsing error rather than identifying that the specific tool name is missing from the provided definitions list.

The model lacks sufficient reasoning capabilities for this tool.

Why it fails: The model's reasoning capacity does not affect its ability to read the provided tool definitions. If the tool is in the schema, the model should see it. The error indicates a mismatch between the agent's output and the server's validation, which is a structural issue, not a reasoning one.

The agent is experiencing a 'hallucination' of the tool name.

Why it fails: While it is a hallucination of sorts, the architectural issue is why the model believed the tool existed. This usually happens when old tool definitions persist in the conversation history, causing the model to believe a previously valid tool is still available when it has been removed from scope.

Include full historical chat logs in every API call.

Why it fails: Including the entire chat history in every call causes 'token bloat,' which drastically increases inference time. A well-architected system should use a sliding window or summary-based approach to history management, ensuring only the most relevant context is sent to keep token counts manageable and response speeds fast.

Require the agent to explain its thoughts before every action.

Why it fails: While reasoning is helpful for accuracy, it adds significant token volume and latency to every turn. If speed is the priority, you must balance reasoning depth against response time. Forcing reasoning on trivial tasks is an architectural mistake that degrades the user experience by increasing wait times unnecessarily.

Granting all agents full read/write access to the central task database.

Why it fails: Granting universal access creates significant security risks and race conditions. If multiple agents modify the task state simultaneously without proper isolation, the integrity of the system state is compromised. Principle of least privilege should be applied to ensure agents only access data necessary for their specific tasks.

Merging all agents into a single massive prompt to reduce latency.

Why it fails: Consolidating agents into one prompt degrades performance due to increased instruction noise and cognitive load on the model. Specialized agents with focused prompts perform significantly better than a single generalist model trying to manage every sub-task, which often leads to poor reasoning and increased hallucination rates.

Bypassing intermediate validation to prioritize speed of execution.

Why it fails: Skipping validation is dangerous in agentic workflows as errors can cascade rapidly. Without intermediate checks, an incorrect decision by one agent will propagate to all subsequent tasks, leading to systemic failure. Validation is the primary mechanism for containment and ensuring high-quality outputs throughout the reasoning process.

Increase the max_tokens parameter to 8192 to provide more space.

Why it fails: Increasing token limits does nothing to improve tool selection logic. The issue is likely a semantic mismatch between the user prompt and the tool description. Adding more token space will not help the model if it already lacks clear instructions on how to prioritize specific tools during reasoning.

Add more tools to the list to give the model more options.

Why it fails: Adding unnecessary tools increases the 'noise' in the model's context. This makes it harder for the model to distinguish between relevant and irrelevant capabilities, leading to more frequent tool selection errors. You should minimize the tool set to only those necessary for the agent's core mission.

Switch the model to a version with a larger context window.

Why it fails: Changing the model version is unlikely to resolve a tool selection issue caused by ambiguous instructions. The problem is a lack of clarity in the system prompt. Optimization of the prompt instructions and providing examples is the standard architectural fix for improving tool-use performance in production systems.

Using a larger embedding model to capture more nuances.

Why it fails: While better embeddings help, they cannot solve the fundamental issue of a query that covers too many topics. A single embedding vector for a complex query will always lose precision. Query decomposition is a structural architectural fix that works regardless of the specific embedding model being utilized.

Increasing the number of top-k chunks retrieved.

Why it fails: Retrieving more chunks often increases noise rather than precision. If the initial query is misaligned, more data only makes it harder for the model to synthesize the correct answer, leading to more hallucinations. Precision should be improved through better query formulation, not by adding larger quantities of context.

Moving to a keyword-based search instead of vector search.

Why it fails: Keyword search lacks the semantic understanding required for modern agentic RAG systems. While hybrid search is often a good strategy, abandoning vector embeddings entirely will significantly decrease the agent's ability to interpret intent. The issue is query-side formulation, not the underlying search technology's ability to handle semantic space.

The tool's description is too short for the model to understand.

Why it fails: Short descriptions rarely cause a total failure to execute. The model has already decided to call the tool ('tool_call' is present). The problem is not the model's knowledge of the tool, but the failure to properly bridge the gap between the thought and the action execution engine.

The temperature is set too low for complex tool execution.

Why it fails: Temperature has no impact on the execution layer. The model has already generated the tool call. The issue is with the system's ability to trigger the function. Lower temperature actually makes it more likely the agent will output the correct, consistent JSON format for the tool call.

The model version is not capable of tool calling.

Why it fails: Most modern LLMs are perfectly capable of tool calling. The issue is almost certainly architectural—a failure in the glue code between the model's output and the tool executor. Before blaming the model, verify the architecture that handles the transition from natural language output to function execution.

Increasing the temperature to 1.0

Why it fails: Increasing temperature makes the model more random and creative, which is likely to make it *less* predictable in its tool usage. It does not provide any structural constraint that would force the model to use a tool when it thinks it already knows the answer to a user's question.

Adding more examples of tool use in the prompt

Why it fails: While few-shot examples can encourage tool use, they are still 'soft' constraints. The model may still choose to ignore the examples if its internal training strongly suggests a direct answer is better. Only the 'tool_choice' parameter provides a 'hard' constraint that the API enforces at the generation level.

Decreasing the 'max_tokens' limit

Why it fails: Reducing 'max_tokens' simply cuts off the model's response after a certain point. It does not influence the content or the logic of the response. If the model starts to answer from its own knowledge, a low token limit will just result in a truncated direct answer, not a tool call.

Implement a shared long-term memory vector database for all agents.

Why it fails: Shared vector memory facilitates information retrieval but fails to enforce process control or state constraints. Without a governing agent or state machine, agents can still enter infinite feedback loops regardless of the data stored in the vector database, making it insufficient for preventing task drift or logical recursions.

Increase the temperature setting of the Planner agent to promote creative task delegation.

Why it fails: Increasing temperature increases stochasticity, which is counterproductive when attempting to stabilize an agentic workflow. Higher entropy makes the decomposition process less predictable and more prone to logical errors, further exacerbating the risks of recursive loops and objective drift rather than providing the necessary guardrails for complex task execution.

Use a sequential chain-of-thought prompt without feedback loops.

Why it fails: Sequential chain-of-thought is useful for simple linear reasoning but lacks the feedback mechanisms required to detect and stop recursion. Without a mechanism to evaluate the output of each step against a goal, the system is blind to the drift occurring within the reasoning process, leading to potential failure.

Continuously summarize the entire interaction history into a single long string.

Why it fails: Continuous summarization of all history leads to significant information loss over time. Important details are often dropped during the compression process, making the agent incapable of accurate retrieval later. While useful for memory management, it cannot be the sole mechanism for high-precision tasks, as it lacks granular data access.

Implement a sliding window buffer that only keeps the last 50 turns.

Why it fails: A sliding window approach inherently discards older information, which is catastrophic for tasks requiring long-term state consistency. If an agent needs to recall an instruction from turn 51 in a 200-turn workflow, a sliding window will have already deleted that context, leading to incoherent reasoning and failure of long-term goals.

Use models with larger context windows to avoid managing memory entirely.

Why it fails: Relying on larger context windows is inefficient and costly. Even with massive windows, latency increases and retrieval accuracy can degrade as the model is forced to process vast amounts of irrelevant tokens. Architecture should prioritize lean, purposeful context to maintain speed and cost-efficiency regardless of the underlying model's capacity.

Configure the agent to automatically retry the request every second until it succeeds.

Why it fails: Aggressive retrying ignores the 'retry_after' signal, potentially worsening the rate-limiting situation and leading to a complete ban from the service. Retries must be respectful of the provider's limits, using exponential backoff or the suggested delay to maintain a stable and compliant connection to external APIs.

Ignore the error and log it, then terminate the agent's current task.

Why it fails: Terminating the task is an unnecessary disruption to the user. A transient error like a rate limit should be handled by the system's infrastructure. By failing the entire task, the system lacks the intelligence to recover from common, expected network conditions, leading to an unreliable and fragile user experience.

Increase the concurrency of the orchestrator to process more requests.

Why it fails: Increasing concurrency during a rate-limiting event will cause the error rate to climb even higher, leading to immediate system-wide failure. The orchestrator must adapt by decreasing load, not increasing it, to allow the target API time to recover and to keep the agentic workflow functioning within limits.

Use a simple 'last response only' logging strategy to save storage costs.

Why it fails: Logging only the final output provides zero insight into the reasoning process, making debugging impossible for multi-step agentic workflows. You cannot troubleshoot failures if you don't have access to the intermediate chain-of-thought, which is where the vast majority of agent errors occur during complex problem-solving tasks.

Rely solely on user feedback for identifying errors in the agent's logic.

Why it fails: User feedback is a lagging indicator and often lacks the technical detail required to fix systemic issues in agent reasoning. A professional architecture must provide proactive observability tools that allow developers to catch and fix issues before they impact the user, rather than relying on reactive reporting from end-users.

Force all agents to log to a single shared file for easier grep searching.

Why it fails: A single shared file becomes a bottleneck and is impossible to parse in high-concurrency production environments. Structured, indexed logging (like JSON logs in an ELK stack) is necessary for performance and searchability. Using a single flat file is an anti-pattern that fails to scale with the complexity of agentic systems.

System prompts are cached globally, reducing latency to zero.

Why it fails: While system prompts might be cached at the API layer, they do not reduce latency to zero. The primary advantage is architectural separation of concerns and safety, not performance optimization. Claims of zero latency are technically inaccurate in distributed LLM architectures due to network and inference overhead.

User messages can be easily ignored, while system prompts cannot.

Why it fails: The model does not ignore user messages; it considers all provided context. The benefit of system prompts is that they define the 'ground truth' of the agent's behavior, which is harder for a user to override during a conversation than instructions placed inside the user message buffer.

It is the only way to enable tool-use capabilities.

Why it fails: Tool-use capabilities are enabled via the API's tool configuration, not solely by the system prompt. While the system prompt can describe how to use tools, it is not the mechanism that registers the tools with the model; tool schemas must be provided through the dedicated parameter structure.

Keep the connection open to avoid re-initializing the agent.

Why it fails: Holding a connection open for an indefinite human-in-the-loop wait is highly inefficient and risks timeouts at the networking or infrastructure layer. It is better to terminate the process and persist the state, allowing for horizontal scaling and better management of resource usage during human decision-making periods.

Store the state only in the client-side browser memory.

Why it fails: Client-side storage is insecure and unreliable. If the browser refreshes or the session times out, the entire agent state is lost. For production-grade agentic architecture, state must be managed on the server side to ensure persistence, auditability, and recovery across different devices or user sessions.

Retry the tool call periodically until the human responds.

Why it fails: Retrying is completely incorrect; it wastes API credits and resources while creating a noisy log. A proper HITL architecture should have an explicit 'pause' state that stops the execution flow until a specific trigger—the human approval—is received, rather than attempting to force the system to continue.

Increase the context window size of the model indefinitely.

Why it fails: Increasing the context window does not solve fragmentation; it only delays the problem while increasing cost and latency. Larger windows don't automatically improve the model's ability to prioritize relevant past information, making this an expensive and ineffective band-aid that fails to address the underlying architectural issue.

Force the user to clear their history periodically.

Why it fails: Forcing the user to manage their own history is a bad user experience and defeats the purpose of an autonomous agent. The agent should be architected to handle its own memory management automatically, providing a seamless experience that feels like a continuous, intelligent conversation without user intervention.

Only use the most recent 10 messages of the history.

Why it fails: Using a strict, small window size often leads to the loss of critical context from earlier in the conversation. This causes the agent to repeat mistakes or forget foundational instructions, making it ineffective for complex tasks that require maintaining a long chain of reasoning or context.