Building an AI agent that can do more than one fixed thing at a time has become a real architecture problem, not just a bigger prompt. Fred Schott’s answer borrows directly from how React solved a similar problem for web interfaces years ago.

Schott, the creator of the Astro web framework, launched version 2 of his AI agent framework Flue on July 31, 2026. In the launch post, he explains why the earlier, simpler design stopped working:

“The static agent approach worked well for simple use-cases, but started to break down for more complex, non-trivial agents and multi-step workflows.”

His fix reaches for a comparison from web development:

“The same problem that React Hooks was invented to solve applies to agents as well: How do you compose functionality at the lowest, most fundamental level?”

Who he is

Schott created Astro, a JavaScript web framework used by companies including Unilever, Visa, and NBC News. Cloudflare acquired Astro’s parent company in January 2026, and Schott has continued building in that space, most recently with Flue, a TypeScript framework for building AI agents.

What he gets right, and where it’s incomplete

An AI agent (software that can call tools, hold state, and decide its next step on its own) usually starts as a simple script: one prompt, a fixed list of tools. Schott’s diagnosis of where that breaks down is accurate. Once an agent needs to add or remove capabilities mid-conversation, like a support bot that should only allow account changes after verifying identity, hardcoding every possible path gets unwieldy fast. Flue’s hooks, such as useSkill() and useTool(), let a developer attach or drop a capability at the exact moment it becomes relevant, instead of loading everything up front.

The React comparison is useful but not exact. React Hooks solved composability for rendering a visual interface, where the cost of getting it wrong is a broken screen. An agent hook can attach a tool that takes real-world action, like sending a payment or deleting a record. The stakes of composing the wrong capability into a running agent are higher than composing the wrong UI component, and Flue’s launch post does not address how developers should audit which hooks an agent can reach at runtime.

Why it’s notable

Agent framework design is still unsettled. Vercel’s eve and Schott’s Flue both launched this year as competing templates for how to structure agent code, and Bret Taylor, the chairman of OpenAI and CEO of Sierra, has separately compared the current state of agent tooling to the early, less structured “jQuery era” of web development, before frameworks like React standardized how developers built interfaces. Schott’s bet is that the same hooks pattern that won that standardization fight for web UI will do the same for agents.

What it means for builders

If you are building anything beyond a single-purpose AI agent, the underlying question Flue is trying to answer, how do you add and remove an agent’s capabilities without rewriting its whole structure, is worth thinking through even if you do not adopt Flue itself. Look at whatever agent framework or hand-rolled setup you are using and ask whether adding a new capability today means editing one isolated piece, or touching the agent’s entire prompt and logic.

The practical conclusion: treat capability composition as a real design decision, not an afterthought. An agent that can only run with every possible tool bolted on from the start is harder to secure and harder to change than one that attaches capabilities as they become relevant. Whether or not the hooks pattern specifically wins out, that underlying discipline is worth building into your own agent code now.

End of article