Release 5.9 is about one thing: giving AI agents real work without losing control of it. Agents now ask for approval before risky actions, record every decision, publish only after their tests pass, remember returning customers within strict limits and work with other companies' agents over the open A2A protocol. What each feature does, and how it works under the hood.
Every bank, insurer and government team I talk to asks the same three questions before an AI agent is allowed to do anything that matters. Who allowed it to do that? What exactly did it do? And if it goes wrong, can we undo it?
For a long time the usual industry answer was a mix of prompts, good intentions and a log file nobody could read. Release 5.9 of the Blits.ai platform is our answer in product form. Agents can now ask permission before they act, record every decision they make, publish changes only after their tests pass, remember returning customers within limits you set, and work with other companies' agents over an open standard.
This post walks through what we built over the last weeks. I'll keep it readable for the boardroom, and I'll also show how it works under the hood, because a risk committee will ask.
An AI agent becomes useful when it can do things: issue a refund, change an address, send an email, call a customer back. It also becomes risky at exactly that moment. In my piece on agentic and generative AI I described the difference between a wrong answer and a wrong action. This feature is about the second one.
You now decide per tool what an agent or workflow may do. Every tool gets one of three permissions: Automatic, Requires approval or Disabled. A disabled tool is hidden from the agent completely. An approval can be required always, or only when a condition is met, such as a refund above EUR 250. And you choose who approves: the customer confirms in the conversation, or an employee with the right role approves from a new Approvals inbox.
What matters is where this is enforced. The check does not live in the prompt, where a clever customer or an injected document could argue the model out of it. It sits in the tool loop, outside the model. When the agent calls a tool that needs approval, the exact call is frozen with its arguments. Only an approved record can run, and only with those arguments. If the model leaves out the amount to slip under the threshold, the platform treats the condition as met and asks anyway. A timeout always counts as a rejection: the tool never runs because nobody answered. Workflows pause on an approval and pick up where they stopped once someone decides.
Some tools start with approval switched on, because the cost of a mistake is obvious: sending an email, calling a contact and starting or stopping a calling campaign. For everything else you choose, and you can set new tools to start as "Requires approval" by default.
When a regulator or an internal auditor asks why a customer got a certain answer, "the model decided" is not an answer. So every turn of every customer conversation now produces a decision log: which intent was recognized, which route and flow step it took, which knowledge was used, which tools ran with which result, which guardrails passed or blocked, which models were called with how many tokens and in which region, and whether there was a handover or an approval.
Three design choices make this usable in a regulated environment.
First, it costs the customer nothing. The log is collected during the turn and written after it, outside the conversation, so it adds no waiting time. Second, it is masked before it is stored, and irreversibly: card numbers, IBANs, one time codes, passwords and tokens never reach the log. It does not store prompts or message text at all; it links to the transcript instead. Third, it goes where your security team already looks. You can export it as JSON Lines or OpenTelemetry, and you can stream every turn live to your own collector or SIEM as OpenTelemetry traces.
Retention is yours to set, from 30 days to ten years, with 180 days as the default, because the EU AI Act asks deployers of high risk systems to keep logs for at least six months. And if your policy says nothing may be stored with a vendor, you switch storage off and the log only goes to your own collector. A customer who says "forget me" takes their log with them.
If you cannot explain a decision afterwards, you should not let an agent make it in the first place.
Prompts are code now. A single sentence changed in an agent's instructions can change how it treats ten thousand customers by lunchtime. Yet in most companies I see, prompt changes go live the way a Word document gets saved.
Every published change to an agent is now a numbered version. You can see what changed, chat with an older version without publishing it, and bring one back with a single click and a written reason. For teams that want more control there is a second mode, which we call publishing after the tests pass. Changes go to a draft, the draft runs your QA test suite, and only when it passes can it go live.
The detail I like most: a test run only counts for the exact draft it ran on. Change one word after the tests pass and the result is stale, so you test again. Restoring an older version deliberately skips the tests, because during an incident you want the last good version back now, not after a test run. A tenant admin can publish without passing tests, but only with a written reason, and the version carries a visible mark in the history. API keys and identity settings are never part of a version, so a rollback can never bring back an old key.
Customers hate repeating themselves. Agents that forget everything the moment a conversation ends make them do exactly that. So agents can now remember lasting facts and preferences per customer across conversations: prefers email over phone, wants answers in Dutch, is moving house in December. They can also follow a goal over several sessions, such as saving towards a car.
Memory is also the feature where it is easiest to get privacy wrong, so most of the engineering went into what is not kept. Memories are extracted after a conversation ends, never during it, so customers don't wait for it. The customer's own words are never stored, only a short extracted sentence. Every memory, whether it comes from the extractor, an agent or an admin, passes one policy filter. Card numbers, bank account numbers, passwords, PINs and one time codes are always refused, and so are health, religion, ethnicity and the other special categories, along with anything that was masked or blocked by a guardrail. By default, contact details and opinions about staff are not kept either.
Retention defaults to a year from the last time a memory was confirmed, with at most 50 memories per customer. Your team can see, correct and delete what an agent remembers, and "forget me" erases memories and goals. Workflows got their own small version of this: a notebook that keeps track of where the last run stopped, such as the last invoice processed.
More and more of the work an agent does involves another company. A bank agent that needs a broker's quote, a telco agent that books an installer, a travel agent that checks a partner's availability. Until now, every one of those connections was a custom integration.
A2A (Agent2Agent) is an open protocol for exactly this, and Blits.ai now supports it in both directions. You can publish an agent or a workflow, and any A2A compatible platform can discover it through its Agent Card, hand it a task and get the result back. And your own agents can call external A2A agents as if they were tools.
A published agent behaves like itself: it runs with its own guardrails, and when it needs one more detail it asks for it instead of guessing. Long running workflows report progress and push the result when they are done. Each published agent gets its own API key, shown once and stored only as a hash, with a rate limit per agent and an option to accept tasks only for a verified end user. On the way out, calls to external agents pass our network safeguards, and what comes back is cleaned and capped before your agent reads it. External agents also fall under the approval rules from the first section, so an outside agent cannot do anything your policy wouldn't allow your own agent to do. The technical details are on our integration standards page.
Being model agnostic is one of the things our customers value most: we connect to more than 300 models. For a regulated customer, though, a long list of models also raises a question. Which of those companies could, in some fallback scenario, receive our data?
A tenant admin can now limit that list per category: language models, embeddings, speech to text and text to speech. A blocked provider is never called, and nothing is redirected to another provider; the feature that needs it simply stops, and the decision log records why. Providers we add in the future are blocked too until you allow them. Before you save, the screen shows which agents and knowledge bases would be affected, so nobody switches off production by accident. This works hand in hand with the privacy shield, which keeps personal data inside your perimeter even when a cloud model does the thinking.
A few changes that won't make headlines but that customers asked for repeatedly.
Outbound calling campaigns and agentic workflows now work together in both directions. A campaign can start a workflow after a completed call, when a contact can't be reached, after an escalation or when the campaign ends. A workflow can add contacts, call someone, start or pause a campaign and read the results. Workflows can also send email, with approval switched on by default for both emailing and calling.
Voice can now be switched off per agent, separately for speech input and spoken answers, for teams that want a text only assistant without a microphone button in any channel. And when a customer switches language halfway through, the agent can now keep the conversation and its history instead of starting over.
A new model makes an agent a bit more fluent. These features make it governable, and in my experience that decides whether an agent stays in a pilot or gets real work. What a bank wants from an agent is that it asks before it pays out, explains itself afterwards and can be rolled back in a minute.
Everything in this post is part of release 5.9. You can read how agents work on the platform on how agents work, and the full list of changes is in our release notes. If you'd like to see approvals, the decision log and memory on one of your own use cases, book a session with me. I'll bring the log.
A chatbot that answers a few FAQs is easy to build. Here are 15 advanced features that move your chatbot from a simple Q&A tool to something your business depends on.
Introducing Agentic AI Studio: a platform agnostic, enterprise ready way to design and run autonomous workflows with your own models and data.
A plain roundup of five things we shipped this year: emotional voice, interactive cards, agentic tasks, in chat payments and response feedback.
New posts on conversational AI, enterprise automation and customer experience, sent to your inbox when they go live
No spam, unsubscribe at any time
