Agentic processes in business: where code, skills and judgement belong

Skill discovery is measured as behaviour, not as a switch

The Agent Skills documentation proposes a statistical trigger protocol that reveals the nature of the format: a description guides a model rather than constituting a guaranteed function call [1].

• Assemble about twenty queries that should or should not trigger the skill.
• Run each query three times to observe variation between trials.
• Use 60% of the examples for improvement and hold out 40% for validation.
• Calculate the trigger rate; the default 0.5 threshold is a protocol setting, not a production quality promise.

This protocol answers a discovery question — ‘does the model think to load the right capability?’ — while a business process must also establish completeness, accuracy and control over effects.

• A well-described skill may trigger far more often than the acceptance threshold.
• A simple request may bypass it if the model believes it can answer directly.
• The same input may produce a different skill choice or output on another run.
• Mandatory actions should therefore be enforced by the orchestrator rather than semantic discovery alone.

What a skill actually preserves

A skill is a folder centred on SKILL.md, whose metadata supports discovery and whose body, scripts, templates and references convey a working method [2] [3].

• name identifies the capability and description explains when to use it.
• The Markdown body describes the procedure, criteria and edge cases.
• Supporting resources are read only when they become necessary.
• Scripts execute operations that benefit from remaining deterministic.

Progressive loading reduces context use but creates a weak point because description quality and catalogue size influence what the model discovers.

• The metadata for available skills is visible before their bodies are loaded.
• A vague description raises false triggers; a narrow one creates missed triggers.
• Large catalogues require discovery tests after additions or changes.
• Trigger evaluations should remain separate from output quality evaluations.

The format is a useful vehicle for transferring know-how across tools, provided each environment is validated instead of treating portability as absolute.

• The standard was opened after its initial launch by Anthropic [4].
• OpenAI, Microsoft and Google document support in some of their products [5].
• Permissions, available tools, commands and paths remain client-specific.
• The durable asset is the written method; its execution must be qualified on every platform.

An agentic workflow organises judgement without surrendering the process

This article uses ‘workflow’ for an execution path controlled by code, following Anthropic’s distinction between predefined paths and agents that dynamically direct their own use of tools [6].

• Code carries queries, filters, joins, conditions, limits and recovery.
• Model calls appear where an answer cannot be specified completely in advance.
• The graph may include dynamic branches without giving up persistence, logging or authorisation.
• The choice between a workflow and an agent loop depends on predictability and the cost of error.

Following up unanswered quotations provides a concrete division between rules, judgement and commitment without claiming that three categories cover every business domain.

#	Step	Nature	Executor
1	Select quotations unanswered for fifteen days	Verifiable	Query
2	Read the exchanges and detect an implicit refusal	Interpretive	Agent, structured output
3	Exclude disputes, deduplicate and cap the batch	Business rule	Versioned code
4	Draft a tailored follow-up	Generative	Agent
5	Save each message as a draft	Controlled effect	Idempotent code
6	Present a summary to the manager	Synthesis	Agent
7	After approval, send and log	Commitment	Code with human authorisation

The interpretive step should return a checkable object rather than free prose so that the model’s reading remains separate from the company’s decision.

• implicit_refusal provides a value the workflow can use.
• reason summarises the rationale needed for review.
• source_quote points back to the original material.
• A schema validates form, while a reference case or review checks substance.

Saving drafts separates creation from commitment and allows approval to cover the exact action rather than an abstract intention.

• The model drafts without holding permission to send.
• The system displays the recipient, content and attachments before approval.
• The authorisation expires or applies to a precisely defined batch.
• The log retains the proposal, decision and effect actually executed.

End-to-end reliability requires explicit assumptions

Multiplying the success rate of every stage is useful only as an illustration under independence and is neither a worst case nor a general lower bound.

• With twenty events each marginally successful 95% of the time, joint success may range from 0% to 95% depending on dependence.
• Under independence, the calculation is (0.95^{20} \approx 35.8%).
• With three events at 95%, the possible range is 85% to 95%; independence gives (0.95^3 \approx 85.7%).
• A real system needs conditional probabilities estimated from representative traces.

Toolathlon measures repeat runs of the same benchmark task, so its results describe stability between trials rather than simulating consecutive stages of a process [7].

• The benchmark reports 80.6% first-trial success for the leading cited configuration.
• Success across three repeated trials is 73.1%, compared with 52.4% from naïvely multiplying 80.6% three times under independence.
• The difference indicates dependence between repetitions on this test set.
• It establishes no universal bound for a business chain and no rate for a particular client.

AutomationBench instead measures the final state of long workflows inspired by Zapier customers in a simulated company, bringing it closer to cross-application orchestration without turning it into production evidence [11].

• The benchmark covers sales, marketing, operations, support, finance and human resources.
• The agent must discover interfaces, follow layered rules and avoid decoy data.
• The April 2026 paper places the best evaluated models below 10% full completion.
• The result supports local controls but does not give the failure probability of a particular workflow.

METR’s time horizons provide a different reference when ‘duration’ is read as human baseline task length and ‘80%’ as four successes in five in the statistical model, rather than as continuous autonomy or a universal production requirement [8].

• The tasks mainly cover software engineering, machine learning and cybersecurity.
• Duration measures the expert human’s time on the task, not the agent’s elapsed time.
• An 80% horizon is where the fitted curve predicts an 80% success probability.
• Acceptable reliability depends on verifiability and consequences; METR notes that some critical, hard-to-verify work may require more than 98% [9].

Four controls make orchestration operable

An agentic process becomes operable when outputs, retries, evaluations and authorisations are treated as parts of the system rather than instructions addressed to the model.

• Output contracts: schemas, business rules and source evidence to check form and substance.
• Idempotency and recovery: operation keys, persistent state and compensation to prevent duplicate effects.
• Evaluations: known cases, risk-based thresholds and comparisons before changing a model or instruction.
• Authorisation and trace: least privilege, approval of the exact action and an append-only log.

MCP provides vocabulary for describing tools, but its annotations are declarative hints and cannot replace a policy enforced by the client [10].

• readOnlyHint describes the claimed absence of modification.
• destructiveHint and idempotentHint qualify the effects of a writing tool.
• openWorldHint signals possible interaction with external entities.
• An untrusted server may misdescribe itself; authorisation needs a trusted source and actual state.

Security and reliability converge on one rule: the model may propose an action, while the program decides whether that action is permitted and under which conditions.

• Show the tool, its inputs and the scope of the action before sensitive approval.
• Restrict rights to the necessary scope and refuse dangerous combinations of capabilities.
• Test failures, timeouts, recovery and double submissions before launch.
• Retain the evidence needed to explain, reverse or resume execution.

NetInjectBench illustrates both the cost of a crude barrier and the value of an execution policy within an experimental protocol whose rates cannot be assumed outside the benchmark [12].

• Naïve execution produces unsafe actions in 82.50% of 240 attacks in this network benchmark.
• A static allowlist reduces the rate to 5% but blocks every approved change.
• A gate using trusted metadata records 0 unsafe actions out of 240 and preserves 99.17% to 100% of measured usefulness.
• The result explicitly depends on metadata integrity and therefore needs a trust root independent of hostile content.

ANSSI draws the same boundary in normative guidance by recommending that automated critical actions on information systems be prohibited and that actions arising from uncontrolled inputs be limited [13].

• R9 concerns critical actions on the information system.
• R27 concerns automatic actions triggered by inputs such as internet data or received messages.
• R29 calls for the logging of AI-system processing.
• Practical application depends on the organisation’s risk analysis and technical scope.

Three questions for assigning each step

The split should be made before model selection by examining verifiability, the nature of the work and the consequence of the output in that order.

• One checkable answer: counting, filtering, joining, calculating and applying a stable rule generally belong in code.
• Interpretive work: reading unstructured material, reconciling sources or adapting a presentation may justify a model.
• Consequential output: an irreversible, financial, regulated or customer-visible action requires authorisation independent of the model.

This grid remains a design heuristic because some tasks mix calculation and judgement and should be decomposed further rather than forced into one category.

• Extract the verifiable substeps first.
• Make the business decision once and version it if it is stable.
• Bound the interpretive step with limited inputs and a checkable output.
• Put approval at the last moment before the consequential effect.

Three limitations to design for

The first limitation concerns processes whose shape emerges during execution, where a fully fixed graph would be too rigid but a durable engine can record decisions and resume the path actually taken.

• Investigations, software development and open research contain unpredictable subtasks.
• The model may choose the next exploration within a permission envelope.
• The engine persists results and replays completed steps after interruption.
• Cost, time and iteration limits prevent the loop from drifting indefinitely.

The second limitation concerns structured outputs, because syntactic validity guarantees neither accuracy nor usefulness.

• Constrained JSON can remove errors of form.
• A model may still produce a false but valid value.
• Business verification must therefore examine fields, sources and invariants.
• If constrained decoding harms reasoning, the schema can be applied when the result is handed over.

The third limitation comes from benchmarks, which isolate useful capabilities without reproducing a whole system, its data and its consequences.

• Toolathlon measures repeatability across tool-use trials.
• METR relates success to human baseline duration for well-specified technical tasks.
• OSWorld 2.0 reports 20.6% full completion against a 54.8% partial score on 108 long workflows, indicating a gap between successful operations and a finished task [14].
• Architecture decisions need local evaluations and simulated incidents.

The first project fits on a process map

An SME can begin without a dedicated platform by choosing a frequent or periodic, measurable and reversible process, then describing its inputs, outputs, rules and effects before automating it.

• Daily: triage incoming requests and suggest a category.
• Weekly: prepare follow-ups for unanswered quotations.
• Monthly: assemble data and prepare a committee pack.
• Avoid initially: payments, contractual commitments or external communication without approval.

The first deliverable is a numbered list that makes the process debatable and testable without pretending that half a day can resolve every exception, access right or data quality problem.

• Describe the input state and expected result of each step.
• Assign the step to code, a model, an upstream human decision or an approval.
• Record exceptions, missing data and effects that cannot be reversed.
• Define a few reference cases and the log required for recovery.

A skill then preserves the working method, while the workflow preserves the order, state and guarantees the organisation needs.

• Revise the skill when the business method changes.
• Revise the workflow when a rule, authorisation or connected system changes.
• Re-evaluate both when the model or execution environment changes.

Book the Junyr AI maturity audit: a free, no-commitment 30-minute video call to choose a first process to assess.

---

References

[1] Agent Skills, ‘Optimizing skill descriptions’, accessed 6 September 2026: positive and negative queries, three trials, train-validation split and default threshold. https://agentskills.io/skill-creation/optimizing-descriptions

[2] Anthropic, ‘Agent Skills’, accessed 6 September 2026: skill structure and progressive disclosure. https://platform.claude.com/docs/en/agents-and-tools/agent-skills/overview

[3] Agent Skills, ‘Specification’, accessed 6 September 2026: metadata and format structure. https://agentskills.io/specification

[4] Anthropic, ‘Skills for organizations and the skills directory’, 18 December 2025. https://claude.com/blog/organization-skills-and-directory

[5] Official documentation: OpenAI, Build skills; Microsoft, Agent skills; Google, Gemini CLI skills, accessed 6 September 2026.

[6] Anthropic Engineering, ‘Building effective agents’, 19 December 2024: the distinction between predefined workflows and dynamically controlled agents. https://www.anthropic.com/engineering/building-effective-agents

[7] Anthropic, System Card: Claude Opus 5, 24 July 2026, §8.13.6 Toolathlon Verified: Pass@1 and Pass³ rates, cited as repeated benchmark trials. PDF

[8] METR, ‘Task-Completion Time Horizons of Frontier AI Models’, updated 8 May 2026: definition using human baseline task length and a fitted success curve. https://metr.org/time-horizons/

[9] Thomas Kwa, METR, ‘Clarifying limitations of time horizon’, 22 January 2026: scope, uncertainty and reliability requirements according to verifiability. https://metr.org/notes/2026-01-22-time-horizon-limitations/

[10] Model Context Protocol, ‘Tools’, 18 June 2025 revision, and MCP blog, ‘Tool Annotations as Risk Vocabulary’, 16 March 2026: output schemas, untrusted annotations and human review. Specification; annotation analysis.

[11] Daniel Shepard and Robin Salimans, ‘AutomationBench’, 21 April 2026: 47 applications, layered business rules and end-state scoring. https://arxiv.org/abs/2604.18934

[12] Ruksat Khan Shayoni et al., ‘NetInjectBench’, 11 July 2026: 130 scenarios, 240 attacks and defence comparisons under a metadata-integrity assumption. https://arxiv.org/abs/2607.10490

[13] ANSSI, ‘Security recommendations for a generative AI system’, 29 April 2024, recommendations R9, R27 and R29. Official English publication

[14] Mengqi Yuan et al., ‘OSWorld 2.0’, 28 June 2026: 108 long workflows, full-completion and partial-score metrics. https://arxiv.org/abs/2606.29537