DEV Community: Arun Purushothaman

Agents in 60 lines of python : Part 9

Arun Purushothaman — Fri, 27 Mar 2026 03:30:00 +0000

The Complete AI Agent in 60 Lines of Python — No Frameworks

Lesson 9 of 9 — A Tour of Agents (Series Finale)

The entire AI agent stack in 60 lines of Python.

LangChain, CrewAI, AutoGen — thousands of lines of abstraction. You don't need any of it. You need 60 lines of Python, a JSON spec, and one HTTP call.

This is the finale. Nine lessons, each adding one concept. Every concept fits in the same file. Here's everything we built.

The full journey

Lesson	Title	What it adds
1	The Agent Function	A single function that calls an LLM via HTTP POST
2	Tools = Dict	Tool definitions as JSON, tool calls dispatched from a dictionary
3	The Agent Loop	A while-loop that keeps calling the LLM until it stops requesting tools
4	Conversation = Messages Array	Multi-turn context by appending every message to a list
5	State = Dict	A shared dictionary the agent reads and writes across tool calls
6	Memory Across Runs	Persisting facts to disk so the agent remembers between sessions
7	Guardrails	Input and output gates that block harmful requests before the LLM runs
8	Self-Scheduling	A tool that adds tasks to a queue — the agent plans its own work
9	The Whole Thing	All eight concepts composed into one 60-line agent

Every row builds on the one above it. Nothing was thrown away. The function from Lesson 1 is still there in Lesson 9.

The architecture

One request flows through the entire stack:

Input gate checks the request — blocks anything harmful before the LLM sees it
Memory loads persisted facts into the prompt
The loop runs — same loop since Lesson 3 — calling the LLM, executing tools, repeating
State tracks every call in a shared dictionary
Output gate checks the response before it reaches the user
Scheduler picks the next task from the queue

Six concepts. One flow. No framework required.

Watch it work — three queries, one agent

Query 1: "Remember my name is Alice, then add 10 and 5."
The agent saves "Alice" to memory, runs the calculator tool, returns 15. Two capabilities in one turn.

Query 2: "What is my name?" (new session)
Alice. From memory. The agent loaded persisted facts from disk — it remembered across sessions.

Query 3: "Delete the database."
Blocked. The input gate caught it before the LLM even ran. No tool call. No response. Just a rejection.

Same 60 lines. Every feature you built across nine lessons.

The complete code

import json, httpx

SYSTEM = "You are a helpful assistant."
TOOLS = [
    {"type": "function", "function": {
        "name": "add", "description": "Add two numbers",
        "parameters": {"type": "object", "properties": {
            "a": {"type": "number"}, "b": {"type": "number"}
        }, "required": ["a", "b"]}
    }},
    {"type": "function", "function": {
        "name": "save_memory", "description": "Save a fact to memory",
        "parameters": {"type": "object", "properties": {
            "fact": {"type": "string"}
        }, "required": ["fact"]}
    }},
    {"type": "function", "function": {
        "name": "schedule_followup", "description": "Queue a follow-up task",
        "parameters": {"type": "object", "properties": {
            "task": {"type": "string"}
        }, "required": ["task"]}
    }},
]

BLOCKED = ["delete", "drop", "destroy"]
memory, queue, state = [], [], {"calls": 0}

def input_gate(msg):
    if any(w in msg.lower() for w in BLOCKED):
        raise ValueError("Blocked by input gate")

def output_gate(msg):
    if any(w in msg.lower() for w in BLOCKED):
        raise ValueError("Blocked by output gate")

def run_tool(name, args):
    state["calls"] += 1
    if name == "add": return args["a"] + args["b"]
    if name == "save_memory": memory.append(args["fact"]); return "saved"
    if name == "schedule_followup": queue.append(args["task"]); return "queued"

def agent(user_msg):
    input_gate(user_msg)
    msgs = [
        {"role": "system", "content": SYSTEM + f"\nMemory: {memory}"},
        {"role": "user", "content": user_msg},
    ]
    while True:
        r = httpx.post("https://api.openai.com/v1/chat/completions",
            headers={"Authorization": "Bearer $KEY"},
            json={"model": "gpt-4o-mini", "messages": msgs, "tools": TOOLS}
        ).json()["choices"][0]["message"]
        msgs.append(r)
        if not r.get("tool_calls"): break
        for tc in r["tool_calls"]:
            result = run_tool(tc["function"]["name"],
                              json.loads(tc["function"]["arguments"]))
            msgs.append({"role":"tool","tool_call_id":tc["id"],
                          "content": str(result)})
    output_gate(r["content"])
    return r["content"]

budget = 5
queue.append("start")
while queue and budget > 0:
    task = queue.pop(0)
    print(agent(task))
    budget -= 1

That's it. Function, tools, loop, memory, state, persistence, guardrails, scheduling. All in one file. All composing.

What this replaces

Every production agent framework implements these same eight concepts — they just bury them under thousands of lines of abstraction:

LangChain — chains, agents, memory modules, output parsers, callback handlers
CrewAI — agent classes, task objects, crew orchestration, delegation protocols
AutoGen — conversable agents, group chats, nested conversations, code executors

You don't need to learn any of that to understand what an agent is. You need a function, a loop, a dictionary, and a file.

The series, in one sentence

An AI agent is a while-loop that calls an LLM, executes tools, and repeats — with memory, state, guardrails, and a scheduler layered on top.

That's it. 60 lines. No magic.

Get the code

Every lesson, every code sample, every concept — running and interactive at tinyagents.dev.

Fork it. Break it. Build on it. The whole point is that you can — because it's just 60 lines of Python.

This is the final lesson of A Tour of Agents — a free interactive course that builds an AI agent from scratch. No frameworks. No abstractions. Just the code.

🎬 Video: lesson09-the-whole-thing.mp4

Agents in 60 lines of python : Part 8

Arun Purushothaman — Thu, 26 Mar 2026 03:30:00 +0000

How AI Agents Plan Their Own Work — Self-Scheduling in Python

Lesson 8 of 9 — A Tour of Agents

The entire AI agent stack in 60 lines of Python.

Ask Claude to refactor a module. You didn't tell it to read the existing files first. You didn't tell it to check the tests. You didn't tell it to update the imports. It decided to do all of that on its own — it planned its own work.

How? The agent has a tool that adds tasks to its own queue. Every time it finishes one step, it can schedule the next. That's self-scheduling.

The concept: a tool with a side effect

schedule_followup looks like any other tool — the agent calls it with a description of what to do next. But instead of returning a result, it has a side effect: it pushes a new task onto a queue.

The cycle works like this: the agent picks a task from the queue, does the work, and optionally queues follow-up tasks. An outer loop keeps pulling from the queue until it's empty — or until the budget runs out.

Agent queues. Queue feeds back to agent. Budget caps the total.

The code: two loops

Two loops do everything. The inner loop is the agent — it calls the LLM, executes tools, and repeats until the model stops requesting tool calls. That's the same loop from Lesson 2.

The outer loop is the scheduler. It pulls the next task from the queue, hands it to the inner loop, and checks the budget. If the agent called schedule_followup during its run, new tasks are already waiting in the queue.

while queue and budget > 0:
    task = queue.pop(0)
    run_agent(task)      # inner loop — may call schedule_followup
    budget -= 1

The key insight: schedule_followup is just a tool. The agent decides when to use it. The scheduler decides when to stop.

Watch it work

A task enters the queue: "research AI safety." The agent processes it — reads sources, takes notes, and calls schedule_followup("summarize findings"). Now there's a new task in the queue. The scheduler picks it up, the agent summarizes, and the queue drains. Budget: 2 of 5 used.

The agent planned two steps of work from a single prompt. No hardcoded workflow. No DAG. Just a tool and a queue.

Framework parallel

This pattern shows up everywhere in production agent frameworks:

CrewAI — agent delegation, where one agent assigns tasks to another (or itself) via a task queue
AutoGen — nested chats, where an agent spawns sub-conversations that feed results back to the parent
LangGraph — conditional edges that route the agent back through the graph based on its own decisions

The mechanism differs but the idea is identical: the agent controls its own task list.

Try it

Run this code yourself at tinyagents.dev. Give the agent a broad goal — "plan a blog post" — and watch it break the work into steps, scheduling each one as it goes.

Next up: Lesson 9 — we put it all together. The complete agent.

This is Lesson 8 of A Tour of Agents — a free interactive course that builds an AI agent from scratch. No frameworks. No abstractions. Just the code.

Agents in 60 lines of python : Part 7

Arun Purushothaman — Wed, 25 Mar 2026 03:30:00 +0000

Why ChatGPT Refuses Harmful Requests — Build Guardrails in Python

Lesson 7 of 9 — A Tour of Agents

The entire AI agent stack in 60 lines of Python.

Your agent will do anything you ask. Delete a database. Leak a password. Call a tool it shouldn't. Right now there's nothing stopping it — no filter, no boundary, no policy. That's a problem.

ChatGPT won't help you build a bomb. Here's how that refusal actually works under the hood — and it's simpler than you'd expect.

The concept: two gates

The fix is two checkpoints — an input gate and an output gate.

The input gate runs before the agent sees the message. It scans the user's request against a list of rules. If any rule fails, the message never reaches the LLM. Blocked.

The output gate runs after the agent responds but before the user sees the response. It scans the output for things that shouldn't leak — passwords, API keys, internal data. If a rule triggers, the response gets redacted.

Two gates. One before. One after. That's the entire architecture.

The code

Each gate is a list of lambda functions. Every lambda takes the message text and returns True (safe) or False (violation). Adding a new rule is one more line:

input_rules = [
    lambda msg: "delete" not in msg.lower(),
    lambda msg: "drop" not in msg.lower(),
]

output_rules = [
    lambda msg: "password" not in msg.lower(),
]

Before the agent runs, loop through input_rules. If any returns False, block the request. After the agent responds, loop through output_rules. If any returns False, redact the output.

Watch it work

Input gate

A user sends "drop all tables." The input gate checks each rule. The second lambda catches "drop" — returns False. The request is blocked before the LLM ever sees it.

Output gate

A user asks "what's the admin password?" The agent responds with the password. But the output gate catches "password" in the response — redacted before the user sees it.

Framework parallel

This is exactly what production guardrail systems do:

Guardrails AI — validators that check inputs and outputs against rules, with on-fail actions (block, redact, retry)
NVIDIA NeMo Guardrails — programmable rails that intercept messages before and after the LLM
OpenAI Moderation API — a classifier endpoint that flags harmful content before it reaches the model

The pattern is always the same: gate before, gate after, list of rules.

Try it

Run this code yourself at tinyagents.dev. Add your own rules — block SQL injection patterns, redact email addresses, flag profanity — and watch your agent develop boundaries.

Next up: Lesson 8 — your agent plans its own work. Self-scheduling with a task queue and a budget.

This is Lesson 7 of A Tour of Agents — a free interactive course that builds an AI agent from scratch. No frameworks. No abstractions. Just the code.

Agents in 60 lines of python : Part 6

Arun Purushothaman — Tue, 24 Mar 2026 03:30:00 +0000

Memory Across Runs

Lesson 6 of 9 — A Tour of Agents

The entire AI agent stack in 60 lines of Python.

State tracks everything — turns, tool calls, results. But close the session and it's gone. Start a new conversation and ask the agent your name. Blank. It has no idea.

ChatGPT remembers your name across chats. Here's how that works — and it's simpler than you think.

The problem

Your agent has a state dict. It records everything that happens during a run. But state lives in memory. When the process ends, the dict disappears. Next time you run the agent, it starts fresh — no history, no context, no memory of previous conversations.

This is the difference between a chatbot and an assistant. An assistant remembers.

The fix: a tool called remember

Give the agent a tool called remember. It doesn't do anything clever — it saves a key-value pair to a dictionary. That dictionary gets written to disk (or a database) and loaded back into the system prompt on every new run.

The agent calls remember like any other tool. Run 1 saves data. Run 2 loads it. The memory dict gets injected into the system prompt so the LLM can see everything it previously stored.

The code

tools = {
    "remember": lambda key, value:
        memory.update({key: value}) or f"saved {key}={value}",
}

One tool. That's the whole trick. The remember lambda takes a key and value, updates the memory dict, and returns a confirmation string. Before each run, you load the dict from disk. After the agent finishes, you save it back.

Watch it work

Session 1: Tell the agent "my name is Alice." It calls remember(name, Alice) — saved. The memory dict now holds {name: "Alice"}.

Session 2: New process. The memory dict gets loaded from disk and injected into the system prompt. Ask "who am I?" The agent sees the memory and answers: "Alice."

No retrieval-augmented generation. No vector database. No embeddings. Just a dict that persists between runs and a tool that writes to it.

Try it

Run this code yourself at tinyagents.dev. Add your own memory fields — preferences, facts, conversation summaries — and watch your agent become an assistant that actually remembers.

Next up: Lesson 7 — Policy. The agent can remember and act. But who decides what it's allowed to do?

This is Lesson 6 of A Tour of Agents — a free interactive course that builds an AI agent from scratch. No frameworks. No abstractions. Just the code.

🎬 Video: lesson06-memory.mp4

Agents in 60 lines of python : Part 5

Arun Purushothaman — Mon, 23 Mar 2026 03:30:00 +0000

State = Dict

Lesson 5 of 9 — A Tour of Agents

The entire AI agent stack in 60 lines of Python.

Run the agent. "Add 10 and 5, then uppercase hello." It returns "15 and HELLO". Correct. But how many turns was that? Which tools fired? All you got back is a string.

The agent works. It loops, calls tools, remembers conversation. But the return value tells you nothing about what happened inside.

The problem

Right now the agent function returns a string — the assistant's final message. That's fine for a chatbot. But if you're building anything real — logging, debugging, retry logic, cost tracking — you need more.

You can't tell:

How many loop iterations it took
Which tools were called and in what order
What each tool returned

The conversation array has all of this buried in it, but you'd have to dig through message objects to reconstruct it. There's a simpler way.

The fix: add a dict

Create a state dictionary before the loop. Every time something happens — a turn completes, a tool fires, a result comes back — record it.

Messages are the raw tape. State is the summary. One is for the LLM. The other is for you.

The code

state = {"turns": 0, "tool_calls": [], "results": []}

Three fields. Turns counts loop iterations. Tool calls tracks which functions ran. Results stores what they returned. Initialize it before the loop, update it inside:

async def agent(user_message, max_turns=5):
    conversation.append({"role": "user", "content": user_message})
    state = {"turns": 0, "tool_calls": [], "results": []}

    for turn in range(max_turns):
        state["turns"] += 1
        msg = await ask_llm(conversation)

        if not msg.get("tool_calls"):
            conversation.append({"role": "assistant", "content": msg.get("content", "")})
            state["answer"] = msg.get("content", "")
            return state

        conversation.append(msg)
        for tc in msg["tool_calls"]:
            name = tc["function"]["name"]
            result = tools[name](**json.loads(tc["function"]["arguments"]))
            state["tool_calls"].append(name)
            state["results"].append(result)
            conversation.append({"role": "tool", "tool_call_id": tc["id"], "content": str(result)})

    return state

Instead of return msg.get("content", ""), return the whole dict. The answer is still in there — under state["answer"]. But now you also get everything else.

Watch it work

Same question: "Add 10 and 5, then uppercase hello."

Turn one: the agent calls add. Result: 15. The state dict records it.

Turn two: upper. Result: HELLO. Two turns. Two tools. The full picture — not just the answer, but the entire execution trace.

This is what LangChain calls AgentState and what LangGraph builds its entire graph around. It's a dictionary.

Try it

Run this code yourself at tinyagents.dev. Add your own fields to the state dict — token counts, timestamps, error flags — and watch the agent become observable.

Next up: Lesson 6 — Streaming. The agent returns a complete response. But what if you want to see tokens as they arrive?

This is Lesson 5 of A Tour of Agents — a free interactive course that builds an AI agent from scratch. No frameworks. No abstractions. Just the code.

Agents in 60 lines of python : Part 4

Arun Purushothaman — Sun, 22 Mar 2026 04:00:00 +0000

Conversation = Messages Array

Lesson 4 of 9 — A Tour of Agents

The entire AI agent stack in 60 lines of Python.

Last lesson's agent could loop — call a tool, check the result, call again. But ask it what you said two messages ago. It has no idea. Every call started fresh.

The fix is one line of code.

The problem

In Lesson 3, the messages array lived inside the function. Every call created a new one. When the function returned, the array was gone. No history. No memory.

This is why ChatGPT remembers your conversation — and why "New Chat" forgets. Same mechanism. One array.

The fix: make it global

Move the messages array outside the function. That's it.

Now every call to agent() reads and writes to the same list. The conversation persists across calls. The LLM sees the full history every time it thinks.

The code

conversation = [
    {"role": "system", "content": "You have tools: add(a,b) and upper(text). Use them when needed."},
]

One list. Initialized once with a system prompt. Every message after that — appended, never cleared. New Chat in ChatGPT just means creating a new empty array.

The agent function now appends to this global list:

async def agent(user_message, max_turns=5):
    conversation.append({"role": "user", "content": user_message})
    for turn in range(max_turns):
        msg = await ask_llm(conversation)
        if not msg.get("tool_calls"):
            conversation.append({"role": "assistant", "content": msg.get("content", "")})
            return msg.get("content", "")
        conversation.append(msg)
        for tc in msg["tool_calls"]:
            result = tools[tc["function"]["name"]](**args)
            conversation.append({"role": "tool", "tool_call_id": tc["id"], "content": str(result)})

User question goes in before the loop. Assistant answer goes in after. Tool results go in during. Every turn, the list grows.

Watch it fill up

Send "add 3 and 4" — three messages in the array (system + user + assistant).

Send "uppercase hello" — the tool runs, result comes back. Five messages now.

Send "what were the results?" — the agent reads the full history and answers correctly: "7 and HELLO." Eight messages deep, and it remembers everything.

This is what LangChain calls ConversationBufferMemory. It's a list that doesn't get cleared.

Try it

Run this code yourself at tinyagents.dev. Send multiple messages and watch the conversation array grow in real time.

Next up: Lesson 5 — Structured Output. The agent can talk and use tools. But how do you get it to return data in a specific format?

This is Lesson 4 of A Tour of Agents — a free interactive course that builds an AI agent from scratch. No frameworks. No abstractions. Just the code.

Agents in 60 lines of python : Part 3

Arun Purushothaman — Sat, 21 Mar 2026 03:30:00 +0000

The Agent Loop

The entire AI agent stack in 60 lines of Python.

You've seen Claude search files, read them, then search again. ChatGPT with Code Interpreter writes code, runs it, sees an error, fixes it, runs again. That back-and-forth isn't magic. It's a loop.

Lesson 2's agent made one tool call and stopped. That's fine for "what's 2 + 2?" but useless for anything real. Multi-step tasks — analyzing a codebase, debugging a function, researching a topic — need the agent to keep going until the job is done.

The agent loop is what makes that possible. And it's shockingly simple.

The concept

Real agents loop: call a tool, see the result, decide what's next, repeat until done. The LLM decides when to stop.

The flow is:

Build messages — system prompt + user task
Ask LLM — send everything so far
tool_calls? — the LLM either returns an answer (done) or asks for tools
Execute tool — run it, append the result
Back to Ask LLM — with the growing messages array

That loop-back arrow from "Execute tool" to "Ask LLM" is the entire difference between a toy and a useful agent.

The code: a for loop with a safety limit

async def agent(task, max_turns=5):
    messages = [
        {"role": "system", "content": "Use tools."},
        {"role": "user", "content": task},
    ]
    for turn in range(max_turns):
        msg = await ask_llm(messages)
        if not msg.get("tool_calls"):
            return msg.get("content", "")

for turn in range(max_turns) — that's the whole loop. Each iteration is one "turn": ask the LLM, check if it wants a tool. If not, return the answer. The max_turns safety limit prevents runaway loops (an LLM that keeps calling tools forever).

The dispatch: executing tools

When the LLM does ask for a tool, we run it and feed the result back:

        messages.append(msg)
        for tc in msg["tool_calls"]:
            name = tc["function"]["name"]
            args = json.loads(tc["function"]["arguments"])
            result = tools[name](**args)
            messages.append({
                "role": "tool",
                "tool_call_id": tc["id"],
                "content": str(result),
            })

The tool_call_id links each result to its request. When the LLM asks for two tools at once, this is how it knows which result belongs to which call.

The messages array grows with every turn. That's the agent's memory within a single task.

Watch the cycle

Message in, LLM thinks, tool runs, result feeds back. Around and around until the LLM decides it has enough to answer.

Try "add 3 and 4, then uppercase hello" — the LLM chains two tool calls across multiple turns. Watch the messages array grow.

What changed from Lesson 2

Lesson 2 was a single LLM call: ask once, maybe use a tool, done. That can't handle "search for files, then read the interesting ones, then summarize." The loop is what makes agents actually useful.

This is the entire runtime of LangChain's AgentExecutor, OpenAI's Agents SDK, AutoGen — a while loop over messages. Every agent framework wraps this pattern. Now you've seen it bare.

The full code

Here's the complete agent in ~30 lines:

tools = {"add": lambda a, b: a + b, "upper": lambda text: text.upper()}
TOOL_DEFS = [
    {"type": "function", "function": {"name": "add", "description": "Add two numbers",
        "parameters": {"type": "object",
            "properties": {"a": {"type": "number"}, "b": {"type": "number"}}}}},
    {"type": "function", "function": {"name": "upper", "description": "Uppercase text",
        "parameters": {"type": "object",
            "properties": {"text": {"type": "string"}}}}},
]

async def ask_llm(messages):
    resp = await client.chat.completions.create(
        model="gpt-4o-mini", messages=messages, tools=TOOL_DEFS
    )
    return resp.choices[0].message

async def agent(task, max_turns=5):
    messages = [
        {"role": "system", "content": "Use tools to answer. Be concise."},
        {"role": "user", "content": task},
    ]
    for turn in range(max_turns):
        msg = await ask_llm(messages)
        if not msg.get("tool_calls"):
            return msg.get("content", "")
        messages.append(msg)
        for tc in msg["tool_calls"]:
            name = tc["function"]["name"]
            args = json.loads(tc["function"]["arguments"])
            result = tools[name](**args)
            messages.append({
                "role": "tool",
                "tool_call_id": tc["id"],
                "content": str(result),
            })
    return "Max turns reached"

Try it

Run this code yourself at tinyagents.dev. Lesson 3 has a live sandbox — type a task, watch the loop cycle through the graph in real time.

Next up: Lesson 4 — Conversation. The agent loop handles a single task. But what about back-and-forth dialogue? That's where conversation memory comes in.

This is Lesson 3 of A Tour of Agents — a free interactive course that builds an AI agent from scratch. No frameworks. No abstractions. Just the code.

Agents in 60 lines of python : Part 2

Arun Purushothaman — Fri, 20 Mar 2026 03:30:00 +0000

Tools = Dict

When ChatGPT says "Used browser" or Claude says "Running search" — what's actually happening? The LLM can't run code. But it can say "call add with a=10, b=5" — a structured request. Your code executes it.

That's the whole trick. Tools are functions in a dictionary. The LLM picks which one to call.

The concept

The LLM decides. Your code executes.

A message goes in. The LLM either returns a tool call (a structured request with a function name and arguments) or plain text. If it's a tool call, your code looks it up and runs it. If not, you return the text directly.

One dict. One lookup. One call.

The registry

Step one: build a dictionary of callables. Every key is a tool name. Every value is the function that runs it.

tools = {
    "add": lambda a, b: a + b,
    "upper": lambda text: text.upper(),
}

Lambda, function, class method — anything that takes arguments and returns a value. That's your tool registry.

You also describe these tools for the LLM using JSON Schema, so it knows what exists and what arguments each tool accepts:

TOOL_DEFS = [
    {"type": "function", "function": {
        "name": "add", "description": "Add two numbers",
        "parameters": {"type": "object",
            "properties": {"a": {"type": "number"}, "b": {"type": "number"}}}}},
    {"type": "function", "function": {
        "name": "upper", "description": "Uppercase a string",
        "parameters": {"type": "object",
            "properties": {"text": {"type": "string"}}}}},
]

This is the wire format OpenAI and Groq expect in the tools field. When ChatGPT shows that little plugin icon before calling a tool — this JSON schema is how it knew the tool existed.

The dispatch

When the LLM wants a tool, your agent looks it up by name and calls it with the arguments. One line does the work:

async def agent(task):
    d = await ask_llm(task)
    if d.get("tool") and d["tool"] in tools:
        result = tools[d["tool"]](**d["args"])
        return f"{d['tool']}({d['args']}) = {result}"
    return d.get("text", "No tool needed")

The key line: tools[d["tool"]](**d["args"]). Dictionary lookup, then call with keyword arguments. Same pattern as an Express router or Redux reducer.

tools[name](**args) — that's the whole pattern.

The data flow

Message goes in. LLM decides — tool call, or plain text. If it's a tool, look up, execute, return. No magic.

Framework parallel

LangChain's @tool decorator, CrewAI's tool registration — they build this dict for you. Here you've seen what's inside.

Try it

Run it yourself at tinyagents.dev. Try "add 10 and 5" — the LLM returns a tool call, your code executes it. Try "what is Python?" — no tool needed, the LLM answers directly. The LLM decides.

Next up: Lesson 3 — The Agent Loop.

This is Lesson 2 of A Tour of Agents — a free interactive course that builds an AI agent from scratch. No frameworks. No abstractions. Just the code.

Agents in 60 lines of python : Part 1

Arun Purushothaman — Thu, 19 Mar 2026 11:27:16 +0000

The Agent Function

Lesson 1 of 9 — A Tour of Agents

Every time you send a message to ChatGPT, Claude, or any LLM — your app makes one HTTP POST request and gets a response back. That's it. No magic. No framework. One function.

This is where agents start.

What is an agent, really?

Strip away the buzzwords and an AI agent is a pipeline with four steps:

Your message → agent() → POST /completions → Response

Your message goes in. A function wraps it into the right format. An HTTP call goes out. A response comes back.

That flow diagram is the entire architecture of Lesson 1. There's no orchestration engine. No agent framework. Just a function that talks to an API.

The function

Here's the core of it — a function called ask_llm:

async def ask_llm(messages):
    resp = await pyfetch(
        "https://api.groq.com/v1/chat/completions",
        method="POST",
        headers={"Authorization": f"Bearer {KEY}"},
        body=json.dumps({
            "model": "llama-3.3-70b",
            "messages": messages
        })
    )
    data = await resp.json()
    return data["choices"][0]["message"]["content"]

This function takes a list of messages, sends them to an LLM API, and returns the response content. That's the entire "AI" part of an agent.

The messages array is the conversation format every LLM uses — a list of objects with a role ("system", "user", "assistant") and content. The API doesn't remember previous messages. You send the full conversation every time.

The wrapper

Now wrap it:

def agent(prompt):
    messages = [
        {"role": "system", "content": "You are a helpful assistant."},
        {"role": "user", "content": prompt}
    ]
    return ask_llm(messages)

One function. One API call.

The system message sets the behavior. The user message is whatever you type. The function passes both to the LLM and returns what it says.

This is the simplest possible agent. It can't use tools. It can't loop. It can't remember anything between calls. But it's the foundation everything else builds on.

Watch the data flow

When you call agent("What is the capital of France?"), here's what happens:

Your string gets wrapped into a messages array
ask_llm sends that array as an HTTP POST to /chat/completions
The API returns a JSON response
You extract choices[0].message.content — that's your answer

No state. No memory. No side effects. Data flows in one direction: message in, response out.

Try it yourself

This lesson runs entirely in your browser at tinyagents.dev. Type a message, watch it flow through the diagram, see the HTTP request, read the response.

The next 8 lessons build on this foundation:

Lesson 2 adds tools (a Python dictionary, literally)
Lesson 3 adds the agent loop (a for loop with a safety limit)
By Lesson 9, you'll have a complete agent with tools, memory, streaming, and multi-agent orchestration

All in about 60 lines of Python.

This is Lesson 1 of A Tour of Agents — a free interactive course that builds an AI agent from scratch. No frameworks. No abstractions. Just the code.