Embedded Files
# Two Faces of "AI Agents": Why 90% of What You're Being Sold Is Just Scripts with LLM
## The Terminology Confusion Problem
When you hear "AI agent," what do you picture? An autonomous digital employee who solves complex tasks, writes code, debugs, tests, and only needs occasional oversight?
Marketing sells exactly this vision. But the reality is: **90% of what's called "agents" are just scripts with an LLM wrapper for routine tasks**.
Let's sort out the terminology, because it determines what you actually get and how much it will cost.
---
## Type 1: Autonomous Agent (Complex Problem Solver)
### What It Is
A system that:
- **Receives a complex, unformalized task** (e.g., "develop a feature based on a 10-page spec")
- **Independently plans steps** (breaks the task into subtasks, chooses execution order)
- **Uses tools** (terminal, browser, file system, API)
- **Adapts to changes** (if one approach doesn't work, tries another)
- **Requires human oversight** ("a foreman" who checks results and adjusts the course)
### Key Characteristic: **Non-determinism**
The task has no single correct path to solution. The agent must:
- Interpret requirements
- Make decisions under uncertainty
- Handle unexpected errors
- Improvise when the standard approach fails
### Examples
- **Hermes Agent** by Nous Research — writes code, debugs, compiles, checks in a browser
- **OpenClaw** — an autonomous developer working with git repositories
- **Devin** (by Cognition) — "the first AI engineer" who solves tasks based on specs
### How It Actually Works
**Without a "foreman" (human controller):**
- The agent fails at the very first unformalized section
- Starts "hacking" — generating meaningless actions
- Burns tokens in vain trying to fix errors
- If there's a **harness** (automatic checking system), it catches and stops the agent — that's good
**With a "foreman":**
- The person sets tasks, reviews PRs, adjusts the course
- The agent works like a "super-fast junior" but requires constant supervision
- The cognitive load on the person is enormous: you're not just a manager, you're a senior engineer babysitting a junior
### Scaling
**Running 10 such agents in parallel is a catastrophe:**
- Git conflicts (they modify the same files)
- Cascade failures (one broke something another depends on)
- Exponential growth in oversight time (not 10 hours, but 40+)
- Economic inefficiency (huge API bills with questionable results)
**The only sensible path:** first perfect one agent (write a reliable harness, automate checks), then scale. But even then, it's not "10 autonomous engineers" but "10 deterministic pipelines with LLMs at key stages."
---
## Type 2: Scripted Agent (Routine Automator)
### What It Is
A system that:
- **Receives formalized input** (structured, predictable)
- **Works according to a strict script** (deterministic set of steps)
- **Uses LLM only for narrow tasks** (e.g., text classification, response generation)
- **Doesn't require human oversight** (works autonomously because the task is predictable)
- **Scales in batches** (you can run 50 such "agents" simultaneously)
### Key Characteristic: **Determinism**
The task has clear input, clear solution paths, clear output. The LLM here is just a "smart function" doing what regular expressions or simple rules used to do.
### Examples
- **Call center bot** — calls clients, asks questions from a script, records answers in the database, generates a report
- **Email sorter** — reads incoming mail, classifies it (spam/important/normal), forwards to the right people
- **Report generator** — pulls data from the database, creates a weekly report in Markdown/PDF
- **Support chatbot** — answers FAQs from a knowledge base, escalates complex cases to a human
### How It Actually Works
**These aren't "agents" in the full sense.** They are:
- Scripts with an LLM wrapper
- Automation of routine tasks that were automated 20 years ago with regular scripts
- Just now LLM can handle slightly more complex cases (e.g., understanding natural language instead of regular expressions)
### Scaling
**Running 50 such "agents" is fine:**
- Each works in isolation, doesn't interfere with others
- No conflicts, no cascade failures
- Predictable API load, predictable costs
- Easy to monitor (if one goes down — just restart it)
---
## Why Marketing Confuses Them
### Reason 1: The Word "Agent" Sounds Cool
"Script with LLM" is boring. "AI agent" sounds futuristic — it sells.
So any chatbot that answers questions from a knowledge base is called a "support agent." Any bot that posts to Twitter on a cron schedule is called a "content agent."
### Reason 2: Blurred Boundaries
There are intermediate cases. For example:
- An agent that writes code according to a strict pattern (e.g., generates CRUD endpoints based on a database schema) — is that an autonomous agent or a script?
- An agent that calls clients but can improvise in dialogue — is that a script or an autonomous agent?
Marketing always chooses the "cooler" definition.
### Reason 3: Reluctance to Acknowledge Limitations
Admitting that "our agent" is actually just a script with an LLM means admitting it can't solve complex tasks. That lowers its perceived value.
So even if an agent works according to a strict script, it's called "autonomous," "self-learning," "solving complex tasks."
---
## How to Tell Them Apart
### Questions for Verification
1. **How formalized is the task?**
- If the task has clear input and clear solution paths → it's a script
- If the task requires interpretation and improvisation → it's an autonomous agent
2. **Can you run 50 such "agents" in parallel without chaos?**
- If yes → it's a script
- If no (conflicts, cascade failures) → it's an autonomous agent
3. **Is a human controller ("foreman") needed?**
- If no (the agent works autonomously, result is predictable) → it's a script
- If yes (without oversight the agent makes mistakes, burns tokens) → it's an autonomous agent
4. **What happens at the first error?**
- If the agent stops or returns an error → it's a script
- If the agent tries to fix the error, improvises, tries other approaches → it's an autonomous agent
---
## Real-World Examples
### Example 1: "Report Generation Agent"
**Marketing:** "Our AI agent automatically generates weekly reports by analyzing data from your CRM!"
**Reality:** It's a script that:
1. Runs a SQL query against the database
2. Creates a data table
3. Passes data to an LLM with the prompt "write a summary based on this data"
4. Returns a Markdown report
**This is not an autonomous agent.** It's a script with an LLM wrapper. The task is fully formalized, there's one solution path, no human oversight is needed.
---
### Example 2: "Feature Development Agent"
**Marketing:** "Our AI agent independently develops features based on specs, writes code, tests, and deploys!"
**Reality:** It's an autonomous agent that:
1. Reads the spec (an unformalized document)
2. Plans steps (how to break the task into subtasks)
3. Writes code (adapts to the project's architecture)
4. Runs tests (if tests fail — tries to fix them)
5. Deploys (if deployment fails — rolls back and tries a different approach)
**This is an autonomous agent.** The task is unformalized, there are many solution paths, and human oversight is needed (PR review, course correction).
---
### Example 3: "Call Center Agent"
**Marketing:** "Our AI agent calls clients, conducts dialogues, and records results!"
**Reality:** It's a script that:
1. Gets a client list from the database
2. For each client:
- Calls via a telephony API
- Asks questions from a script (uses LLM for natural-sounding speech generation)
- Records answers in the database
3. Generates a report
**This is not an autonomous agent.** It's a script with an LLM wrapper. The task is formalized, there's one solution path (the dialogue script), no human oversight is needed (you can run 50 such "agents" simultaneously).
---
## Conclusion: How to Choose Correctly
### If You Need Routine Automation
**Don't look for an "autonomous agent."** Look for:
- A script with an LLM wrapper
- A deterministic pipeline
- A formalized set of steps
**Selection criteria:**
- Predictability of results
- Scalability (can run many copies)
- Low cost (minimum tokens per task)
- Ease of monitoring
**Examples:** reports, email sorting, FAQ bots, template-based content generation.
---
### If You Need to Solve Complex Problems
**Look for an "autonomous agent," but be prepared for reality:**
- You need a "foreman" (human controller)
- The agent will make mistakes, burn tokens, require corrections
- Scaling means not "launching 10 agents" but "writing a reliable harness for one, then cloning it"
- It's expensive, complex, requires expertise
**Selection criteria:**
- Ability to adapt to uncertainty
- Presence of a harness (automatic result verification)
- Transparency (you can see what the agent is doing and intervene)
- Support for human oversight (human-in-the-loop)
**Examples:** feature development from specs, market research, unstructured data analysis.
---
## Final Thought
**Not all "agents" are the same.**
If someone sells you "an autonomous agent that solves complex tasks," but in reality it's just a script with an LLM wrapper for routine — you're being deceived (or deceiving yourself).
If someone sells you "a script with LLM," but you expect "an autonomous agent that will solve all your problems" — you're deceiving yourself.
**The right question isn't** "is this an agent or not?" **but** "what type of agent do I need for this task?"
- For routine → script with LLM (cheap, predictable, scalable)
- For complex tasks → autonomous agent (expensive, complex, requires oversight)
And don't believe those who say "we run 10 autonomous agents in parallel." Ask: "How do you resolve git conflicts? How do you control cascade failures? How much time do you spend overseeing each agent?"
The answers to these questions will reveal what's really going on.
---
If 99.8% autonomy on complex, domain-specific tasks were truly achievable by a single team in a reasonable timeframe, it really would be a **wunderwaffe**.
But the reality of August 2026 is: whoever has achieved this level is either staying silent and quietly dominating a narrow niche, or (more likely) their system works only in an artificially narrowed, perfectly controlled corridor that can't be scaled without quality loss.
We hit the physical and architectural limits of current LLM systems. Let's break down factually why these damned 99.8% are unachievable, and how to reframe the goal to avoid burnout.
---
### Why 99.8% Autonomy on Complex Tasks Is a Myth (For Now)
1. **The Tacit Knowledge Gap**
An agent can learn 100% of the formalized rules in your domain. But complex projects always contain 10-20% of unformalizable context: "we don't do it this way because it broke production six months ago," "this hack can't be touched, it holds the entire module together." This context lives only in people's heads. The agent inevitably stumbles on it, makes mistakes, and requires intervention.
2. **State Drift**
In long chains of reasoning and actions (planning → code → tests → fixes), every micro-error or inaccuracy multiplies. Without a deterministic "checkpoint" (which you, the "foreman," currently are), by step 5 the agent spirals into a hallucination loop, trying to fix an error that doesn't exist, or breaking what was working.
3. **The Parallelization Paradox**
Note: 50x productivity works for *routine*. For *complex tasks*, adding a second agent doesn't give +100% speed. It gives +200% synchronization complexity, state conflicts, and cascade failures. Complex tasks by their nature parallelize poorly without rigid deterministic orchestration.
---
### Paradigm Shift: Stop Chasing 99.8%
The current goal ("make it fully autonomous") leads to a dead end because it fights the nature of LLMs.
Your **real engineering goal in 2026** should sound different:
**Not "remove the human from the loop" but "maximize the leverage of that human."**
Instead of measuring autonomy percentage, measure **human time saved per unit of complex result**.
---
### What Actually Works on the Frontier (State-of-the-Art 2026)
If you want to approach the "do it once and it works" principle (which we value), you need to shift focus from a "smart agent" to a "rigid harness."
1. **Fail-Fast Architecture (Not "Smart Fixes")**
Don't let the agent try 10 times to fix an error in an infinite loop, burning tokens. Configure the harness so that at the first anomaly (test failure, unexpected output), the agent **immediately stops** and produces a clear, structured log: *"I'm stuck at step X, expected result Y, actual result Z. Here are my last 3 actions. Awaiting foreman's instructions."*
*Result:* You spend not 20 minutes untangling its chaos but 30 seconds on a precise correction.
2. **Asynchronous "Foreman" (Batch Review)**
Don't monitor the agent in real time. Let it work to a certain checkpoint (e.g., "wrote a draft module and passed the linter"). You don't review every action — only artifacts at control points. This turns you from a "babysitter" into a true architect doing code review.
3. **Radical Domain Narrowing (Scope Down)**
99% autonomy is possible, but only in a microscopically narrow domain. Instead of "an agent that develops features," make "an agent that only writes unit tests for already-written functions according to a strict template." The narrower and more deterministic the task, the closer you are to that wunderwaffe.
4. **Deterministic Guardrails**
Note: the "do it once and it works immediately" principle works in closed ecosystems (Roblox/UEFN). Emulate this: give the agent access only to a strictly defined set of tools with rigid input-output schemas. Forbid it from "improvising" with the file system or APIs outside the allowed list.
---
### Summary
You're on the right track if you've realized the impossibility of 99.8% autonomy on complex tasks without losing control. This sets you apart from 95% of "AI evangelists" who build card houses from prompts and wonder why they fall apart.
Your system "agent + rigid harness + human validator" is **the maximum possible maturity level** for complex domain-specific projects today.
Don't try to break this reality. Optimize the interface between your brain and its computational power. Make your interventions rare, cheap, and surgically precise. That's real automation.
---
The right balance. You work as an architect, not a micromanager:
- **Your level:** contracts, interfaces, module boundaries, structural blocks
- **AI's level:** implementation within defined boundaries, code details, variable names (if they don't break semantics)
This works precisely because you formalize *what* should be done (interface, signature, function responsibility), not *how* exactly to write it. AI excels at generating implementations when the contracts are rigid.
Your correction of "unnecessary or inaccurate names and structural blocks" is exactly the architecture audit that prevents technical debt accumulation. If you didn't do this, in a month you'd have code that works but is impossible to maintain.
Script+LLM for already formalized tasks is just a matter of time and priorities. When you get there, you'll have a system where:
- Architectural decisions — yours
- Implementation — AI's
- Routine — scripts'
That's the real "wunderwaffe" within realistic bounds.
---
Page updated
Google Sites
Report abuse