The word "agent" is everywhere in software right now.
That is a problem.
Not because the shift underneath it is fake, but because once a term gets slapped onto everything, it stops telling you anything useful. I have watched "agentic" get attached to chat interfaces, automation scripts, copilots, and real workflow systems in the same week, sometimes by the same people.
If every company with a model API counts as an AI agent startup, the category collapses into mush. It stops helping founders think clearly about what they are building. It stops helping investors distinguish between different kinds of bets. It stops helping buyers understand what they are actually purchasing.
So I use the term ANSO.
ANSO (pronounced "Ann-So") -- Agent-Native Software Organization -- is a software company where AI agents are the primary execution layer.
ANSOs are architected so the agent(s) produces the core deliverable the customer is paying for. In practice, that usually means an orchestrated system of prompts, tools, routing, memory, and review loops, not just a single model answering directly. Humans are still in the loop, but they have moved into a different seat: approving, escalating, catching edge cases, and exercising judgment when the workflow gets messy.
That is a structural distinction, not a marketing one.
Traditional software helps people do work better. ANSOs are built so software does more of the work itself. Both can be good businesses, but they are not the same kind of business. Pretending otherwise creates bad decision making, bad investment logic, and buyer confusion.
The naming problem
"AI-native" has been too broad to be useful for a while. "AI agent" sounds sharper, but it still lumps together structurally different businesses: copilots, task automators, orchestration platforms, and true execution systems. If those all live in the same category, the category stops doing useful work.
ANSO is my attempt to draw the line tightly enough to be useful.
The defining question is simple: does the agent produce the primary deliverable, or does it help the human produce it?
A company that helps an attorney research faster is one thing. A company whose system generates the legal work product that the attorney then reviews is another.
Both may be useful, but they have different economics, trust requirements, org designs, and competitive dynamics.
Four criteria for ANSO classification
I use four tests before I call something an ANSO.
- Agents produce the primary deliverable
- Post-LLM-era architecture
- Software-centric
- Agent as execution layer, not a tool
1. Agents produce the primary deliverable
This is the anchor.
Start with what the customer is actually paying for: the legal brief, the clinical note, the resolved support ticket, the freight booking, the software feature.
Then ask the blunt question: who produces the first usable version of that thing?
The deliverable should be something the customer would otherwise pay a person or team to produce or complete.
If the human produces it and AI helps, that is AI-augmented software. If the agent produces it and the human reviews or approves, that is much closer to agent-native.
This test cuts through positioning language because it forces specificity. You cannot answer it with homepage theater.
2. Post-LLM-era architecture
The relevant architecture boundary is not a single branded model release. It is the period when large language models became reliable enough to anchor real commercial workflows, roughly 2022 through 2024 depending on the use case.
Early GPT-4-class models mattered because they made more complex reasoning and longer-form output commercially usable. Later model families improved reliability, tool use, latency, and actionability. The important point is not whether one model flipped the switch on its own. It is that a real capability break happened across this period, and it made agent-native workflows commercially buildable.
This is not about founding date. A company founded in 2019 can qualify if it rebuilt around agent-native execution after that capability threshold was crossed. A company founded in 2024 does not qualify just because it was born recently.
What matters is whether the system design reflects the real capability unlock: multi-step reasoning, usable tool invocation, and output quality strong enough to support a workflow the customer would otherwise pay humans to do.
3. Software-centric
ANSO describes software organizations, not labor-heavy service businesses with AI features.
There are adjacent categories worth watching: AI-native service firms, workforce platforms with AI matching, robotics companies with agentic loops. Some will become important. But the ANSO framework applies where software and agents are the primary scaling mechanism, not human labor.
That keeps the category tight enough to be worth using.
4. Agent as execution layer, not a tool
This is the criterion most companies fail.
A product can have impressive AI features and still not be agent-native. Summarization, drafting assistance, search enhancement, recommendation systems, automation helpers, all of these can improve workflows materially without making the agent the primary executor.
The real question is whether the system owns meaningful parts of the workflow end to end. Does it move from context to finished output? Is the company selling access to software, or the output that software produces?
An assistant that prepares a human to act is a tool. A system that acts, with a human checking the result, is closer to an ANSO.
The classification system
The four criteria produce four buckets.
Some companies will move between these buckets over time as their architecture changes. That is normal. The framework is useful because the edge cases exist, not because they do not.
ANSO
An ANSO substantially satisfies all four criteria. The agent produces the primary deliverable under human oversight.
Harvey fits. Agents generate legal work product that attorneys review and refine. The attorney is still essential for judgment, client accountability, and edge cases, but the production role has shifted.
Abridge fits. Clinical documentation used to eat hours of physician time. Abridge captures the encounter and produces the note. The clinician reviews it. That is software absorbing work that used to happen at a keyboard late at night.
Sierra fits in customer operations. EliseAI fits in property-management workflows. HappyRobot fits in freight coordination. Different verticals, same underlying pattern: the agent executes, the human governs.
Adjacent
Adjacent companies show strong agentic characteristics, but one criterion is partial, muddy, or still genuinely contested.
Cursor is the clearest example. For some teams it still functions like a developer tool. For others it is becoming a system where agents perform substantial pieces of software production. The classification debate is active, which is partly why the company matters. It suggests the ANSO boundary is moving into engineering.
Lovable shows agent-driven creation clearly, but many users still experience it partly as tooling rather than as a fully re-architected software organization. Mercor has real agentic workflow intelligence, but it still depends heavily on human hiring markets in ways that complicate the classification.
Adjacent does not mean weak. It means the primary-deliverable test returns a more complicated answer, often because the system matters a lot while the market still experiences it partly as a tool.
Enabler
Enablers build infrastructure for ANSOs without being ANSOs themselves.
Examples include companies building agent hosting, orchestration layers, security tooling, identity systems, browser control, and payments infrastructure for AI agents. In the broader ANSO dataset, this includes companies like Browser Use, Terminal Use, Agentic Fabriq, Sponge, Runlayer, and Gumloop.
These companies may become very valuable. They are the picks and shovels of the ANSO era.
This distinction matters because growing enabler share is sometimes misread as ANSO decline. I think it usually signals the opposite. Categories produce specialized infrastructure after the application layer proves real enough to support a whole stack underneath it.
AI-Augmented
A company can use AI, grow quickly, and still not be an ANSO.
A copilot inside legacy software is not an ANSO. A chat interface over a database is not an ANSO. A workflow automation tool that still requires humans to produce the main output is not an ANSO.
That is not dismissive. It is a classification boundary.
The primary deliverable test in practice
If you only keep one framework from this piece, keep this one.
Ask three questions:
- What is the primary deliverable?
- Who produces the first usable version of it?
- What does the human do after that?
Legal: agent-drafted memo, attorney reviews and approves. That is an ANSO. Healthcare: system-generated clinical note, clinician reviews. That is an ANSO. Support: agent resolves the conversation, human handles escalations. That is an ANSO.
Now flip each one.
Legal: agent surfaces relevant cases, attorney drafts the memo. That is AI-augmented. Healthcare: system surfaces history, clinician documents the visit. That is AI-augmented. Support: agent suggests responses, human reviews and sends each one. That is AI-augmented.
Both versions can be valuable products, but they are different. They have different architectures, trust requirements, and competitive profiles.
The framework removes most of the wiggle room.
Implications
For founders: earn the label. Be specific about what the agent produces, where human oversight sits, and what failure looks like. Autonomy theater, claiming agent-native status while humans quietly do the work, is a short-term narrative win and a long-term credibility problem.
For investors: sharper taxonomy produces better decisions. ANSOs, adjacent companies, and enablers have different moat mechanics, risk profiles, and competitive dynamics. Treating them as the same bet on "AI" misses the variation that matters.
For buyers: understanding what you are buying changes what questions you ask. Software access, software assistance, and software-performed work have different evaluation criteria, trust requirements, and accountability structures. Procurement gets smarter once the distinction is clear.
The point of this framework is not to create an exclusive club. It is to make the market legible.
Right now, one of the biggest obstacles to clear thinking in this space is category blur: too many structurally different businesses described with the same vocabulary.
That blur does not just create confusion. It creates bad product positioning, lazy investing, and sloppy buying.
If ANSOs represent a real architectural shift in how software organizations are built, and I think they do, then precise language about what qualifies is not pedantic theatre. It is the foundation an emerging category stands on.
-Larry J. Erwin
Disclosure: I work at OpenAI. Some companies mentioned in this essay use OpenAI’s models. The views here are my own. No company mentioned paid for this piece.