What Students Build in 30 Days of Hermes Agent

Why "what will I build" is the first question every student asks

Before anyone commits to a course, they want proof that the syllabus turns into something real. Nobody wants thirty days of slide decks and toy examples that fall apart the moment you close the laptop. That's the question we get most often about 30 Days of Hermes Agent: what does a student actually walk away with?

The honest answer is that it's not one project — it's a progression. Students start with something almost embarrassingly simple (an agent that can reliably answer one question using one tool) and end the month with a multi-step, multi-tool system that plans its own work, recovers from its own errors, and runs somewhere other than a Jupyter notebook. This article walks through that progression in the order students actually experience it, with concrete examples pulled from the kinds of builds that show up week after week in the cohort. None of the names below are real students — they're representative projects, the pattern every cohort converges on because the curriculum is structured to produce them.

Week 1: single-tool agents that actually finish the job

The first week is deliberately narrow. Students aren't building "an AI agent" yet — they're building a loop: prompt in, tool call out, result back, decide whether to stop. The goal is to internalize the ReAct-style reasoning loop before adding any complexity on top of it.

A typical Week 1 project is a weather-and-schedule assistant — an agent with exactly one tool (a weather API call) that has to decide, on its own, whether it needs to call the tool at all. Sounds trivial. It isn't, because most first attempts either call the tool every single time (wasteful, and wrong when the user asks "what's 12 times 8") or never call it (hallucinating a forecast instead of fetching one). Getting the decision boundary right is the actual lesson.

Here's roughly what that loop looks like once a student has it working:

def run_agent(user_message, tools, model_client):
    messages = [{"role": "user", "content": user_message}]

    while True:
        response = model_client.chat(messages=messages, tools=tools)

        if response.tool_calls:
            for call in response.tool_calls:
                result = execute_tool(call.name, call.arguments)
                messages.append({
                    "role": "tool",
                    "tool_call_id": call.id,
                    "content": str(result),
                })
            continue

        return response.content

By the end of Week 1, most students have built two or three of these single-tool agents: a currency converter agent, a simple file-lookup agent, or a "define this term" agent that hits a dictionary API. None of these are impressive on a resume. All of them are load-bearing for everything that follows, because Week 2 is where the tools stop being one and start being several — and an agent that can't reliably decide whether to call a tool will fall apart the moment it has to choose between four of them.

Week 2: multi-tool agents and the routing problem

Once a student has one tool working, the natural next question is "what if it had five?" That's where things get interesting, because the challenge stops being about calling a tool and becomes about choosing the right one — and knowing when none of them apply.

A common Week 2 build is a personal research assistant: an agent wired up to a web search tool, a calculator, a unit converter, and a note-saving tool that appends findings to a local file. The student's job isn't to write four tools — that part's mechanical. The job is to write tool descriptions precise enough that the model doesn't reach for "web search" when the user asks it to convert 40 kilometers to miles, and doesn't reach for the calculator when the user asks a genuinely open-ended question.

This is also where students hit their first real debugging wall: silent tool misuse. The agent doesn't crash — it just calls the wrong tool, gets a plausible-looking result, and confidently reports something false. The fix isn't a smarter model; it's better tool schemas and, often, a validation step that checks tool output before it's handed back to the reasoning loop.

A second popular Week 2 project is a code-explainer agent that combines a file-reader tool with a static-analysis tool (something as simple as counting function definitions or flagging TODOs) so the agent can answer questions like "what does this file do" or "are there any unfinished pieces in this module" without hallucinating structure it never actually read. Students who build this one usually reuse it later in the course as a component of something bigger — a pattern the curriculum encourages rather than discourages.

Week 3: giving agents memory and planning

This is usually the week where a student's agent stops feeling like a chatbot with extra steps and starts feeling like something that persists. Two capabilities get added almost simultaneously: memory (so the agent doesn't forget what happened three turns ago) and planning (so the agent can break a vague goal into an ordered list of steps before touching any tool).

A representative Week 3 project is a trip-planning agent that takes a goal like "plan a 4-day trip to Lisbon under a modest budget" and has to decompose that into sub-tasks: look up flights, check weather, find lodging within budget, draft a day-by-day itinerary, and keep a running total of estimated costs across every step. Without planning, the agent tries to do all of this in one shot and produces something vague. With planning, it writes out a task list first, works through it one item at a time, and — critically — updates the plan if an early step changes the constraints (say, flights eat more of the budget than expected, so lodging search parameters have to shift).

A simple planning scaffold students often land on looks like this:

def plan_then_execute(goal, planner_model, executor_agent):
    plan = planner_model.generate(
        f"Break this goal into a numbered list of concrete sub-tasks: {goal}"
    )
    steps = parse_numbered_list(plan)

    results = []
    for step in steps:
        context = "\n".join(results[-3:])  # short rolling memory
        outcome = executor_agent.run(f"{step}\n\nContext so far:\n{context}")
        results.append(f"Step: {step}\nResult: {outcome}")

    return summarize(results)

The other half of Week 3 is memory that survives beyond a single session. Students typically implement this with a lightweight vector store or even a structured JSON log, and the project that tends to click hardest here is a study-notes agent — something a student points at their own lecture notes or reading, which then answers questions by retrieving relevant chunks instead of trying to hold an entire textbook in context. It's a small-scale RAG (retrieval-augmented generation) pipeline, and building it from scratch — rather than importing a framework that hides the retrieval step — is what makes the concept stick.

Week 4: agents that talk to other agents

By the fourth week, most students have functioning single agents. The remaining question is what happens when one agent's output becomes another agent's input — multi-agent coordination, without necessarily reaching for a heavyweight orchestration framework.

The flagship Week 4 project across most cohorts is an inbox triage system: one agent classifies incoming messages (urgent, needs-reply, informational, spam), a second agent drafts replies for anything flagged "needs-reply," and a third agent reviews those drafts against a short list of tone and accuracy rules before anything is shown to the user. Students build this with a simple message-passing pattern rather than a black-box framework, specifically so they understand what's happening when a agent hands work to another agent — because debugging a multi-agent system you didn't build the plumbing for is close to impossible.

A minimal version of that hand-off:

def triage_pipeline(email_text, classify_agent, draft_agent, review_agent):
    category = classify_agent.run(email_text)

    if category != "needs-reply":
        return {"category": category, "draft": None}

    draft = draft_agent.run(f"Draft a reply to:\n{email_text}")
    review = review_agent.run(
        f"Review this draft for tone and accuracy issues:\n{draft}\n\n"
        f"Original message:\n{email_text}"
    )

    if review.get("approved"):
        return {"category": category, "draft": draft}
    else:
        revised = draft_agent.run(
            f"Revise this draft based on feedback: {review['feedback']}\n\nDraft:\n{draft}"
        )
        return {"category": category, "draft": revised}

Other common Week 4 builds include a customer-support simulator (one agent plays a frustrated customer, another plays a support rep, a third scores the transcript) and a content pipeline agent that takes a rough outline, hands it to a drafting agent, then a fact-checking agent, then a formatting agent. What all of these share is the same underlying lesson: coordination is a design problem, not a library import. Students who understand the message-passing contract between two agents can debug it when it breaks. Students who only know how to call CrewAI or AutoGen often can't.

Error handling: the unglamorous skill that separates demos from tools

Nobody signs up for an agent course excited to write error handling. But this is consistently the part of 30 Days of Hermes Agent that students say changed how they think about building software, because it's the difference between an agent that works in a demo and one that survives contact with a real user.

The projects in this stretch of the course are less "build a new agent" and more "make your Week 2 or Week 3 agent not fall over." Concretely, that means:

• Tool call retries with backoff — when an API tool times out or rate-limits, the agent needs to retry with a delay rather than immediately reporting failure to the user.
• Malformed output recovery — when the model returns something that isn't valid JSON for a tool call, the agent needs to catch that, re-prompt with the parsing error included, and try again instead of crashing.
• Guardrails against infinite loops — a planning agent that keeps generating "next steps" forever needs a hard cap on iterations and a fallback response when it hits that cap.
• Cost and token budgets — students add a running token counter to their agent loop so a runaway conversation doesn't silently burn through an API budget.

A typical retry wrapper students end up writing:

import time

def call_tool_with_retry(tool_fn, args, max_attempts=3):
    last_error = None
    for attempt in range(max_attempts):
        try:
            return tool_fn(**args)
        except (TimeoutError, ConnectionError) as e:
            last_error = e
            time.sleep(2 ** attempt)
        except ValueError as e:
            # malformed args — don't retry blindly, surface to the agent
            return {"error": f"invalid arguments: {e}"}
    return {"error": f"tool failed after {max_attempts} attempts: {last_error}"}
}

Students who skip this stretch of the course tend to have agents that look great in a five-minute walkthrough and fail the first time a real API hiccups. Students who take it seriously end up with something they can actually leave running unattended for a few hours — which matters a lot for the final project.

The capstone: agents that ship, not agents that demo

Everything in the first three and a half weeks builds toward a capstone project, and this is where the course pushes hardest on one idea: an agent isn't finished when it works on your machine. It's finished when someone else can use it without you standing next to them.

Capstones vary by student interest, but they cluster into a few recognizable shapes:

1. A Slack-integrated agent that monitors a channel, answers questions using a company's internal docs (via retrieval), and escalates to a human when confidence is low.
2. A personal automation agent that runs on a schedule — checking calendars, drafting daily summaries, flagging conflicts — deployed as a small background service rather than a script you run by hand.
3. A domain-specific assistant, often tied to whatever the student already does for work: a legal-clause-checker agent, a recipe-scaling agent, a bug-triage agent for a GitHub repo.
4. A voice-driven agent that layers speech-to-text and text-to-speech onto an existing multi-tool agent from earlier weeks, turning a text interface into something closer to a real assistant.

The deployment piece is non-negotiable in the capstone, and it's usually the part students underestimate going in. Wrapping an agent loop in a minimal API server, adding a health-check endpoint, and containerizing it is a small amount of code, but it's the code that turns a script into a product:

from fastapi import FastAPI
from pydantic import BaseModel

app = FastAPI()

class AgentRequest(BaseModel):
    message: str

@app.post("/agent")
def handle_request(req: AgentRequest):
    result = run_agent(req.message, tools=configured_tools, model_client=client)
    return {"response": result}

@app.get("/health")
def health_check():
    return {"status": "ok"}

That's the whole leap: from "I ran this in a notebook" to "this is a service someone can call." Students deploy their capstones to a small VPS, a free-tier platform, or a container host — the specific target matters less than the fact that, for the first time, the agent runs independently of the student's own machine and session.

What ties the four weeks together

Looking back across a full cohort's projects, the pattern isn't really about the specific builds — it's about which skill each project is forcing the student to earn. Week 1 forces a correct decision loop. Week 2 forces disciplined tool design. Week 3 forces state and planning. Week 4 forces coordination between independent components. The unglamorous error-handling stretch forces resilience. The capstone forces the whole thing to survive outside a notebook.

None of these are hard requirements you can skip by picking a flashier project. A student who tries to jump straight to a multi-agent capstone without first internalizing the single-tool decision loop from Week 1 usually produces something that looks sophisticated and breaks constantly — because the underlying reasoning loop was never solid to begin with. The order matters as much as the content.

What this means if you're deciding whether to enroll

If you're evaluating whether an agent-building course is worth your month, the projects above are a reasonable proxy for what any solid curriculum should produce: not one polished portfolio piece, but a sequence of increasingly capable systems, each one exposing a real failure mode of the last. Single-tool agents expose bad tool-call decisions. Multi-tool agents expose routing mistakes. Stateful agents expose memory and planning gaps. Multi-agent systems expose coordination bugs that only show up when two components have to agree on a contract. Deployment exposes everything that "works on my machine" was quietly hiding.

That's the structure behind 30 Days of Hermes Agent — not a single flashy demo, but a month of projects designed so each one forces the skill the last one was missing. If you want to see what thirty days of consistent, structured building actually produces, that's the course to look at.