Every few weeks a new open-source agent framework trends, and a client sends us the link asking whether they should be using it.
Usually the honest answer is that the framework is the least important decision in the project. But "should we use open source for this" is a genuinely good question, and it has a real answer — just not at the level people ask it.
So rather than a tool list that's stale in a month, here's the durable version: the stack has four layers, they have very different economics, and the right open-source decision is different for each.
Layer 1 — The model
The most discussed and least consequential decision.
Open-weight models are now good enough for the majority of business agent work — classification, extraction, routing, summarisation, structured tool-calling. The gap to frontier commercial models has narrowed to the point where, for most tasks in a business workflow, you would struggle to tell them apart in a blind test.
Rent (a hosted API) when: you're starting out, your volume is low or unpredictable, you need the strongest reasoning available, or you don't want to run inference infrastructure. This is the right default for almost everyone at the start.
Self-host when: your data genuinely cannot leave your infrastructure, your volume is high and steady enough that per-token pricing exceeds the cost of running your own, or you need latency you can control.
The honest cost picture: self-hosting is rarely cheaper until volume is substantial. You're trading a per-token bill for GPUs, ops time, and someone who can debug a serving stack at 2am. Teams consistently underestimate the third.
The practical move: put the model behind your own interface from day one so switching is a config change. That single decision matters more than which model you pick, because you will change models — the market moves too fast not to.
Layer 2 — Orchestration
Where the frameworks live, and where most of the churn happens.
Here's the uncomfortable observation from building these: for most business agents, you don't need an orchestration framework at all. The majority of useful agents are a loop — call the model, parse a tool call, execute it, feed the result back, repeat until done or a limit is hit. That's a few hundred lines you fully understand.
Frameworks earn their place when you need genuinely complex multi-agent coordination, or when a team benefits from shared conventions. They cost you when you spend a week fighting an abstraction to do something a direct API call does in ten lines — and that happens more than the documentation suggests.
Our default: write the control flow yourself. It's less code than you expect, it's debuggable, and it doesn't break when the framework ships a major version. Reach for a framework when the coordination is genuinely complex, not by default.
If you do adopt one, weight maintenance signals over feature lists: commit recency, issue response times, breaking-change frequency, and whether anyone is running it in production at your scale. Framework abandonment is common, and inheriting an unmaintained dependency at the centre of your agent is a bad position.
Layer 3 — Tools and integrations
The layer that actually determines whether your agent works, and the one that gets the least attention.
An agent's usefulness is bounded by what it can do. Connecting to your ERP, your WhatsApp Business account, your payment gateway, your logistics provider — that's the work. It's unglamorous, it's specific to your business, and no framework does it for you.
Open source helps here in a narrower way than people expect. Generic connectors exist for common SaaS products. For Indian systems — Tally, regional ERPs, government APIs, local logistics providers — you will be writing them yourself. That's not a gap in the ecosystem; it's the nature of integration work.
Standardised tool protocols are the genuine advance in this layer. Rather than writing a bespoke adapter per agent, you expose a capability once behind a standard interface and any agent can use it. That's worth adopting, because it means your integration work outlives whichever agent framework you're using this year.
This layer is where you should invest, and it's where your real lock-in lives — not in the model or the framework, but in the accumulated integration work. Own it deliberately: your business logic in your repository, behind interfaces you define. That's the same argument as putting an adapter around every vendor.
Layer 4 — Data: vectors, logs, traces
The layer where self-hosting is most clearly right.
This is where your business content lives — documents you've embedded, the conversation history, every prompt and response, every action the agent took. It is the most sensitive part of the stack and the part with the strongest argument for keeping it inside your own infrastructure.
Vector storage. Perfectly good open-source options exist, and for typical business corpus sizes the honest answer is often simpler still: if you're already running Postgres, its vector extension handles most workloads without adding a system to operate. Reach for a dedicated vector database when you have a scale problem you can actually demonstrate.
Observability is not optional. You need to see what the agent did, what it was asked, which tools it called, what came back, what it cost, and where it went wrong. Debugging an agent without traces is guesswork. Mature open-source options exist and self-hosting keeps prompts — which contain your business data — inside your boundary.
Evaluation. A test set of inputs with known-good outputs, run on every change. Open-source tooling exists, but the tooling matters far less than having the test set. Most teams have neither.
The three reasons people actually choose open source
Data residency and control. The strongest reason, and often decisive in Indian fintech, healthcare and government work where data cannot leave your infrastructure or the country. Everything else is negotiable; this frequently isn't.
Avoiding lock-in. Legitimate, but aim it at the right layer. Your lock-in risk is in integrations and accumulated prompts, not in the model. Self-hosting a model while hardcoding a vendor's SDK across forty files gets the priority exactly backwards.
Cost at scale. Real, but later than people think. Below meaningful, steady volume the hosted API is cheaper once you count engineering time. Model it honestly at your projected twelve-month volume, including the person who maintains it.
A reason that isn't good enough: "open source is free." It isn't. You've swapped a licence fee for operational burden, and for a small team that's usually a worse trade.
What we'd actually recommend
For most Indian businesses building their first agent:
- Model: hosted API, behind your own interface. Revisit at volume.
- Orchestration: write your own loop. Add a framework only when coordination is genuinely complex.
- Tools and integrations: own this completely. Standard protocols where they exist, your own adapters where they don't. This is the investment.
- Vectors: Postgres with a vector extension unless you can demonstrate you need more.
- Observability and evals: self-host, from day one, not after the first incident.
That's a stack you understand end to end, with no dependency you can't replace in a week, and your sensitive data inside your own boundary.
The part that outlasts the tooling
The tools in this space will keep changing. What won't:
Your integrations are the asset. Your evaluation set is what lets you upgrade anything safely. Your observability is what makes production debuggable. Your abstraction over the model is what makes the churn survivable.
Teams that invest in those four things can adopt whatever trends next in an afternoon. Teams that build directly on this quarter's framework rebuild every time it changes.
Deciding what to build and what to buy?
We build agent systems for Indian businesses, including the parts that are genuinely yours to own — integrations, evaluation sets, and observability — and we'll tell you honestly when a hosted service is the better answer than something we'd build for you.
Bengaluru-based, working with clients across India and globally.
Get in touch · See our agentic AI work · WhatsApp: +91 9677749648