The Four Types of AI Agents Companies Actually Use

The tech industry has a taxonomic problem. We use the word "agent" to describe everything from a coding assistant that writes a single function to a fully autonomous system that ships production code without human oversight. This linguistic laziness is expensive.

Nate B Jones, who runs AI News & Strategy Daily, argues that sophisticated AI agents diverge into at least four distinct species—and confusing them leads companies to waste months applying the wrong architecture to the wrong problem. The classification matters because each type solves fundamentally different problems with fundamentally different constraints.

Coding Harnesses: The Individual Contributor Model

The simplest agentic pattern is what Jones calls a coding harness. These are tools like Claude or Codex that act as stand-ins for individual developers. The agent has access to files, can write and read code, can use search tools—essentially the same toolkit a human engineer would have.

Andre Karpathy has described running agents for 16 hours a day. Peter Steinberger managed multiple agents simultaneously while building OpenClaw, each handling discrete 20-minute tasks. This is 2026's version of an engineering workflow: a human in a managerial role, [decomposing problems and delegating execution to AI.

The unlock here is decomposition. As Jones puts it: "If you can get the work decomposed well, you can give that work to a bunch of single-threaded agents and you're going to get real far." Developers who understand how to break gnarly problems into well-defined chunks can parallelize work across multiple agents effectively.

But there's a ceiling. Individual coding harnesses are "built for the mind of an individual developer," Jones notes. When you scale to teams of eight or sixteen or twenty developers working on something, the architecture breaks down. You have too much complexity in the room.

Project-Scale Harnesses: When Agents Manage Agents

Cursor has pioneered a more sophisticated variant: project-scale coding architectures where the agent itself becomes the manager. The company has used this approach to code millions of lines across multiple real projects, from browsers to compilers.

The architecture inverts the human-centered model. Instead of a human managing multiple agents, you have a planner agent that coordinates short-running executor agents. Each executor spins up to solve exactly one problem and then terminates. The planner tracks tasks, maintains memory, and evaluates whether each piece of work was done well.

Cursor tried adding three levels of management. It didn't work. "Simple scales well with agents," Jones reports the Cursor team concluded. The lesson: sophistication doesn't mean complexity. It means finding the right simple configuration for the work you're doing.

The shift from individual to project-scale harnesses requires rethinking the entire development paradigm. Jones describes a common reaction when he suggests reframing work around what makes it easy for agents rather than what makes it easy for humans: "Sometimes people look at me like I'm going crazy. They're like, 'What? What? Why would we do that? We see so much speed up with them as individual assistants. Isn't that great?'"

It is great. But from a project perspective, speeding up human work without removing human bottlenecks means you still have all the same constraints—plus more code review and busier engineers juggling multiple AI assistants.

Dark Factories: Humans at the Edges Only

Dark factories represent the furthest point on the autonomy spectrum. The name comes from Chinese manufacturing facilities that operate in literal darkness—no lights needed because no humans are present. In software terms, a dark factory takes a specification as input and produces working software that passes evaluation as output, with minimal human involvement in between.

The architecture relies on rigorous evals or tests. The system iterates automatically until the software passes evaluation. Some companies launch directly to production from there. Most don't. Enterprise risk management tends to be calibrated to actual production realities, and most companies want a human engineer reviewing code before deployment.

Amazon learned this the hard way recently, calling senior and principal engineers to Seattle to discuss AI-generated production incidents caused by junior engineers. The meeting underscores a tension in the dark factory model: full automation is technically possible but organizationally uncomfortable for companies that understand their liability exposure.

Jones acknowledges the boundary between advanced project-scale harnesses and dark factories is blurry. The distinction is less about technical architecture and more about human involvement. If you're checking in obsessively throughout the process, you're running a project harness. If humans are primarily involved at specification and final review, you're approaching a dark factory model.

Auto Research and Orchestration: The Outliers

Auto research represents a different problem class entirely. Unlike the coding-focused architectures, auto research is about optimizing for a metric—conversion rates, performance benchmarks, model parameters. As Jones puts it: "If you don't have a metric, you're not doing auto research." This descends from classical machine learning's hill-climbing approaches.

Orchestration frameworks, common in large enterprises, coordinate multiple LLMs with specialized roles: researcher to drafter, writer to editor. The coordination overhead only makes sense when you have genuinely distinct jobs that aren't well-suited to a single long-running agent.

The Misapplication Problem

The taxonomy matters because mismatched architectures fail predictably. Jones has watched companies try to scale single-task agents into dark factories for complex projects. "It's not going to work," he says flatly. "That's not how that works. Agents have different needs."

The art of building good agents is finding simple configurations that enable the work you need done. Not more complicated—more appropriate. A coding harness optimized for individual tasks won't magically handle project coordination. A dark factory designed for spec-to-production workflows won't help you optimize a conversion funnel.

The species matters as much as the model. You can plug any LLM into these systems and get results—maybe not the results you want, but results. Understanding which architecture serves which problem is where the actual engineering judgment lives.

Companies that treat all agents as interchangeable will waste months debugging the wrong layer of the stack. The question isn't whether AI agents work. It's whether you're using the right kind of agent for the actual problem in front of you.

Samira Okonkwo-Barnes