A chatbot writes an answer. A copilot prepares it in the CRM. An agent searches the file, updates the status, schedules an appointment and sends the message. Potentially the same model; an entirely different risk surface.
Autonomy is not an interface. It is authority to act.
1. Definition: assistants, copilots and agents form an autonomy scale
An AI assistant responds to a request and produces an output that the user transfers or applies. A copilot is integrated into a software context, proposes, completes or explains, while the person remains in control of the sequence.
An AI agent receives an objective, observes an environment, plans or selects steps, invokes tools and adapts its next actions to their results. It can read, write, communicate, trigger a workflow or coordinate other components.
The boundary is not the product label. A product called "agent" can only perform a fixed workflow; a copilot with a send button already has an engaging act. Classify actual capacity, permissions and reversibility.
2. Key figures: capabilities are improving quickly, but reliability remains uneven
- The Stanford AI Index 2026 indicates that success on OSWorld, a computer task benchmark, has increased from about 12% to 66% in one year. Even in this structured framework, the best systems still fail in approximately one case out of three.
- The reported organizational adoption of AI was 88% in Stanford's survey, but the deployment of agents remained in the single digits in almost every business function. Use of AI and autonomous delegation are not equivalent.
- METR measures the "time horizon": duration of software tasks that a frontier agent can complete with a given level of reliability. Its historical trend has doubled approximately every seven months, but METR points out that the result depends on tasks, human baselines and configuration.
- EnterpriseBench, a paper accepted at EMNLP 2025 and available as a preprint, 500 HR tasks, finance, administration and engineering were simulated; the best performing agents reached 41.8% of completion. This emerging study should be read as a signal, not as a production standard.
- NIST repeated five indirect injection attacks 25 times against agents: the mean rate of attack success increased from 57% to 80%. A single test underestimates the risk when the attacker can try again.
- In December 2025, OWASP has published a Top 10 specific for agentic applications from contributions from more than 100 researchers and practitioners, covering misappropriation of behaviour, misuse of tools, abuse of identity and privileges.
The trajectory invites you to build now, but in scopes where an error is visible, contained and recoverable.
3. The autonomy scale: choose between six levels without relying on marketing labels
Each level inherits the controls of the previous one. You only climb when the gain justifies the extra freedom.
4. Level 0 — Response without privileged context
At this stage, the model transforms a given text: reformulation, summary, ideation or light extraction. It does not access internal data or tools.
The value comes from speed and shape. The risks concern the confidentiality of the entry, accuracy, rights and use of the output. A charter, an approved environment and human validation are often sufficient for weak cases.
Example without context: prepare three variants of a message from non-sensitive, verified information.
5. Level 1 — A response rooted in a corpus
The system searches authorised documents and returns a cited answer. It has more context, but no writing rights.
Evaluate retrieval, faithfulness, versioning, rights and abstention. A permission must filter before retrieval: hiding the quotation after the model has read the document does not protect the secret.
Document example: Answer a procedural question with a link to the exact page and date of validity.
6. Level 2 — Copilot within an application
The copilot knows the current object and proposes an action that the user approves: CRM field, response, query, code or analysis. It shortens the flow without choosing the next step alone.
The interface shows proposal, sources, modifications and consequence. The "Accept All" button should not make the verification more expensive than manual execution.
Copilot example: pre-fill a report and suggest tasks, with explicit confirmation.
7. Level 3 — Read-only and simulation agent
The agent selects several searches, calls tools with no external effect and prepares a plan or simulation. It can explore, but not modify production systems.
This level reveals the system's real ability to plan, manage tool errors and stay within the perimeter. It makes it possible to compare proposed and human decisions on historical cases without exposing the company.
Example in simulation: analyse an incident, gather logs and documentation, and then propose the diagnostic steps.
8. Level 4 — Reversible writing agent
The agent creates a draft, ticket, label, cancellable reservation or limited update. The action has dedicated identity, minimum permissions, budget and logging.
The changes are idempotent, versioned and reconciled. Human control can be systematic at the outset, then targeted according to the evidence and the consequence.
Reversible example: create and prioritise tickets from incoming requests, without closing them or committing an expense.
9. Level 5 — Supervised action-taking agent
The agent can communicate outside, change a price, make a payment or make an important decision. The file requires separation of roles, approvals, thresholds, sandbox, red teaming, fallback mode and recourse.
Certain uses must remain prohibited or subject to sectoral rules. The technical possibility never constitutes a legal or managerial authorization.
Controlled high-impact example: Prepare a Supplier Order and request double approval before sending.
Level 5 is not a medal. Many processes are better at Level 2 or 4.
10. The security file: nine pieces of evidence before production
Any professional agent arrives with a safety case: a structured set of arguments and evidence showing that the service is sufficiently controlled in its context. This Logiks framework is inspired by critical system practices without claiming certification.
11. Evidence 1 — A bounded task
Define trigger, goal, tools, data, population, output, duration, budget and bans. "Managing the customer relationship" is not a perimeter; "preparing an appointment proposal from a qualified request, without sending" is one.
List terminally acceptable states: success, need for information, transmission, refusal and failure. Continuing until something is produced can invent a solution when abstention was correct.
12. Evidence 2 — Dedicated identity and permissions
The agent does not reuse the account of a human or an administrator credential. Its identity is authenticated, limited by tool, action, resource, environment, amount and duration.
Tokens are short, secrets remain outside the model context and the delegation verifiable. A human approval creates a narrow authorisation for the act, not permanent general access.
NIST worked in 2026 on the identity and authorization of agents precisely because their actions went through several systems. The traditional IAM principles remain the basis, adapted to more dynamic software actors.
13. Evidence 3 — Tools as contracts
Each tool has schema-defined input, output, error, timeout, ID and effect. The agent does not freely generate a destructive request when a limited function "propose_cancel" is enough.
Validate the output of the model before the call and the tool's response before it is reused. A site, email or external file remains unreliable, even if its text resembles an internal instruction.
14. Evidence 4 — A tested hostile environment
Indirect injection places malicious instructions in the data that the agent consults. NIST describes diversion as a persistent difficulty, especially when instructions and data share the same channel.
Build scenarios: page asking to exfiltrate a secret, attachment modifying the beneficiary, ticket inviting to ignore the policy, encoded string, conflict between tools and repeated attack. Measure successful legitimate tasks, successful attacks and degradation caused by defenses.
A defense that blocks everything is safe but useless. The assessment must cover safety and capacity simultaneously.
15. Evidence 5 — A multi-run evaluation
Models are probabilistic. Replay each case several times, with variations in context, latency, order and tool errors. Report full success rate, partial success, cost, duration and consistency.
If a task consists of five successful steps each at 95% and their mistakes are independent, the theoretical end-to-end success rate is 0.95^5 ≈ 77.4%. Long orchestration amplifies fragility.
Use a final status validation, not the agent's account. A "completed" message does not prove that the ticket, payment or calendar matches the system of record.
16. Evidence 6 — Effective supervision
Decide what the human sees and when. Before action: plan, data and consequence. During: unusual steps or exceedance. After: result, deviation and possibility of cancelling.
Supervision must have time, information and authority. Asking for one hundred identical validations per hour turns the person into a biological button and increases the automation bias.
17. Evidence 7 — Observability without excessive monitoring
Trace objective, version, tools, controlled arguments, latency, costs, errors, approvals and final status. Protect the data, limit retention and separate analysis of the individual employee performance assessment.
The traces must answer three questions: what happened, why could the system act and how to repair? Detailed internal reasoning is neither always available nor necessary; external decisions and evidence are more important.
18. Evidence 8 — Graceful degradation and recovery
Set automatic shutdown, kill switch, persistent case state, deterministic fallback, human fallback and reconciliation. Simulate tool failure, unavailable model, explosive cost, loop, inconsistent data and partial response.
A limit of steps, time, tokens and money prevents the agent from pursuing indefinitely. A suspended state keeps the record for recovery without replaying the successful acts.
19. Evidence 9 — The economics of autonomy
Cost includes model, multiple calls, tools, latency, review, observability, incidents and maintenance of evaluations. Compare the less autonomous copilot or workflow.
In this example, the automaton saves twenty minutes on 5,000 tasks, but costs €1.20 inference, €0.80 in tools and five minutes review at €40/hour. The direct cost per task is €5.33; the value of the gross time saved is €13.33, or €8 before integration, errors and support.
If a copilot saves twelve minutes for 1 €, without risk of writing, its net savings may be higher. Autonomy must justify the added complexity.
20. Design case: a B2B appointment-booking agent
The need seems simple: receive a request, propose slots and update the CRM. The real journey includes spindles, private agendas, specialised commercials, existing customers, duplicates, consent, timelines and brand messages.
20.1. copilot version
The system summarizes the demand, identifies the sector, suggests three available slots and prepares the message. The salesperson approves the recipient, text and schedule. This version measures quality of qualification and correction rate without autonomous sending.
20.2. Reversible agent version
After proof, the agent can put a temporary option in the calendar and create a CRM task. It does not contact the prospect. Options expire, conflicts are checked when written and the agent's identity can only read the necessary availabilities.
20.3. Communication version
Sending is open only to compliant applications, with approved templates, verified domain, limited frequency and exclusions. A new type of customer, contradictory information or a slot that violates policy returns to the commercial.
The final test checks the status of the two calendars, CRM, recipient, language, content and no double message. The proposed appointment rate is not enough if 3% of the invitations are sent to the wrong person.
The team stops at level 4 if the additional value of the autonomous sending does not cover its control. This decision is a sign of maturity.
21. What an agent can break: define a risk budget before a token budget
The error budget describes the number and severity of acceptable failures over a period, as well as the response triggered when the threshold is crossed. It complements the technical cost: a low-cost execution is not cost-effective if its correction mobilizes several teams or reaches a customer.
For an agent who creates internal tickets, the company can accept twenty misclassifications among ten thousand tickets, provided that no one closes a critical incident and that each error remains correctable before the SLA deadline. For a change of bank details, the budget of false positives must in practice be zero: any proposal requires an independent verification and an authorised person.
Build a taxonomy with four classes: nuisance, interruption, incorrect commitment and serious harm. Each class receives detectability, recovery time, cost, person affected and ceiling, which prevents a good average rate from masking a rare error whose consequence dominates the entire portfolio.
Monitoring distinguishes between failures detected by the service, operator, customer and by chance. An apparent decrease may be due to a loss of observability, especially if the team reduces the review at the same time as it increases autonomy.
Add a near-incident budget. A properly blocked call attempt, a loop stopped before writing or an attack without exfiltration does not create any damage, but reveals a threat that must inform the controls and new scenarios.
The climbing rule is written in advance: a serious incident shall immediately suspend the action concerned; three incorrect commitments over a week restore systematic approval; an increase in nuisances above the threshold triggers analysis without interrupting the entire service.
This mechanism avoids two extremes. The team does not cut a useful agent after the first imperfect ranking, and it does not maintain a dangerous action on the ground that 99% of the tasks remain correct.
Finally, the committee compares prevention costs, detection costs and recovery costs. Sometimes, limiting permission removes an entire class of damage for almost nothing; elsewhere, double approval on each case destroys the benefit and justifies staying at the copilot level.
The error budget makes tolerance explicit. It transforms an abstract discussion of trust into decisions of service, supervision and investment.
Without this framework, a management can quietly accept thousands of small mistakes because the overall rate remains flattering, then discover too late that only one rare category — the wrong recipient, excessive permissions or unrecoverable payment — concentrated almost all economic and reputational loss.
With this framework, business teams, security and product teams address the same question: not whether the model appears intelligent during a demonstration, but to determine what consequences remain possible, how they will be detected, who has the authority to suspend and what evidence will allow a controlled return.
22. Minimum architecture for a deployable agent
- Authenticated entry and classification of need.
- Policy engine external to the rights and prohibitions model.
- Orchestrator with step limits, time and cost.
- Model(s) routed according to task and risk.
- Hardened tools with schemas, identity and idempotency.
- Controlled memory by range, source and duration.
- Validation of inputs, outputs and states.
- Human exposure at engaging borders.
- Observability technique, trade, cost and security.
- Recovery by file, rollback and manual mode.
The model is only one component. Changing a model doesn't fix excessive permission or a non-idempotent tool.
23. Logiks four-tier programme
23.1. Tier A — 100 historical tasks
Replay without writing tool. Establish human baseline, success, cost and taxonomy of errors. Build the attacks.
23.2. Tier B — Real-time simulation
Observe actual entries, propose actions and compare to decisions, without effect. Measure distribution and drift.
23.3. Tier C — Reversible writing subject to approval
Open a bounded tool, log, approve each act and test recovery. Increase the volume per batch.
23.4. Tier D — Targeted supervision
Automate green cases after proof, keep sampling and thresholds, and then periodically reassess. Red acts remain approved.
Progression depends on pre-recorded criteria. It does not depend on the date of the launch committee.
24. Logiks recommendations: twelve questions before calling a system an AI agent
- Can it act or only respond?
- Who defines its exact purpose?
- What tools and permissions does it have?
- What external data can influence this?
- How does it refuse a task?
- Is the final state independently verified?
- How many executions have been tested?
- What act is irreversible?
- Who can stop immediately?
- How can it resume without duplication?
- What is the full cost per task?
- Why isn't a copilot enough?
If the answers remain vague, autonomy is premature.
25. FAQ
25.1. What is the difference between a copilot and an AI agent?
The copilot proposes in a human-led flow. The agent pursues a goal, chooses steps and uses tools. Hybrid products are classified by actual capacity.
25.2. Should you start with an autonomous agent?
No. Start by reading, simulation or reversible writing. Autonomy increases only when its value exceeds the cost of control.
25.3. How should you measure an agent?
End-to-end success verified in the environment, consistency over several executions, cost, duration, security, human intervention, final state and avoided damage.
25.4. Can an agent read email?
Technically yes, but emails are unreliable and sensitive data. Limit the box, rights, actions and test resilience to indirect prompt injection.
25.5. Is human-in-the-loop enough?
Only if the human has information, time, competence, authority and recourse. Otherwise, validation becomes mechanical.
25.6. How can you prevent loops and excess costs?
Step limits, tokens, time, budget, tool calls and attempts; repeat detection; stop and roll back.
26. Conclusion
An agent is not more advanced merely because it acts more. It is more demanding because its mistakes cross the boundaries of systems.
Choose the minimum useful level. Bound the task. Give a narrow identity. Test several executions and hostile data. Check the final state. Prepare the stop before autonomy.
Control makes action possible.
27. Main sources
- Stanford HAI, AI Index Report 2026 — Technical Performance: https://hai.stanford.edu/ai-index/2026-ai-index-report/technical-performance
- Stanford HAI, AI Index Report 2026 — Economy: https://hai.stanford.edu/ai-index/2026-ai-index-report/economy
- METR, Task-Completion Time Horizons of Frontier AI Models, updated May 8, 2026: https://metr.org/time-horizons/
- Vishwakarma et al., EnterpriseBench, accepted at EMNLP 2025, prepublication of October 2025: https://arxiv.org/abs/2510.27287
- NIST CAISI, Strengthening AI Agent Hijacking Evaluations, updated on December 19, 2025: https://www.nist.gov/news-events/news/2025/01/technical-blog-strengthening-ai-agent-hijacking-evaluations
- NIST, Security Considerations for AI Agents, NIST AI 800-5, May 2026: https://www.nist.gov/publications/summary-analysis-responses-request-information-regarding-security-considerations-ai
- NIST, Lessons Learned: Tool Use in Agent Systems, August 5, 2025: https://www.nist.gov/news-events/news/2025/08/lessons-learned-consortium-tool-use-agent-systems
- OWASP GenAI Security Project, Top 10 for Agentic Applications, December 2025: https://genai.owasp.org/2025/12/09/owasp-top-10-for-agentic-applications-the-benchmark-for-agentic-security-in-the-age-of-autonomous-ai/