AI decisions Architecture and technology
Agent framework vs custom orchestration: should you adopt a framework or write your own agent loop?
Adopt an agent framework when you need to move fast on common patterns, such as tool calling, multi-step plans, memory and tracing, and your team will follow its conventions. Write custom orchestration when the flow is mostly deterministic, the control and audit requirements are strict, or the framework's abstractions get in the way more than they help. Either way, keep your prompts, tools, policies and evaluations outside the framework so you can change it later.
The options
Agent framework
A library or platform that provides ready-made building blocks for agents: the reasoning loop, tool calling, memory, multi-agent patterns and tracing.
Custom orchestration
Your own code that calls models and tools directly and controls the flow, state and error handling explicitly.
Side by side
| Criterion | Agent framework | Custom orchestration |
|---|---|---|
| Time to first version | Faster for common patterns: the loop, tool schemas and integrations come ready to use. | Slower to start: you write the loop, retries, state handling and tracing yourself. |
| Control over the flow | Shaped by the framework's abstractions; unusual flows may need workarounds or extensions. | Complete: every step, branch and stop condition is explicit in your code. |
| Debuggability | Built-in tracing helps, but failures can hide inside layers of abstraction you did not write. | Plain code is easier to step through, provided you add your own logging and tracing. |
| Upgrades and stability | You benefit from new features, but fast-moving APIs can break your code between versions. | Changes only when you change it; new model capabilities must be wired in by your team. |
| Lock-in | Agents, state and tooling can become tied to the framework's concepts and, sometimes, to its hosted services. | Tied only to your own interfaces and the model APIs you call, which you can wrap. |
| Determinism and audit | Possible, but you must check what the framework does implicitly: retries, prompt rewriting, hidden calls. | Easier to guarantee that the same input follows the same path and that every call is logged. |
| Team skills | Requires learning the framework; easier to hire people who already know a popular one. | Requires solid software engineering; the code is only as good as the team that maintains it. |
| Maintenance effort | Shared with the framework's community or vendor; you track releases and deprecations. | Fully yours: bugs, security fixes and new patterns are your responsibility. |
Choose Agent framework when…
- You are prototyping or piloting and need to learn quickly what the agent should do.
- The use case matches patterns the framework handles well, such as tool calling, retrieval or multi-agent handoffs.
- Several teams will build agents and a shared, documented convention matters more than fine control.
- The framework's tracing, evaluation or deployment tooling covers needs you would otherwise build.
Choose Custom orchestration when…
- The process is mostly deterministic, with the model used at a few well-defined steps.
- Audit, security or regulatory requirements demand that you can explain and reproduce every call.
- Latency, cost or token budgets need fine control over each request.
- The framework's abstractions have become the main source of bugs or workarounds in your code.
- You have a strong engineering team willing to own the orchestration layer long term.
When to combine them
Many teams use a framework where it saves time and plain code where control matters. A practical split: keep the business flow, approvals and side-effecting actions in explicit code you own, and use a framework inside well-bounded steps, such as a research or extraction sub-agent. Put models behind your own gateway, expose tools through stable interfaces such as MCP where they fit, and version prompts and evaluations in your repositories. Then the framework becomes a replaceable component, not the foundation.
Common mistakes
- Choosing a framework by popularity or a demo, without testing it on your hardest flow and your audit needs.
- Spreading framework-specific objects through business logic, so changing it later means a rewrite.
- Writing custom orchestration without tracing, retries or tests, then struggling to explain what the agent did.
- Letting implicit framework behaviour, such as automatic retries or hidden prompts, reach production unreviewed.
- Treating the choice as permanent instead of revisiting it as the use case and the tooling mature.
How Thinkia approaches it
We do not start from a preferred framework. We start from the process: which steps need judgement from a model, which must be identical every time, and what evidence the business and its auditors will ask for. That map usually shows where a framework saves effort and where explicit code is safer, and we test both on the hardest real flow before committing.
Whatever the choice, we keep the parts that carry value outside it: prompts, tool contracts, policies and evaluation sets live in the client's repositories, and agents call models through a governed, model-agnostic layer. Synapse provides that layer, with corporate SSO, rate limiting, routing between models, a RAG repository on the company's own infrastructure and ROI dashboards, so the orchestration code can change without losing access control, logs or cost visibility.
Thinkia products involved
Related AI solutions
Frequently asked questions
Do we need an agent framework to build AI agents?
No. An agent can be a loop that calls a model, parses the tools it asks for, executes them and feeds back the results. Frameworks package that loop with extras such as memory, tracing and multi-agent patterns. Whether the extras are worth the dependency depends on your use case and your team.
Which agent framework is best?
There is no general answer, and the field changes quickly. Shortlist options against your own criteria: the flows you need, model support, tracing, how it handles state and errors, licence, release stability and the skills of your team. Then test them on a real use case with an evaluation set.
Is custom orchestration more secure?
Not automatically. It gives you more visibility into what runs, but security still depends on scoped credentials, input validation, protection against prompt injection and logging. A well-configured framework can be safer than custom code written without those controls.
How do we avoid lock-in if we adopt a framework?
Keep a thin boundary between the framework and your business logic. Store prompts, tool definitions and evaluations in your own repositories, call models through a gateway you control, and use standard interfaces for tools where they fit, so moving to another framework or to plain code is a contained change.
Can we start with a framework and move to custom code later?
Yes, and it is a common path: the framework speeds up learning in the pilot, and the parts that need strict control are rewritten as explicit code for production. Plan for it by keeping evaluation sets stable, so you can check that the rewrite behaves at least as well.
Keep exploring
Related decisions
- Build vs buy AI agents: which agents should you own, and which should you rent?
- MCP vs custom API integrations: how should your AI agents connect to your systems?
- Single AI vendor vs multi-model strategy: should you bet on one provider?
- Open-source vs proprietary LLMs: how should an enterprise choose?
- Human in the loop vs autonomous agents: how much should an AI agent decide on its own?