You Probably Don’t Need an Agent Framework | Towards Data Science

Justy Cody, I spent way too long this week going down a framework rabbit hole and then I read this piece that basically says — you probably don't need one.

Cody Which one?

Justy Shuai Guo, Towards Data Science. His whole argument: most LLM apps need a clear workflow, not an autonomous agent, and you can build it in plain Python.

Cody Okay, that's… actually aligned with what we keep landing on. This is the harness thesis again.

Justy Right? It's very ep five-fourteen — product is the harness, not the model. But this one's more pointed. He's saying the framework itself might be the wrong first abstraction.

Cody Yeah.

Justy Like, you start by picking CrewAI versus LangGraph versus whatever, spend hours comparing docs, and you haven't even written code yet.

Cody And the real question he's asking is — do you even need an agent? Which is the thing Sydney Runkle was getting at with loop engineering too. If you already know the steps, why hand control to the model?

Justy Exactly. He says for a lot of real problems, you know roughly how it should be solved. So define the steps yourself, use the LLM as a decision node inside the process, not the whole system.

Cody Mm-hm.

Justy And the wins are pretty concrete — workflows are transparent, modular, and the control flow is deterministic. The LLM can still reason inside a step, but the overall path is owned by code.

Cody That's the part I actually buy. Deterministic control flow removes a whole class of debugging nightmares. You're not chasing why the agent decided to call tool X instead of Y — the path was already decided, you just need to check what the model did at that one node.

Justy He walks through an anomaly explanation example, like a real use case — not toy stuff. And he says there's basically four ingredients you need.

Cody Let me guess — control flow, system prompts, something for prompt construction, and structured output?

Justy Yeah — role instructions, prompt builders, structured output. That's it. No framework. Just Python functions and the OpenAI Responses API.

Cody I mean… he's right for the cases he's describing. If your problem decomposes into known steps with LLM calls at specific points, a framework is overhead. You're paying an abstraction tax for routing you could write in fifteen lines.

Justy Right.

Cody But here's where I'd push back — he's basically saying 'if you already know the graph, just write the graph.' That's true! But some problems genuinely don't have a known graph. The whole point of an agent is dynamic routing when you can't predefine the path.

Justy And he admits that, to be fair. Says frameworks are clearly useful in some scenarios and he's not arguing they're bad.

Cody Right, right. But the framing is still 'you probably don't need' — and I think the 'probably' is doing a lot of work there. If you're doing anything open-ended — research, debugging, multi-step exploration — you actually do need dynamic control.

Justy I think the audience he's really talking to is the person who reaches for CrewAI on day one because they heard 'agents' and assume that's the architecture. Not someone who's already evaluated whether they need dynamic routing.

Cody Sure.

Justy And from the product side — I've seen this so many times. Someone picks a framework, builds around it, and then the framework's opinions about state or tool-calling become constraints they have to work around.

Cody That's real. And it's the same thing we talked about with Flue — the framework should serve the workflow, not the other way around. Flue's whole pitch was zero lock-in and portable primitives.

Justy The other thing he doesn't really address is what happens at scale. Like, okay, plain Python works for a prototype. But when you need persistence across restarts, recovery, multi-channel integration — that's where frameworks earn their keep.

Cody Agreed. 'Just Python' starts to look a lot like a framework you built yourself, badly, at two AM.

Justy That's every production system ever.

Cody The honest version of this article is — start with a workflow, start in plain code, and only reach for a framework when the problem demands it. Not 'you probably don't need one,' but 'earn the abstraction before you adopt it.'

Justy I like that better actually. Start simple, add complexity when you have evidence. That's just good product thinking.

Cody Yeah.

Justy Anyway — I'm going to go write some plain Python workflows now and pretend I never looked at those CrewAI docs.

Cody Sure you are.