The standard advice for building LLM apps is now “just use LangChain,” and it is quietly costing people their production reliability. That is the argument I want to make for native agent architecture. Fourteen years of untangling over-engineered abstractions in WordPress taught me the shape of this pattern, and AI tooling is repeating it.
Frameworks are great for a demo. You can chain a prompt, a vector store, and a model call in twenty lines. Three weeks into production, when a request hangs or an agent skips a verification step, you are reading 500 lines of somebody else’s source code to find out where your context got cut. Writing that layer yourself is not reinventing the wheel. It just means the code you have to debug is code you can read.
The cost of hiding complexity
Abstraction is supposed to hide the details you don’t need. LangChain also hides the ones you do need once real traffic shows up, mainly visibility and control. A heavy framework trades observability for development speed. At the prototype stage that is a good trade. It stops being a good trade the first time you have to explain an outage to someone.
The abstraction debt usually comes due in a few places:
- A failing multi-step chain drops you into the framework’s internal routing and callback layers before you can even confirm your own logic was wrong.
- Every layer adds overhead. Five model calls per request means five rounds of the framework’s serialization and validation, and that lands in a p99 your users can feel.
- Framework-managed state holds up on the happy path. When one agent reads stale context written by another, the same machinery that made setup quick hides where the bad value came from.
I wrote earlier about an LLM agent memory architecture that holds up under this kind of pressure, mostly because every read and write of state is written out where you can see it.
What a native agent architecture actually is
A native agent architecture still uses libraries. What changes is the orchestration layer, which you write yourself. You define the state, you write the tool-calling logic, and the instrumentation sits directly on the model calls.
Compare the framework version below with the native one. The second takes more typing and leaves nothing about the flow to guess at.
// The Framework Way (Black Box)
$chain = new ConversationChain($llm, $memory, $prompt);
$response = $chain->run("Process this order.");
// The Native Agent Architecture Way (Explicit Control)
function bbioon_orchestrate_agent($input, $state) {
$context = bbioon_get_validated_context($state);
// Explicit Model Call
$llm_response = bbioon_call_model($input, $context);
// Explicit State Transition
if ($llm_response->requires_tool()) {
return bbioon_execute_tool_and_update_state($llm_response, $state);
}
return $llm_response->content;
}Once the orchestration is your own code, ordinary event-driven patterns are back on the table. Parallel execution and conditional branching are far easier to write that way than they are when you bend a synchronous chain into something that behaves like a state machine.
When to make the switch
LangChain is not useless. Validating a feature, or shipping an internal tool for three colleagues, is what it is good at. The calculation changes once you have an SLA, several agents coordinating, and a pager pointed at the system. I made a related argument in my post on why LLM wrappers are dying: at some point the job stops being configuration and starts being architecture.
If wiring your own agent orchestration is eating your dev hours, I take on this kind of work. I have been building on WordPress since the 4.x days, and I know how to build systems that stay up.
Own the code you have to debug
You should not have to hope that a framework’s memory module isn’t quietly trimming your context. When you own the orchestration, the failure lands in code you can read, and so does the fix. That is worth more than the week the framework saved you at the start.
