Tools and workflows — automation, identity and emerging systems
New technologies are usually either dismissed too early or adopted too early, and both have the same cause: there is no sober measure of what problem the technology actually solves. This page assesses four areas — automation, agentic systems, digital identity and blockchain — against exactly that question. Not by what is technically possible, but by when the technology makes a real difference compared with the simpler alternative.
Automation: the task first, the tool second
Automation offers the most reliable payoff of these four areas and the highest rate of half-finished solutions. The difference rarely lies in the tool:
- Stability of the process. A process that changes every few weeks generates maintenance work exceeding the effort it saves. Automate what is stable enough to outlive the automation.
- Behaviour on failure. What happens when a step fails — does the run stop visibly, or does it silently complete halfway and leave an inconsistent state? The second is more expensive than no automation at all.
- Visibility. Who notices that the automation has not run for four days? A process with no alert on failure is a process nobody should trust.
- Ownership. An automation built by one person and understood only by that person is a dependency, not a process.
The unspectacular conclusion: a well-documented manual process with clear ownership beats an unobserved automation almost every time.
Agentic systems: separate the value from the scope to act
Agentic systems carry out several steps on their own, call tools and make intermediate decisions. That is the source of both their value and their risk, and the two should be assessed separately:
- What can the system trigger? Reading and summarising is a different risk class from writing, sending or paying. An agent's permissions should match the task, not whatever the interface happens to expose.
- How far does it run without asking? A defined threshold — amount, reach, set of recipients — decides whether an error is an annoyance or an incident.
- What happens on incomplete input? A system that plausibly guesses its way past missing information is more dangerous in production than one that stops and asks.
- Can the run be reconstructed? Without a record of intermediate steps, every later investigation is guesswork — and that is exactly what gets demanded after the first incident.
Where those four points are settled, agentic systems are productively usable today for bounded, recurring tasks. Where they stay open, the risk is merely deferred.
Digital identity: the value is in removing media breaks
Digital identity is less spectacular than its presentation and still concretely useful in specific flows — above all where ID scans, copies and manual checks currently slow a process down:
- Which proof is actually needed? Often the confirmation of a single attribute is enough — over eighteen, authorised to sign, employed by a given company — rather than a full identity record. Less data here also means fewer obligations.
- Who accepts the proof? A scheme the other side does not support just relocates the media break.
- What happens when it is lost? Recovery and revocation are where everyday viability is decided, and the part that never appears in a demo.
- How long does the statement hold? An attribute verified once can change. Whether the proof can be re-checked or withdrawn belongs settled in advance.
Blockchain: ask the narrow question
Blockchain is the area where the gap between presentation and applicability is widest. The useful question is narrow: are there multiple parties who do not fully trust each other, who need a shared record, and is there no single party all of them would accept as its keeper?
- Does that constellation actually exist? Inside one company, almost never. A database with proper access control and logging is simpler, faster and cheaper there.
- Is the data suitable? What is written cannot readily be removed. For personal data that is a problem, not a feature.
- Who runs the nodes? If the answer is "we do", the opening question has already been answered no.
- What does operating it cost over years? Including key management, recovery, and the question of who will still understand the system in five years.
In the rare cases where the opening question is genuinely a yes — multi-tier supply chains with competing participants, for example — the choice is defensible. In the remaining cases the honest answer is that a conventional solution solves the problem better.
Where this goes wrong in practice
The recurring error is the reversed order: a technology is chosen, and then a use case is sought to justify it. Such projects reliably reach pilot status and stay there, because the use case was never strong enough to carry the running cost. The pattern is visible early: if the benefit can only be described in terms of the technology used, rather than the task it performs, there is no use case.
The second common failure is comparing against the status quo instead of against the simpler alternative. Almost any new technology beats "we do nothing". The relevant question is whether it also beats the obvious conventional solution.
Next step
If you are seriously considering one of these technologies and want to know whether it carries the task — or whether something simpler delivers the same result — get in touch. A description of the task and the alternatives you have already weighed is enough to start from.