The concepts our work is built on
These five texts define how we think about agentic AI: what agentic process specification is, why specification comes before implementation, what a buildable specification contains, why verifiability is a competitive advantage and what acceleration does to people.
01 // Agentic process specification
What is agentic process specification?
Agentic process specification is a way of defining AI processes so that our platform's agents produce the first version of the specification from expert input, and the client's people review, approve and complete it. The result is a machine-readable, technology-independent specification that acts as an owner's representative in an AI programme: it states what gets built, under what conditions it is accepted and how the implementation is verified. The owner's-representative role has moved into the platform and the agents, which do the specification work faster and more repeatably than human effort alone.
Why AI programmes need an independent specification
Between an AI buyer and a vendor there is deep information asymmetry: the buyer cannot judge whether the proposed solution is correctly sized, correctly priced or even necessary. A vendor selling implementation has an incentive to grow the implementation. An independent specification dissolves the setup: when the specification exists before the offers, offers can be compared, scope can be controlled and the outcome can be verified against something.
How agents and people share the work
Three stages. Elicitation: in workshops and interviews, expert knowledge is gathered and agents identify process steps, decision points and approval gates. Specification: agents write the first version of a machine-readable specification that includes human approval points, risk classifications and an audit trail. Validation: the client's experts review, approve and complete the specification, which can then be compared against implementation and used in procurement.
What the client owns
The specifications, process descriptions, work instructions and governance documents are the client's property. This is the core of the model: the knowledge and the specification do not remain inside a vendor's systems; they travel with the client from vendor to vendor and make building an in-house team possible.
What we do not do
We do not implement or operate runtimes, and we do not sell licences to implementation platforms. This is a boundary, not a gap: independence is possible only if the verifier has no implementation of its own to defend. If you only need an implementer for a finished specification, we would rather help you find one than do the work ourselves.
Q:How does this differ from ordinary AI consulting?
Ordinary consulting usually sells implementation or the work leading to it. Agentic process specification is not implementation, so specification and verification are done for the client's benefit, not as a sales funnel.
Q:Do we need this if we already have a good IT partner?
Even a good implementer benefits from a clear order. Independent specification gives your partner an unambiguous job and gives you a way to verify the result.
Q:Does the model suit small projects?
For specifying a single workflow, yes. If the need is one light automation for a few users, an off-the-shelf product may be cheaper, and we will say so directly.
Q:Where does the idea come from?
From the owner's representative in construction. That role safeguards the client's interest on a building project, and the same need exists in AI programmes. In agentic process specification, the safeguard is built into the platform and the specifications it produces.
02 // Spec-first AI transformation
What does spec-first AI transformation mean?
Spec-first AI transformation means that every process to be automated is specified as a machine-readable specification before anything is implemented. The specification states what the agents do, where the data comes from, where a human approves and under what conditions the result is acceptable. The order is the reverse of a typical AI project, where a tool is chosen first and uses are sought for it afterwards. Spec-first makes AI buyable: a specified whole can be compared, tendered and verified. Without specification, the scope drifts, the outcome cannot be checked against anything, and the platform choice becomes a lock.
Most of a project's time has always gone into specification
AI projects typically do not fail on the model or the code but on the fact that no one has described the process at the precision automation requires. That work gets done in any case; the only question is whether it is done in a controlled way up front or expensively during implementation, where every ambiguity is discovered while building.
What a machine-readable specification is
The specification structures the process into a hierarchy: a process decomposes into workflows, workflows into agents, and agents into technical tasks. Each step gets defined inputs, outputs, acceptance conditions and human control points. Because the format is machine-readable, diagrams for people, instructions for operators and the implementation baseline are generated from the same source. When the implementation changes, the change is made to the specification, and the documentation stays current by definition.
How spec-first changes buying
When the specification exists before the implementation decision, the buyer's position changes. The implementation can be tendered with comparable offers, because everyone is bidding on the same specified whole. The platform can be replaced, because the logic does not live inside the platform. And building an in-house team becomes realistic, because the specification tells the builder exactly what done means.
Where spec-first does not fit
For a one-off experiment or a single person's helper tool, a specification process is too heavy. Spec-first pays off when the process is recurring, the volume matters and the correctness of the outcome matters. We will say directly if your need is solved with something lighter.
Q:Does specification slow the project down?
The specification work is done in any case. Done up front, it is faster and cheaper than discovered during implementation.
Q:Does the specification go stale when the process changes?
Not if changes are made through the specification. Then documentation and implementation stay on the same version, which is the point of the model.
Q:Can anyone implement the specification?
That is the goal. The specification is technology-independent, and the implementer can be your own team, your current partner or a chosen third party.
Q:What does spec-first cost compared to going straight to implementation?
Specification is a fraction of the implementation cost, and it reduces implementation risk and scope drift. The exact price depends on the size of the process, and we quote it as a fixed fee before starting.
03 // Agentic process specification
What must an agent specification contain to be buildable?
An agentic process specification is a description from which an AI agent can be built without guessing. A buildable specification contains five things: the structure (a process decomposes into workflows, workflows into agents, agents into technical tasks), the data flows (where each step's input comes from and where its output goes), the acceptance conditions (by what criteria a step counts as done), the human control points (where a human reviews, approves or decides) and the risk classification (what is allowed to go wrong in a step, and what is not). In most failed AI projects the problem is not the model but the fact that at most one of these five has been defined.
Structure: an agent is small, the process is the whole
The most common mistake is to specify "an agent that handles customer service". That is not a specification; it is a wish. A working specification decomposes the whole into parts small enough that each agent has a few clear technical tasks whose success can be verified. The whole emerges from connecting small, verifiable parts into a process, not from one large agent attempting everything.
Not every step is AI, nor should it be
In a well-specified agentic process, a significant share of the steps are deterministic tools: retrievals, transformations, checks and transfers that behave the same way every time. A language model is used where interpretation is needed. This division is among the most important decisions in the specification: it determines the process's predictability, its costs and the traceability of its errors.
Acceptance conditions make "done" verifiable
For every step, the specification defines how you know the result is acceptable: the format, the content requirements and approved example cases against which the output is compared. Without acceptance conditions, "does it work" is an opinion. With them, it is a checkable claim.
Human control points belong in the specification, not in a retrofit
Where a human approves before the process continues, which cases always route to a human, and who has the authority to stop: these decisions are made at specification time and written into the structure. Oversight added afterwards is typically both too heavy and in the wrong places.
Q:Who writes the specification?
The people who run the process describe the work; we structure it into a specification. Neither succeeds alone: the practitioners have the knowledge, we have the structure and the method.
Q:How precise does it need to be?
Precise enough that two different implementers would build essentially the same process from it. That is a practical test of a specification's readiness.
Q:Does the specification go stale?
Not if changes are made through it and the implementation is regularly compared against it. That is exactly what our governance service exists for.
Q:How does this differ from a traditional process description?
A traditional description is documentation for people to read. An agentic specification is machine-readable, and both the human-facing documents and the implementation baseline are generated from the same source.
04 // Verifiability as competitive advantage
Why is verifiability a competitive advantage in AI?
The fundamental problem of buying AI is that the buyer cannot judge quality in advance, and often not afterwards either: the promises are large, the result is a black box and there is nothing to compare against. Economics has long known where such markets drift: towards distrust and poor choices, because good and bad vendors look the same at the moment of purchase. Verifiability dissolves the setup: when a process has a specification, acceptance conditions and a run trail, every promise becomes a claim that can be checked. For an organisation this is a double advantage. Internally, it separates working AI from wishful thinking. Externally, it is a selling point: clients, auditors and authorities can be shown what the system does, who approved it and which version of the specification the implementation is based on.
What verifiability is built from
Four mechanisms. The specification states what the system is supposed to do. Review gates ensure the specification was checked before implementation. The run trail shows what happened in production and who approved it. And comparing production against the specification reveals if the implementation has drifted from what was agreed. None of these suffices alone; together they form a chain in which every claim is one document or log away.
Regulation rewards verifiability, but is not the reason for it
The EU AI Act requires human oversight and documentation for high-risk use, and ISO 42001 certification brings corresponding requirements into the management system. For a verifiably built process these are light, because the required materials emerge from the structure itself. But the reason to build verifiably is not regulation; it is business: an organisation that can show its AI works makes decisions faster and sells more credibly than one that can only assure.
Verifiability disciplines us too
The same principle applies to our own communication: we publish only measured figures as measured and estimates labelled as estimates, and references only in wording the client has approved. If a vendor will not accept the same discipline for its own promises, that says something about how it builds its systems.
Q:Does an auditable trail slow things down and make them rigid?
The opposite: when acceptance conditions exist, changes can be made faster, because their effect is visible. Rigidity comes from uncertainty, not from structure.
Q:Is the vendor's own reporting enough for verification?
Not entirely. A builder's own report on its own work carries an inherent conflict of interest. That is why independent verification is a role of its own, the same principle as in financial auditing.
Q:Can the verifiability of an existing, already deployed AI be improved?
Yes. The work starts by writing a specification for the current implementation, against which it can be verified from then on.
05 // Cognitive load in AI adoption
Why does AI acceleration overload people, and what is done about it?
When agents take over the routine, a person's workday does not empty; it condenses: what remains are decisions, approvals, exceptions and oversight, the most demanding parts of the work without the recovering routine that used to sit between them. If a process accelerates severalfold but the human role is left undesigned, decisions arrive at a pace no one sustains for long. This is decision fatigue in the AI transition, and it is the most common hidden cost of acceleration. The solution is not to slow the AI down but to design the human work with the same precision as the agents' work: size the approval work, bring sufficient context to the decisions and redesign the roles.
The role shift: from user to modeller and approver
In an agentic process the human role changes in two ways. As a modeller, the expert describes how the work is done correctly, and their expertise multiplies through the process. As an approver, they review and decide at the points designed for them. Both are more demanding and more valuable work than executing routine, but neither is grown into without support, which is why the role shift must be designed, not assumed.
Approval work must be sized like any other work
Approval points cannot be sprinkled across a process just in case. Every point is somebody's work, and too many of them produce a rubber stamp: an exhausted approver approves everything, and the oversight becomes nominal. At specification time, we calculate how many approvals actually fit in a role's day, and oversight is directed by risk classification to where it matters.
A decision without context is the heaviest decision
Much of the load of approval work comes not from the number of decisions but from uncertainty: the approver cannot see what the agent's proposal is based on. That is why the specification also defines what the approver is shown: where the data came from, which rules were applied and what is least certain. A justified proposal is fast to review; an unjustified one must either be investigated from scratch or approved blind.
Pace is a leadership question
An organisation can absorb change, but not an unlimited rate of change. Taking processes to production should be paced so that role changes settle before the next wave, and line managers need the means to recognise overload before it shows up as errors or departures. This is a core task of transformation leadership, not a soft extra.
Q:Will this resolve itself as people get used to the new tools?
No, because it is not about tools but about the structure of the work. Getting used to badly designed approval work produces a rubber stamp, not a sustainable practice.
Q:How is overload recognised in time?
Approval work leaves a trail: handling times shortening across the board, exceptions disappearing and returns stopping are signs that review has turned into waving things through.
Q:Does this apply to leadership too?
Especially. When operational decisions accelerate, what escalates to leadership accelerates at the same rate, and leadership's own decision pace should be designed as part of the whole.