olivlawolivlaw

From books

Choose the framework after you have a simple agent that works; the framework must keep your loops visible, not hide them.

John Gall · Systemantics: How Systems Work and Especially How They Fail · 1975 · Systemantics: How Systems Work and Especially How They Fail (1975) — «legea lui Gall»1 minute read
“A complex system that works is invariably found to have evolved from a simple system that worked.”John Gall · Systemantics: How Systems Work and Especially How They Fail · 1975 · Systemantics: How Systems Work and Especially How They Fail (1975) — «legea lui Gall»

Start from the hundred-line raw loop; adopt a framework when you need durable state, human pauses or routing.

The 2026 open-source landscape, as examples: graph orchestrators with state and checkpoints (LangGraph), agents with typed inputs and outputs (PydanticAI), role-based crews (CrewAI), agents that write code instead of calling tools (smolagents), the model labs' SDKs (OpenAI Agents SDK, Google ADK, Microsoft Agent Framework — the autumn-2025 merger of AutoGen and Semantic Kernel — Claude Agent SDK). The criteria: can you see every model call and tool call? can you pause, resume, replay? does it tie you to one model provider? how much context does it add on its own? Start from the raw loop over the API (a hundred lines); adopt a framework when you need durable state, pauses for a human, or multi-agent routing. Beware "magic" that hides prompts you will have to debug.

The card says: choose a framework late. The next step is that the simple loop you start with becomes the yardstick for judging that framework. Once you have run a hundred lines by hand, you already know what your agent does at each step. Adopting a framework then becomes a comparison: what does it add beyond my loop? If the answer is only convenience, you do not need it. If it gives you state that survives restarts or pauses for a human, then it earns its place. It is like cooking a recipe from scratch once before buying a kitchen gadget: only then do you know which step you want to automate. Without a loop you wrote yourself, the framework decides for you what matters. The next question: which parts of your loop should stay visible when you migrate?

Passage 1 ended with a question: what do you keep visible when you migrate? Gall's answer is brutally clear: a system that hides its own steps is not a system, it is a black box that fails late and unexplainably. So the real selection criterion is not the feature list, but transparency. A good framework shows you every model call and every tool call, just like your hundred-line loop did. A bad one says "don't worry, we know what we're doing" and buries the prompts deep inside. It is the difference between a dashboard and a closed hood: the first warns you before the breakdown, the second only after you're stranded. When comparing frameworks, put your hands on the generated code and ask: could I debug this at three in the morning? If not, it's not yours. But visibility has a price, and you pay it yourself — which is what comes next.

Why it matters The wrong framework shows in month three, when you cannot explain why the agent did what it did.

Raw loop overthe APITypedworkflowStatefulorchestratorMulti-agent
Climb only when the system below works.
Open on YouTube ↗

Shelves

← Back to the feed