Why Static AI Agent Specs Broke Down
We break down why early AI agent frameworks relied on brittle static specs, and how a more React-like approach lets agents re-render before each model turn to adapt tools, models, and state on the fly.
Plus, we look at Agent Hooks, composable TypeScript logic, and why the underlying harness is becoming the real foundation for building reliable agent systems.
Chapter 1
Beyond the jQuery Era Why Static Agent Specs Failed
William Palmer
Bret Taylor, the CEO of Sierra and chairman of OpenAI, made this, this really striking comment recently. He said we are currently stuck in the jQuery era of AI agents, not the React era yet. And, er, when you look at how developers were building agents even six months ago, you see exactly what he meant.
William Palmer
Fred Schott, who created the Astro web framework, set out to build what he initially called the Next dot js or Astro for agents. It was called Flue. And at first, he took concepts straight from web development, like, you know, file based routing. The idea was simple. Put your five agents in five separate files, and those become your five routes. But then enterprise teams started using it, and they came back with a total curveball. They told him, er, our whole company is one agent. We do not care about routing at all. There is just one central agent.
William Palmer
That feedback sparked a fundamental shift from Flue one point zero to Flue two point zero. See, in Flue one point zero, you defined agents using static configuration objects, kind of like a fixed blueprint. But as soon as you try to run complex, multi step workflows in the real world, those rigid static specs just break down completely.
William Palmer
Think about an issue triage bot. When it boots up, maybe it starts on a faster or cheaper model. It checks who the user is. Once it verifies their permissions, it suddenly needs to attach administrative tools to its context. And if the user submits a really tricky bug report, that bot might need to conditionally hand off the task or trade up to a more powerful model like Claude to handle the deep reasoning. You cannot easily configure all of that statically in advance before the conversation even starts.
William Palmer
As someone who spent years, you know, building software and racing cars, this feels so familiar to me. It is the exact same transition we saw in web UI development years ago. We moved away from manually tweaking the DOM element by element, toward declarative re rendering where the UI is just a function of state. In Flue two, an agent is literally a JavaScript function that re renders before every single LLM turn. Re evaluating the agent code before every model call stops that massive context drift that usually destroys long running agents.
Chapter 2
React Hooks for AI Composable Logic and the Harness Paradigm
William Palmer
So how does this actually work under the hood? Flue two introduces what Schott calls Agent Hooks, authored in TypeScript. Before every turn, these hooks run and dynamically adjust what the agent can see and do. There are sixteen built in hooks, things like use Tool, use Skill, use Subagent, or managing persistent state and sandboxes. You can attach capabilities at runtime based on what just happened in the chat history.
William Palmer
And the real beauty here is composability. Because hooks are just reusable functions, you can package up agent logic and share it on npm. Imagine downloading a package that wraps Linear and GitHub integration into a clean hook, like use Linear, and just dropping that into any agent codebase. It brings proper software engineering patterns into prompt engineering and agent setup.
William Palmer
Now, this is also where an architectural debate is heating up. Flue is competing closely with frameworks like Vercel's eve. But while some frameworks try to build custom CLI tools or heavy lock in, Schott stripped all that out. Flue two runs on Vite, the standard open source build tool, and builds on top of an open source minimal harness called Pi, written P I.
William Palmer
The core philosophy here is that an agent cannot exist without a harness. The harness provides the execution environment, the tools, the sandbox, and the memory. But this brings us to a massive double edged sword that every developer needs to grapple with.
William Palmer
On one hand, giving an agent the power to dynamically attach tools, swap its own models, and rewrite its instructions on the fly unlocks incredible runtime flexibility. On the other hand, if an agent is constantly changing its own tools and state dynamically, good luck debugging why it took a wrong turn on step fourteen. We are moving from deterministic programming to dynamic behavioral orchestration, and that is going to be wild to tame. But it definitely feels like the direction the whole field is moving. Alright, that is the deep dive for today.