On stage Jimmy lays out the whole agent stack in just three layers. The bottom layer is the harness, the equivalent of an OS. The middle layer is the agent itself, the equivalent of an app. The top layer is the framework, the equivalent of an SDK. He states it plainly, a framework is not an agent, it is only the SDK of the agent era. The comparison is simple. When building a mobile app, nobody calls React Native an app. It is the tool used to assemble the app. A framework for agents sits in exactly the same spot.
With three layers laid out like this, he splits frameworks into two camps right away. One camp is the independent framework, one that runs on any model vendor. The other camp is the model provider's own SDK, which trades independence for deeper integration with its own system. He says plainly this is not a new fight, it is the same old fight that keeps coming back at every layer of the stack. Whichever side you pick, you trade independence for lock in. You cannot get both in full.
The Three Pieces Every Agent Shares, No Matter the Framework
Whichever camp you pick, the agent you build ends up with the same three pieces. The model is the brain. The tools are the hands. The instructions are the operating manual. These three pieces do not change no matter which framework wraps around them.
Wherever these three pillars are weak, the agent fails right there. Pick the wrong size model, and a big model on an easy task costs more than it needs to, while a small model on a hard task gets the answer wrong often. Give it too few tools and the agent can only do half the job. Give it too many without filtering and the agent picks the wrong one because there are too many choices. Instructions are the piece people overlook the most, because 1 ambiguous line of instruction is enough to send the whole task the wrong way, no different from handing a new employee an unclear manual and leaving them to figure it out alone.
This is exactly where the most practical advice in this piece comes from. Always start with a single agent. One agent, done well, already covers most of the work. Multi agent setups add complexity before anyone has even proven it is necessary. He sums it up in one line that governs this whole piece.
Add complexity when the evidence demands it, not when you feel like it.
That evidence is not a feeling that the job has grown bigger, it has to be something you can point to. The single agent starts missing deadlines. 1 task now holds two roles that conflict inside the same instruction. Or the queue starts backing up because one agent can only do one thing at a time. Only when signals like these actually show up should you split into multiple agents, not because you want to try out a new architecture.
Once you actually reach the point where complexity is forced by evidence, guardrails and human checkpoints at the risky steps have to come with it. The goal of the whole system is not to get it right once and be done, it is to get it right every single time, and if it fails one day, it has to fail in a way you can control, not in a way that has no idea where it will stop.
The point where a human has to sign off does not need to be at every step, but it needs to be at the steps that are hard to undo, before actually sending an email, before deleting data, or before deploying work into production. Steps that are easy to fix if they go wrong can be left for the agent to keep working through without stopping to wait on a person.
The way to check whether your checkpoints are placed right is to pull the logs from around ten runs the agent has already done. If every run ends the same way, the three pillars are strong enough. But if some runs come out different and nobody notices until later, that is a sign the checkpoints are in the wrong spot, not just too few or too many, but not placed where the system actually risks breaking.
The Criterion for Picking a Framework That Beats a Feature List
Now, when it actually comes to picking a framework, he gives one single criterion, the depth of protocol support, not the number of features listed on the marketing page. A framework that only supports the protocol on the surface tends to break when it has to connect complex tools or switch between models from several vendors at once. A framework with real depth keeps working even when the model underneath changes. He gives an example to back this up, same model, same task, but change the framework and the score can differ by a wide margin.
Part 2 of this series already warned about exactly this, that a number quoted for comparison has to be traced back to where it came from before you use it to decide anything. The criterion you can lean on is the depth of protocol support, which you see by wiring up real tools and swapping the model underneath, not from a single summary figure.
Where This Actually Applies to Your Work
The last post covered permission, that an agent differs from a chatbot because it acts and produces a real effect in the world. This one is the continuation. Before letting an agent act, you have to choose what to build it with, and these two posts link together into one piece of advice for anyone about to pick a framework or build their team's first agent.
Always start with a single agent. Let it cover work you can clearly check the results of first, then move to harder to interpret work later. When you reach the point of considering a second agent, ask yourself first what evidence forces you to do it, not just a wish to try something new. If you cannot answer what the evidence is, that means it is not time yet.
When it comes to picking a framework, check the depth of protocol support first, not the feature count on a marketing page. And if you see a score comparing frameworks anywhere, trace it back to where it came from before you believe it, every time.
And once the agent is actually running, do not forget to place human checkpoints at the hard to undo steps from the start, not at every single step until the system becomes too slow to use, and not skipping them entirely until a mistake happens that you cannot catch up to.
Framework and a single agent is the starting point, but there is still a question this post has not answered. If you pick the right framework and start with one agent correctly, then let it run in real work, how long does it last before it fails, and who is actually watching over it. The next post will cover the answer to both questions.
Source
Everything here comes from AI Update Bangkok 2026, held on 21 August 2026 at The Cloud Bangkok by Jimmy Tejasen. This part covers the session on frameworks in the agent era.