When No Framework Is the Right Answer · Agent Frameworks in Depth

There is a genre of engineering blog post that recurs every few months: "Why we removed LangChain", "Life after CrewAI", "We replaced our agent framework with 200 lines of Python". The details vary; the shape never does. A team adopted a framework for a simple agent, shipped fast, and then spent the next two quarters fighting it — debugging through abstraction layers to find their own prompt, patching around an upgrade that broke retries, and discovering that the framework's opinion about context assembly was not their opinion. The punchline is always the same: for what they were actually building, the framework was more code than the problem.

These posts get dismissed as engineering vanity, but the position is credible, and you are unusually well placed to hold it. In Agent Architectures: Loops, Planning & Memory you built a ReAct loop, budgets and stop conditions, a memory layer, and checkpointing with resume — and in Tool Use, Code Execution & Sandboxing you built the tool layer under it. That is not a toy; it is most of what a framework sells. The question this lesson answers is not "frameworks: good or bad?" but the engineering question: for this system, does the framework's price buy anything I do not already own?

1. The Inventory: What You Already Own

Write down what your from-scratch work amounts to, because the no-framework position starts from an honest inventory, not bravado. From the previous two courses you have, in roughly 300-500 lines of Python you fully understand:

The loop — model call, tool-call detection, dispatch, result append, repeat until stop. Perhaps 40 lines.
The tool layer — schema generation from signatures, validation, timeouts, error messages the model can act on, result truncation. The part that actually took design effort.
Budgets and stop conditions — step caps, token budgets, loop detection, wall-clock limits.
Memory — working context assembly plus whatever episodic store your product needed.
Checkpointing — serialize state at step boundaries, resume from the last good step.

Every line of that is code with zero dependencies you do not control, zero upgrade treadmill, and a debugging story that is just "read your own code". That baseline is what a framework must beat — not zero.

2. What a Framework Actually Buys

Be equally honest in the other direction. Three purchases are real, and two of them are expensive to replicate well.

Persistence machinery, done properly. Your checkpointing lesson produced save-and-resume. Production-grade durable execution is more: state saved transactionally at every step boundary, keyed by thread, with history you can inspect, replay from any point, and fork for debugging — plus pause semantics robust enough that a human approval can arrive three days later, after two deploys, and the run continues. LangGraph's checkpointer, Mastra's suspend/resume, and Microsoft Agent Framework's durable workflows are each multiple person-months of hardening you get off the shelf. If your system needs this, the buy is genuine.

Streaming plumbing. Users expect tokens as they generate, tool-call progress as it happens, and resumable streams when a tab reconnects. Wiring token-level streaming through nested calls, subagents, and a web transport is boring, fiddly, and entirely solved by the better frameworks. The Vercel AI SDK's entire early success was this purchase alone.

Ecosystem and staffing. Integrations someone else maintains, docs a new hire has already read, patterns your team can Google. A from-scratch stack is a stack only its author knows; five engineers maintaining bespoke agent infrastructure is a framework, just one with a single-digit user count and no docs.

3. What It Costs

Abstraction debugging. The failure that finds you at 2 a.m. is now underneath someone else's call stack. When context assembly is wrong, you read framework source to learn what was actually sent to the model — and the fix may be a monkeypatch against internals the next release rewrites. Rule of thumb: a framework saves you writing code and charges you reading it.

The upgrade treadmill. Lesson 1's churn section was not decoration. Frameworks in this space ship breaking changes roughly quarterly — renamed constructors, rewritten cores, a breaking V2, a merger. Each one is a tax on every team that adopted, paid in migration PRs and re-validation of behavior that used to be tested. Your own 400 lines change only when you change them.

Lock-in and opinion. Framework message types leak into your business logic; framework prompt scaffolding leaks into your model behavior. The deeper the adoption, the more your system's semantics are defined by an API you do not control — the full accounting comes in Framework Evaluation Criteria and Lock-In at the end of this course.

4. A Decision Rule

Score your system against the five requirements that actually predict framework value. Count a point for each that is a hard requirement in the next two quarters — not "would be nice", but "the product is wrong without it":

Durable runs — executions must survive process death and resume, or pause for humans measured in days.
Complex topology — branching, parallel fan-out over dynamic item counts, or multiple cooperating agents.
Approval gates in the loop — humans approve or edit actions mid-run as a governed workflow, not a log review.
Streaming UX — token-level and progress-level streaming into a product surface.
Team scale — three or more engineers touch agent code, or agents are a long-lived product line, so shared vocabulary and docs carry weight.

Score 0-1: no framework. Your from-scratch loop plus a model SDK is less total system than any framework wrapper. Score 2: no framework, but steal designs — take the reducer and checkpoint patterns from lessons 4-5 and implement the one you need; revisit in a quarter. Score 3+: adopt — you would otherwise re-build a framework badly, in increments, without docs. Then pick by philosophy using Lesson 1's table, and wrap it behind your own interfaces so the treadmill stays outside your business logic.

5. Three Worked Examples

Example A: internal ops Q&A bot. A Slack bot for the platform team: answers questions over runbooks (RAG from Retrieval & Knowledge Systems: RAG to Agentic RAG), two read-only tools (search_runbooks, get_service_status), no writes, single turn or short conversations. Score: durable runs no (a failed answer is retried by the human asking again), topology no, approval no (read-only), streaming no (Slack posts whole messages), team scale no (one owner). 0 points: no framework. The model SDK, your loop, your tool layer — perhaps 250 lines, dependency-free. A framework here is pure carrying cost.

Example B: invoice-processing agent. Extracts data from inbound invoices, checks them against purchase orders, and queues payments — with finance approving anything over $10,000, sometimes days later; runs must survive deploys; month-end batches fan out over hundreds of invoices. Score: durable runs yes, topology yes (dynamic fan-out), approval yes (governed, auditable gates), streaming no, team scale yes (finance engineering owns it long-term). 4 points: adopt. The requirements are almost a description of LangGraph's feature list — checkpointers, interrupt(), Send — which is exactly what lessons 5 and 6 build.

Example C: writing assistant in a Next.js product. A TypeScript product team adds an AI editor: streaming suggestions, a couple of tools (search, document lookup), per-session state, three frontend engineers shipping weekly. Score: durable runs no, topology no, approval no, streaming emphatically yes, team scale yes. 2-3 points, with a twist: both points live at the UI seam, so the from-scratch position is weak precisely where the team's time would go — reinventing streaming transport. The Vercel AI SDK (or Mastra, if workflows loom) buys the expensive part and stays out of the rest. Framework choice follows the shape of the points, not just the count.

6. Holding the Position Honestly

The no-framework position is credible for simple loops — and it stays credible only while the system stays a simple loop. The failure mode of the purist is accreting a bespoke framework one urgent patch at a time: a retry decorator here, a hand-rolled approval queue there, until the team maintains an undocumented LangGraph with none of the tests. Re-run the five-point score every quarter or at every major feature request, whichever comes first, and treat a rising score as a scheduled refactor rather than a defeat.

What you can now do: inventory what your from-scratch stack already covers; name the three genuine purchases (persistence, streaming, ecosystem) and the three genuine costs (abstraction debugging, treadmill, lock-in); and defend a build-or-adopt call with a score instead of a vibe. For the rest of this course, keep Example B in your head — it is the running justification for everything LangGraph charges. The next lesson starts paying that bill: your first agent as an explicit graph.