Strands Agents vs Flue: Who Owns the Environment?

An agent that calls tools in a loop is the easy part. Both of these do that well.

The interesting difference is everything around the loop: where the agent's code runs, what happens when the machine it was running on goes away mid-task, and whether it can safely execute something it just wrote.

Strands leaves those to you. Flue treats them as the product.

The short answer

Strands suits an agent that lives inside a system you already run. You have a service, a deploy pipeline, and somewhere to keep state; you want an agent loop to slot into it.

Flue suits an agent that runs on its own, unattended, and has to survive contact with reality. Long jobs triggered by a webhook or a cron, work that needs a sandbox to run code in, sessions that pick up where they left off after a restart.

What "harness" means here

Flue calls itself an agent harness framework, which is worth unpacking, because it is the whole argument.

A harness is the environment a model needs to do real work: a filesystem it can read and write, a place to run commands, a set of skills it can load when relevant, a session that remembers what happened, and a way to be triggered by the outside world. Coding agents you have used already have one. Flue's pitch is that the harness should be a library you program rather than an application you drive, the way its author puts it, like a coding agent but fully headless and programmable.

An agent is a plain exported function, and hooks in the body compose its capabilities:

export async function triageAgent() {
  useModel("glm-5.3");
  useSandbox("cloudflare");
  useSkill("repo-conventions");
  useTool(searchIssues);

  return "Triage the inbound issue and label it.";
}

The return value is the instruction. The hooks supply the environment.

Strands starts from the other end. The agent is the object, and the environment is the caller's business:

agent = Agent(
    system_prompt="Triage the inbound issue and label it.",
    tools=[search_issues],
)

Both are a handful of lines. The difference is what is assumed. The Strands version runs wherever you call it and keeps state for as long as your process lives. The Flue version brings a sandbox and a session with it.

Head-to-head

The two questions that decide it

Does the agent need to run code it just wrote? If yes, Flue has a real head start. Sandboxing is the part teams most often underestimate, and it is the part you least want to improvise. With Strands you would bring your own, a container, a Firecracker VM, a remote sandbox service, and wire it in as a tool.

What happens if the process dies at minute forty of an hour-long job? With Flue, the session is durable and the agent picks up where it stopped. With Strands, that depends entirely on what you built around it: the conversation manager keeps the session inside the context window, and persisting it somewhere durable is your call.

If both answers are "does not apply", because the agent answers a question in a few seconds inside a request you already handle, then Strands is the lighter choice and the maturity gap matters. Strands is 1.0 and running in production inside AWS behind Amazon Q Developer, AWS Glue and VPC Reachability Analyzer. Flue is a young 1.0 beta with a fast-moving surface, which is a fine thing to build on with eyes open and a reason to pin your versions.

The deployment question underneath

Look again at the two deploy lists, because they say who each project expects you to be.

Strands names AWS services. On AWS that is a strength, because the path is paved and documented. Off AWS it is a shrug, since the SDK runs anywhere Python or Node does.

Flue names Node, Cloudflare Workers, GitHub Actions, GitLab CI, Daytona and Render, which is a different bet: that an agent should be deployable next to whatever already triggers it, including CI. An agent that runs as a GitHub Action on every pull request is a natural Flue shape.

Both keep the model choice open, which is the part worth protecting. Either one will run an open model such as GLM-5.2 or DeepSeek-V4-Pro as happily as a proprietary one, so the framework decision and the model decision stay independent.

How we would choose

Write down the three things that would page you at 3am. If they are "the sandbox escaped", "the eight-hour job died at hour seven" and "the webhook fired twice", Flue is built around those problems and you should start there.

If instead they are "the agent picked the wrong tool" and "the bill was higher than expected", the environment is already solved in your stack, and Strands gives you the loop without asking you to adopt a runtime.

For the rest of the landscape, see Strands Agents vs LangGraph, Strands Agents vs Mastra, and Mastra vs Flue.

Sources

• Flue on GitHub
• Bringing more agent harnesses and frameworks to Cloudflare, starting with Flue
• Strands Agents documentation
• Strands Agents 1.0