The feature we are proudest of this week is a refusal. Not a faster conversion, not a longer list of supported formats — a plain-language answer, raised before any work begins, that says: this operation would make your file bigger, so we are not going to do it.
That sentence sounds like a small thing. It took longer to agree on than half the features shipped this quarter at UglyPear Data, and we think it says more about where everyday tools are heading than anything else on the changelog. So here is the story, and the lessons we would hand to anyone building tools that get called from a conversation.
The behavior we shipped
When someone asks their assistant to convert an image into a different format, SmartSlim now checks what the converted file would look like before doing anything. If the target format would inflate this particular image — and some images genuinely grow when re-wrapped — the tool stops, explains why in one sentence, and offers what would actually help: keep the current format and compress in place, or leave the file untouched.
No pretend success. No "task completed" for a job that made things worse. And no cryptic error code either. The request gets an honest answer, in language a person can act on.
The internal debate was about whether we should just run the conversion anyway and report the resulting size. Let the user decide, the argument went. But think about what "let the user decide" means when the request arrives as a sentence in a conversation: the user asked for a smaller, cleaner file, in the reasonable belief that a conversion would produce one. Handing back a bigger file with a cheerful status is not a decision point. It is a trick. The honest move is to surface the surprise before it happens, not after.
Why "success" was the wrong goal
Most file tools are built around a completion model of success: did the process run to the end without an error? By that standard, a conversion that swells a two-megabyte image into nine megabytes is a triumph. The job ran, nothing crashed, everyone goes home.
Users are running a different program in their heads. They wanted a file that is easier to store, send, or feed somewhere. When a tool reports success and delivers the opposite, it does not merely fail — it fails while claiming to have helped, which is the most expensive failure mode there is. A clean failure costs seconds: read the message, adjust, move on. A fake success costs the difference plus the hunt to discover there was a difference, plus a permanent suspicion that now attaches to every future result.
Once you accept "the user is better off" as the definition of done, refusals stop being edge cases and become a natural part of the interface. Sometimes the correct output of a tool is a sentence explaining why the tool should not run.
What tool-calling changes about responsibility
Everyday file work is migrating into conversation. You tell an assistant what you want done; the assistant calls a tool; the tool does the work. compress-mcp is our layer for exactly this pattern — the assistant speaks, the engine acts, and the pieces are laid out on the products page.
Something structural changes in that flow, and it is behavioral more than it is technical. When a person drives a tool by hand, they watch the dials. They see the output size, they notice when a file gets bigger, they can hit undo. When the tool is invoked from a conversation, nobody is watching the dials. The user has delegated not just the labor but the vigilance.
That delegation transfers responsibility. If a conversational tool converts an image into something larger and reports a cheerful success, the user may never find out — and the harm lands silently, in their storage, their transfers, their costs. A tool that acts on your behalf has to act with your judgment. Which means it needs the ability to disagree with the request, out loud, in words, before it pushes your file through a transformation you did not actually want.
We think this is the part most tool builders have not absorbed yet. In the old model, a tool was a lever: pull it, something happens, you watch. In the new model, a tool is a deputy: you state an outcome, and the deputy decides how — and whether — to proceed. Nobody would accept a deputy who never says no. We should not accept tools like that either.
And the range of work flowing through this pattern keeps widening. Receipts that need flattening before expense season. Scanned forms a department wants made sendable. Screenshots destined for documentation. Folders of recorded sessions nobody has the storage budget for. Each of these used to be an errand with its own app, its own menus, its own waiting. In the conversational model they are all sentences, which is precisely why the judgment inside the tool matters more with every month that passes. When the tool was a lever, a bad outcome was visible. When the tool is a deputy, the deputy's judgment is the whole safety story.
The governance angle nobody budgets for
Here is the number that should reorganize every roadmap in this space. IBM's Cost of a Data Breach research found that one in five breached organizations traced the incident to employees using unsanctioned AI tools — the pattern now called shadow AI — and that those breaches cost on average $670,000 more than the rest. Meanwhile, 63 percent of breached organizations have no AI governance policies at all.
Read those figures together and the lesson is uncomfortable. The risk is not that people will start using AI to handle work. They already do, and they will keep doing it, because it is faster. The risk is that the tools they reach for behave unpredictably — acting when they should not, on data they should not touch, with no way to inspect what happened.
For tool builders, this reframes what "safe" means. Safety is not a permissions page that nobody reads. Safety is a tool that behaves the same way every time, refuses predictably and explainably, and never trades the user's interests for a completed transaction. Predictable tools are what make assistant-driven workflows governable in the first place. An organization cannot write a policy about a tool that lies to its users; it can write one about a tool whose refusals are consistent and whose reports are true.
Five lessons from shipping a refusal
- Model the outcome, not the input. Check what the file will become, not merely what it currently is. A conversion can be mechanically valid and practically harmful at the same time, and only the second fact matters to the user.
- Refuse early, in plain language. A refusal that arrives after the work is done is not a refusal; it is an apology. The most useful moment to stop is before the first byte moves.
- Make every refusal actionable. "No" without a next step is a dead end. Ours names the alternatives: keep the format and compress in place, or leave the file alone. The user should exit the conversation knowing more, not less.
- Redefine done. "The process completed" is not success. "The user is better off" is. Audit your tool's outputs against the second definition and you will find the places where it currently pretends.
- Report reality, not activity. Say what happened to the file, in terms of the file — sizes, before and after. If the number went the wrong way, say that too. Users forgive honest numbers; they do not forgive cheerful ones that are wrong.
Speed is table stakes; direction is the product
None of this means performance stopped mattering. Our engine processes a 443-page OFD document end to end in 124 seconds, and compressed images cut token cost by roughly 85.9 percent against a GPT-4o baseline — numbers that matter to anyone feeding documents to models at any scale. But throughput is the price of entry, and it is the same price everyone is paying. The direction of the tool — whether it reliably moves the user's work forward or merely spins — is the part that has not been commoditized.
An engine that runs fast in the wrong direction is just an efficient way to lose. The refusal feature changed nothing about our speed. It changed the sign of the value we deliver: from "it finished" to "it finished, or it stopped, and either way you can believe it."
What we would tell other builders
If your tool will be called from a conversation — and increasingly it will — spend a sprint on its no before you spend another on its yes. Walk through every operation the tool performs and ask: what should happen when this would hurt the user? Where does the tool currently pretend? Each of those places is a future support ticket and, if the IBM numbers hold, potentially a line item nobody wants to see.
The tools people will trust with real work are not the ones that never refuse. They are the ones whose refusals you can count on — and whose yeses therefore mean something.
FAQ
Q: When exactly does the tool refuse an operation?
A: Before anything runs. SmartSlim predicts what the output file would look like — for a format conversion, whether the image would grow in the target format. If the operation would work against the goal you stated, you get one plain sentence explaining why, plus the alternatives: compress in the current format, or leave the file as it is.
Q: Why not simply run the conversion and let the user judge the result?
A: Because the request arrived as a sentence, the user already stated their goal: a smaller, cleaner file. Handing back a larger file with a success message makes them do the vigilance work they delegated. Stopping early with an explanation respects the request; a cheerful status on a worse outcome does not.
Q: Is a tool that refuses still fast enough for real workloads?
A: Refusal costs nothing in throughput. The same engine compresses a 443-page OFD document end to end in 124 seconds, and compressed images cut token cost by about 85.9 percent against a GPT-4o baseline. Saying no to one file costs a sentence; saying yes to everything else costs the same seconds it always did.
Q: How does honest tool behavior relate to shadow AI risk?
A: IBM's research links shadow AI to breaches costing $670,000 more on average, and finds 63 percent of breached organizations lack AI governance policies. A tool that refuses predictably and reports truthfully is one an organization can actually write a policy about — predictability is the precondition for governance.
Q: Where should a builder start if they want to design refusals?
A: Audit every operation the tool performs and ask what should happen when it would hurt the user. Then redefine done as "the user is better off" rather than "the process completed," and report outcomes in the file's own terms — sizes before and after, including when the number went the wrong way.
Try it now
If you would rather trust a tool's no as much as its yes, the pieces are ready to examine. The overview lives at https://www.uglypear.com/en/ , the products — including SmartSlim and the compress-mcp layer that lets an assistant drive it — are listed at https://www.uglypear.com/en/products/ , and we write regularly about tool behavior and honest automation at https://www.uglypear.com/en/blog/. Try the refusal yourself: ask for a conversion that would backfire, and see what comes back instead of a success message.