Choosing an AI Agent Framework: An Honest Comparison for Mid-Sized Companies

There are now many agent frameworks, and their feature pages now look almost identical: tool calling, memory, multi-agent support, tracing. For an IT lead in a company of a few hundred people, the useful question is not which framework does the most, but which one your team can run for years against your systems and your data-protection constraints. This guide sorts the main options along five decision criteria. Everything below was checked against vendor documentation in October 2026.

What is an AI agent framework, and when do you need one?

An agent framework is a library that handles the repetitive mechanics of an AI agent: calling the model, running tools, feeding results back, keeping state and controlling the flow. You need one once an agent does more than answer a single question, for example assembling a quote from three systems or working a support ticket over several steps.

Without a framework you write that loop yourself. The model asks for a tool, your code runs it, the result goes back to the model, and so on until the task is done. For simple cases that is perfectly reasonable, and sometimes the better choice. Microsoft's own documentation advises that if a plain function can do the job, you should write the function rather than use an agent.

The hand-written loop gets painful when real-world requirements arrive. A run fails after ten minutes and must resume where it stopped. Someone in finance must approve before anything is sent. Two agents split the work. An auditor asks why the agent chose a particular supplier. These are the problems frameworks solve with ready-made parts.

If you are still deciding which business processes deserve an agent in the first place, start with the overview of AI agents for quoting, service, knowledge and sales. This article covers the technical choice underneath.

How does an agent framework work? The building blocks

Almost every framework is built from the same five parts: a model connector, a tool layer, flow control, state storage and observability. The real differences lie in how much of each part the framework decides for you and how much it leaves to your code.

• Model connector. Translates between your code and a model provider's API. Some frameworks are designed around one provider; others ship adapters for many providers and for locally hosted models.
• Tools. Functions the agent may call: query a database, look up an order in the ERP, read a PDF, draft an email. A shared denominator across frameworks is the Model Context Protocol (MCP), an open standard for connecting AI applications to external systems. A tool built once as an MCP server can be reused by several frameworks.
• Flow control. This is where frameworks differ most. At one end sits an explicit graph in which you define every step and transition. At the other end sits an open agent loop in which the model decides which tool to use next.
• State and memory. Conversation history, intermediate results, checkpoints for resuming after a crash, and optionally long-term memory across sessions.
• Observability. Traces of every model and tool call. Without them, production issues are close to impossible to debug. For data protection, check where those traces are sent.

How these parts fit into a wider architecture, including document retrieval and access control, deserves its own discussion. Here the focus is the choice of library.

Which frameworks are realistic candidates?

In October 2026, six frameworks cover most realistic choices for a mid-sized company: LangGraph, CrewAI, the Claude Agent SDK, the OpenAI Agents SDK, Microsoft Agent Framework and Google's Agent Development Kit (ADK). They differ mainly in control philosophy, programming language and model coupling, much less in raw features.

LangGraph

LangGraph describes itself as a low-level orchestration framework and runtime for long-running, stateful agents. Its documented focus is durable execution that survives failures, human inspection and editing of agent state, short- and long-term memory, and mixing deterministic code steps with model steps in one graph. You do not need LangChain to use it. A JavaScript/TypeScript port, LangGraph.js, exists, and local models can be wired in through packages such as langchain-ollama.

CrewAI

CrewAI is a standalone, MIT-licensed Python framework with its own primitives. Its documentation separates Flows, which own structure and state, from Crews, which are teams of autonomous agents that a Flow step can delegate to. OpenAI, Anthropic and Google Gemini have native integrations; everything else, Ollama included, runs through LiteLLM.

Claude Agent SDK

According to Anthropic, the Agent SDK exposes the same tools, agent loop and context management that power Claude Code, as a Python or TypeScript library. Built in are file and shell tools, hooks, subagents, MCP, permissions and sessions. The quickstart lists the Anthropic API, Amazon Bedrock, Claude Platform on AWS, Google Cloud and Microsoft Foundry as ways to reach the model.

OpenAI Agents SDK

OpenAI positions its SDK as a lightweight package with very few abstractions: agents, handoffs between agents, guardrails, sessions and tracing. It is Python-first with a JS/TS sibling. Other providers can be used through OpenAI-compatible endpoints or through LiteLLM and Any-LLM adapters, which the docs mark as best-effort beta.

Microsoft Agent Framework

Microsoft calls it the direct successor to Semantic Kernel and AutoGen, built by the same teams. It pairs agents with graph-based workflows and lists Microsoft Foundry, Azure OpenAI, OpenAI, Anthropic and Ollama among its model providers. The Go version is still in public preview according to the docs.

Google ADK

The ADK repository states that ADK is optimised for Gemini but is model-agnostic and deployment-agnostic. The documentation covers five languages, adapters for locally running models, and deployment either on your own infrastructure or on Google Cloud.

A head-to-head of the four most-discussed options and a short selection checklist are covered in separate articles in this section.

How should you decide? A five-criteria matrix

Work through five criteria in a fixed order: team language, control, model coupling, self-hosting and lifecycle. The first two usually eliminate half the field. Feature comparisons help far less, because the frameworks have converged on features.

1. What language does your team actually maintain?

A framework your team cannot maintain in its main language becomes a liability. If most of your developers write C#, Microsoft Agent Framework is the obvious starting point because .NET is a first-class citizen there. Java and Kotlin teams get native support from Google ADK. TypeScript-only teams can choose between LangGraph.js, the Claude Agent SDK, the OpenAI Agents SDK's JS/TS version and ADK. Python is covered everywhere; CrewAI is a Python framework.

2. How much control do you need over the flow?

This is the most important functional question. A process such as "check the enquiry, fetch prices from the ERP, draft a quote, sales manager approves, send" has fixed steps and checkpoints. You want an explicit flow in which the model only decides inside individual steps. LangGraph, the workflows in Microsoft Agent Framework and CrewAI Flows are designed for exactly that.

An open investigation such as "find the likely root cause in manuals, past tickets and maintenance logs" benefits from an agent loop that chooses which source to read next. That is where the Claude Agent SDK fits well, because it ships a mature loop with file, search and shell tools plus a permission system. Many production systems combine both: a fixed flow on the outside, an open loop inside one step.

3. How much model lock-in will you accept?

Tight coupling to one model is a trade-off, not a flaw. A framework built around one provider often uses that model's capabilities more fully and has fewer translation layers. An open framework lets you move when pricing, availability or quality shifts.

The Claude Agent SDK is deliberately built for Claude. The OpenAI Agents SDK defaults to OpenAI's API and reaches other models through compatibility layers whose feature coverage, as its docs note, can vary by provider. LangGraph, CrewAI, Microsoft Agent Framework and ADK are multi-provider by design. Even then, test tool calling, structured output and streaming with the exact model you plan to run.

4. Must everything stay on your own hardware?

All six are libraries that run inside your own process. Self-hosting is therefore really a question about the model and about where traces go. If data must not leave the building, you need a locally hosted model and a framework that can talk to it.

LangGraph, CrewAI, Microsoft Agent Framework and ADK explicitly document local models; the OpenAI Agents SDK reaches them through OpenAI-compatible endpoints. The Claude Agent SDK runs in your process but calls Claude models at Anthropic or one of the listed cloud platforms, so it is not designed for fully air-gapped operation. For what a self-hosted setup looks like end to end, see sovereign AI on your own infrastructure.

Check the observability layer as well. Some frameworks point to hosted tracing services by default. For sensitive data, traces should go to a system you operate, or be switchable off.

5. What does the lifecycle look like?

Agent frameworks change fast, and APIs shift between releases. For a system you expect to run for three years, it matters who backs the project, how migrations are documented, and how cleanly your own code is separated from framework classes.

Microsoft's consolidation of Semantic Kernel and AutoGen into Agent Framework is a useful reminder: it came with migration guides for both, which is well handled, but it shows that even large vendors restructure their frameworks. Look for published changelogs, a permissive licence (MIT and Apache 2.0 let you keep running and patching the code if a vendor moves on) and tools attached through MCP or thin interfaces of your own rather than deep inheritance from framework classes.

What needs to be in place before you choose?

Three things should be settled first: one concrete process with a measurable outcome, access to the data the agent needs, and a named person who will own the agent's behaviour in the business. Without them, framework selection turns into a technology debate with nothing to decide against.

• A process. Describe one workflow precisely enough that a new hire could follow it: input document, steps, systems, approvals, output. That description tells you how much control you need.
• Data and systems. Which systems must the agent read or write, and do they have APIs? An ERP without an API is a bigger obstacle than any framework question.
• Privacy and works councils. Agree early with your data protection officer, and in countries such as Germany or the Netherlands with the works council, what the agent may see and where the model must run. That answer settles criterion 4. This is technical orientation, not legal advice.
• People. Who will write and maintain the code? A framework in a language only one person knows is an operational risk.

How do you run the selection, step by step?

Use five steps: weight the criteria, narrow to two candidates, build the same small prototype with both, measure against fixed test cases, then decide and write it down. A double prototype takes a few days but stops you deciding on the strength of landing pages.

1. Weight the criteria. Decide which of the five are hard constraints for you. Language and self-hosting often are.
2. Narrow to two. Comparing more than two at once dilutes the result.
3. Build the same prototype. Pick a real but small slice of a process, for instance reading a customer enquiry, calling two tools and drafting a reply. Build the tools once, ideally as MCP servers, and reuse them in both candidates.
4. Measure against test cases. Use twenty to thirty real, anonymised examples with expected outputs. Watch error handling, how readable the traces are, and how much glue code you had to write.
5. Decide and record. Write down why you chose, and which versions you tested. That note saves a lot of time at the next review.

In our own operations, keeping the tool layer strictly separate from the framework has proved its worth: the framework choice stays reversible instead of becoming a multi-year commitment. If you want to frame this decision together with process selection, ownership and governance, the fractional Head of AI page describes how that organisational side can be set up.

What are the limits and risks?

The biggest risk is not picking the wrong framework but running an agent without clear boundaries: too many tools, overly broad permissions and no tests. On top of that come fast-moving framework releases and quiet dependencies on hosted add-on services that nobody notices during the first prototype.

• Abstraction hides behaviour. The more a framework decides for you, the harder it is to see which prompt actually reached the model. Confirm during the prototype that traces show the full model call.
• Release churn. Pin versions and schedule upgrades deliberately rather than pulling the latest release automatically.
• Compatibility layers. Adapters for third-party models do not always cover every feature; the OpenAI Agents SDK documentation says as much. Test the exact framework-and-model pair you will run.
• Too much autonomy. An open agent loop with write access to production systems is a security risk. Use the permission and approval features the frameworks provide, and start with read-only access.
• Multi-agent for its own sake. Cooperating agents are appealing but add cost, latency and debugging effort. One agent with well-cut tools is enough for many processes.
• When none of them fit. If your process is fully rule-based and the model only summarises text, you do not need an agent framework. A single model call from your existing code will do.

How do you get started?

Start with a process, not a framework. Choose one workflow with clear inputs and outputs, answer the five criteria for it, and build the same small prototype with the two candidates that remain. The decision is usually obvious afterwards.

As a starting heuristic rather than a verdict:

• .NET team, Microsoft stack, Azure: look at Microsoft Agent Framework first.
• Fixed process with approvals and resumption, Python or TypeScript: look at LangGraph.
• Python team that wants to experiment quickly with agent crews: look at CrewAI.
• Open-ended work on files, documents and code, with Claude as the chosen model: look at the Claude Agent SDK.
• OpenAI models as the default and a preference for minimal abstraction: look at the OpenAI Agents SDK.
• Java or Kotlin team, or Google Cloud and Gemini already in use: look at Google ADK.

If data must stay in-house, first remove every candidate that cannot reach your local model, then apply the heuristic. For a concrete example of where an agent pays off in a single department, the page on AI agents for quotation is a practical place to begin.