Adopting a full agent orchestration framework versus building a thin custom layer on top of a model provider's own SDK is a real architectural fork, and which side is right depends more on what your agent actually needs to do than on which framework is currently most talked about.
What a framework like this actually gives you
Full-featured agent frameworks provide structured patterns for multi-step reasoning, state management across a conversation or workflow, built-in patterns for tool use and multi-agent coordination, and often visual debugging or tracing. For a genuinely complex, multi-step, stateful workflow, that structure removes a real amount of work you'd otherwise have to build and maintain yourself.
What building it yourself actually gives you
A thin custom layer on top of a vendor SDK (the model provider's own agent tooling plus your own orchestration code) keeps your dependency surface small, avoids learning a framework's specific abstractions and debugging model, and can be genuinely faster to ship for a well-defined, single-agent task with a small number of tools. For many real production agents, especially the first one a team builds, this is a meaningfully faster path with less to learn and less to maintain.
What actually determines which is right
How many agents, and how they coordinate
A single agent calling one or two tools rarely needs a full framework's multi-agent coordination features. A system genuinely coordinating multiple specialized agents, with handoffs and shared state between them, benefits much more from a framework's structured patterns for that specific problem, which is exactly the distinction we cover in single agent vs. multi-agent.
How much of the workflow is genuinely stateful and long-running
If a workflow needs to pause, resume, checkpoint, and recover across a long-running process, potentially with a human-in-the-loop step in the middle, a framework with built-in checkpointing and state persistence saves real engineering time versus building that infrastructure yourself.
How much debugging and observability tooling you need out of the box
Frameworks with mature tracing and visual debugging can meaningfully speed up development and production troubleshooting for complex workflows. For a simpler agent, that tooling is less valuable relative to the overhead of learning and maintaining the framework itself.
Your team's appetite for a dependency that evolves fast
Agent frameworks in this space are still maturing quickly, and some have shifted direction or maintenance posture within a single year. A custom layer on a vendor SDK is a narrower dependency surface with typically more stability, since it tracks the model provider's own roadmap rather than a separate framework's.
The honest middle ground
These aren't mutually exclusive in the long run. Plenty of production systems start with a thin custom layer for a well-defined first agent, and adopt framework-level structure later once real complexity (more agents, more state, more coordination) actually shows up, rather than committing to framework overhead before the complexity that justifies it exists.
How we approach this
We start with the simplest architecture that fits the actual complexity of the agent being built, often a thin custom layer on a vendor SDK for a well-defined first agent. We adopt a full orchestration framework when real multi-agent coordination or long-running state genuinely requires it, not by default.