LangChain or No Framework for Building AI Agents: How to Decide

LangChain or No Framework for Building AI Agents: How to Decide

For a company's first AI agent, a simple loop built on the model provider's SDK is usually enough. LangChain starts to pay off when the workflow grows and the structure it brings saves more work than it creates. The useful question is not which option is better, but who will maintain and debug the agent a few months from now.

Key takeaways

• At its core, an agent is a loop: the model receives context, decides whether to call a tool, the tool runs, and the result goes back to the model. That fits in a few dozen lines with the provider's SDK.
• A framework helps when you have many integrations, stateful workflows with branches, or several people who need a shared vocabulary. It does not, on its own, make the agent behave correctly.
• The hidden cost of a framework shows up in debugging: more layers between you and the actual prompt sent to the model.
• The decision is not permanent. If the simple loop keeps tools, prompt and logging well separated, migrating later is feasible. The reverse is also true.
• Limits, human approval, logs and evaluation matter more to the outcome than the choice of library.

What an agent really is once you remove the framework

Anthropic's documentation on agents describes the difference between workflows, where code defines the path, and agents, where the model decides the next step using tools. In both cases the core is small. You build a list of messages, send it to the model along with a description of the available tools, read the response and, if the model asks for a tool, run it and return the result. You repeat until the model answers without requesting anything, or until a step limit is reached.

People who see this loop clearly make better decisions. Everything else is decoration, useful or not: conversation memory, document search, retries after failure, logging, human approval. Each item can be written by hand or come ready-made from a library. In practice, choosing between LangChain and no framework means choosing which of these items you want delivered ready-made, and at what price in abstraction.

When a framework genuinely helps

There are situations where writing everything by hand turns into rework. The most common:

• Many integrations: the agent needs to talk to several model providers, vector databases and document sources, and you do not want to maintain each connector.
• Stateful workflows with branches: steps that depend on earlier results, pauses for approval, resuming after an interruption. The LangChain ecosystem includes LangGraph precisely to model this kind of state graph.
• Frequent model swaps: if the company wants to compare providers without rewriting the calling layer, a common interface reduces friction.
• A larger or rotating team: a shared vocabulary (chains, tools, retrievers) helps newcomers understand where to make changes.
• Ready-made observability: tracing tools tied to the framework show every step without you instrumenting everything.

In these cases the framework is a legitimate accelerator. The caveat is that it accelerates what is already clear. If the business process has not been mapped yet, the framework just speeds up building something poorly defined.

When the provider SDK and a simple loop are enough

Anthropic's guide to building effective agents recommends starting by using model APIs directly, because many patterns take only a few lines of code, and warns that frameworks can add extra layers that hide prompts and responses, making debugging harder. This is an observation from official documentation, not an absolute rule, but it describes the risk well.

The simple loop tends to be enough when:

• The agent has a narrow goal, such as answering questions about a catalog or preparing a draft quote.
• There are few tools, a handful at most, each with a well-defined input and output.
• A single model provider does the job, at least during the pilot.
• The maintainer is one person or a small team that needs to read all the code in an afternoon.
• The flow is mostly deterministic, with the model brought in only where judgment is needed.

The main gain is transparency. You know exactly what was sent to the model, what it returned and why the tool was called. When the agent says something odd to a customer on WhatsApp, that is the information you need within minutes, not after digging through layers of abstraction.

Maintenance and debugging: where the cost appears

The choice looks technical, but the impact is operational. Three costs deserve attention before you decide.

First, updates. Agent libraries evolve quickly and change their interfaces. That is healthy for the ecosystem, but it means someone at the company has to follow versions, read release notes and test. With the provider's SDK you also track changes, just on a smaller surface.

Second, debugging. When something goes wrong, the question is always the same: what exact text was sent, with which tools, and what was the raw response? If the framework builds the prompt for you, you need to know how to extract that text. With or without a framework, log every model call and every tool call. The OpenTelemetry semantic conventions for generative AI are a good reference for which fields are worth keeping, and they apply to both paths.

Third, handover. Whoever inherits the system has to understand it. A short, well-commented loop is easy to pass on. A large graph with many abstractions can be just as clear, but only if there is internal documentation and someone who knows the framework. Ask who, on your team or your client's team, will master it a year from now.

None of these costs is decisive alone. Together, they suggest that complexity should be adopted when bought on purpose, not by default.

A decision guide in two lists

Use the questions below before choosing. The more yes answers in one block, the more you lean toward it.

Leans toward the simple loop with the SDK:

• Can I describe the agent's flow in one paragraph?
• Do I have few tools, all with a clear contract?
• Will I use a single model provider in the pilot?
• Do I need to read and audit every prompt sent?
• Is the team that will maintain it small?

Leans toward a framework:

• Does the flow have many stateful steps, pauses and resumptions?
• Will I integrate with many data sources and providers?
• Do I need to swap models often to compare them?
• Is there already someone on the team who knows the framework well?
• Does the ecosystem's ready-made tracing save real work?

If the two blocks tie, start with the simple loop, with tools and prompt isolated in their own modules. That way, adopting a framework later means replacing the orchestration layer, not rewriting everything.

Illustrative scenario: an after-sales agent

Imagine a services company that wants an agent to answer customer questions about orders and open tickets for the team. This is an illustrative scenario, unrelated to any real client.

The agent needs three tools: check an order's status (read-only), look up an answer in the FAQ base, and open a ticket for a person. It does not change orders or promise deadlines outside company policy. The flow is short, there is one model provider and the technical team is one or two people.

In this design, the loop with the SDK is enough. The code has a system prompt, three functions, a step limit per conversation and a log of every call. Handing off to a human is a tool like any other. If, months later, the company wants multi-step approval, resuming long conversations and integration with many systems, it makes sense to reassess a graph framework, with the earlier pilot as a baseline for comparison.

Notice that the important decisions in this scenario, such as read-only access, a step limit and handoff to a human, do not depend on the library. They depend on design. For the channel itself, see the guide on how to integrate AI into your company's WhatsApp.

How to build your first agent without a framework, step by step

If your case looks like the scenario above, this outline works as a starting point:

• Step 1: write the agent's goal in one sentence and list what it must never do.
• Step 2: define the tools with clear names, simple parameters and objective descriptions. Anthropic has a specific piece on how to write good tools for agents, and the quality of those descriptions weighs heavily on behavior.
• Step 3: write the loop: send messages and tools to the model, run the tool request, return the result, and repeat until the final answer or the step limit.
• Step 4: handle failures explicitly. Timeouts, rate limits and provider outages need defined behavior, as described in handling LLM API rate limits and outages.
• Step 5: add validation on input, on output and before any action with side effects, following guardrails for AI agents.
• Step 6: log every model call and tool call with a conversation identifier, so you can reconstruct any interaction.
• Step 7: build a small set of real test cases and run it on every prompt or model change. Anthropic's guide on evaluating agents helps with this.
• Step 8: put human approval on actions that affect money, contracts or personal data, and confirm how that data is handled under Brazil's LGPD.

Note that the entire list fits either a homegrown loop or a framework. The difference is how much of each step you write and how much you inherit.

How the method applies: map, limit, pilot, hand over

The choice of tool comes after the process. First we map the current workflow and the starting point: who handles requests, with what information, where rework happens. Then we limit data and actions, defining what the agent reads, what it can do and when it passes the case to a person. Next we pilot one real flow, with logs and a success metric agreed in advance. For that, the article on how to measure an AI automation pilot offers decision criteria.

Finally, we hand over: documentation, access and the decision to expand, adjust or stop. This last step is where simplicity pays off. A codebase the client's team can read and operate is more likely to outlive the project than one that requires a permanent specialist. When a framework is the best answer for the flow, we use it, but only after asking the maintenance question first.

Frequently asked questions

Is LangChain required to build an AI agent? No. An agent can be built with the model provider's SDK and a loop that runs tools. A framework is an option for when integrations, state and team size justify the extra layer.

Can I start without a framework and migrate later? Yes, as long as you keep the prompt, tools and logging in modules separate from orchestration. In that case the migration mainly replaces the core loop. What usually makes the change expensive is mixing business rules into the code that calls the model.

Does a framework make the agent safer or more accurate? Not by itself. Safety and accuracy come from well-described tools, restricted permissions, output validation, evaluation with real cases and human approval. OWASP maintains a list of the main risks for applications built on language models that is worth consulting regardless of the library you choose.

How do I decide whether my small team should use a framework? Check whether someone can calmly read and debug all the code, and whether the flow fits in a few tools. If so, the simple loop tends to be cheaper to maintain. If the flow requires state, pauses and many integrations, evaluate a framework with a short pilot before committing.

Sources

• Anthropic: Building effective agents
• Anthropic: Writing effective tools for agents
• Anthropic: Demystifying evals for AI agents
• OpenTelemetry: semantic conventions for generative AI