There's a growing sentiment among developers building agentic systems that heavyweight orchestration frameworks solve a problem most projects don't actually have yet. The core loop behind a huge share of production agents is genuinely simple: call a tool, observe the result, decide what to do next, repeat until done. That loop can be written in well under two hundred lines of plain code, with no abstraction layers, no framework-specific configuration objects, and no need to learn a library's particular vocabulary for chains, agents, and callbacks before you can reason about what your own code is doing. The appeal of a framework is usually the promise of built-in features: memory management, tool-calling conventions, retry logic, and integrations with dozens of vector stores and APIs out of the box. But for a huge fraction of real projects, only a handful of those features are ever actually used, while the rest of the framework's surface area still has to be understood, configured around, and debugged when something goes wrong deep inside an abstraction the developer didn't write. A minimal hand-rolled loop, by contrast, is fully legible: every line is something the team wrote and can modify freely, there's no framework version to track or migrate between, and debugging means stepping through your own code rather than tracing through several layers of framework internals to find where a tool call actually got dispatched. This doesn't mean frameworks are never worth it. Complex multi-agent systems with many interacting components, shared memory across dozens of tools, and sophisticated planning strategies can genuinely benefit from the scaffolding a mature framework provides. But it's worth treating framework adoption as a decision to actively justify rather than a default starting point, especially early in a project when the actual requirements are still being discovered.