Rules are an agent's best friend

There’s a quiet argument going on inside every team trying to put agents into production. It looks like a question about technology, but it’s really a question about trust.

The argument is whether to use rules or agents.

One side says: if you have rules, you don’t need agents — agents are just slow, expensive, non-deterministic ways to do what if/else already does. The other side says: if you have agents, you don’t need rules — agents can read the situation, weigh the options, and decide. Rules are training wheels.

Both are wrong. And the way they’re wrong matters, because if you build an ops platform around either premise, you end up with a tool that nobody trusts in production.

The truth is the more useful one: rules and agents are complements, not substitutes. They balance each other. Rules give agents rails. Agents give rules judgment. A team that has both has something neither side has alone.

This post is about why that’s the design choice underneath Ekso’s MCP surface, and what it looks like in the rule tool specifically.

What rules are good at — and what they aren’t

Rules are deterministic. If the ticket has been open for 24 hours, escalate to the on-call. That logic runs the same way every time. It runs cheaply. It runs without an LLM. It runs while the agent is asleep, while the API is rate-limited, while the model provider is having an outage. If the rule fires, the rule acts. If it doesn’t, it doesn’t.

That predictability is what compliance auditors want, what on-call engineers want at 3 a.m., and what budget owners want when they have to defend the bill.

But rules have a ceiling. They’re brittle on the edges. If the customer’s email contains the word “urgent”, flag as P1 fires for the customer who is genuinely on fire and also for the one whose subject line happens to say “I urgently need to update my mailing address”. The rule can’t tell the difference. You can pile more conditions on, but every condition is a guess at the future, and the future has more shapes than your rule can hold.

Rules are sharp where the world is sharp. They go blurry where the world is blurry.

What agents are good at — and what they aren’t

Agents are the inverse. They’re non-deterministic. They read context. They weigh things a rule can’t easily express. Is this customer email actually urgent, given they’ve already raised three tickets this week and one of them is open? An agent has a view that a WHERE subject LIKE '%urgent%' clause never will.

But agents wobble. The same prompt produces slightly different answers on different days. They’re slower than rules. They’re more expensive. They sometimes hallucinate. They sometimes get talked into things by clever inputs. And — most importantly — they don’t have authority you’d want them to have without a check.

Agents are great where the world is blurry. They go wrong where the world is sharp and the answer needs to be the same every time.

The complementarity

Once you’ve named the two correctly, the design falls out.

You let rules handle the unambiguous cases: scheduled triggers, threshold-based escalations, well-defined state transitions, known-bad patterns, regulatory must-dos. Anything where you can write the rule down and your auditor would nod.

You let agents handle the ambiguous middle: classification calls that hinge on context, summarisation, drafting, suggesting, routing where the org chart isn’t a tree, “is this email asking about billing or about a feature.” Anything where the answer is “it depends” and the dependence is too rich to enumerate.

And then — this is the bit most teams miss — you let them work together. Rules pre-classify so the agent’s prompt is shorter and more grounded. Agents propose actions that rules then validate before they happen. Rules catch the cases the agent shouldn’t be near. Agents catch the cases the rule wasn’t written for. Each one’s strength is the other one’s weakness, which is exactly what you want from a partnership.

How this shapes the rule MCP tool

When we shipped the rule tool to the Ekso MCP server, we had a choice: do we let agents create rules, or only read them?

We chose read. The tool ships with two calls:

get_rule_list      — list all automation rules in the tenant (read-only)
add_endpoint_action — attach a webhook-style POST action to an existing rule

That’s it. There is no create_rule. No update_rule. No delete_rule. An agent connected to an Ekso tenant can ask “what rules are running?”, can see what they trigger on, can attach an external receiver — but it cannot author a rule.

This looks like a limitation. It is, on purpose. Here’s the reasoning.

A rule is a piece of authored intent. We always escalate after 24 hours. We always tag finance work to the project owner. We always notify on-call when the queue exceeds 50. These are decisions the team has made and committed to. They have meaning beyond what’s in the ticket of the moment. They’re often shaped by compliance, by service-level promises, by hard-won lessons from past incidents.

Letting an agent author them — even a careful agent, even with approvals — moves the seat of authorship away from the humans who own those commitments. The agent might write a fine rule. It might also write one that subtly drops a regulatory obligation off the back. It might re-introduce a rule the team killed last quarter for a reason it doesn’t know about. The cost of an agent-written rule going wrong is much larger than the cost of an agent-written ticket going wrong, because rules persist and apply to everything that comes after them.

So the agent doesn’t write rules. The agent reads them, understands them, and acts in the rails they create.

The add_endpoint_action call is the one place we lean the other way — and it’s deliberately narrow. An agent can attach a webhook to an existing rule, so when the rule fires, an external system gets a POST. That’s how an agent extends what a rule does without redefining what the rule is. The trigger stays human-authored. The reach is what gets extended.

What this gives you, in practice

The rule tool is the foundation, but the same logic plays out across the rest of the Process & Workflow cluster — process, constraint, clock, notification. Each one is something a human admin authors. Each one is something an agent reads and operates within.

When an agent goes to move an item from “in review” to “done” and a constraint says no — items can’t move to done while their sub-items are still open — the agent doesn’t get to argue. The constraint is the contract. The agent reads the rejection, surfaces the issue, and either resolves it or escalates. That’s the pattern.

This is why “rules are agents’ best friends” is more than a slogan. The team that authored the constraint isn’t fighting the agent. The constraint is what lets the agent be useful in production, because it’s the floor under everything the agent does.

Without the floor, every agent action needs a human in the loop, every time, because nobody knows what could go wrong. With the floor, the loop only needs to engage when the floor itself is at risk — which is far rarer, and far easier to staff for.

The takeaway

If you’re building agents into how your team operates, don’t treat your existing automation rules as legacy you need to migrate away from. Treat them as the deterministic backbone the agent leans on.

Write rules for the things that should always happen the same way. Let agents do the things where context decides. Then let them work together — agents drafting and proposing, rules catching and constraining, humans approving the calls that need a human.

The teams that get this right end up with something neither side wins on its own: a system that’s both predictable enough to run and intelligent enough to be worth running.

Sharp where the world is sharp. Smart where the world is blurry. That’s the pairing.

---

Want to see the rule MCP tool in action? It’s documented at ekso.dev/mcp-tools/rule. The whole MCP surface starts at ekso.dev/mcp-tools/introduction.

If you’re new here, the launch post — Operations is going AI-native. Most tools aren’t. — sets up why we built Ekso headless-first in the first place.