Can You Build an AI Assistant Without a Framework

What You Build Yourself

Without a framework, you are responsible for four components that frameworks handle for you. The tool routing loop detects tool calls in the model's response, executes the corresponding functions, feeds results back to the model, and repeats until the model produces a final text response. This is typically 30 to 50 lines of code and is straightforward to implement using any model provider's SDK. Context management assembles the model's input from system instructions, conversation history, retrieved memories, and tool definitions, deciding what fits within the token budget and what gets trimmed or summarized. Conversation history storage persists messages and manages session state across requests. And error handling catches tool failures, model errors, and edge cases, formatting them appropriately for the model to recover from.

Each of these components is well-defined and implementable in a few hundred lines of code. The total is more code than a framework-based setup, but every line is yours: visible, testable, debuggable, and modifiable without worrying about framework internals or upgrade compatibility.

The Typical Frameworkless Structure

A frameworkless assistant codebase tends to organize into a few clear modules. A model client module wraps the provider SDK and handles API calls, streaming, retry logic, and rate limiting. A tool registry maps tool names to handler functions and manages schema definitions. A conversation manager stores message history, handles context window overflow, and assembles the prompt for each model call. And an orchestrator ties these together in the main request-response loop, deciding when to call the model, when to execute tools, and when to return a response to the user.

This structure typically adds up to 500 to 1,500 lines of code depending on the number of tools and the complexity of your context management. For comparison, a LangChain-based assistant might be 100 to 300 lines of your code plus thousands of lines of framework code that you depend on but did not write and cannot easily modify. The frameworkless approach trades initial development speed for long-term maintainability and control. Most teams that ship frameworkless report that the additional upfront work pays for itself within the first month of production, when debugging, performance tuning, and feature changes all benefit from the simpler dependency chain.

When Frameworkless Makes Sense

The frameworkless approach works best when your assistant's behavior is specific enough that framework abstractions do not add value. If your assistant uses a fixed set of tools, has a well-defined conversation pattern, and needs custom logic for context assembly, error handling, or response formatting, the framework is providing infrastructure you do not need while constraining the parts where you need flexibility. Production teams with experienced developers often prefer frameworkless because the engineering cost of writing the boilerplate is a one-time investment, while the ongoing cost of fighting framework constraints and debugging through abstraction layers is perpetual.

Frameworkless also makes sense when you need to support multiple model providers with seamless failover. Frameworks abstract provider differences, but their abstractions sometimes lag behind provider-specific features (new tool calling modes, structured output formats, caching APIs). When you own the provider integration layer, you can adopt new features immediately and implement custom failover logic that matches your specific reliability requirements.

Frameworks are better when you are exploring, prototyping, or building an assistant that fits standard patterns. If you do not know exactly what your assistant will do yet, LangChain's pre-built agents and chains let you iterate faster than building from scratch. If your assistant follows a common pattern (RAG-based Q&A, customer support routing, tool-using agent), the framework handles the pattern's boilerplate so you can focus on your specific tools and prompts.

Common Concerns and Reality

The most common objection to frameworkless development is "I would be reinventing the wheel." In practice, the "wheel" for an AI assistant is smaller than most developers expect. The core tool-calling loop is about 40 lines. Context window management is about 100 lines. Conversation history storage depends on your database choice but is straightforward CRUD. The provider SDK does the heavy lifting of API communication, authentication, and streaming. What frameworks add on top of this is convenience (less code to write initially) and abstraction (one interface across providers), both of which have diminishing returns as your requirements become more specific.

The second concern is community and ecosystem. Frameworks like LangChain have large communities, many integrations, and extensive documentation. Going frameworkless means you write your own integrations rather than importing them. For common integrations (vector databases, embedding APIs, standard tools), this is trivial because those services have their own SDKs. For exotic integrations, the framework's pre-built connector might save real time. Evaluate your specific integration needs rather than assuming the framework ecosystem is necessary.

Memory Without a Framework

The one area where going frameworkless does not mean going alone is memory. Building a production-quality memory system (extraction, storage, retrieval, lifecycle management, confidence scoring, entity graphing) is a substantial engineering project that is better handled by a dedicated service regardless of whether you use a framework. Adaptive Recall integrates through a REST API or MCP, which means it works with any codebase, frameworkless or not. You get persistent memory without building the memory infrastructure, and you retain full control over every other aspect of your assistant. The memory tools appear in your tool registry alongside your other tools, and the model calls them the same way it calls any function.