---
description: What an AI agent actually is, why a model alone isn't one, and what makes a Flue agent different.
---

# What is an agent?

Last updated May 29, 2026 [ View as Markdown](https://flueframework.com/docs/concepts/agents/index.md) 

Ask ten people what an “AI agent” is and you’ll get ten answers: a chatbot, a clever prompt, a workflow, a model with tools. But none of these fully capture it.

**Our preferred definition of an agent is: a large language model (LLM) running inside a harness.** The model is the part that you’re probably already familiar with: GPT 5.5, Opus 4.8, etc. So let’s spend some time on the other half of the equation.

**The harness is what the LLM uses to navigate the world and complete tasks.** The harness is what makes a model useful for real work, and the industry now recognizes it as [essential](https://www.langchain.com/blog/the-anatomy-of-an-agent-harness) to building autonomous agents and workflows.

Without a harness, a model is only reachable through the individual API calls you write. That is not real autonomy, and therefore that is not a real agent.

Flue was the first agent framework to fully embrace this new agent architecture. Flue’s built-in TypeScript harness lets you get started today building truely autonomous agents for products, background work, internal tooling and more. We believe this architecture is already defining the future of what agents can do, and we are exited to be helping to lead the charge.

## What is a harness?

A language model does just one thing: it takes text (and sometimes images) in and produces text out. On its own it can’t remember anything once a response ends, run code, read a file, change anything in the world, or look up something that happened after its training cut off. It’s a brain in a jar — extraordinary at reasoning, with no memory, no hands, and no senses.

Each piece of the harness exists to give the agent new abilities and focus:

* **We want the agent to keep its work** — so we give it a _filesystem._
* **We want the agent to act, not just describe** — so we give it _tools._
* **We want the agent to act safely** — so those actions run in a _sandbox._
* **We want the agent to stay sharp across long work** — so we give it _context._
* **We want the agent to do more than one thing at a time** — so we created _subagents._

Flue’s built-in agent harness gives you all of these pieces in TypeScript, ready to power your agents and run on the deployment target of your choice:

```
// Example: .flue/agents/triage.ts
import { createAgent } from '@flue/runtime';
import { local } from '@flue/runtime/node';

export default createAgent(() => ({
  model: 'anthropic/claude-sonnet-4-6',
  instructions,      // who the agent is and how it works
  tools,             // what it can do
  skills,            // expertise it can load on demand
  sandbox: local(),  // where it runs, safely
}));
```

Building an agent is really less about coding and more about building up the context that you provide your agent — choosing the model, instructions, tools, skills, and environment it runs in.

## Building autonomous agents

The first agents were scripts. You’d chain a few model calls together and hardcode the steps: do this, then that, then format the result. That works for narrow, predictable tasks, but it’s brittle — the moment reality doesn’t match the script, it falls apart. The model was never really in charge; you were.

Tools like Claude Code and Codex flipped that around. You don’t write the steps anymore. You give the model a goal, a capable environment, and a loop, and you trust it to find the path on its own — reading, trying something, observing what happened, correcting, and going again. That autonomy is as much a harness achievement as a model one: it only works because the model has a real environment to act in and recover within.

So when people say “agent” today, they usually mean this: a model given enough of a harness to pursue a goal by itself.

For the people building these systems, that inverts the job. You’re no longer writing the solution — you’re setting the stage for one. You give the agent the context around a problem, connect it to the tools and data it’s allowed to use, check that the caller is who they say they are, and then hand the problem over. The answer comes from the model’s intelligence working over the context you gave it, not from logic you wrote in advance. After years of spelling out every step by hand, trusting a system to work out the _how_ on its own still feels genuinely new.

## Going headless

Some of the most popular agent harnesses today were designed for coding. Flue is deliberately the opposite. A Flue agent is purely headless — there’s no CLI or developer-facing product experience like Claude Code or Codex. Our JavaScript API is essential to Flue’s success, whereas for others it’s often an afterthought to their primary product. So we invest a lot of attention and care into getting it right.

```
// Compose the agent: its model, capabilities, and environment.
const agent = createAgent(() => ({
  model: 'anthropic/claude-sonnet-4-6',
  tools,
  skills,
}));

// Then drive it from your own code.
const harness = await init(agent);
const session = await harness.session();
const { text } = await session.prompt('Triage this incoming issue.');
```

A Flue agent is **programmable**: you assemble and drive it in code, choosing its model, instructions, tools, skills, and environment, then operating it through an API instead of a chat app, or TUI, or different config files on your local machine.

It’s also **headless**: it has no interface of its own. You are responsible for calling your agents — via `flue run`, HTTP, WebSocket, etc. — and building your product around it. With Flue you have maximum flexibility to build your agents and connect them to the rest of your team, company, or product however makes sense.

## The sandbox

For a harness to do anything beyond generate text, the agent needs a real environment to work in. That environment is the **sandbox**: the filesystem and command-execution boundary available to the agent. It is what lets an agent read and write files, run shell commands, install packages, load context such as instructions and skills from disk, and make network requests. The built-in filesystem and shell tools operate inside this boundary; custom tools you write are ordinary functions that run in your agent runtime.

Out of the box, Flue provides a lightweight virtual sandbox — an in-memory filesystem and shell — so an agent has a usable environment with no setup. When you need more, you connect a different one behind the same API: direct access to the host machine, a platform-native option such as Cloudflare, or one of the popular sandbox providers. The [ecosystem](https://flueframework.com/docs/ecosystem/overview/) lists the available connectors.

## Where to go next

* [Why Flue](https://flueframework.com/docs/introduction/why-flue/) — the case for building agents and workflows this way.
* [Agents](https://flueframework.com/docs/guide/building-agents/) — defining an addressable agent, its sessions, and its runtime configuration.
* [Workflows](https://flueframework.com/docs/guide/workflows/) — initializing an agent from code during a finite operation.
* [Sandboxes](https://flueframework.com/docs/guide/sandboxes/), [Tools](https://flueframework.com/docs/guide/tools/), [Skills](https://flueframework.com/docs/guide/skills/), and [Subagents](https://flueframework.com/docs/guide/subagents/) — the pieces of the harness, in depth.
* [Workflows](https://flueframework.com/docs/guide/workflows/) — bounded jobs with inspectable run history.

## Docs Navigation

Current page: [What is an agent?](https://flueframework.com/docs/concepts/agents/)

### Sections

* [Guide](https://flueframework.com/docs/getting-started/quickstart/)
* [Reference](https://flueframework.com/docs/api/agent-api/)
* [CLI](https://flueframework.com/docs/cli/overview/)
* [SDK](https://flueframework.com/docs/sdk/overview/)
* [Ecosystem](https://flueframework.com/docs/ecosystem/overview/)

### Introduction

* [ Getting Started ](https://flueframework.com/docs/getting-started/quickstart/)
* [ What is an agent? ](https://flueframework.com/docs/concepts/agents/)
* [ Why Flue? ](https://flueframework.com/docs/introduction/why-flue/)
* [ Changelog ](https://github.com/withastro/flue/blob/main/CHANGELOG.md)

### Guides

* [ Project Layout ](https://flueframework.com/docs/guide/project-layout/)
* [ Models & Providers ](https://flueframework.com/docs/guide/models/)
* [ Agents ](https://flueframework.com/docs/guide/building-agents/)
* [ Workflows ](https://flueframework.com/docs/guide/workflows/)
* [ Skills ](https://flueframework.com/docs/guide/skills/)
* [ Tools ](https://flueframework.com/docs/guide/tools/)
* [ Subagents ](https://flueframework.com/docs/guide/subagents/)
* [ Sandboxes ](https://flueframework.com/docs/guide/sandboxes/)
* [ Routing ](https://flueframework.com/docs/guide/routing/)
* [ Develop & Build ](https://flueframework.com/docs/guide/develop-and-build/)
* [ Chat ](https://flueframework.com/docs/guide/chat/)
* [ Observability ](https://flueframework.com/docs/guide/observability/)