AI in companies — use cases, agentic systems and workflows

Most companies are past the question of whether they will use AI. The open question is where exactly — and whether what is already running actually holds up day to day. This page covers three tasks that come up repeatedly in practice: prioritising use cases, assessing agentic systems before rollout, and turning an introduction into an operational workflow that does not break on the first exception. The measure in each case is a team's concrete task, not a general promise about "AI in the enterprise".

Prioritise use cases instead of collecting tools

The most common false start is not the wrong technology but the wrong order: a tool gets introduced before anyone is clear about which task it will actually make faster, cheaper or more reliable. A workable prioritisation therefore starts with the task, not the model:

• Repetition and volume. Tasks that recur often and in a similar shape deliver measurable value faster than one-off cases where a system never gets enough practice.
• Cost of being wrong. A bad draft text is one correction round. A wrong number in a quote, or a wrong approval in a customer process, is a different kind of risk — the same class of model does not justify the same level of autonomy in both.
• Checkability of the output. Can a person verify the output in reasonable time, or does the use case demand blind trust in a black-box result? If nobody on the team can check the output in reasonable time, that is not an operating model — it is a delayed risk.
• Existing data infrastructure. A use case that draws on clean, already-available data is a different proposition from one that first needs a new data pipeline before it can work at all.

Prioritising along these four criteria typically produces a short list of two or three use cases that can be built and verified in production within a manageable timeframe — rather than a backlog of twenty ideas, most of which never get past pilot status.

Assess agentic systems before they go live

An agentic system differs from a conventional AI feature in that it carries out several steps on its own, calls tools and makes intermediate decisions without a person confirming each one. That is exactly what makes pre-rollout assessment more important, not optional:

• Scope of action. What can the system actually trigger — send an email, initiate a payment, change a record? The scope of action determines what a single wrong decision can cost, regardless of how rarely it occurs.
• Traceability after the fact. If an agentic system makes a wrong decision three weeks after rollout, it has to be possible to reconstruct which intermediate steps led there. Without a record of those steps, every later investigation is guesswork.
• Limits of autonomy. Which actions can run automatically, and above which threshold — amount, reach, customer type — does a person need to approve before the system continues? That threshold belongs in place before rollout, not after the first incident.
• Behaviour off the demo path. A system that convinces in a prepared test scenario also has to behave predictably with incomplete inputs, contradictory instructions or a failed tool — rather than guessing what would plausibly come next.

This assessment is not a one-off sign-off. An agentic system that gains new tools or new data sources needs the same review again, because its scope of action shifts with every extension.

Introduce workflows that survive daily use

A use case that works in a pilot is not yet an operational workflow. In between sits the work that rarely appears in a project plan but decides whether a system is still in use three months later:

• Ownership when it fails. Who gets told when an AI-assisted task goes wrong, and who has the authority to stop the system at that moment? Without named ownership, nobody takes that role in practice until an incident forces it.
• Checkpoints instead of blanket trust. A workflow needs defined points at which a person verifies the output, by sample or in full — graded by the cost of being wrong that was already identified during prioritisation.
• Documentation that lasts. What a system does, why it holds the permissions it holds, and who approved the last change all have to remain findable after the person who introduced it has left the team.
• A way back. Every workflow needs a defined fallback to the manual process in case the system fails or has to be switched off — prepared in advance, not improvised under pressure.

These four points are unspectacular, which is exactly why they get skipped under time pressure. They are also the difference between a tool a team uses and a tool a team quietly switches off because nobody is quite sure what it does any more.

Where this goes wrong in practice

The recurring failure is structural rather than technical: a use case gets picked because a vendor demonstrated it well in a sales meeting, not because it meets the four prioritisation criteria above. The result is a system that convinces in the pilot and then fails quickly in production on edge cases that never appeared in the demo — badly formatted inputs, a third-party system that is down, a customer request that does not fit the expected pattern. At that point there is usually neither named ownership for the failure case nor a prepared fallback to the manual process, both of which would have been easier to settle before rollout than after.

Next step

If you are weighing which use case to take first, whether an existing agentic system respects your approval threshold, or how an introduction becomes a workflow that still runs in three months, get in touch. A short description of the current situation and the decision in front of you is enough to start from.