Building an AI agent from scratch — then seeing LangChain do the same thing

Section 00

The class moves through a series of numbered files, each adding one idea to the previous one:

Section 01

The session opens with a five-minute recap of the ladder of capability, because the whole point of an agent only lands once you see what a bare model lacks.

The instructor is careful about one thing here: a raw model, by itself, is not very useful. Asked directly — “without memory, without tools, is a model helpful?” — the intended answer by the end of class is no. The value comes from the harness you wrap around it.

Section 02

Before code, the class settles a practical question that tripped people up the previous day: where does the “brain” actually come from, and how do you pay for it?

Section 03

Two recap ideas feed directly into the agent loop: getting structured output out of the model, and understanding that a “tool” is nothing exotic.

Section 04

This is the pivot the whole loop depends on. When you send a message and a list of tool schemas, the model’s reply is one of exactly two shapes.

• A plain reply. Ask “hi, how are you?” → tool_calls is None, and content holds the text answer. Nothing else to do.
• A tool request. Ask “what’s the weather in Tokyo?” → content is None, and tool_calls contains a structured request: the function name and the arguments.

Section 05

This is file 06, the “mini Claude.” The setup is deliberately boring so nothing distracts from the loop: a mock weather tool over a small dictionary. All code below is the exact source from the supplied notebook.

The tool and the two lookup tables

# A "tool" is just a normal Python function.
SAMPLE_WEATHER = {
    "tokyo": {"celsius": 22, "conditions": "partly cloudy"},
    "delhi": {"celsius": 34, "conditions": "clear skies"},
    "london": {"celsius": 15, "conditions": "light rain"},
}

def get_weather(city: str) -> str:
    data = SAMPLE_WEATHER.get(city.lower())
    if data is None:
        return f"No weather data for {city!r}."
    return f"{city.title()}: {data['celsius']}C, {data['conditions']}"

# What the MODEL sees — so it knows the tool exists,
# what args it needs, and how to format the call.
TOOL_SCHEMAS = [
    {
        "type": "function",
        "function": {
            "name": "get_weather",
            "description": "Get the current weather for a city.",
            "parameters": {
                "type": "object",
                "properties": {"city": {"type": "string"}},
                "required": ["city"],
            },
        },
    }
]

# What YOUR CODE uses — maps the string name to the real function object.
TOOLS_BY_NAME = {
    "get_weather": get_weather,
    "get_currency": get_currency,
}

Two tables, two audiences. TOOL_SCHEMAS is for the model (a description). TOOLS_BY_NAME is for you (the actual callable). Section 06 explains why you need both.

The loop itself

Strip away the verbose printing and the whole agent is remarkably small. Read it once top-to-bottom, then we walk each decision.

def run_agent(messages: list[dict], max_turns: int = 4) -> str:
    client, model = get_client_and_model()

    for turn_number in range(1, max_turns + 1):

        response = client.chat.completions.create(
            model=model,
            max_tokens=300,
            messages=messages,
            tools=TOOL_SCHEMAS,
        )
        message = response.choices[0].message

        # 1) No tool requested → this is the final answer.
        if not message.tool_calls:
            messages.append({"role": "assistant", "content": message.content})
            return message.content

        # 2) Tool(s) requested → first record the request in memory,
        #    preserving order. content here is None.
        messages.append({
            "role": "assistant",
            "content": message.content,
            "tool_calls": [
                {
                    "id": call.id,
                    "type": "function",
                    "function": {
                        "name": call.function.name,
                        "arguments": call.function.arguments,
                    },
                }
                for call in message.tool_calls
            ],
        })

        # 3) Now actually run each tool and append its result.
        for call in message.tool_calls:
            tool_name = call.function.name
            arguments = json.loads(call.function.arguments)
            tool_function = TOOLS_BY_NAME[tool_name]
            result = tool_function(**arguments)
            messages.append({
                "role": "tool",
                "tool_call_id": call.id,
                "content": str(result),
            })
        # loop back: the model can now read the tool result and answer

    return "Reached max_turns without a final answer."

Watching memory grow (the verbose walkthrough)

After the break, Mayank re-runs everything in a Colab notebook that prints every state, so you can literally watch the message list grow. This is the moment most of the class said things clicked.

Section 06

The model gives you back a tool name as a string, like "get_weather". A string is not callable. This tiny mapping is how you recover the real function — and it’s the piece the instructor spends a live tangent making concrete.

# AI says: call "get_weather". But a string can't be called.
tool_name = call.function.name        # "get_weather"  (a string)
tool_function = TOOLS_BY_NAME[tool_name]   # the real function object
arguments = json.loads(call.function.arguments)   # '{"city":"Tokyo"}' → dict
result = tool_function(**arguments)   # actually call it

Section 07

Two subtle details generated the most Q&A in the session, and both are about bookkeeping the message history correctly.

Section 08

max_turns (4 in file 06, 5 in the project) is the guard rail on the outer loop. It carries no clever logic — it exists so the agent can’t run forever.

Section 09

File 07 keeps the identical loop but proves it scales: three tools instead of one, and a small web front-end. Mayank calls it “project zero — a mini ChatGPT / mini Claude.”

All three get a schema, all three go into TOOLS_BY_NAME, and max_turns is raised to 5. The run function is unchanged. He then wraps it in Streamlit (streamlit run) so you get a chat box in the browser — the same loop, now behind a UI.

Section 10

Having just built the loop by hand, the natural question is: so why use LangChain? The answer is framed as a maintenance problem, not a magic one.

Section 11

The class installs LangChain with uv and writes the smallest possible agent. The shock is how little code it takes — and how the printed message trail is exactly what they built by hand.

from langchain.agents import create_agent

agent = create_agent(
    model="...",          # the brain; key read from the environment
    tools=[get_weather],   # pass functions directly
    system_prompt="...",
)

result = agent.invoke({"messages": [{"role": "user",
                                     "content": "weather in San Francisco?"}]})

Everything from §05 — the loop, the memory, feeding tool results back — happens inside invoke.

The same message trail, revealed

He prints the raw messages LangChain produced, and walks them one by one:

Environment & project setup (uv)

The scaffolding matters for the project work that follows:

• uv init to start the project, then uv add langchain langchain-openai langchain-anthropic (adding 3 packages pulls ~45 dependencies). uv sync / uv lock manage the rest; the virtual env doesn’t even need manual activation for uv, though you still source .venv/bin/activate on Mac to run scripts.
• Create a .env with placeholder keys for every provider you might use (OpenAI, Groq, Anthropic, Gemini, OpenRouter).
• Add a .gitignore that excludes .env and .venv — so secrets and the huge env never get pushed.
• Ship a .env.example (a copy with blank values) so others know which keys to fill in, without leaking yours.

Section 12

LangChain ships several products. The instructor’s food analogy makes the trade-off between control and convenience memorable.

Section 13

Nearly two hours of questions followed the teaching. These are the exchanges that carried real learning value, kept close to the concepts they clarify.

Section 14

Only the ones the session actually surfaced — no generic warnings.

Section 15

These exercises are derived from what was taught — they aren’t transcript content. Work them against file 06/07.

Section 16

Answer out loud before opening each one. These test understanding, not trivia.

Section 17

Code patterns worth keeping

# branch on the reply shape
if not message.tool_calls:
    return message.content        # final answer

# string name → real function, then call
fn   = TOOLS_BY_NAME[call.function.name]
args = json.loads(call.function.arguments)
result = fn(**args)

# echo the id back so the model can match request↔result
messages.append({"role": "tool",
                 "tool_call_id": call.id,
                 "content": str(result)})

# bound the loop
for turn in range(max_turns): ...

Section 18

Tools & libraries referenced

• Groq & OpenRouter — OpenAI-compatible providers with free tiers; used throughout so learning stays cheap. (Groq ≠ Elon Musk’s Grok/xAI.)
• Llama 3.3 70B — the open model used as the “brain” in the notebook.
• Frankfurter API — the real currency endpoint behind the project’s convert_currency tool.
• Streamlit — the quick web UI for the mini-project (streamlit run).
• uv — project/dependency manager (uv init, uv add, uv sync, uv lock).
• LangChain V1 — create_agent, @tool, init_chat_model, InMemorySaver; plus LangGraph, DeepAgents, LangSmith (monitoring).
• Pydantic — used earlier for structured output; tiktoken — mentioned for counting tokens.