Enterprise agentic processes: a skill is reused, a workflow is replayed

The official measurement of skill triggering

The documentation of the open standard that today defines skills contains a passage that few business leaders have read, although it ought to govern their architectural choices. In order to verify that a skill triggers when it is supposed to trigger, the standard recommends a three-stage procedure: writing some twenty test queries, running each of them three times, then calculating a trigger rate defined as the proportion of runs in which the skill was actually invoked. A query that is meant to trigger the skill counts as a success as soon as that rate exceeds a threshold, and the standard specifies that 0.5 constitutes a reasonable default value [1].

Put differently, the official acceptance procedure for a reusable task, in the format that forty-six products are now able to read, consists in verifying that it triggers more than once in every two runs. The standard owns this choice and explains it in a single line: “Model behaviour is non-deterministic: the same request may trigger the skill on one run and not on the next” [1].

This figure of 0.5 nonetheless lends itself to a misreading that is best cleared up straight away. The threshold serves as an acceptance criterion inside a testing protocol, where it makes it possible to decide whether a description is good enough to be kept, and a properly tuned skill triggers in practice a great deal more often than once in every two runs. What this figure reveals therefore has less to do with performance than with the unit of measurement: the standard reasons in terms of frequency, whereas a company that runs a management process reasons in terms of guarantees.

Non-determinism belongs to the material, and the standard documents it instead of concealing it. The difficulties begin when a company builds an invoicing process, a sales follow-up process or a document production process on top of that property without being aware of it, and is then surprised that the result obtained on Monday does not resemble the one obtained on Tuesday. The discipline that answers this problem is an old one, and it carries a name that technical departments have known for forty years: software engineering.

Anatomy of a skill

A skill takes the material form of a folder, organised around a mandatory SKILL.md file made up of a header and a body written in Markdown, to which scripts, templates and reference documents are added [2]. The header contains only two mandatory fields, a name of at most 64 characters and a description of at most 1,024 characters [3]. The body describes a working method in natural language, in the same way that an internal procedure would: how to review a subcontracting agreement in this particular company, which checks to run on a quotation before sending it, which standard outline to follow when responding to an invitation to tender.

The loading mechanism deserves to be understood, because it explains both the economy of the format and its fragility. At start-up, the agent loads only the name and the description of each available skill, which represents around one hundred tokens per skill and is enough to signal to it the existence of a capability without cluttering its working memory [2]. When a request appears to match one of those descriptions, it then reads the complete SKILL.md. The ancillary files remain free of charge as long as they are not opened, and the embedded scripts execute without their code entering the context, only their output being billed in tokens [2]. Anthropic refers to this behaviour under the name of progressive disclosure.

Three properties explain the rapid spread of the format:

• readability: the file remains intelligible to a human being, which makes it a company document that the business side can review and amend, rather than an artefact reserved for developers;
• portability: launched by Anthropic on 16 October 2025 [4], published as an open standard on 18 December 2025 with distinct governance [5], the format is today recognised by the official documentation of OpenAI for ChatGPT and Codex [6], of Microsoft for GitHub Copilot in VS Code [7] and of Google for Gemini CLI [8], the compatibility page of the standard listing forty-six products as at 30 August 2026 [9];
• composability: several skills can be stacked on the same task, the agent itself identifying those that it needs [4].

This last property also constitutes the limit of the format, since the agent that identifies the relevant skills is also the one that can get it wrong. The documentation of the standard is explicit about this transfer of responsibility, stating that “the description alone carries the entire burden of triggering” [1], and it adds a nuance that teams most often discover in the field: a simple single-step request may fail to trigger the corresponding skill even though the description matches it perfectly, the agent judging that it can manage without it [1]. Tuning the triggering therefore falls within a statistical exercise rather than a configuration setting, with a training set of around 60% of the queries and a validation set of 40% held back in order to verify that improvements generalise [1].

One detail in the Claude Code documentation completes the picture, and it ought to be known to any organisation contemplating the deployment of skills on a large scale. The catalogue of available skills occupies a share of the context capped at 1% of the model’s window, whose size and cost constraints this site has detailed elsewhere, and when the list exceeds that budget the tool shortens the descriptions in order to make it fit, “which can remove the keywords Claude needs to match your request” [10]. Adding one skill can therefore be enough to make another cease to work, without anything having been modified in the skill that has fallen silent, which is precisely the kind of invisible coupling that software engineering took decades to learn how to eliminate.

It then becomes possible to state with precision the contract that a skill carries.

• What it guarantees: the reuse of know-how, in the form of a method written once, applied by any compatible agent, transportable from one tool to another, and revisable by the person who knows the business rather than by a developer.
• What it leaves open: the moment at which it triggers, together with the strict identity of two successive results obtained from the same input.

The human equivalent of this contract is familiar to every organisation. A skill corresponds to a procedure handed to a competent member of staff: it raises the average standard, it makes the work transmissible and it survives the departure of whoever wrote it, without thereby turning its recipient into a machine tool. Nobody expects two salespeople to produce the same tender response word for word.

Anatomy of an agentic workflow

One word must be disambiguated before going any further, failing which the discussion becomes impossible with a technical counterpart, because the term workflow covers two distinct uses in vendor documentation. Inside a SKILL.md, it designates a procedure described in Markdown, that is to say a series of written steps that the model follows with its judgement. In architectural vocabulary, it designates a sequence driven by code, and it is this second sense that concerns us here. Anthropic already adopted it in its engineering post of 19 December 2024, distinguishing two families of systems: workflows, “where LLMs and tools are orchestrated through predefined code paths”, and agents, “where LLMs dynamically direct their own processes and tool usage” [11]. That text is approaching its second birthday, which makes it a dated conceptual landmark rather than a state of the art, but the distinction it establishes has not aged.

An enterprise agentic process, in the sense in which I use the term in this article, is a workflow in the second sense of the word. Its skeleton is algorithmic, composed of queries, filters, joins, loops, conditions and retries, written once and versioned, and that skeleton never improvises. It calls on agents at points identified in advance, in order to carry out the three operations that an algorithm is unable to perform:

• analysing, that is to say reading unstructured material and extracting usable information from it, whether an email thread, the minutes of a video call, a contract or a complaint;
• synthesising, that is to say reconciling several sources that do not say the same thing and ranking what matters for the decision to be taken;
• presenting, that is to say formatting a result for a given recipient, in that recipient’s register and in that recipient’s format.

Every other operation falls to code. Counting, sorting, deduplicating, capping, joining two tables, applying a business rule, writing to a database or sending a notification all admit a single right answer, and entrusting a right answer to a non-deterministic performer constitutes an architectural choice from which the company derives no benefit whatsoever.

The table below applies this division to an ordinary and verifiable process, the following-up of quotations that have gone unanswered, written as a workflow of seven steps of which only three call on an agent.

#	Step	Nature	Who runs it
1	Select quotations sent more than fifteen days ago, with no incoming reply from the contact	Deterministic	A query
2	Read the email thread and the video-call minutes of each case, detect an implicit refusal	Non-deterministic	An agent, structured output
3	Set aside customers in dispute, deduplicate by company, cap at twenty cases	Deterministic	Code
4	Draft a follow-up message suited to each case retained	Non-deterministic	An agent
5	Write each message as a draft in the mail client, without ever sending it	Deterministic	Code
6	Produce the summary note intended for the business leader	Non-deterministic	An agent
7	Log, mark the cases as handled, notify	Deterministic	Code

Two steps in this table deserve a comment, because they carry the bulk of the engineering value of the chain.

Step 2 contains the most profitable gesture of the whole set, since the agent returns a structured object there rather than a paragraph: a boolean indicating whether it has detected an implicit refusal, a short reason, and the exact quotation on which it relies. Three immediate consequences follow from this. The result becomes verifiable, a human being being able to go back to the sentence quoted in order to check the judgement rendered. It becomes testable, since the company can assemble a set of cases whose correct answer it already knows. It finally becomes a piece of data directly usable by the following step, which avoids paying for a second non-deterministic draw simply in order to interpret what the previous one meant.

Step 5 illustrates the opposite movement, that of deliberate restraint. The process drafts and stops there, the decision to send remaining with a human being because this is the only step in the chain that is both irreversible and visible to a customer. That restraint takes the form of a constraint written into the code, which quite simply does not expose the sending function, rather than of an instruction addressed to the agent in its prompt.

This architecture ceased to be an opinion in the course of 2026, since it became a product at several vendors within the space of six months. The Claude Code documentation has described a workflow primitive since the end of May 2026, and its official comparison table sets side by side the four ways of putting agents to work. To the question of who decides what runs next, the answer given is “Claude, turn by turn” for subagents as for agent teams, “Claude, following the prompt” for skills, and “The script” for a workflow; to the question of what is repeatable, the answer is “The instructions” for a skill and “The orchestration itself” for a workflow [12]. The title of this article therefore takes up a line from a documentation table. Determinism is moreover imposed there by the machine rather than recommended, since inside a workflow script the calls Date.now() and Math.random() raise an exception, so that a relaunched run repeats exactly the same agent calls [12].

Temporal, the vendor of a durable execution engine, gave the fullest formulation of this on 20 August 2026. Its author observes that it has become remarkably easy to give an agent capabilities and considerably harder to entrust it with a responsibility, inasmuch as responsibility presupposes control. Language models being both extraordinarily capable and unpredictable by nature, placing one on the path of a business process that speaks to customers, operates production systems or moves money makes it necessary to surround that unpredictability with predictable elements: enforceable rules, reliable execution and a history that restores exactly what happened [13].

The reliability cost of non-determinism

The calculation that follows fits on a single line and is nonetheless rarely performed. If each step in a chain succeeds with a probability of 95% and the steps are independent, a chain of twenty steps succeeds end to end in 36% of cases, whereas the same chain brought down to three non-deterministic steps rises back to 86%. No model was improved between those two values, only the number of draws having changed.

The curve carries a second lesson, less intuitive than the first. Moving from 95% to 99% reliability per step, which represents a considerable research effort on a model, brings a chain of twenty steps back up from 36% to 82%, whereas dividing the number of non-deterministic steps by seven, which falls within an architectural decision taken in the course of an afternoon, produces an effect of the same order of magnitude. These two levers therefore come at costs that bear no comparison with one another.

A reservation in the interest of honesty is called for on this calculation, and it can be measured. The independence assumption is false, and the published data now make it possible to assess the size of the gap. On Toolathlon, a benchmark of 108 real tool-use tasks that exposes more than 600 tools across 32 applications, with trajectories of twenty to twenty-six turns, the best model of July 2026 succeeds on 80.6% of tasks at the first attempt and on 73.1% of tasks three times in a row [14]. Under the independence assumption, the second value would be 0.806 cubed, that is 52.4%, and the twenty-point gap indicates that failures concentrate on durably difficult tasks instead of distributing themselves at random. Multiplying the probabilities therefore constitutes a worst-case heuristic rather than an empirical law, and a properly written chain, equipped with retries and intermediate checks, still sits above the curve. The direction of the slope, by contrast, depends on no assumption at all, since every non-deterministic node added lowers the reliability of the whole according to a multiplicative law.

There remains the question that a business leader legitimately asks, namely where an agent left alone on a real enterprise process stands today. A benchmark published on 21 April 2026 by two researchers at Zapier answers it in the most direct manner possible. AutomationBench places the agent inside a simulated company spanning 47 applications, with tasks drawn from workflows actually observed among the platform’s customers, in sales, marketing, operations, support, finance and human resources, and asks it to discover the endpoints on its own, to chain dozens of interdependent calls, to comply with layered business-rule documents and to avoid deliberately planted decoys, the scoring being binary and bearing solely on the final state of the systems [15]. In April, the founding paper observed that the best frontier models were scoring below the 10% mark; three months later, the best of them reaches 26.0%, against 17.0% for the previous generation [14]. The progress is real and rapid, and it nonetheless leaves three realistic business processes out of four in failure when the agent works without supervision.

These figures explain why an enterprise process gains from being designed as a sequence from which all unproductive non-determinism has deliberately been removed, rather than as an autonomous agent to which an objective would be described.

The four software engineering practices applicable to orchestration

For the past two years, agents have been writing the business code, a shift that this site has described under the name of UltraCoding. An article published in July documented this turning point on a register covering seventeen working days: once writing correct code costs almost nothing, the bottleneck becomes the decision as to what ought to be written [16]. What remains to be designed in an agentic process therefore lies in the orchestration, that is to say in the layer that determines at which moment an agent is called, with which inputs, under which guarantees, and what happens when it gets things wrong.

Anthropic names the central question of this layer in its own skill-authoring documentation, under the term degrees of freedom [17], and distinguishes three regimes within it:

• high freedom, when several approaches are valid and the context settles the matter, in which case natural-language instructions are sufficient;
• medium freedom, when one pattern is preferred while acceptable variation is still allowed;
• low freedom, when the operations are fragile, when consistency is critical and when a precise sequence must be respected, in which case the vendor recommends an exact script with no parameters.

The image employed in the documentation is that of a robot advancing along a path: a narrow bridge bordered by precipices calls for guard rails and exact instructions, whereas an open field free of danger calls for a general direction and nothing more. The operational instruction that follows from this appears in the official checklist in five words, prefer scripts for deterministic operations [17], which amounts to writing validate_form.py rather than asking the model to generate the validation code on every run.

Four software engineering practices are deduced from this principle, and none of them is obtained by improving the drafting of a prompt.

First practice, declaring idempotence rather than hoping for it. The MCP protocol, which connects an agent to its tools, provides in its official schema for four annotations per tool, bearing respectively on read-only status, destructiveness, idempotence and open-world behaviour [18]. The default values deserve careful reading, since in the absence of any declaration a tool is deemed destructive and non-idempotent, with destructiveHint set to true and idempotentHint set to false: the protocol works on the assumption that an undocumented tool may break something and that a second identical call will produce a second effect. The specification adds that clients must treat these annotations as untrusted for as long as they do not come from a trusted server [19], so that the effective guarantee is built on the calling side, in the form of an idempotency key, a lock or a check before writing. The maintainers of the protocol write as much without hedging in a post dated 16 March 2026: an untrusted server can lie, announce a read-only operation and delete files all the same; these annotations do not constitute an enforcement mechanism, and obtaining a guarantee that a tool cannot exfiltrate data falls within network control or sandboxing. Their instruction fits on one line, keep your real safety guarantees in deterministic controls [20].

Replay is not, however, obtained for free, and an evaluation of multi-agent orchestrations published on 5 August 2026 measures this, observing that blind replay reproduces latent faults and lengthens the time to detection [21]. Resumption therefore only brings value if the system first knows that it has failed and at which point, the authors themselves specifying that their results probe mechanisms in a controlled chain and do not constitute a measurement on a real production workload.

Second practice, validating outputs by machine. The same protocol allows a tool to publish an output schema, accompanied by an asymmetric rule under which the server must produce a conforming result and the client should validate it [19]. Anthropic extends the principle in a pattern that it explicitly recommends for batch operations, destructive changes and high-stakes work, in five stages: analyse, produce a plan file, validate that plan with a script, execute, verify [17]. The justification put forward repeats that of classical software engineering, since validation identifies problems before the changes are applied and a script provides an objective check, the intermediate plan remaining modifiable whereas execution commits.

Third practice, building the evaluations before they are needed. Anthropic’s documentation is direct on this point, and a project budget gains from incorporating it from the outset: evaluations constitute the source of truth that makes it possible to measure the effectiveness of a skill, and “there is currently no built-in way to run these evaluations. Users can create their own evaluation system” [17]. The recommended method consists in building the evaluations before writing the documentation, by first measuring what the model produces without the skill, in order to know what the skill actually contributes. A company that deploys agents without a reference set of cases deprives itself of any means of observing a regression, although it will necessarily encounter one, if only at the next change of model.

Fourth practice, writing the human loop and the audit trail into the code. The revision of 28 July 2026 of the MCP specification formulates these two requirements at the level of the protocol itself. On the human loop, it indicates that, for reasons of trust, safety and security, there should always be a human being in a position to refuse a tool invocation. On the audit trail, it asks clients to display the tool inputs to the user before the call, to seek confirmation on sensitive operations, to impose timeouts and to log tool usage for auditing purposes [19]. Those four lines make up an operating specification, set down in a protocol specification.

Security arrives at the same conclusion by another route, and the 2026 edition of the OWASP Top 10 devoted to language model applications, published at the beginning of August, formulates it without hedging. The ranking rests on a corpus of 7,714 real incidents of which 6,639 could be classified, weighted three quarters to the community vote and one quarter to the incident record, and it draws two lessons from this for anyone who builds processes. The first concerns the rise of excessive autonomy, a category named Excessive Agency, which climbs to third place and constitutes “the most consequential move on the list”, because the vote and the incidents agree that the damage lands in agentic deployments [22]. The second concerns a sentence that would deserve to appear in every specification: prompt injection is intrinsic to the current state of generative AI, “no reliable prevention mechanism exists today”, and “defense is therefore architectural rather than interceptive” [22]. The associated recommendation, called complete mediation, joins what this article has been describing from the outset, in asking that authorisation be implemented in the logic of the programme instead of relying on a language model to decide whether an action is permitted. The opening letter of the document moreover fits into two sentences that would serve as a specification for any business process: stop trying to build a model that cannot be fooled, and build the system around it so that, when the model is fooled, and it will be, nothing important breaks [22].

A piece of work published on 11 July 2026 puts figures to that sentence, and the detail there is worth more than the summary. The benchmark counts 130 network operation scenarios and 240 attack cases, evaluated on three small open models, and a naive run produces 82.50% dangerous tool actions there. Four defences formulated at the level of the instructions bring that rate down to 25.63%, 21.67%, 18.33% and 10.00%, which represents real progress while remaining very far from what a business process can accept.

The same work then publishes the result that forbids concluding too quickly. A static allow-list, the crudest form of determinism, comes down to 5.00% dangerous actions while blocking the entirety of the approved changes as well, that is 0% utility. A policy gate that reasons on the tool metadata before the call produces for its part zero dangerous actions out of 240, with an upper bound of 1.58% at 95% confidence, while preserving 99.17% of utility under attack scenarios and 100% on approved changes, subject to the explicit proviso that the metadata are themselves sound [23]. Applied indiscriminately, determinism therefore destroys the service it claims to protect, whereas applied in the right place and to the right data it costs practically nothing, which is the same gap already encountered in Figure 2, measured this time on the ground of security.

ANSSI was already formulating comparable recommendations in its guide for a generative AI system of 29 April 2024, published before the word agent became commonplace. Two of them bear directly on the subject: prohibiting the automated use of an AI system for critical actions on the information system, and limiting or even prohibiting automatic actions triggered from an AI system on the basis of uncontrolled inputs, such as data coming from the internet or from received messages [24]. That document is more than two years old, which underlines the stability of the rule, since only the number of companies concerned has changed in the meantime.

One pattern runs through the whole of these documents, and it deserves to be named because it locates precisely the work that remains the responsibility of the company. The ecosystem of 2026 has adopted the vocabulary of software engineering, while making clear that this vocabulary commits nobody. The MCP protocol standardises an idempotence indicator, then indicates that it is an unverifiable hint. The OpenTelemetry observability conventions define traces dedicated to agents and to tool calls, in a specialised repository created on 5 May 2026, while marking them with the Development status, whose official definition states unambiguously that the component should not be used in production and may be removed without prior notice [25]. The most starred agent design framework on GitHub, the 12-Factor Agents, whose factor 8 is entitled “Own your control flow”, displays 25,590 stars and has received no content commit since 21 September 2025 [26]. The standard thus designates the engineering work without taking it on, and refers it back to the integrator.

None of these four practices presupposes a new competence. They are the reflexes that teams have always applied to an overnight batch job, namely interface contracts, controlled replay, a log, an alert and minimal permissions, and they had simply ceased to be visible because the business code was taking up all the room.

The three-question method for dividing a process

The division between what falls to code and what falls to the agent is decided before any writing takes place, step by step, with the help of three questions asked in an order that is not a matter of indifference.

The first question bears on verifiability: does this step admit a single right answer, checkable by someone else? Counting quotations, applying a threshold, joining a customer table to an invoice table or calculating a margin all call for an affirmative answer, and those steps fall to code. This one question generally removes half the steps of a process from the domain of judgement, which explains why it comes first, since it is by far the most profitable of the three.

The second question bears on the nature of the work: does this step involve reading unstructured material, reconciling diverging sources or formatting output for a recipient? A negative answer most often signals a management decision disguised as a process step, of the kind that consists in knowing whether customers in dispute should be followed up or whether processing should be capped at twenty cases rather than at fifty. Such judgements are settled once, by a human being, and then become constants in the code, because leaving them to an agent’s appreciation on every run would amount to taking a business rule away from the company in order to entrust it to a draw.

The third question bears on consequence: does the output of this step trigger an action that is irreversible or visible to a customer? An affirmative answer keeps the agent in place and interposes a human validation, written into the code. The Claude Code documentation supplies both the mechanism and its justification, since a setting makes it possible to remove the model’s right to trigger a skill by reserving invocation to the human being, motivated by the vendor in these terms: “you don’t want Claude deciding to deploy because your code looks ready” [10]. This principle is the one already set out by this site’s article devoted to agentic systems engineering and human-in-the-loop [27], according to which the guard rail lives in the code rather than in the prompt.

The steps that none of the three questions has eliminated fall to the agent, with a structured output, and are limited to the three operations identified above: analysing, synthesising, presenting.

The three objections to this analysis

The argument developed here has weak points that it is better to set out oneself than to leave to a technical reader.

The first objection bears on the shape of the graph. A vendor of durable execution engines, Inngest, formulates it clearly: the critical difference between an agent loop and a classical workflow graph lies in the dynamic character of the loop. A graph has a shape that is known at design time, with a step A, then a step B, then a fan-out towards C and D, whereas the shape of an agent is decided at runtime by the model, the graph being drawn as the agent proceeds [28]. A shape that is unknown in advance obviously cannot be written in advance. The answer lies in the choice of a single word, since what a company needs to guarantee concerns prior knowledge of the graph less than its capacity to be replayed. Inngest moreover resolves the matter in exactly that way, with non-deterministic code on the first pass and deterministic replay on resumption, the memoised results forcing the same path [28]. A field observation completes this answer: most of the processes that a small or mid-sized company wishes to automate first do indeed have a known shape, the following-up of unanswered quotations always comprising the same seven steps.

The second objection bears on a recommendation formulated earlier in this very article, that of constraining the output of an agent with a schema, and it makes it necessary to qualify that recommendation. A piece of work published on 20 May 2026, based on 15,000 generations, measures what its author calls the constraint tax: imposing a hard schema during decoding takes structural validity from 61.5% to 100% and answer accuracy from 19.7% down to 11.0%, with the proportion of outputs that are wrong yet structurally valid climbing from 49.5% to 88.9%. On the case closest to a tool call, JSON output requested by simple instruction reaches 91.5% executable accuracy, against 48.0% when the same schema is hard-imposed, at identical structural validity in both cases [29]. The study bears on small models of fewer than three billion parameters and its author explicitly declines to extrapolate, but his formulation usefully corrects mine and I adopt it: reason free, constrain late. The schema serves to package a result at the moment of transmitting it, without guiding the reasoning that produces it, and a dashboard that tracked only the rate of well-formed outputs could therefore improve while downstream execution degrades.

The third objection is the most awkward, because it comes from researchers who do not defend the thesis of this article. OSWorld 2.0, a benchmark of 108 long computer workflows published on 28 June 2026, retains tasks that take a human being a median of one hour and thirty-six minutes and mobilise an average of 318 tool calls. On its principal measure, full completion, the best configuration tested reaches 20.6% of tasks for a partial score of 54.8% [30], and the gap between those two figures constitutes the whole subject, since it describes an agent that correctly performs numerous operations and rarely finishes the job. The diagnosis of the authors bears on staying the course rather than on raw capability, the agents losing track of the constraints stated to them and missing the information that arrives in the course of the task. They conclude that better agents are needed, where this article concludes in favour of an external skeleton, and the two readings can perfectly well be true together: the skeleton makes it possible to put agents to work this year, whereas better agents will push the boundary back next year, without either of the two dispensing anyone from knowing where that boundary runs today.

What an SME or a mid-cap can start on right now

An article published on this site three days ago argued that three layers of an agentic product move continuously beneath a company’s feet, namely the harness, the model and the connectors [31]. The practical conclusion of the present analysis follows directly from that, since the element that survives a change of model without losing its value is the sequence itself.

A workflow written in code retains its meaning when the model changes version: the queries remain valid, the output schemas remain valid, the tests remain executable, and the replacement of one model by another is observed on a known set of cases instead of being discovered in production. A skill constitutes an asset of a different nature, one that carries know-how, travels from one vendor to another and derives its value precisely from its flexibility. The two objects complement one another, provided that one does not expect from either the guarantee that only the other can bring. This division extends a thesis already defended here, according to which conversation cannot become a working interface: the durable interface of a process is its written sequence, and the conversation is only its point of entry.

A Deloitte study published on 11 August 2026 puts a figure on the gap that still separates intentions from achievements. Conducted from April to June 2026 among 501 executives whose organisations were all piloting agentic solutions at a minimum, it measures that only 15% have reached orchestrated multi-agent adoption at scale, whereas 42% are testing a handful of agents and 43% are extending them across several functions. Above all it ranks seven dimensions of readiness and places business processes last, at 21%, behind strategic vision at 52%, technical infrastructure at 48%, the data foundation at 42%, governance at 39%, partnerships at 34% and workforce at 25% [32]. The causes that the study names are, in order, poorly documented and poorly understood processes, fragmented data and systems, and entrenched working habits. The least prepared dimension is therefore the one that presupposes neither a licence nor a server.

For a small or mid-sized company, the operational translation fits into a single deliverable. The first document of an agent-based automation project is a numbered list that sets out the steps of an existing process and carries, alongside each of them, the answer to the three questions set out above. That document is written in half a day, without tooling and without budget, and it then indicates beyond any possible argument how many non-deterministic draws the company is about to stack up and which of them it can remove.

Most of the processes that are believed impossible to automate are above all processes that nobody has ever taken the time to write down.

---

Sources

All the pages listed below were retrieved directly on 30 August 2026. Living documentation does not carry a publication date: the date indicated is that of consultation.

[1] Agent Skills, "Optimizing skill descriptions", documentation of the open standard, accessed 30 August 2026: protocol for measuring the trigger rate, twenty queries, three runs each, default threshold of 0.5, split of 60% training and 40% validation. https://agentskills.io/skill-creation/optimizing-descriptions

[2] Anthropic, "Agent Skills", documentation, accessed 30 August 2026: three-level progressive disclosure, around 100 tokens of metadata per skill always loaded, body of the SKILL.md under 5,000 tokens loaded on triggering, resources at no cost until read, scripts executed by bash of which only the output enters the context. https://platform.claude.com/docs/en/agents-and-tools/agent-skills/overview

[3] Agent Skills, "Specification", accessed 30 August 2026: mandatory fields name (64 characters at most) and description (1,024 characters at most). https://agentskills.io/specification

[4] Anthropic, "Introducing Agent Skills", 16 October 2025: launch of the format. https://claude.com/blog/skills

[5] Anthropic, "Skills for organizations and the skills directory", 18 December 2025: publication of the format as an open standard. https://claude.com/blog/organization-skills-and-directory

[6] OpenAI, "Build skills", documentation, accessed 30 August 2026: support for the open standard in ChatGPT and Codex. https://learn.chatgpt.com/docs/build-skills

[7] Microsoft, "Agent skills", Visual Studio Code documentation, page dated 26 August 2026: support by GitHub Copilot in VS Code, the command-line interface and the cloud agent. https://code.visualstudio.com/docs/copilot/customization/agent-skills

[8] Google, "Skills", Gemini CLI documentation, page dated 30 April 2026. https://geminicli.com/docs/cli/skills/

[9] Agent Skills, "Client Showcase", accessed 30 August 2026: 46 products listed, counted by hand from the published list. https://agentskills.io/clients

[10] Anthropic, "Extend Claude with skills", Claude Code documentation, accessed 30 August 2026: disable-model-invocation setting, budget of the skill catalogue set at 1% of the context window and shortening of the descriptions beyond that point. https://code.claude.com/docs/en/skills

[11] Anthropic Engineering, "Building effective agents", 19 December 2024: distinction between workflows, orchestrated through predefined code paths, and agents, which dynamically direct their own processes. A dated conceptual landmark, cited as such. https://www.anthropic.com/engineering/building-effective-agents

[12] Anthropic, "Orchestrate subagents at scale with dynamic workflows", Claude Code documentation, accessed 30 August 2026: comparison table for subagents, skills, agent teams and workflows ("Who decides what runs next": "Claude, turn by turn" / "Claude, following the prompt" / "The lead agent, turn by turn" / "The script"; "What's repeatable": "The instructions" for a skill, "The orchestration itself" for a workflow); determinism constraint ("Claude Code makes Date.now(), Math.random(), and a no-argument new Date() throw inside the script, so that a relaunched run repeats the same agent() calls"). Primitive shipped at the end of May 2026. https://code.claude.com/docs/en/workflows

[13] Cornelia Davis, "Temporal Agent Harness: durable agent infrastructure", Temporal blog, 20 August 2026. https://temporal.io/blog/temporal-agent-harness-durable-agent-infrastructure

[14] Anthropic, System Card: Claude Opus 5, 24 July 2026. §8.13.6 Toolathlon Verified: 108 real tool-use tasks, more than 600 tools across 32 applications, trajectories of 20 to 26 turns; Claude Opus 5 obtains 80.6% Pass@1, 87.0% Pass@3 and 73.1% Pass³, with an average of 23.5 turns. §8.13.7 AutomationBench: Claude Opus 5 at maximum effort obtains 26.0%, against 17.0% for Claude Opus 4.8 and 17.4% for Claude Fable 5; at medium effort, 24% for $0.89 per task. PDF retrieved and converted locally on 30 August 2026. https://www-cdn.anthropic.com/c5fbac3f0b1280a933ebd26d3cb8bb9f5bdeaf48/Claude%20Opus%205%20System%20Card.pdf

[15] Daniel Shepard, Robin Salimans, "AutomationBench", arXiv:2604.18934, 21 April 2026: tasks drawn from real workflows on the Zapier platform, six domains (sales, marketing, operations, support, finance, human resources), autonomous discovery of the endpoints, layered business rules, decoys, programmatic scoring on the final state. "Even the best frontier models currently score below 10%." https://arxiv.org/abs/2604.18934

[16] Paul-Antoine Tual, « Le développement à décision gardée : quand le goulot passe de l'exécution à la décision », paulantoinetual.fr, 29 July 2026. /blog/developpement-a-decision-gardee

[17] Anthropic, "Skill authoring best practices", documentation, accessed 30 August 2026: high, medium and low degrees of freedom, image of the narrow bridge, instruction "prefer scripts for deterministic operations", pattern of analyse then plan then validate then execute then verify, and absence of a built-in tool for running the evaluations. https://platform.claude.com/docs/en/agents-and-tools/agent-skills/best-practices

[18] Model Context Protocol, official schema, revision 2026-07-28, ToolAnnotations interface: readOnlyHint defaulting to false, destructiveHint defaulting to true, idempotentHint defaulting to false, openWorldHint defaulting to true. https://github.com/modelcontextprotocol/modelcontextprotocol/blob/main/schema/2026-07-28/schema.ts

[19] Model Context Protocol, specification, revision 2026-07-28, "Tools" section: annotations to be treated as untrusted outside a trusted server, output schema that the server must respect and that the client should validate, human in the loop with the ability to refuse, confirmation on sensitive operations, timeouts and logging for auditing purposes. https://modelcontextprotocol.io/specification/2026-07-28/server/tools

[20] Model Context Protocol, official blog, "Tool Annotations as Risk Vocabulary: What Hints Can and Can't Do", 16 March 2026, Ola Hungerford (maintainer), Sam Morrow (GitHub), Luca Chang (AWS): an untrusted server can lie about its annotations, these do not constitute an enforcement mechanism, and real safety guarantees must live in deterministic controls. https://blog.modelcontextprotocol.io/posts/2026-03-16-tool-annotations/

[21] Kumar Shashwat et al., "OrchestraBench: Evaluating Multi-Agent Orchestration Failure Modes, Recovery, and Decomposition Quality", arXiv:2608.05263, 5 August 2026: blind replay reproduces latent faults and lengthens the time to detection; the authors themselves describe their results as probes of mechanisms in a controlled chain, and not as measurements on a production workload. https://arxiv.org/abs/2608.05263

[22] OWASP GenAI Security Project, "OWASP Top 10 for Large Language Model Applications", 2026 edition, published at the beginning of August 2026, licence CC BY-SA 4.0: methodology (7,714 real incidents collected, 6,639 classified, weighting of three quarters community vote and one quarter incident record), chapter LLM01 Prompt Injection ("no reliable prevention mechanism exists today", "defense is therefore architectural rather than interceptive") chapter LLM03 Excessive Agency (complete mediation, authorisation implemented in the logic of the programme) and opening letter from the project leads ("Stop trying to build a model that cannot be fooled. Build the system around it, so that when the model is fooled, and it will be, nothing important breaks."). Content reused here under the Creative Commons Attribution-ShareAlike 4.0 licence, https://creativecommons.org/licenses/by-sa/4.0/. https://github.com/GenAI-Security-Project/GenAI-LLM-Top10

[23] Ruksat Khan Shayoni, Muhammad Faraz Shoaib, S M Asif Hossain, M. F. Mridha, "NetInjectBench: Benchmarking Indirect Prompt Injection in Tool-Using Large Language Model Agents for Network Operations", arXiv:2607.10490, 11 July 2026: 130 scenarios, 240 attack cases, three open models (Qwen2.5-7B, Llama3.1-8B, Mistral-7B); naive run 82.50% dangerous actions, defences at the level of the instructions 25.63% / 21.67% / 18.33% / 10.00%, static allow-list 5.00% with 0.00% utility and 100.00% over-blocking, metadata-sensitive policy gate 0 out of 240 with a Wilson upper bound of 1.58%, 99.17% and 100.00% of utility preserved. https://arxiv.org/abs/2607.10490

[24] ANSSI, « Recommandations de sécurité pour un système d'IA générative », ANSSI-PA-102, 29 April 2024: recommendation R9, prohibit the automated use of AI systems for critical actions on the information system, and recommendation R27, limit automatic actions from an AI system processing uncontrolled inputs. A normative document predating the freshness window for market sources, cited with its date. https://cyber.gouv.fr/publications/recommandations-de-securite-pour-un-systeme-dia-generative

[25] OpenTelemetry, GenAI semantic conventions, repository open-telemetry/semantic-conventions-genai created on 5 May 2026 (recorded on 30 August 2026, last push on 27 August 2026); the agent and tool-call spans carry the Development status, defined in specification/maturity-levels.md by "The component SHOULD NOT be used in production. The component MAY be removed without prior notice." https://github.com/open-telemetry/semantic-conventions-genai

[26] Dex Horthy (HumanLayer), "12-Factor Agents", GitHub repository humanlayer/12-factor-agents, created on 30 March 2025: 25,590 stars and last commit on the main branch dated 21 September 2025, recorded by a call to the GitHub API on 30 August 2026. Factor 8 is entitled "Own your control flow". https://github.com/humanlayer/12-factor-agents

[27] Paul-Antoine Tual, « Ingénierie des systèmes agentiques : règles d'or, architecture et sécurité du Human-in-the-Loop », paulantoinetual.fr, 4 July 2026. /blog/ingenierie-systemes-agentiques-human-in-the-loop

[28] Inngest, "Durable agents", documentation, accessed 30 August 2026: "A workflow DAG has a known shape at design time [...] In contrast, an agent's shape is decided at runtime by the model [...] The workflow graph is drawn as the agent runs", and the resolution proposed, non-deterministic code on the first pass and deterministic replay on resumption, with the memoised results forcing the same path. https://www.inngest.com/docs/learn/durable-agents

[29] Jaideep Ray, "The Constraint Tax: Measuring Validity-Correctness Tradeoffs in Structured Outputs for Small Language Models", arXiv:2605.26128, 20 May 2026: 15,000 generations on Qwen2.5-0.5B, Qwen2.5-1.5B and SmolLM2-1.7B; hard-schema decoding takes structural validity from 61.5% to 100.0% and lowers answer accuracy from 19.7% to 11.0%, with wrong but valid outputs rising from 49.5% to 88.9%; on a tool-call schema (Qwen2.5-1.5B), 91.5% executable accuracy by simple instruction against 48.0% under a hard schema, at 100% validity in both cases; recommended pattern "reason free, constrain late". https://arxiv.org/abs/2605.26128

[30] Mengqi Yuan et al., "OSWorld 2.0: Benchmarking Computer Use Agents on Long-Horizon Real-World Tasks", arXiv:2606.29537, 28 June 2026 (v2 of 13 July 2026): 108 long workflows, median of around 1.6 hours of human work per task, 318 tool calls on average; under the principal binary completion metric at 500 steps, the best configuration tested reaches 20.6% of tasks for a partial score of 54.8%, with GPT-5.5 topping out at around 13%. https://arxiv.org/abs/2606.29537

[31] Paul-Antoine Tual, « Conception agentique : pourquoi Cowork ne construit pas des agents durables », paulantoinetual.fr, 27 August 2026. /blog/cowork-agents-ia-durables

[32] Deloitte, "AI agents are only the beginning: The path to agentic transformation", 11 August 2026: survey conducted from April to June 2026 among 501 American executives, all the organisations questioned piloting agentic solutions at a minimum, supplemented by 20 interviews. https://www.deloitte.com/us/en/insights/industry/technology/path-to-agentic-transformation.html