An LLM agent that demos well and an LLM agent that survives production are almost different projects. The demo needs the happy path. Production needs everything else. Here are the five guardrails we put on every agent we ship, the ones that decide whether it's an asset or an incident.
1. Bound what the agent can actually do
The single biggest mistake is giving an agent broad tool access "so it can figure things out." An agent that can call any endpoint eventually will call the wrong one. Give it the smallest set of tools that covers the task, with typed inputs and server-side validation on every call. The agent proposes, your code decides whether the action is allowed. Treat every tool call as untrusted input, because it is.
2. Put a human in the loop on high-stakes actions
Not everything needs approval, that kills the point of automation. But irreversible or regulated actions do: moving money, sending an external communication, changing a record that has downstream consequences. Draw a clear line: below the threshold, the agent acts; above it, it drafts and a human confirms. Make the threshold explicit and configurable, not buried in a prompt.
3. Build an eval harness before you build features
"It worked when I tried it" is not a test. Before you add capabilities, build a set of real cases with known-good outcomes and run the agent against them on every change. Without this, you can't tell whether a prompt tweak improved things or quietly broke three other flows. The eval harness is what turns agent development from vibes into engineering, and it's what you show a stakeholder (or an auditor) who asks "how do you know it works?"
4. Make it observable, you can't debug what you can't see
An agent that acts needs a trace of why. Log every step: the input, the reasoning or tool selection, the tool result, the final action. When something goes wrong in production, and it will, a full trace is the difference between a five-minute fix and a two-day mystery. Bonus: those traces become your next eval cases.
5. Fail safe, not silent
Agents fail in ways deterministic code doesn't: a tool times out, the model returns garbage, a step loops. Decide in advance what happens then. The wrong answer is "return whatever it produced." The right answer is graceful degradation: retry with backoff, fall back to a simpler path, or escalate to a human with the context already gathered. A production agent should be boring when it fails, not creative.
The pattern underneath
None of this is exotic. It's the same discipline you'd apply to any system that acts on real data, least privilege, tested changes, observability, safe failure, applied to a component that happens to be probabilistic. The teams whose agents survive production aren't the ones with the cleverest prompts. They're the ones who treated the agent like production software from day one.
If you're building agents that have to hold up in a real business, with the integration and guardrails that implies, that's the work we do at Levitation.
Top comments (0)