Brief

"Agent" has become a crowded word. Product pages use it for chatbots with a browser tab. Research talks use it for systems that plan, call tools, and recover from failure. Philosophy has used it for centuries for anything that acts for reasons. This note does one narrow job: pin down what we mean when we say an LLM-based system is an agent, how that differs from ordinary generative AI, and why two different layers of improvement (model and harness) should not be collapsed into one story about "self-improvement."

The through-line is old and precise. An agent perceives and acts. A language model predicts. When prediction is coupled to sensors, actuators, and a loop that can change the world and then see what changed, you have crossed a category boundary, not a marketing one.

The AIMA sentence

"An agent is anything that can be viewed as perceiving its environment through sensors and acting upon that environment through actuators."

Russell & Norvig, Artificial Intelligence: A Modern Approach

That sentence is deliberately wide. A thermostat qualifies. So does a robot arm. So does software that reads a ticket queue and opens a pull request. The definition does not require consciousness, goals in the human sense, or full autonomy. It requires a coupling: input from an environment, output that can affect that environment, and a stance from which the whole thing can be analyzed as an agent.

What the sentence quietly refuses is a common slide: treating "agent" as a synonym for "smart chatbot." Perception without action is sensing. Action without perception is open-loop control. Prediction without either is generation. Agency sits at the join.

For lab work, the quote is useful because it is operational. If you cannot name the environment, the sensors, and the actuators, you do not yet have an agent description. You have a model description wearing a costume.

What GenAI does

Before agency, the default stack. A modern generative model, especially a large language model, is trained to continue text. Given a context (system instructions, conversation history, retrieved documents, tool schemas), it produces the next token, then the next, conditioned on everything that came before. That is the core loop of inference: not "thinking" as a separate faculty, but sequential prediction under a learned distribution.

Chain of thought is still that loop. When a model writes intermediate reasoning before an answer, those intermediate tokens are part of the context for later tokens. The apparent plan is generated the same way the final sentence is generated. Useful, often. Metaphysically different from a separate planner module, usually not.

From the user's side the sequence is familiar. A prompt arrives. It is packed into a context window along with whatever the system chooses to attach. The model runs inference. Tokens stream out. The session may continue, but each turn is still: context in, tokens out. If nothing outside the chat transcript changes (no file written, no ticket updated, no browser navigated), the system has generated language. It has not yet acted on an environment in the AIMA sense, except insofar as the chat UI itself counts as a trivial environment of pixels and keystrokes.

That distinction matters later. Generative AI supplies a powerful policy over text. Agency begins when that policy is allowed to touch the world and to observe the touch.

When an LLM becomes an agent

An LLM becomes (part of) an agent when three things are present and coupled.

First, an environment: a state space the system can affect and, at least partially, observe. That might be a codebase, a browser, a cloud account, a lab instrument interface, a game, or a document store. The environment need not be physical. It must be real enough that actions have consequences beyond rearranging tokens in the prompt.

Second, tools (actuators) and observations (sensors). Tools are the channels through which the model proposal becomes a side effect: search, shell, API call, editor, email send, database query. Observations are what comes back (stdout, page text, error codes, screenshots, diffs). Without tools, the model can only propose. Without observation of tool results, the loop cannot correct.

Third, a loop: observe, reason, act, repeated. The model (or a controller around it) reads the current state, decides on an action, executes it through a tool, and folds the result back into context. Tool calls are the hinge. They are not decorative function names in a prompt. They are commitments that something outside the model will run.

Chat without side effects is not enough. A model that only replies inside a sandboxed conversation can be brilliant and still fail the AIMA test for any environment you care about. Conversely, a brittle script that reads a sensor and flips a relay is an agent by the textbook definition, and a poor one if it cannot adapt. The interesting systems sit where language models supply flexible reasoning and the harness supplies grounded action and feedback.

Agency, in this framing, is not a vibe. It is an architectural claim: sensors, actuators, and a closed loop over an environment.

Two ways to build capabilities

Once you accept that an agent is the pairing of a model and a way of acting, capability work splits into two roads that look similar in demos and diverge in engineering.

LLM training. One road improves the weights. Supervised fine-tuning (SFT) teaches the model to imitate trajectories (successful tool-using dialogues, well-formed plans, preferred formats). Reinforcement learning (RL) goes further: the model is optimized against a reward signal so that entire behaviors become more likely, not just next tokens that look locally correct. Tool use can be trained in so that the model learns when to call which tool and how to recover from noisy results. Trajectory-level behavior matters here: credit assignment over multi-step episodes, not single-turn fluency.

A useful name in this neighborhood is reinforcement learning from execution feedback (RLEF): the reward or preference signal comes from what actually happened when tools ran (tests passed, pages loaded, tasks completed), rather than from a human ranking of prose style alone. The model is shaped by the world's response to its actions, still inside the training loop that updates parameters.

Training is slow to iterate, expensive to reverse, and powerful when it works. Failures often live in the distribution: the model never saw enough of a failure mode, or optimized for a proxy that looked like success. Changing behavior means another training run, or at least another adaptation pass, not a config tweak.

Harness engineering. The other road improves everything around the weights. Tools and their schemas. Memory: what is stored, retrieved, summarized, or forgotten. Context window control: what enters the prompt, in what order, with what budgets. Safety boundaries: allowlists, sandboxes, human approval gates, rate limits. Retries, timeouts, fallbacks, verification steps, routing between models, logging for later analysis.

The harness is the scaffolding that turns a predictor into a system that can act repeatedly without melting the environment. Much of what users experience as "the agent got smarter" is harness work: better tool choice policies in code, clearer observation formatting, stricter stop conditions, memory that actually helps on the next turn.

Harness iteration is fast and reversible relative to training. You can ship a change, watch trajectories, roll back. Failures often live in glue: wrong tool exposed, observation truncated, loop that never terminates, memory that pollutes context. The model may have been capable. The system was not.

Differences, and a light bridge. Weights versus scaffolding is not a purity contest. It is a map of where effort and risk sit. Training changes what the model is inclined to do before any particular prompt. Harness engineering changes what the model is allowed and helped to do on every run. Iteration speed favors the harness for product and research exploration. Depth of competence still often needs training when the gap is in the model's priors, not in the wiring.

Where failures live tells you where to look. If the model proposes sensible tool calls and the world still breaks, inspect the harness. If the model never proposes the right call even with perfect tools and clean observations, inspect the training mixture and objectives. Reversibility matters for safety culture: a bad harness change can be reverted; a bad weight update is a longer story.

At Seriora we treat the agent as the pairing. Researching the harness is not a sideshow to "the real model." The same observe-reason-act loop that makes an LLM an agent is implemented in software that can be studied, instrumented, and improved, often without touching weights at all. Confusing the two layers produces confused roadmaps: people either wait for a smarter model when the loop is broken, or overfit scaffolding when the model cannot follow the trajectory you need.

After a normal agent: self-improving agents

A normal agent runs a fixed loop: perceive, decide, act, repeat, under policies set by training and by harness code written by humans. A self-improving agent revises part of that setup over time. The critical mistake is to treat "self-improving" as one phenomenon. There are at least two layers, and they are easy to smuggle into each other in conversation.

LLM-level recursive self-improvement. Near-horizon discourse about recursive self-improvement (RSI) usually means the model improving itself (or successor models) with less human intervention in the training and data pipeline. The object of improvement is capabilities encoded in weights (or in closely related model artifacts). The feedback loop is a research and training loop: generate data, evaluate, train, deploy, repeat, with increasing automation.

That discourse is real and contested. It is also not the same as an agent that writes better prompts for itself on Tuesday. Collapsing every adaptive system into "RSI" erases the difference between changing the predictor and changing the procedure around the predictor.

Harness-level improvement from trajectories. A different, nearer engineering path: a process (automated analysis and update) that studies past execution trajectories and improves harness behavior (when and how to use tools, how to retry, what to store in working memory, how to structure observations) without updating LLM weights, and without treating the harness as a dumping ground for project facts or global knowledge bases.

The target is internal harness behavior: policies and procedures for acting, not encyclopedia contents, not the base model's parameters. The agent (or a supervisor process) looks at what happened across runs (failed tool sequences, wasted context, successful recovery patterns) and adjusts the scaffolding so future loops behave better. That is self-improvement at the control layer.

Do not confuse the two. LLM-level RSI aims at the model. Harness-level trajectory learning aims at the loop's software habits. Both can matter; only one is "the model improving itself." Mixing them produces false confidence ("we have RSI because the agent edits its prompt templates") or false fear ("any adaptive harness is unaligned recursive improvement"). Precision here is part of safety and part of honest research communication.

Close

Return to the sentence that opened the note. An agent perceives through sensors and acts through actuators. An LLM predicts tokens. Wire prediction into a loop that observes an environment and changes it, and you have an agent in the sense that matters for building and evaluating systems. Improve the weights and you change what the predictor brings to that loop. Improve the harness and you change how the loop is run. A self-improving agent, at the harness layer, revises that loop's behavior from experience. At the model layer, the longer-range claim is that the predictor itself is remade with less human hands-on work.

Keep the layers straight. The word "agent" earns its keep when sensors, actuators, and a loop are real, not when a demo needs a noun.