Agent Framework or Custom Code?
Agent frameworks like LangChain offer a faster start but add an abstraction that costs at debugging time, at version upgrades, and through lock-in to the framework's patterns. Thin custom code built directly against model APIs gives more control when the logic is simple. Either way, you need tools for evaluation and observability.
When a team is about to build its first AI agent, the question comes up early: should we use a framework like LangChain, or write the orchestration ourselves, directly against the model APIs? It’s a real choice with consequences for how easy the solution is to debug, maintain, and swap out later. Here’s how the trade-off looks, and which tools you need regardless of how you choose.
What the choice actually comes down to
An AI agent is at its core a loop: the model gets a task, chooses to call tools, receives results, and continues until it’s done. The question is who writes that loop and the glue around it.
An agent framework gives you ready-made building blocks for exactly this – tool connections, memory handling, patterns for chaining calls. Custom code means you build the orchestration yourself, thin and directly against the API. The first option gives you a faster start. The second gives you a smaller codebase you understand down to the last detail. Much of the decision comes down to weighing the two against each other.
The abstraction cost of frameworks
Frameworks are sold on how much they simplify, and that holds true early on. But the abstraction has a price that shows up later, and it’s worth going in with eyes open.
- Debugging. When something goes wrong, the error sometimes sits deep inside the framework instead of in your own code. Understanding what actually happened then requires digging through layers you didn’t write yourself.
- Version upgrades. Frameworks under rapid development change behavior between versions. An update can force rewrites, and you tie your pace to someone else’s release schedule.
- Lock-in to patterns. Your solution gets shaped around the framework’s way of thinking. The more you build, the more you’re stuck in its abstractions – and the harder it becomes to change course later.
None of this makes frameworks a bad choice. The point is that the abstraction cost is real and is paid over time, not at the start. Weigh it against the running start the framework saves you.
When thin custom code is enough
For many agents, the logic is actually fairly simple: a few steps, a handful of tools, a clear flow. A full framework can then become more detour than help.
A concrete scenario: you want to build an agent that takes a customer question, looks up the answer in two internal systems, and compiles a response. That’s a handful of calls in an easy-to-follow order. A thin custom orchestration built directly against the model API does the whole job, is easy to debug, and keeps the codebase small. Here, custom code is often the faster and more sustainable choice, contrary to what you might expect.
The rule of thumb: the simpler and more predictable the flow, the stronger the case for custom code. The more dynamic and branching the logic becomes, the more a framework’s building blocks can start to pay off. Better to start simple and add structure once the complexity actually demands it, rather than building for a need you don’t have yet.
Tools you need regardless of choice
This is the most important insight, and it holds regardless of which path you choose: two things are needed either way, and they’re often underestimated.
The first is evaluation. You need to be able to determine whether the agent is doing the right thing, and that requires a test suite with real examples that runs systematically, not just a sense that it “seems to work.” Without it, every change becomes a guess.
The second is observability. When an agent makes a mistake, you need to be able to see what it did at each step – which calls, which tools, which responses. Without traceability, debugging becomes nearly impossible, since agents often fail in unexpected ways in the middle of a chain.
Note that none of this comes free with a framework. Evaluation and observability are their own investments regardless of whether the orchestration is custom code or built on LangChain. Budget for them from the start, so you don’t end up building them in a panic the day the agent starts behaving unexpectedly in production.
If you want help architecting an AI agent and making this choice on solid ground, read more about our AI work or get in touch.
Frequently asked questions
What's the difference between an agent framework and custom code?
An agent framework like LangChain gives you ready-made building blocks for connecting model calls, tools, and memory. Custom code means you write that orchestration yourself, thin and directly against the model APIs. The framework saves you a running start but adds a layer to learn and maintain, while custom code gives full control over a smaller codebase.
When is thin custom code enough?
When the agent's logic is easy to follow: a few steps, a handful of tool calls, and a clear flow. A full framework is then often more detour than help, and a thin custom orchestration built directly against the API is easier to debug and own. The simpler the flow, the stronger the case for custom code.
What is the abstraction cost of a framework?
That the abstraction hides what's actually happening. It shows up in debugging, when an error sits deep inside the framework instead of in your own code, and at version upgrades, when the framework changes its behavior. There's also lock-in: your solution gets shaped around the framework's patterns, which can be hard to leave later.
What tools are needed regardless of which we choose?
Evaluation and observability. You need to be able to measure whether the agent is doing the right thing – a test suite with real examples – and to see what it did at each step when something goes wrong. Those needs are independent of whether you build on a framework or custom code, and they're often underestimated early on.
Can we start with custom code and switch to a framework later?
Often yes, if you keep the model calls and the logic clearly separated from the start. Then a later switch becomes manageable if complexity grows. The reverse, leaving a framework, is usually harder because more of the solution has already been shaped around its patterns. Better to start simple and add structure once the need is proven.