SURVEY OF AGENT FRAMEWORKS

BUILD YOUR OWN VERSUS ADOPT A FRAMEWORK The most important skill in this chapter is deciding whether to use a framework at all. Consider the reasons to adopt a framework. Speed: you reach a working prototype sooner. Shared knowledge: other developers have used it, so tutorials, examples, and answers to common questions exist. Built-in features: things like checkpoints, tracing, and tool plumbing arrive ready-made. Hiring and teamwork: new team members may already know it. Now consider the reasons to build your own. Fit: your needs may be unusual, so a general-purpose framework might fight you at every turn. Understanding: when you build the pieces, you understand exactly how your harness behaves, which helps greatly with debugging and with the safety work of Part Nine. Stability: frameworks change, and an upgrade can break your code or alter agent behavior. Dependency risk: you rely on the framework's authors to keep it maintained and secure, a concern you will revisit in Chapter 52. Weight: a large framework may bring many pieces you never use. A useful middle path is to build a thin layer of your own around a framework, so that most of your code does not depend on the framework's details. Then, if you must switch later, you replace only the thin layer. This protects you against being locked in, which means being so tied to one product that leaving becomes very costly. A practical rule for beginners is to build your first harness by hand, as in Part Sixteen, before adopting a framework. When you know what the loop, the tools, and the context management are doing, you can judge a framework's choices instead of simply trusting them. Another rule is to run a small trial before committing. Build the same small agent in your top two candidates, and compare how long it took, how readable the result was, and how easily you could see what happened inside.