Your AI Agent Doesn't Need More Skills. It Needs Hard Gates.

The most useful thing you can give an AI agent isn't a skill that tells it what to do. It's a tool that refuses to do the wrong thing. If your AI setup feels busy but you can't tell whether it's safe, this is usually why: you've built soft guardrails where you needed hard ones.

The standard advice is reasonable on its face. Wire up the MCP servers for the systems you use — Stripe, your CRM, your helpdesk — then write skills: scoped markdown documents that teach the agent your process and your rules. Every vendor recommends some version of this. Plug in the tools, describe the policy, let the model orchestrate.

It works in a demo. It breaks the first time the policy actually matters — and that break is not a rare event. In an October 2025 survey, Gartner found that 45% of martech leaders say the AI agents they've deployed fail to meet their expectations of promised business performance. The gap between the demo and the result is the norm, not the exception.

The refund that should refuse itself

Take a rule of the kind plenty of support teams actually run — the sort that lives in an internal playbook, not the public Help Center: refund a charge only if it's the customer's first-time accidental renewal, and only if it's under $100. Two conditions, undocumented anywhere public. And it's not a niche case: subscriptions are the default B2B SaaS billing model, so most support teams field exactly these small, conditional judgment calls every day.

Now wire it up the recommended way: raw Stripe MCP, plus a skill that explains the rule. What actually happens at runtime? The model reads the policy, looks at the request, and decides. The skill is a soft guardrail — instructions in the prompt the model is asked to honor. A model under context load, or just having one bad generation, can talk itself past instructions. It happens quietly. One hallucination and the agent refunds a $4,000 annual plan for a customer on their third renewal, because in that moment the rule was a suggestion, not a constraint.

That's the core problem with skills as a control mechanism: they're soft gates. They depend on the model choosing to comply, on every single call.

Move the rule into the tool

The fix is to move the rule out of the prompt and into the tool. Instead of a raw Stripe endpoint plus a skill, you build one custom tool — call it refund_subscription — and you encode the guardrail inside it. The tool checks: first-time? under $100? If yes, it refunds. If not, the call fails and returns a descriptive error:

Refused: refunds are limited to first-time accidental renewals under $100. This is the customer's 3rd renewal ($4,000). Not eligible.

The agent doesn't need to know the policy. It doesn't need to be trusted with the decision. It calls the tool blindly, and the tool is the hard gate. If the conditions aren't met, there is no path to the wrong outcome — the function returns an error, and the agent does the only sensible thing left: it tells the human. The support rep working the refund in their AI assistant gets a clear reason, not a silent mistake.

This is the distinction nobody names:

A skill is a guardrail you hope the model honors. A tool is a guardrail it can't get around.

For anything that touches money, customer data, or an irreversible action, you want the second one. The model's job should be to call the right tool — not to be trusted with the policy.

There's a side benefit. Encoding the logic in the tool collapses the agent's cognitive load: it isn't reasoning through a five-step process and a rulebook on every call, it's making one function call. Less context burned, fewer steps, fewer places to go wrong. The process lives in one place you can actually test, instead of being re-derived by a language model on every request.

Fewer skills, not more

So the maturity curve for running operations on AI isn't "write more skills." It's the opposite. It's moving logic out of prompts and into tools, until skills become rare — reserved for the genuinely open-ended work where you actually want the model reasoning freely. Most of what a business calls "operations" isn't open-ended. It's policy-bound and deterministic: these conditions, that action, in this order. That work belongs in tools with hard gates, not in skills the model can rationalize past. (I'll break down exactly why raw MCP servers fall short — context bloat, missing permissions, atomic actions instead of chains — in a follow-up piece.)

It's worth being honest about the incentives here, and this part is my opinion, not an accusation: the companies telling you to plug in more servers and write more skills tend to make money when you use more — more calls, more context, more tokens — not when you achieve the outcome you were after. That's worth keeping in mind before you take any architecture advice at face value, including mine.

The obvious objection: skills are more flexible. True — and that's exactly the point. For open-ended reasoning, flexibility is a feature. For a refund policy, flexibility is the bug. The whole job of an operations control is to be inflexible in the right place.

If your AI setup feels busy but you can't tell whether it's safe, start there: find the soft gates you built where you needed hard ones.

FAQ

What's the difference between a skill and a custom MCP tool? A skill is instructions in the model's prompt — a soft guardrail it's asked to follow. A custom MCP tool is code: it executes the rule, and fails with an error when conditions aren't met. The skill depends on the model complying; the tool doesn't give it the choice.

When should I still use a skill instead of a tool? For genuinely open-ended, complex work where you want the model reasoning freely. For policy-bound, deterministic operations — refunds, approvals, anything with hard rules — encode the logic in a tool.

What happens when a request doesn't meet the rules? The tool call fails and returns a descriptive error explaining why. The agent can't proceed, so it surfaces the reason to a human instead of guessing.