How much autonomy should your AI assistant get? You decide flow by flow

Connecting is easy, deciding is not

Once an AI assistant is connected to your processes through MCP, the technical work is largely done. The hard part starts right after: what do you let it do, and without asking anyone first?

The honest answer is that it depends on the process. A request for office supplies and an approval that commits budget or contracts do not deserve the same level of trust. That is why in FlowSharp the assistant's autonomy is not a global switch. It is a project decision, made flow by flow.

This article does not cover how to connect the assistant (the «FlowSharp and MCP» article does that). It covers what happens after the connection: who decides, who keeps control, and what gets recorded.

The lever: «Require confirmation»

Every flow has a setting called «Require confirmation». It is on by default, so the starting position is a cautious one. Whoever designs the flow can untick it, but only by doing so deliberately.

Without confirmation, a case created by the assistant starts immediately. That is the right choice for routine processes that are low-risk or easy to reverse: an internal request, opening a ticket, capturing data.

With confirmation on, a case created by the assistant waits. It runs no tasks and makes no AI calls, so it costs nothing in the meantime. It only starts when a person clicks «Confirm start». This suits processes with a financial or legal impact.

One point is fixed: the assistant cannot confirm its own work. It cannot do so directly, and it cannot do so through the Flow Agent either. The decision to start the case stays with a person.

When confirmation is on, control stays manageable

Asking for confirmation only makes sense if it does not turn into a forgotten queue. So the tools around confirmation are built to keep whatever is waiting for a decision under control.

The case list has a «To confirm» filter. The flow shows a badge with the number of cases waiting, so whoever owns it can see at a glance whether something needs attention.

Each flow can have a deadline, set in hours or days, with a reminder before it arrives. When the deadline passes, you choose between two behaviours: automatic rejection, or a simple notice that the case has expired. New flows start with a 7-day deadline and automatic rejection.

Anyone who can start the flow can also reject the case, giving a reason. Rejecting does not mean deleting: the case stays available, with the reason and the person who made the decision. If someone asks six months from now why that request never went ahead, the answer is on record.

Either way, the same traceability

Whether confirmation is on or off, the audit trail stays the same. The history shows the action with the person who asked for it and the assistant they used: for example «Mario via Claude», not a generic «System». When the action comes from an integration key, the key's name is shown.

For management, this is the real counterweight to the freedom you grant. You can let a routine process start straight away, and you still know who asked for it and with which tool. Autonomy does not erase accountability. It makes it readable.

For integrators: predictable behaviour

Anyone building on top of FlowSharp needs three things: audit data they can work with, consistent errors, and operations that can be repeated without surprises. Here is what exists.

The history exposed through the API and MCP includes a structured author, with person, assistant, key and engine, and no internal identifiers. It can be read without decoding anything.

MCP tools respond with the same codes as the API. A nonexistent case, a closed case and a transition that is not allowed are three distinct responses, so a client can handle each differently. Retries on transitions are safe: if the integration declares which phase it thought it was starting from and the case has already moved on, the repeated request has no effect.

Assistants can also propose a preview of a Map or a Solution to import. The preview alone changes nothing: applying it takes an explicit choice. If the attempt is repeated, you get back the result that was already saved.

How to choose, in practice

A simple rule: if a mistake can be fixed in a few minutes and costs little, the flow can start without confirmation. If a mistake has financial or legal consequences, leave confirmation on and let a person decide.

You do not have to decide everything up front. Start with confirmation on, which is the default, and remove it from the flows that turn out to be routine in practice. The history shows who asked for what and with which assistant: if cases started by the assistant are always confirmed without corrections, that flow is a good candidate for removing the tick. It is the same principle as everywhere in FlowSharp: measure first, then automate.