Control in an AI-powered organisation

The first is to give AI broad access. An agent gets into your systems and works out for itself how to reach its goal. That removes the rigidity of old software, but replaces dependence on software with dependence on AI: nobody can say any more what it was allowed to do, or why it did what it did.

The second is to put a person in front of everything. Every result waits for someone to click "approve". That feels safe, but when an agent does a thousand routine steps a day, the person becomes part of the loop on paper only. Nobody can really answer for a thousand clicks.

Neither gives you control. Control comes from deciding, in advance and explicitly, what AI may do, and being able to see afterwards what it did.

In CaseFlows, work is organised around cases, and everyone takes part through a case role: a defined responsibility with the information and actions that belong to it in the phase the case is in. An AI agent in a caseflow works the same way. It doesn’t get access to your organisation; it gets one role, in one case, at one moment.

This is about agents that do work in your running cases. The code assistant that builds your platform works on the development environment, under different rules; where that stands is at the bottom of this page.

What the agent asks for outside that role is refused, and the refusal is recorded. The limit is not a guideline the agent is asked to respect. It is enforced by the platform the agent runs on.

Hard limits stay hard. What you lay down as a rule, such as a field that stays hidden from a role or an amount above which someone else must approve, is enforced for a person and for an agent alike. Translating the law, privacy rules and your own mandates into those rules remains your organisation’s work; CaseFlows enforces what you specify. Within those limits there is room to act, and that room is visible.

So we don’t start from “a human in the loop”, but from accountability. An agent may act on its own when three things are explicit: which responsibility it has been given, within which limits, and who in your organisation answers for deploying it there.

Sometimes a person should check every result: a decision with serious consequences for someone, or a step where the agent often turns out to be wrong. Then you put that check in the caseflow, as a step of its own. Elsewhere the agent does its work, and you look at what it did, not at every click.

The same goes for people. A professional who departs from the usual route in an exceptional situation is better off doing that visibly, inside the system, than quietly outside it. Room for judgement and accountability go together.

A log that says “user X changed field Y” tells only part of the story. To understand a decision a year later, you need to know from which responsibility it was taken. For every action, CaseFlows records:

• who acted, and from which case role, a person or an agent;
• in which case, and in which phase it stood at that moment;
• what changed, not just that something changed;
• which version of the caseflow the case ran under, so you judge it by the rules of then, not of now;
• what was refused: what someone tried that their role did not allow.

For AI calls, CaseFlows also records which model answered and on whose key it ran. The trail is append-only: the database refuses changes and deletions, and each entry is chained to the one before, so tampering would show. The execution tells you what happened; the specification tells you within which agreements it happened.

CaseFlows runs on your organisation’s own AI keys, not on ours. Model use runs on your contract and under your terms, and you see what it costs.

You also choose where the intelligence comes from: a large AI platform, a host that runs models in Europe, or a model on your own infrastructure. CaseFlows connects to all three. The model sits behind a connection of your platform, not inside your caseflows, so you can move a workload to another provider without redesigning the work.

You don’t choose AI once. You keep the ability to keep choosing.

AI is at its strongest where trying is cheap: describing a process, building a first version, testing it with test cases. There, CaseFlows uses it as much as it can. A business expert describes the work to a coach, and a code assistant builds it.

What goes to production is not an AI improvising, but a specification your process owner approved, run as it is written. AI does a step there only where you gave it one, in a role, with limits. Maximise AI in development. Minimise AI in production.

That doesn’t mean AI does little in production. An agent can take on a large share of the work there, as long as it does so in a role you defined. What we minimise is not AI, but AI improvising where nobody decided it could.

The trail is not only for when something goes wrong. If an agent often gets stuck in a certain phase, or keeps asking for help, you can see that. Maybe it lacks context, maybe its role is too narrow, or maybe this is a decision that belongs with a person.

People who work with the agent can flag that from the case, with its context. That becomes a proposal to change the caseflow, tried on the development environment before anything changes in production. Accountability then becomes a source of improvement, not only of control.

AI takes part more and more in decisions with real consequences for people: an application turned down, an offer, a selection. Explaining what the system did is then not always enough. Someone has to be able to challenge the outcome.

That requires knowing who is responsible for the decision, and being able to reconstruct the circumstances under which it was taken. “The AI decided” is not an answer. A model can advise, an agent can act, a service can calculate, but in CaseFlows it stays visible which role, and so which organisation, answers for using them.

Runs today

• Agents and skills that do a step in a caseflow, on your organisation’s own AI key.
• Case roles whose limits the server enforces per phase, with refusals recorded, also for agents.
• A trail per action with the role, the case, what changed and the caseflow version, append-only and chained, so changes would show.
• For AI calls: which model answered, and on whose key.
• Your own keys, and a choice of provider: a large platform, a host that speaks the common API, or a model you run yourself.

Where we’re heading

• Choosing per case role which model may be used, for instance “only a model on our own infrastructure” for the most sensitive role. Today that choice is made per platform.
• The code assistant that builds your platform working under the same role limits as agents in your caseflows. Today it still works with platform-wide rights, on the development environment.