What Makes a Good Agent Ability

Ask someone what ability they'd want to give their agent, and the answer usually comes back in one of two shapes. Either it's enormous — "write my code," "run customer support," "handle my finances" — or it's so narrow it barely sounds worth building — "check today's exchange rate," "look up a shipment." The first kind can't actually be installed as one thing. The second kind is a real ability, just not one that changes how a business runs. The interesting answer sits between the two, and it has a specific shape once you go looking for it.

"Coding" is the clearest example of the too-broad answer. It sounds like one ability, but it's a bundle of wildly different-risk operations wearing one name — reading a file is nothing, writing one is something, running a test suite is mostly nothing, running an arbitrary shell command is everything. A loopengine ability is a tool, a skill teaching the model when to reach for it, and an actauth rule gating it — and a permission rule only means something if it answers a specific question. "Allow coding" isn't a gate, it's a shrug. "Read access to an agent's own tools directory, ask before any write outside a session's scratch space" is. The broad version doesn't install as one ability because it was never one ability.

The narrow end has the opposite problem. Summarizing today's sports results is a real, buildable ability — one tool to fetch the scores, one skill for telling a recap request from a live-score request, one actauth rule (read-only, always auto-allowed, nothing to gate). It's clean by every definition of the format, and also not the kind of thing anyone builds a business around. Most honest answers to "what ability do you want" land closer to this than people realize — it just feels safer to say, because it's obviously installable.

The answer worth actually giving sits where both problems cancel out: narrow enough that the permission rule is specific, consequential enough that the specific rule matters. Look up an order and its shipment status — narrow, one API shape, and it's the tool a support agent reaches for fifty times a day. Restart a service — narrow, one command, one target — and getting its gate wrong (auto-allow, in production) is the kind of mistake that ends up in a postmortem. Issue a refund — narrow, and it matters for the obvious reason: it moves money. None of these are "run my business." All of them are things a business already does, over and over, where the real question was never "can an agent do this" — it's "who has to say yes." These three aren't hypothetical, either — they're the exact abilities behind loopengine's own customer-service, incident-triage, and expense-approval scenarios, each one live-verified end to end.

That's also the test for whether something is worth packaging as an ability at all, not just worth having: if the permission rule you'd write for it doesn't tell you anything you didn't already know, it's not an ability, it's a plain function. And if the rule can't be written as one rule — if the honest answer is "depends which part of this you mean" — it's not one ability, it's several wearing a trenchcoat.

The abilities published so far are deliberately on the unglamorous side of that line — a web search chained across a few providers, a fetch tool with an SSRF guard, a local docs index. None of them move money or restart anything, which is exactly why none of them needed a real answer to "who has to say yes." The ability behind your refund, your restart, your reimbursement does — and it's no harder to build: `loopengine add-ability <spec> --agent <name>`, and the tool, the skill, and the rule land as real files in your own repo, one unit, ready to review before anything runs. What's the one you'd write first?