Models, Memory, Tools and Frameworks

Five practical decisions turn a blueprint into something running: which model reasons, what coordinates it, where memory lives, what tools it can reach, and where people find it.

Five practical decisions turn a blueprint into something running: which model reasons, what coordinates it, where memory lives, what tools it can reach, and where people find it. This chapter walks each in turn.

A note on how to read it. Every product named here will still exist in some form for years, and every one of them will have changed by the time you use it. So treat what follows as a map of the kinds of component you need, with current examples attached, rather than a shopping list.

The model

The model is the reasoning engine. You reach it over a network: you send text, you get text back. The better it is at following instructions and using tools, the better your agent behaves.

Table 8-1: Where models come from

Provider	Character
Anthropic — Claude	Careful instruction following, long context, strong tool use and coding
OpenAI — GPT family	Broad capability, very wide ecosystem support
Google — Gemini	Multimodal reasoning, very long context
Open-weight models	Run on your own infrastructure; licence varies by model

For a first agent, start with a capable general-purpose model from one of the major providers. They are reliable, well documented and widely supported by tooling. Look at open-weight models when you need more control, lower cost, or data that must not leave your own systems.

Worth Remembering Open weight means the trained parameters are published so you can run the model yourself. It does not automatically mean an open-source licence. Some licences restrict commercial use or redistribution. Read the licence before you build on it.

What coordinates it

With a model in place, you need something to manage the logic: which instruction goes out when, which tool gets called, what is remembered, what happens on failure. Frameworks do this so you do not write it from scratch.

Table 8-2: Frameworks and what each is for

Framework	Suits
LangChain and LangGraph	General agents, and loops you want explicit control over
LlamaIndex	Assistants built on your own documents
CrewAI	Several agents with assigned roles
AutoGen	Lightweight multi-agent experiments
Semantic Kernel	Production systems inside larger software estates
A provider's own toolkit	Building close to one model, with its tool use and subagent features ready made

LangChain if you want a full coordinating layer, paired with LlamaIndex when documents are central. Reach for CrewAI or AutoGen only when you genuinely have several agents — Part V will help you judge whether you do. A provider's own toolkit is often the shortest route once you have settled on a model.

Memory

Without memory an agent starts from nothing every time. Two kinds, as Chapter 6 set out: short-term for the session, long-term across sessions. Short-term memory mostly lives in the context window and a cache. Long-term memory needs somewhere real.

Table 8-3: Where long-term memory lives

Store	Suits
Chroma	Small projects, running locally
Pinecone or Weaviate	Larger systems needing scale, or structured metadata
Redis	Session state and caching
PostgreSQL with a vector extension	When you already run it and want one store rather than two

Start small. If you already operate a relational database, its vector extension is usually the pragmatic choice, because one fewer system to run is worth a great deal.

Human Checkpoint Anything in long-term memory is information you now hold about a person. Decide up front what is stored, for how long, who can read it, and how somebody reviews or deletes it. Deciding this at the start costs an hour. Deciding it after launch costs a migration and possibly a disclosure. Chapter 15 returns to it.

Tools

A genuinely useful agent does not only talk. Tools let it look things up, schedule, send, update and calculate. In practice you will be connecting to a handful of these:

A calendar, to create, move or cancel meetings.
Search, to retrieve current information.
Mail or chat, to send notifications and summaries.
Your own internal systems — the ticketing system, the customer record, the HR platform.
Code execution in a contained environment, so the agent can actually compute an answer rather than estimate it.

Pick the two or three the agent genuinely needs, and stop. And write the descriptions carefully, because this matters more than newcomers expect: the model decides whether to call a tool by reading its description. A vague description produces an agent that calls the wrong thing at the wrong moment. Write them as though for a new colleague who cannot ask you a follow-up question. Chapter 11 has evidence for how much difference this makes.

Your own knowledge

No model knows your internal documents. If the agent must answer from product manuals, policies or contracts, it needs retrieval — Chapter 4 applied to your own material:

The agent finds the relevant passages in your stored documents.
Those passages are added to what the model receives.
The model answers from them, plus its own capability.

LlamaIndex handles the ingesting, splitting and retrieving; LangChain's retrieval components do the same job inside a larger flow; the embeddings themselves sit in whichever store you chose above.

Where people reach it

Table 8-4: Places to put an agent

Where	Suits
A web page or portal	Customer-facing and internal tools
Slack or Teams	Internal work, where people already are
An interface other software calls	Integration into a larger system
A terminal	Engineering and coding agents
Voice	Accessibility and hands-free use

Start where your users already are, which is usually a chat platform or a page they already visit. Tools such as Streamlit and Gradio will get a prototype in front of people in an afternoon, which is worth more than a month of design.

And keep one distinction clear, because it causes arguments. Deploying means making the system available. Running in production means monitoring it, bounding its permissions, keeping logs you can audit, and having a plan for the day it behaves unexpectedly. The first is an afternoon. The second is the job.

Key takeaways

Five decisions: the model, what coordinates it, where memory lives, which tools, and where users find it.
Start with a capable general-purpose model from a major provider.
Use a framework rather than writing the coordination yourself.
Long-term memory is user data. Decide retention before you store anything.
Two or three tools, with descriptions written as carefully as the instructions.
Add retrieval when the agent must answer from your own documents.
Deploying is not the same as running in production.

That is everything needed to build one working agent. Which raises a fair question: if the pieces are this well understood, what do the systems that millions of people already use actually look like inside?