What it takes to let an agent take action in production

If a guardrail is working, you never hear about it. Hearing about one means something upstream already went wrong.

What are agent guardrails?

Guardrails are the constraints that hold when the agent behaves in a way nobody predicted. You can only anticipate so much of how a model will act inside a live system, so guardrails exist to make sure that in the situations you did not foresee, the agent cannot do something destructive.

They are deliberately not the mechanism that makes the agent good. They are the mechanism that bounds what happens when it is not.

What is the difference between evals and guardrails?

Evals make the agent predictable. Guardrails contain it when the predictability fails.

The analogy that holds is hiring an engineer. Evals are the performance review and the training, the work you do to make sure someone knows what to do in a given situation and does it well. Guardrails are the access controls, which exist regardless of how good the engineer is, because competent people still occasionally do the wrong thing.

The order matters for how the system gets built. Guardrails are deterministic, and deterministic systems do not scale well as the space of possible situations grows. The investment goes into evals and model quality so that the guardrails rarely have to fire. As models improve, guardrails should stay in the role of a boundary rather than becoming the thing that tells the agent how to behave.

What limits what an agent can do in your environment?

The ceiling is the access of the user it is acting for. Resolve AI's access to a customer's system is bounded by what that user already has, and a user cannot click a button to execute an action they do not independently have the right to perform.

This is why role-based access control underneath the agent matters more than it might appear. Without well-defined access layers you end up in gray areas where the agent had access to something the person did not, and there is no clean answer about what should have happened.

What gets recorded when an agent takes an action?

All of it, attributed to both parties. An agent executing changes in a production system without a record is not an acceptable design, because when something breaks the organization has to be able to account for it. Resolve AI operates as its own identity within the customer's system, and when a user approves an action that Resolve AI suggested, the record ties the action to both the agent that proposed it and the person who approved it.

Can guardrails be configured per customer?

Yes, and the two types behave differently. Deterministic guardrails are the hard limits, the actions that are simply not permitted, and these are the ones a customer can most directly adjust. A team that does not want the agent auto-executing any action can turn that off.

The other type is AI-based and shaped by the knowledge and customer artifacts the agent works from, which is what makes it act the way that organization's own engineers would. Customers influence this layer too, but it is nondeterministic, which makes it best-effort rather than a hard boundary. Treating those two layers as if they offered the same guarantee is a mistake.

Why does explainability matter as much as access control?

Because knowing who took an action is not sufficient when you need to know why. An audit log that records the action and not the reasoning still leaves the system a black box, which is tolerable right up until something goes wrong, which is exactly when it stops being tolerable.

The standard is the one applied to people. When an engineer makes a call, good or bad, you expect them to explain what they were reasoning from. Agents should be held to the same accountability. With Resolve AI, an investigation or action can be interrogated after the fact to surface what the agent saw and why it decided what it did.

How do guardrails hold up when a new model ships?

Every model release moves the line between efficiency and safety, and the question is how deliberately an organization moves with it. A new model makes more things possible, which creates pressure to expand what the agent is permitted to do.

Resolve AI's position is that safety comes first in the ordering and efficiency follows, rather than the two being traded against each other. Because the change is measured through the eval infrastructure, moving that line is a slow and deliberate decision with evidence behind it rather than a reaction to a release.

Why is an internally built tool likely to have weaker guardrails?

Because internal tools are usually scoped as internal, and the safety thinking gets sized accordingly. When everything stays inside the organization, the pressure to formalize the boundaries is lower, and the guardrails end up less considered than the functionality they surround.

That gap widens over time rather than closing. Each new model release moves the efficiency and safety line again, and a team maintaining an internal tool has to re-answer where they stand on every one of those releases, without the measurement infrastructure that would tell them whether the answer was right.