ResearchPilot in Practice: My AI Agent Crashed 5 Times After Going Live — Here's My Reliability Checklist

An AI Agent that ran perfectly fine locally crashed five times in a row after being deployed to production — this isn't a joke, but a real experience of an intern at Valentius Kryptix completing the "Agentic AI Workflow" milestone. The ResearchPilot he developed can autonomously choose among three tools — web search, calculator, and Python code executor — to answer multi-step questions. Everything worked fine in local testing, but when he launched the project using Groq's free API and Vercel, problems came one after another. This article is not another "how to build an AI Agent" tutorial, but a practical retrospective on "how to make an Agent truly reliable."

Why Does It Run Locally but Crash in Production?

The core logic of ResearchPilot isn't complicated: receive a user question, determine whether a tool needs to be called, select the appropriate tool to execute, integrate the results and give an answer. During local development, developers can intervene at any time, retry manually, and the environment is relatively controllable. But once deployed to production, the situation is completely different — APIs have rate limits, servers have timeout constraints, user input is unpredictable, and a public link means anyone can trigger code execution.

The author states frankly in the retrospective: "Building the Agent's logic is only a smaller part of the work. Retry mechanisms, constraints, safety guardrails, and honest testing are what make it reliable." This judgment deserves serious attention from every developer pushing AI Agents into production environments.

LLM Tool Calling (Tool Calling/Function Calling) is a capability of large models: the model no longer directly outputs natural language answers, but instead generates structured tool call requests according to a predefined JSON Schema, which external code executes and passes the results back to the model, which then continues reasoning based on the results. This mechanism allows Agents to break through the boundaries of pure text generation and connect to external capabilities such as search, computation, and code execution. But tool calling isn't always reliable — the model may generate parameters that don't conform to the Schema, omit required fields, or confuse tools across multiple rounds of calls. Therefore, production environments typically need a layer of validation and fault tolerance between the model and the tools, such as parameter validation, automatic retries, and error message feedback — which is also the root cause of the frequent tool calling failures in the original article.

Test with Pass Rules, Not Gut Feeling

The author wrote 25 test cases covering no-tool Q&A, calculation, code execution, search, multi-step tasks, and failure scenarios. For a case to pass, multiple conditions must be met simultaneously: the Agent used the correct tool combination, didn't crash, didn't exceed the tool call budget, the facts were accurate, and the automated judge gave at least 4 points (out of 5).

The first run result was 22/25 passing, an accuracy of 88%. But the author emphasizes that the three failed cases were more valuable than the passing ones — they exposed vulnerabilities in real scenarios. This "pass rules" approach is worth learning from: instead of judging whether the Agent "feels right," measure each execution with quantifiable standards.

Five Production Pitfalls and Fixes

Tool Calls Break Inexplicably

Sometimes the model sends an empty search request with no query terms, and the API rejects it outright. The fix includes three layers: automatic retry with fine-tuned parameters, having tools return clear error messages instead of crashing directly, and explicitly specifying in the prompt that each tool accepts only one parameter. This reminds us that LLM tool calling isn't always reliable and needs engineering-level fallbacks.

Empty Answers Are More Insidious Than Wrong Answers

After search completes, the model sometimes returns a blank message — neither an error nor any content. The current approach is to have the Agent proactively request the model to continue generating, and trigger a retry if it still fails. Empty answers are the most easily overlooked failure mode because they don't trigger any exception alerts.

Time and Tokens Are Hard Constraints

Vercel terminates requests after 60 seconds, and Groq's free plan allows only 8,000 tokens per minute per model. The author's countermeasures are: set a 40-second time budget, compress search results into three short entries, streamline prompts, and configure a backup model to take over when the primary model is saturated. If both models are busy, the page displays a friendly "please wait a minute" message instead of a long string of errors.

The execution time limit of Serverless functions is a hard constraint that must be considered when deploying AI Agents. Vercel's Serverless Functions have a default maximum execution time of 60 seconds on the free/hobby plan (Pro plans can be configured longer), after which requests are forcibly terminated and return an error. Agent-type applications, due to involving multiple rounds of LLM calls and tool execution, often take far longer per request than ordinary APIs. Coping strategies include: setting an internal time budget for the entire workflow (like the 40 seconds in the original article), proactively degrading or returning partial results before the budget is exhausted; splitting long tasks into multiple short requests; or switching to environments that support long-running tasks (such as containers or background task queues). Understanding this limitation helps explain why Agents that run fine locally with no time limit frequently time out after going live.

A Public Agent Is a Security Decision

Anyone with the link can use the online app, which means the code executor must be strictly restricted. The author only allows safe operations and ensures the runtime environment cannot access secrets. But he also honestly notes in the README: this reduces risk but is not a perfect sandbox environment. This kind of honesty is rare in open-source projects, yet it is precisely the responsible approach.

Code execution sandboxing refers to the technology of running untrusted code in an isolated environment, with the goal of preventing code from accessing the host file system, network, environment variables, or secrets. Common implementations include container isolation (Docker), micro-VMs (Firecracker), language-level sandboxes (such as Pyodide, RestrictedPython), and sandbox services provided by cloud vendors. A qualified sandbox should restrict system calls, network egress, and resource usage. The original author only allows safe operations and ensures the environment cannot access secrets, but admits it's not a perfect sandbox — this tiered security awareness is important: for publicly triggerable code executors, the isolation strength should be chosen according to the risk level, and boundaries should be clearly documented to avoid users mistakenly believing it's absolutely safe.

Next Steps: Re-evaluation and Experience Optimization

The 88% pass rate was measured before subsequent fixes, so the author plans to first re-run the evaluation on the current version. After that, he hopes to stream the Agent's every step in real time on the page and cache repeated searches to save token consumption.

Both directions point to the same goal: making the Agent's behavior visible, understandable, and predictable to users. Streaming steps can reduce waiting anxiety, while search caching directly lowers operating costs — for projects relying on free quotas, the latter is especially critical.

Engineering Lessons for Reliable AI Agents

ResearchPilot's story is not an isolated case. It reveals an industry-wide reality: building a demonstrable AI Agent may only take a few days, but making it run stably, safely, controllably, and at an acceptable cost requires several times the engineering investment. Fault tolerance for tool calls, validation of output quality, management of resource constraints, and definition of security boundaries — these "unsexy" tasks are precisely what determine whether an Agent can move from Demo to product.

For teams exploring Agentic AI workflows, this pitfall checklist from an intern project may be more down-to-earth than any framework documentation.

Full project article: https://valentiuskryptix.com/making-an-ai-agent-reliable-is-harder-than-building-it/ Live Demo: https://researchpilot-one.vercel.app/