Approval-driven automation: why “yolo automation” is dangerous for production operations

In presentations, AI automation looks neat: an agent detects a problem, picks a solution, executes, reports. In reality, such an agent acting without confirmation in production ops is a source of incidents, data loss and litigation. This article argues why “yolo automation” — an agent pulling the trigger by itself — is unfit for any operation with impact and why the approval-driven pattern, in which the user approves each impactful action via an asynchronous channel like Telegram, is the best combination of speed, control and auditability.

TL;DR

• Yolo automation works in demo. It fails when the agent gets it wrong once in an impactful context.
• Approval-driven automation keeps speed for trivial requests and inserts a human check only for impactful actions.
• Telegram inline approval with buttons is the right UX: response in seconds, trace in history, accessible from phone.
• Three real examples show where the pattern stopped incidents: backup deletion, service restart, DNS modification.
• The cost in speed is on the order of seconds; the gain in auditability and trust is permanent.

What “yolo automation” means

The term is not academic; it is vernacular for an agent that receives a request, decides an action, and executes it without an intermediate confirmation step. The argument in favor of this design is simple: maximum speed, minimum human intervention. The argument against appears at the first significant error.

A yolo agent is only as good as the worst moment of the model powering it. Language models occasionally hallucinate, misinterpret ambiguous requests, mix contexts from parallel conversations, draw incorrect extrapolations from partial data. In demo, these errors cost zero. In production they can cost an incident night.

Direct results of a yolo error:

• Agent confused about which backup to delete deletes the current backup instead of the old one.
• Agent misunderstanding “restart agent service X” restarts “all agents”.
• Agent updating DNS on the wrong domain because two names are nearly identical.

None of these errors are theoretical. All have been reported by teams running AI agents with direct execution in production.

The approval-driven pattern

Approval-driven automation solves the problem by separating decision from execution and placing decision in the user’s hands. The steps:

1. The agent receives the user’s request.
2. The agent builds a textual plan: what action it will take, on which resource, with what parameters, what the risk is.
3. The plan is sent to the user via asynchronous channel — Telegram with inline buttons “Approve / Reject / Modify”.
4. The user approves, rejects or requests modifications. The response is recorded with timestamp and user ID.
5. On approval, the agent executes. On rejection, the agent closes the plan. On modification, the agent rebuilds the plan with the new input.
6. All three outcomes (approved, rejected, modified) are written to the audit database.

For trivial requests with no impact (info, status, lookup), the agent answers directly without a plan. For impactful requests, the plan is mandatory. The “trivial vs impactful” classification is per action, not per user.

Why Telegram (or an equivalent channel)

Approval can happen in a web UI, in email, in Slack, in Telegram. Each has advantages and disadvantages. Telegram is our choice for ops for practical reasons:

• Response latency. The notification reaches the phone instantly. Approval can come in 5-10 seconds.
• Inline buttons. The user does not need to type; a single tap of “Approve” or “Reject” is enough.
• Persistent history. The conversation stays in Telegram, resilient to local accidents.
• Mobile-first. Operations often happen outside office hours. The phone is always available.
• Multi-user. A request can be routed to one or more people who can approve.

For organizations with strict hosting requirements, an in-house web UI with push notifications can replace Telegram with similar UX. Email is the weakest option (high latency, no inline interaction, fragile to spam filters).

Three real case studies

Case 1: deleting old backups

User request: “delete backups older than 30 days on storage X”.

Yolo scenario: the agent lists backups, identifies candidates, deletes. Risk: if a backup’s timestamp is wrong (format or timezone), the agent deletes recent backups too. Irreversible loss.

Approval-driven scenario:

Proposed plan:
- I identified 47 backups older than 30 days (created < 2026-03-30)
- Estimated total space freed: 2.8 TB
- Most recent backup remaining: 2026-03-30 23:55
- Oldest: 2025-08-12

Approve deletion? [Approve] [Reject] [See full list]

In 2 seconds, the user sees whether the numbers are reasonable. Approves or rejects. If suspicious, “See full list” expands details.

In real operation, this pattern stopped an accidental deletion: the agent had proposed deleting 200 backups instead of 50, due to a wrong date comparison. The user noticed the number in the plan and rejected. Cost: 30 seconds of human time. Benefit: no backup lost.

Case 2: service restart

User request: “restart the logging service”.

Yolo scenario: the agent finds a service with a matching name, restarts it. Risk: if there are multiple similar-named services (logging-collector, logging-aggregator, logging-archive), the agent restarts the wrong one — or worse, all.

Approval-driven scenario:

Proposed plan:
- I will restart the service: logging-collector
- On host: primary production node
- Estimated impact: log loss in ~5 second window
- Other similar services not affected: logging-aggregator, logging-archive
- Action backup: if restart fails, I will report and NOT auto-escalate

Approve restart? [Approve] [Reject]

The user explicitly confirms name and host. We eliminate the ambiguity of “logging” which in colloquial English can refer to multiple things.

Case 3: DNS modification

User request: “add a DNS record for subdomain X”.

Yolo scenario: the agent assumes default values (TTL, IP), creates the record. Risk: TTL too high blocks future changes; wrong IP routes traffic nowhere.

Approval-driven scenario:

Proposed plan:
- I will create DNS record:
  - Subdomain: status.example.eu
  - Type: A
  - Value: <IP proposed by user in context>
  - TTL: 300 (5 minutes, for fast rollback)
  - Provider: <name of registrar where the domain is hosted>
- Post-creation check: I will read propagation for 60 seconds and report

Approve creation? [Approve] [Reject] [Modify TTL]

DNS is a sensitive domain where the agent must assume conservative defaults (small TTL), and the user must confirm the provider (in case multiple exist).

The cost in speed

The “yolo is faster” argument is correct but misleading. The difference is 5-15 seconds per impactful request. For low-to-medium-volume production operations (tens of impactful requests per day, hundreds without impact), this delay is insignificant.

For status / info requests with no impact, the agent answers without a plan. This covers the bulk of volume. Approval is reserved for impactful actions, where 15 seconds of thought are worth infinitely more than 0 seconds of regret.

Mistakes in approval-driven implementation

Mistake 1: automated approval through familiarity. Users seeing 100 plans daily start approving “ok ok ok” without reading. Solution: for high-impact actions (DNS, deletions, deploy), the agent refuses simple “ok” and asks for a specific phrase. For low-impact actions, “ok” is enough.

Mistake 2: plans too long. A 30-line plan is not read. Reduce to 5-10 lines with the user-action on the first row. Technical details on demand (“See details”).

Mistake 3: no approval timeout. If the user does not respond in 30 minutes, the plan should expire. Otherwise, a plan approved late might execute on stale context (e.g., the proposed backup no longer exists).

Executive conclusion

Approval-driven automation is not a limitation of an AI agent; it is the correct shape of an agent participating in impactful operations. The team stays in control, the agent accelerates, the audit is complete. The pattern scales: requests without impact go instantly, those with impact wait for a tap. The cost in speed is measurable in seconds per request; the gain in safety and trust is permanent.

For any CTO or head of ops evaluating an AI agent, the first question should be: “how does it ask permission for impactful actions?” If the answer involves “trust the model”, reconsider.

Related articles

• The propose-then-act architecture for AI agents
• Cost-aware LLM routing
• Pillar IRIS — the CAI Technology orchestrator agent
• Pillar Consulting — AI assessment

External sources

• NIST AI Risk Management Framework — Govern function — governance of automated decisions
• ITIL 4 Change Enablement practice — standard reference for change management in ops
• OWASP Top 10 for LLM Applications — LLM08 Excessive Agency — officially documented risk for agents acting autonomously
• ISO/IEC 42001:2023 — AI Management Systems — standard for AI systems governance
• “Constitutional AI” — Anthropic, arXiv 2212.08073 — design context for agents with explicit constraints

Next step

If your team is evaluating how to introduce AI into operations without losing control, we offer a 30-minute consultation at no cost.