← Back to the summary

Calling an LLM Once Doesn't Make It an Agent

I've repeatedly run into a problem recently: many people call anything that "uses a large model," "connects a few tools," or "organizes a set of Skills" an Agent.

Once, during a discussion about AI workflows, someone referred to a collection of Skills organized for Codex as "an Agent." I immediately felt something was off: are Skills working methods and specifications, or are they runtime units that can advance tasks on their own? If we can't even separate these two layers, any subsequent discussion about Agent architecture will only get more confusing.

Later, when talking about code review, someone else said: he had an Agent project that calls an LLM to do code review, outputs review results and suggestions, and automatically triggers a pipeline notification to a DingTalk bot.

My first reaction was: this is at best "an automated workflow that integrates a large model." Why rush to put the Agent label on it? Whether it has goals, state, tool execution, and next-step decision-making hasn't been clarified yet, but the conclusion was already drawn.

Then, at the beginning of this year, I also spoke with a general manager of a state-owned enterprise about AI. He said with great confidence: "Isn't a large model just a search engine?"

无语 _4_爱给网_aigei_com.gif

That was exactly my expression at the time. Not because he needed to understand some AI details, but because he flattened a system involving understanding, generation, tool invocation, external execution, and boundary control directly into "search." Before even understanding the capability boundaries, he finished the conclusion with a familiar phrase — that kind of confidence is more alarming than simple ignorance.

These scenarios look different, but the problem is the same: everyone is using the same word to talk about things at different layers. Someone is talking about a Skills file, someone about a single model call, someone about a system that can continuously act around a goal.

So, I want to break apart Skills, Agent, Subagent, and Harness and explain them one by one. This isn't to make the terminology more complicated, but to see clearly what an AI project actually does more of: which capabilities are real, and which are just a new name.

Whether you see AI as a bubble or an opportunity, you first have to figure out what it can and cannot do. And what truly creates a gap has never been "who connected the most model APIs first," but who can combine models, tools, and business processes into a reliable system.

So, this article answers only one question:

What exactly qualifies a project to be called an Agent?

Start with a task: fix a mobile bug

Suppose I tell Codex:

"Please fix the layout overflow issue on this page on mobile, run the tests, and submit the code after confirming there are no problems."

If behind the scenes there is only a single model call, the flow might be:

User question -> Call LLM -> Return a suggestion or code

The model might tell me to check overflow, container width, and media queries, but it won't automatically open the repository, modify files, run tests, much less continue fixing after seeing a test failure.

This is no different in essence from integrating an OCR, payment, or search service: the application sends a request to a third-party service, gets a result, and then the code decides the next step.

So, calling an LLM API only means the project uses model capabilities; it does not directly mean it is an Agent.

What an Agent actually does more of

Here, I understand an Agent as a runtime unit that continuously advances a task around a goal, not a chat box that "answers more like a human."

For the same bug-fixing task, if the system allows the model to view files, modify code, run tests, and decide the next step based on results, it might work like this:

Understand goal
  -> View project structure
  -> Find relevant components
  -> Read CSS and tests
  -> Modify files
  -> Run tests
  -> Continue modifying based on failure information
  -> Report results

The key change is not how many times the model is called, but whether the model can choose the next step based on current results. It can decide which file to read first, whether to run tests, what to change after a test failure, and when it counts as done.

You can think of LangChain's create_agent as a kind of Agent runtime: it wraps model calls, tool calls, and loops together. It is not a new model, nor does it retrain a model into an Agent.

from langchain.agents import create_agent

agent = create_agent(
    model,
    tools=[read_file, edit_file, run_tests]
)

result = agent.invoke({
    "messages": [
        {"role": "user", "content": "Fix mobile page overflow and run tests"}
    ]
})

If you only call llm.invoke() once, even if the function is named review_agent, it is still just a single model service call. A name does not automatically change the architecture.

What Skills are: a reusable way of doing things

Continuing with the bug-fixing task.

I can give the Agent a frontend debugging Skill, which clearly states: which files to look at first, how to start the project, when to take screenshots, which tests to run, and finally how to record results.

It might look like this:

frontend-debug/
  SKILL.md          # Applicable scenarios, steps, and judgment rules
  scripts/          # Start project, take screenshots, collect logs
  references/       # Team conventions and framework docs
  templates/        # Bug report and acceptance templates

A Skill is like an operations manual for a specific job, and also like a workflow specification that can be loaded by an Agent. It packages experience, scripts, and materials so that different people and different Agents can all work according to the same set of methods.

But a Skill itself usually does not receive user goals, nor does it decide on its own which tool to call, much less is it responsible for saving state, handling permissions, or maintaining loops.

Therefore, simply organizing a set of Skills for Codex to use is essentially a set of reusable working methods and specifications — more accurately an "Agent capability pack," not an Agent. Only when it is backed by an independent model decision loop, tool execution, and state management mechanism can the entire system be called one that contains an Agent.

What a Subagent is: another Agent delegated by the main Agent

A Subagent is most easily misunderstood as "just calling the LLM again." In fact, it is first and foremost a relationship: there is a main Agent that hands off a clearly bounded task to another independent Agent.

For example, the main Agent is responsible for fixing code, and it can say:

"Please have the Code Reviewer check this modification, read the relevant files, run the tests, and list serious issues and evidence."

If the Reviewer here has its own instructions, tools, context, and stopping conditions, and can independently complete the check and then return structured results to the main Agent, it can usually be called a Subagent.

But the following kind of code is usually not a Subagent:

def review_code(diff: str) -> str:
    return llm.invoke(f"Please review the following code changes:\n{diff}")

It is just a function that wraps the LLM API. It can be called a "code reviewer" and can serve as a tool for the main Agent, but it does not have its own Agent loop.

The OpenAI Agents SDK supports two common multi-Agent relationships: the main Agent calls a specialized Agent as a tool, with the main Agent retaining the final answering authority; or through a handoff, control is transferred to the specialized Agent, which continues processing the task. OpenAI Agents SDK Agents

So, to judge whether the Code Reviewer called by Codex is a Subagent, don't look at whether it is another API, and don't look at its name, but look at four things:

Is it an independently configured Agent?
Does it have its own tools and context?
Can it independently loop to advance the review task?
Is it explicitly delegated by the main Agent, and does it return results or take over the conversation?

What a Harness is: the outer system that lets the Agent truly run

If the Agent is the person responsible for deciding the next step, then the Harness is the entire set of environments and rules in which it works.

In the bug-fixing example, the Harness might be responsible for:

Giving the correct repository directory to the Agent;
Restricting it to reading and writing only specified files;
Running tests and scripts in a sandbox;
Controlling network, keys, and system permissions;
Saving messages, tool calls, and intermediate results;
Setting timeouts, maximum loop counts, and retry rules;
Requiring human confirmation before submitting code;
Logging, and resuming tasks after interruption.

The model is only responsible for proposing the next step suggestion. It saying "please run the tests" does not mean the tests are actually run. What truly executes commands, puts results back into context, checks permissions, and decides whether to continue is the external runtime layer.

OpenAI's introduction to the Codex Harness mentions exactly these kinds of capabilities: Agent loop, thread persistence, configuring authentication, tool execution, sandbox, and Skills integration. Unlocking the Codex harness

Therefore, a Harness is not "another name for a large model," nor is it a Prompt. It is more like the control layer that connects the model, tools, state, and the real environment.

How create_agent, Agent, and Harness fit together

These concepts can be understood like this:

Harness
  -> Agent runtime
       -> Main Agent: Understands goal, decides next step
       -> Subagent: Delegated independent Agent
       -> LLM: Generates judgment and tool invocation intent
       -> Tools: Files, database, search, business APIs
       -> Skills: Provide steps, materials, and scripts for a type of task

create_agent mainly provides the Agent runtime, that is, the loop between the model and tools. A production system also needs permissions, sandbox, state, auditing, retries, human approval, and failure recovery — these together form a more complete Harness.

Skills are working methods that an Agent can load on demand. Subagent is a delegation relationship between Agents. They are not concepts at the same layer, nor can they substitute for each other just because they are placed in the same code repository.

Walk through the boundaries again with a Code Reviewer scenario

Suppose Codex is modifying code and needs a review after completion.

First case: Codex sends the diff to an API, and the API returns a few comments. Here it is "Agent + an LLM tool"; this API is usually not a Subagent.

Second case: Codex hands the review task to an independent Reviewer Agent. The Reviewer reads files itself, runs tests, checks specifications, and finally returns a report. In this case, it more closely matches the definition of a Subagent.

Third case: The Reviewer needs to run tests in an isolated directory, cannot access production keys, and can recover from a checkpoint after failure. The outer system providing these capabilities is the Harness.

Fourth case: The team also writes a code-review/SKILL.md, specifying the review order, severity levels, and report format. This is a Skill, responsible for fixing the method in place.

The same Code Reviewer functionality can simultaneously have a Skill, an Agent, a Subagent, and a Harness, but they bear different responsibilities.

Don't use "called a model" to judge whether something is an Agent

To judge whether a system is an Agent, directly check against the following five questions:

Does the system have a goal that needs continuous advancement?
Can the model choose the next step based on current results?
Does it actually execute tools or external actions?
Do action results return to the model, forming a loop?
If multiple Agents exist, is there a clear delegation or handoff relationship?

If it is just "input a piece of text, call the LLM once, return a piece of text," it is an LLM application.

If the steps are fixed by code, with only an LLM, OCR, search, or payment inserted in the middle, it is an LLM-enhanced business process.

If the model can choose tools around a goal, read results, continue acting, and end the task within boundaries, it is closer to an Agent.

If there is also an independent Agent delegated by the main Agent, it can usually be called a Subagent.

If the system is also responsible for context, state, permissions, sandbox, retries, auditing, and recovery, then it has a complete Harness.

Once these concepts are clearly distinguished, many debates will become much simpler: are we discussing model capability, workflow methods, Agent decision-making, or the runtime control system?