"AI Agent" Has 4 Meanings. Most Teams Pick the Wrong One.

Why Everyone Keeps Getting AI Agents Wrong

There is a word problem in AI right now. The word is "agent."

Every vendor says they have one. Every framework claims to build them. Every LinkedIn thought leader insists you need them yesterday. But here is the uncomfortable truth that most people skip right past: the term "agent" has become so diluted that it now obscures more than it reveals. When everything is an agent, nothing is. And if you are an SME leader or an individual builder experimenting with these systems, that confusion is costing you real time and real money.

At the most basic level, yes, all AI agents share the same skeleton. An LLM connected to tools, running inside a feedback loop. That is the anatomy. But anatomy alone does not tell you what an animal does. A hummingbird and an ostrich both have wings. You would not ask an ostrich to pollinate flowers.

The way that feedback loop gets constructed, who sits inside it, where humans intervene, and what the system is actually improving for: those structural choices create fundamentally different types of agents. At least four distinct types are operating in production environments right now. Mix them up, and you will waste months building the wrong thing for the wrong job.

Let us break each one apart.

What Exactly Is a Coding Apply, and Why Should I Care?

The first species is the coding put to work. It is also the simplest, which is precisely why so many people start here and then get confused when they try to stretch it into something it was never designed to be.

A coding capture puts an LLM in the seat of a developer. It gets access to the tools a developer would use: reading files, writing files, running code, searching documentation, calling external resources. Products like Claude Code and Codex are prime examples. You, the human, step into the manager role. The agent does the rollout work.

This comes in two flavors, and the difference between them matters enormously.

Individual Scale: One Agent, One Task, One Human Watching

At the individual level, these harnesses are single-threaded. One agent tackles one task while you supervise. André Karpathy reportedly runs agents for up to 16 hours a day on coding projects. Peter Steinberger, building OpenClaw, took a different approach: he ran multiple Codex agents simultaneously, each handling a discrete 20-minute task, with his own judgment functioning as the quality gate between them.

The secret ingredient here is not the agent itself. It is decomposition. Your ability to break a sprawling problem into well-defined, self-contained chunks determines whether individual coding harnesses produce gold or garbage. If you cannot articulate a clean task boundary, the agent will flounder.

For solo builders and small teams of two or three, this pattern works beautifully. You think in tasks. The agent executes tasks. Your brain handles the architecture and integration.

Project Scale: When One Human Cannot Hold All the Threads

But what happens when the project outgrows your ability to decompose and supervise every piece? This is where teams of 8 to 20 developers hit a wall that most people do not even recognize as a wall.

If your team is using individual AI coding assistants, each developer gets faster. That sounds great. In practice, though, you have simply accelerated human work while preserving every original bottleneck and introducing fresh ones. More code gets written, which means more code review. Parallelization becomes harder, not easier. The humans are still the connective tissue, and connective tissue does not scale linearly.

Project-scale coding harnesses flip the architecture. Instead of humans managing agents, a planner agent manages executor agents. The planner breaks the project into sub-tasks, spins up executor agents to solve each one, evaluates whether the work was completed correctly, and terminates executors when they finish. The planner tracks state, maintains memory across the project, and keeps the whole operation coherent.

Cursor's approach exemplifies this model. They used this architecture to produce millions of lines of code across projects that included browsers and compilers. And here is a detail that should permanently change how you think about agent hierarchies: Cursor experimented with three levels of management hierarchy. It failed. A two-tier structure, planner plus executors, proved far more effective than anything deeper.

Simple scales well with agents. Remember that sentence. Write it on a sticky note if you have to.

What Are Dark Factories and Why Does the Name Sound So Ominous?

The name comes from lights-out manufacturing facilities in China where automated robots produce goods with zero human presence on the factory floor. No lights needed because no humans are there to see.

Dark factories in the AI agent world follow the same logic. They are fully autonomous pipelines with minimal human involvement between the moment work starts and the moment output arrives. The workflow looks like this:

A human writes a detailed specification. The agent system builds the software. The output gets evaluated against a predefined test or eval suite. If it fails, the system iterates automatically until it passes. Then the software ships.

Why remove humans from the middle of the process? Because agents move fast enough that human checkpoints become bottlenecks and, frankly, sources of strain. Imagine trying to review code every seven minutes for eight hours straight. Your attention degrades. Your judgment erodes. You become the weakest link in a chain that does not need you there.

Instead, human involvement concentrates at exactly two points.

At the beginning: design quality, specification clarity, intent definition, customer requirements. This is where your expertise as a domain expert and business leader generates the most value.

At the end: eval review, production validation, accountability sign-off. Most enterprises retain a senior engineer review at this stage. Amazon reportedly learned this lesson after AI-generated production incidents, traced back to insufficient oversight from junior engineers, forced a rethink of their review process.

Here is the nuance that trips people up: dark factories exist on a spectrum with project-scale coding harnesses. As your project apply becomes more stable and requires less mid-process human guidance, it gradually drifts toward dark factory territory. The dividing line is whether humans are primarily involved only at the specification and evaluation stages. If yes, you have crossed over.

For SMEs, the practical implication is major. You do not need to build a dark factory from scratch. You evolve toward it. Start with a project-scale capture. Improve your specs. Tighten your evals. Reduce the human touchpoints in the middle. One day you realize the humans only show up at the edges. Congratulations. You have a dark factory.

Is My Problem Software-Shaped or Metric-Shaped?

This single diagnostic question separates two completely different worlds of agent work, and almost nobody asks it early enough.

The first two species, coding harnesses and dark factories, produce software. They write code. They build things. They ship artifacts. Auto research does something fundamentally different. It optimizes a metric.

Auto research descends from classical machine learning, not from software engineering. Its mechanism mirrors ML's core principle: run repeated experiments, measure outcomes against a target metric, and iteratively improve. The technical term is hill climbing. You start somewhere. You try variations. You keep whatever moves the number in the right direction. You throw away whatever does not.

The hard boundary is this: if there is no metric to improve against, it is not auto research. Period. Do not try to force it.

Where Auto Research Actually Shines

Toby Lütke used auto research to tune Shopify's Liquid presentation framework, the engine powering millions of stores, targeting improved runtime performance. That is a classic metric-shaped problem. You have a number (runtime speed), a direction you want it to move (faster), and a system that can run thousands of variations to find improvements humans would never spot.

André Karpathy released an auto research package aimed at auto-tuning LLM training settings toward GPT-2-scale efficiency. Think about that for a moment. The technique can be applied across an entire LLM development chain, which means it is not limited to niche applications.

For a more grounded business example, consider conversion rate refinement on landing pages. You have a metric (conversion rate), a direction (higher), and a system that can generate and test variations far faster than any human team running A/B tests manually. That is auto research territory.

Forks of Karpathy's package already exist that accept plain-English questions, which signals that broad accessibility is arriving quickly. You will not need a machine learning background to use this. You will need a clearly defined metric and the discipline to let the system run.

The Mistake That Wastes Months

Using auto research to build software is a category error. Using a coding use to tune a conversion rate is equally misguided. Software-shaped problems call for coding harnesses or dark factories. Metric-shaped problems call for auto research. These are not interchangeable approaches wearing different hats. They are structurally distinct systems designed for structurally distinct work.

Ask the question early. Is this software-shaped or metric-shaped? Your answer determines your entire agent architecture.

When Does Orchestration Make Sense (and When Is It Overkill)?

Orchestration is the fourth species, and it is the one that generates the most excitement and, predictably, the most wasted effort.

Orchestration involves routing work across multiple specialized agents with defined roles, managing the handoffs between them. Platforms like LangGraph and CrewAI are built for this pattern. A typical orchestration workflow might look like: ticket intake agent passes to research agent, which passes to resolution agent, which passes to closure agent. Or: research agent feeds a drafting agent, which feeds an editing agent. Each agent has a specialized function. The orchestration layer decides what gets handed off, in what form, and with what context.

This is not the same as the planner/executor model in project-scale coding harnesses. That distinction matters. In the Cursor model, all agents work toward a single unified goal: producing code. In orchestration, agents have genuinely different specialized functions. One researches. Another writes. Another reviews. They are collaborators with distinct skill sets, not copies of each other executing subtasks.

The Hidden Tax of Orchestration

Here is what nobody puts in the demo video. Orchestration has joints. Lots of them. Every handoff between agents is a point where context can get lost, where quality can degrade, where the wrong information gets passed forward or the right information gets left behind. Each of those joints requires human review or tuning.

Prompt engineering for one agent is manageable. Prompt engineering for five agents plus their handoff protocols plus their context management plus their error handling? That is a full-time job. Sometimes several.

This makes orchestration feel heavy relative to the other agent types. It is heavy. The investment only pays off at scale.

The question you should ask before committing to orchestration: What is the volume? For 10,000 customer support tickets, or 10 million, the investment in prompt engineering, context management, and handoff design is clearly worthwhile. The per-unit cost of that coordination overhead drops to almost nothing when spread across massive volume.

For 100 tickets? You are almost certainly better off with a simpler approach. Maybe even a well-prompted single agent with human review. The coordination tax will eat you alive on small volumes.

So How Do I Actually Choose?

Stop thinking about agents as a monolith. Start with these questions instead.

Am I solving a software problem or a metric problem? If metric, go to auto research. If software, keep reading.

How much human supervision can I realistically provide in the middle of the process? If you want to stay hands-on and your tasks are decomposable, individual coding harnesses are your starting point. If your team has outgrown that, move to project-scale harnesses with a planner/executor structure. If your specs and evals are strong enough that mid-process humans add drag instead of value, you are ready for dark factory territory.

Am I routing work across genuinely different functions? If your workflow involves specialized roles handing off to each other, that is orchestration. But only invest in it if your task volume justifies the coordination overhead.

| Situation | Agent Type | |-|-| | Individual developer judgment is the quality gate | Coding put to work (individual scale) | | Team-scale project with planner/executor structure and human final review | Coding capture (project scale) | | High-confidence evals, minimal mid-process human involvement, spec-driven output | Dark factory | | Tuning a measurable rate or metric | Auto research | | Routing work across specialized agents in a defined workflow | Orchestration |

The Mistakes I Keep Seeing SMEs Make

Five patterns show up repeatedly, and every single one traces back to treating agents as interchangeable.

Throwing auto research at a software problem. If there is no metric to hill-climb against, auto research has nothing to tune. You will get noise, not progress.

Using a long-running coding put to work for creative production. Asking a coding capture to produce something like a novel is almost certainly an orchestration problem, or possibly still a human task. The feedback loop structure is wrong for that kind of work.

Scaling individual harnesses instead of adopting project-scale architecture. Eight developers each using their own AI coding assistant is not a team of agents. It is eight individual speed boosts stapled together with all the original coordination problems intact, plus new ones.

Skipping the specification work for dark factories. The entire dark factory model depends on specification quality at the front end. If your spec is vague, the autonomous pipeline will confidently produce the wrong thing over and over, passing its own evals because the evals were built on the same vague spec.

Building orchestration for low-volume workflows. If you do not have the volume to amortize the coordination overhead, orchestration is an engineering exercise masquerading as a business solution. It will look impressive in a demo. It will not generate returns.

Where This Goes Next

The lines between these four species will blur over time. Project harnesses will drift toward dark factories as eval quality improves. Auto research will become accessible to non-technical users through plain-language interfaces. Orchestration frameworks will get lighter as handoff management gets automated.

But the categories themselves will persist because they reflect genuinely different problem structures, not just different implementations. Software-shaped versus metric-shaped is a permanent distinction. High-volume versus low-volume workflow routing is a permanent consideration. The level of human involvement you can and should maintain is a permanent design decision.

The organizations and individuals who get this right will not be the ones using the most agents. They will be the ones using the right agents for the right problems, and refusing to pretend that one architecture fits every situation.

Start by naming the problem correctly. Everything else follows from there.