Production AI agents should be built from small primitives because frameworks change too slowly for evolving models and standards.
2
Threads, memory, parsing, chunking, tools, and workflows can provide the building blocks for serverless agents that scale without a large abstraction layer.
3
Plain JavaScript or TypeScript can express routers, parallel workers, evaluators, deep research agents, and multimodal applications with relatively little code.
Summary
Ahmad Awais argues that production AI agents should be assembled from AI primitives rather than built on general-purpose frameworks. He compares primitives to Amazon S3: small, low-level services that handle one job and can support many applications. His examples include threads for conversation context, memory with vector search for long-term data, parsers, chunkers, tools, and workflow primitives. He demonstrates a PDF question-answering agent, then walks through augmented LLMs, prompt chains, routers, parallel agents, orchestrator-worker systems, evaluator-optimizers, memory agents, deep research, OCR, and image analysis. The implementations use plain JavaScript or TypeScript and connect different models where appropriate. His concern is that framework abstractions will become difficult to replace as models improve and new standards appear. He is honest that the approach means building some application-level structure yourself, but says the smaller pieces are easier to understand, debug, deploy, and change.
Production agents are moving away from large AI frameworks
Awais points to Perplexity, Cursor, v0, Lovable, Bolt, and CHAI as production agents that are not built on AI frameworks. He says frameworks add limited value because they are bloated, move slowly, and contain abstractions engineers may not need. He recommends AI primitives instead. His argument comes from working with frameworks and deploying agents over several years, rather than from a purely theoretical preference. He compares the approach to Amazon S3, which provides simple object upload and download primitives that can support many systems without becoming a framework for object storage.
Awais describes agents as a new way of writing code. Existing practices for coding projects and SaaS applications are changing because software can now use LLMs and agent workflows. He says a framework abstraction may not be broad enough for this changing style of development. Instead, engineers can build small pieces that work across a stack. Threads are his first example. Every agent needs somewhere to store conversation history or context, so threads can be a reusable primitive rather than a feature trapped inside one framework.
Cloud-backed primitives can remove much of the scaling work
Awais says Langbase is trying to make it fast to build production-ready agents for developers coming from frontend, full-stack, DevOps, and ML backgrounds. He proposes composable primitives that include cloud infrastructure. Memory, for example, combines storage with a vector store and can accept very large amounts of data while scaling automatically. Parsing and chunking turn source files into searchable context. Threads hold conversation state. An agent assembled from these pieces can run as a serverless application without the developer separately building every deployment and scaling component.
A PDF agent can be assembled from memory, parsing, chunking, and generation
CHAI creates a PDF question-answering agent by first making a memory for the documents. A parser converts PDFs to text, and a chunker splits the text into small pieces for similarity search. The agent retrieves relevant pieces from memory and passes them to a generation step that answers the user's question. Awais uploads documents about himself, his talks, and Langbase, then asks who the founder is, what his last three talks were, and how to get an API key. The same data can be accessed through an agent app or an API, and he shows that the generated application can be edited when a bug appears.
A small set of primitives covers several common agent architectures
The first architecture is an augmented LLM with tools, threads, and memory. Tools let the agent call APIs or connect to MCPs. Threads store conversation or short-lived working context, such as the details held while booking a flight. Memory stores longer-term events and can contain large searchable datasets. Awais then shows prompt chaining, where one agent's output determines whether another runs, and agent routers, where an LLM selects a specialized agent. His router example sends work to separate summary, reasoning, or coding agents, each using a different model. The code is plain JavaScript or TypeScript.
Orchestrator-worker agents can express deep research workflows directly
In the orchestrator-worker pattern, one agent plans a problem and creates subtasks. Worker agents complete those subtasks, and another step synthesizes their results. For a blog post about remote work, the orchestrator creates assignments for the introduction, productivity, work-life balance, environmental impact, and conclusion. The workers run in parallel with Promise.all, then their outputs are combined. Awais says the example is about 90 lines of code and does not require a framework. He expects LLMs to improve at agentic workflows, which could make a fixed framework abstraction harder to migrate away from.
Evaluation loops let one model revise another model's output
The evaluator-optimizer architecture has a generator produce an answer and an evaluator judge it. The evaluator either accepts the result or returns feedback for another iteration. Awais demonstrates this with product copy for an eco-friendly water bottle aimed at conscious millennials. The first version misses the audience, so the evaluator gives specific feedback. The next version improves in response. He says the evaluator should use a model suited to the domain, with a health-related application requiring the right supporting information and checks.
The same primitives can support multimodal and research agents
Awais uses the patterns to build a deep research agent that analyzes a query, searches the web with Exa, consolidates results, and writes a response. He also builds a receipt checker by adding Mistral OCR when the available primitives do not include OCR. The application combines OCR with GPT-4.1 to extract information from an image. A separate image-chat agent uses a vision-capable GPT-4o model to answer a question about facial expression from an image URL. These examples support his claim that developers can add an external primitive when the existing set does not cover a need.
"You're basically building very simple agents, worker agents in an orchestrator agent, and you're Promise.all running all of them."19:12
Who should watch
You are choosing an AI framework and want to understand the tradeoff between its abstractions and direct model or API calls.
You are building agents that need memory, tool calls, document search, or multi-step workflows and want concrete architecture patterns.
You expect models and agent standards to keep changing and need an implementation that is easier to replace piece by piece.
