AI agents that prove the action landed

An agent that only answers is a chatbot. An agent that acts changes something you care about: it sends the message, moves the record, issues the refund, books the slot. The moment it can do that, the interesting question stops being how clever it is and becomes how you know what it actually did.

That is most of the job. Bles Software builds agents that run against live systems, and the time goes almost entirely into the parts around the model: what the agent is allowed to touch, what it does when an API refuses, and how each action is read back from the destination before anyone calls it done.

What you can check about us before you ever talk to us

Bles Software has run its own AI operator, Teleclaudious, in production for 27 months: 14 months on the first version and 13 months and counting on the current one. Founded 2021 in Yehud Monosson, Israel. 4.9 out of 5 from 9 verified client reviews on Clutch.

Every number on this page names where it came from, and the ones that live outside our walls link straight to the public record. If a claim here cannot be checked without asking us, it should not be here.

The checklist a buyer should hold every agent vendor to, and our answer to each

A real production agent with measurable outcomes. Ours is Teleclaudious, the operator that runs our own company: 27 months live across two versions. It is not a case study we wrote, it is the system that books our meetings and files our invoices while you read this.

Evals before deployment and after every change. Every agent we ship carries a regression suite over recorded real turns, and a change that lowers the score does not go out. We run the same loop on our own operator, which is why a 27 month run is possible at all.

Explicit tool permissions, not open access. An agent gets the specific calls its job needs and nothing else, and consequential actions route to a human first. The default is refusal, so a new capability is a decision somebody made rather than a side effect.

Audit logs that say what the agent did and why. Every action writes an immutable receipt from the provider that performed it. We learned why this matters the hard way: on 30 August 2026 our own integration logged three social posts as published that did not exist, because a success line was written from intent instead of from a receipt. A publish log is a record of an intention. Only the provider receipt is evidence.

Failure, retry and idempotency, plus model fallback and monitoring. Retries are keyed so a repeat cannot double-charge or double-send, model routing falls back when a provider degrades, and the whole thing deploys into your cloud with your team owning the code. You get a 59 day path to a full deployed version, not a proof of concept that stops at the demo.

"Sent" is not a receipt, and we learned that on our own account

On 30 August 2026 we found that our own X integration had been reporting posts that never existed. X refused the publish call with error code 226, the automation wrote its usual success line, and nothing appeared on the timeline. The tool believed itself, and so did we, for longer than we would like.

Two days of digging turned up the same shape on a different network. Three LinkedIn image posts, published on 26, 28 and 29 August, all logged green. None of them are on the profile, and fetching each one back by its own id returns 404. A publish log records an intention. It is not evidence of a result.

Both are closed the same way now. Every action reads itself back from the destination by id, and an action that cannot be found afterwards is a failure regardless of what the response said. It costs one extra call per action. It is the whole difference between an agent that works and an agent that appears to work.

If an agent in your business sends invoices, updates a CRM or answers customers, the question worth asking is what proves each action landed. If the answer is the HTTP status code, the agent is guessing on your behalf.

What the agent may do is code, never instruction

Every rule that matters lives in the server, on the path the action has to pass through, not in the prompt. A rule written into a prompt is a suggestion a model can be talked out of, and a rule enforced only in the interface is a suggestion with better manners.

Ours are boring and absolute. Every LinkedIn action our system takes stops at seventy percent of that account's live daily limit and the remainder waits for tomorrow. The cap sits inside the one function every caller has to go through, so a new automation written next month cannot route around it by accident.

The same shape holds in sales. Our own marketplace responder cannot send a price or an offer until three real replies from that buyer exist in the thread, checked in the backend. Asked nicely, the model would happily quote on the first message, which is exactly why the check is not the model's job.

The test for any guardrail takes one minute. Could somebody add a new caller tomorrow and skip it? If yes, it is not a guardrail, it is a habit.

Agents fail quietly, so we build for the silent failure

The dangerous failure of an agent is not a crash. A crash gets attention. The dangerous one is an empty result that looks exactly like a calm day.

For four days in August one of our own lanes searched a community with a filter that returned zero rows, because the plugin behind that filter was switched off in that category. Nothing errored. The queue simply looked empty, so a lane that should have been answering people did nothing at all while every health check stayed green. We found it on 30 August 2026 by comparing runs, not by reading logs.

So an agent we ship treats nothing to do as a claim that has to be defended. It compares against the previous runs, and a stretch of empty results raises an alert instead of a shrug.

Where the model belongs in the design

Models are very good at reading a mess and choosing between options. They are poor at remembering, counting, enforcing and proving. So each part of the agent goes to whatever is actually good at it: the model for judgment, code for rules, a store for memory, a queue for time.

A concrete one. Our inbound lead agent decides what to answer and in which language, then hands the send to code that owns one answer per address, a working-hours window, and a delay drawn between five and forty five minutes so nobody gets a robotic reply at three in the morning. Swap the model out tomorrow and every one of those guarantees survives.

Which model you pick matters less than most vendors imply. Nearly every agent we have been asked to take over failed on plumbing, not on intelligence.

What you own when it goes live

The agent runs on credentials you own, on infrastructure you control, and it writes logs your own engineers can read without a translator. One place shows what it did, what it refused to do, and why.

We would rather be called for the next agent than be the only people who can keep the last one breathing. Documentation is written for whoever has to fix it at 3am, not for whoever signed the contract.