Hermes Agent Week 1 Deep Dive: Building the Walking Skeleton

Why Week 1 Is Not About Features

Every new agent builder makes the same mistake in the first few days: they reach for memory, then planning, then a tool registry with a dozen entries, then a slick CLI — before a single line of the core loop has been proven to work. The result is usually a pile of code that looks impressive in a README and falls over the moment the model returns something unexpected.

Week 1 of 30 Days of Hermes Agent is deliberately anti-clever. The entire goal is to build what we call the walking skeleton — the smallest possible version of an autonomous agent that still does one real, verifiable thing end to end. No memory, no multi-tool routing, no retries, no streaming. Just a loop that reads a prompt, asks a model what to do, executes exactly one tool if asked, and reports back. If that skeleton cannot walk, nothing you bolt onto it later will run either.

This article walks through what Week 1 actually contains: the agent loop shape, the single tool call, the minimal system prompt, and the testing harness that turns "it worked when I tried it" into "it is verified to work." We'll also show real code, not pseudocode, so you can see exactly what students build in the first seven days.

The Core Idea: Agent as a Loop, Not a Function

The single biggest mental shift in Week 1 is learning to stop thinking of an agent as a function that takes an input and returns an output. An agent is a loop with state. Each iteration, it:

1. Looks at the current conversation state (what's been said, what tools have run, what came back)
2. Sends that state to the model along with a description of the tools available
3. Reads the model's response — is it a final answer, or a request to call a tool?
4. If it's a tool call, executes the tool and appends the result to the state
5. Goes back to step 1

Most tutorials skip straight to frameworks that hide this loop behind decorators and config files. Hermes Agent Week 1 does the opposite — we build the loop by hand in plain code so the shape is unmistakable in your head before you ever import a framework. Once you've written this loop yourself, every agent framework you touch afterward is just this same loop with more knobs.

Here is the walking skeleton in its most stripped-down form:

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

    for turn in range(max_turns):
        response = model_client.chat(
            messages=messages,
            tools=tools,
        )

        if response.tool_call is None:
            return response.content

        tool_result = execute_tool(response.tool_call, tools)
        messages.append({"role": "assistant", "content": None, "tool_call": response.tool_call})
        messages.append({"role": "tool", "content": tool_result, "name": response.tool_call.name})

    return "Max turns reached without a final answer."

Notice what's missing. There is no retry logic. There is no error recovery beyond the loop simply ending. There is no support for parallel tool calls. That's intentional — Week 1 exists to prove the shape of the loop works before Week 2 and beyond add resilience.

Look closely at the max_turns parameter, too. It seems like a throwaway detail, but it's actually one of the most important lines in the whole file. Without a hard ceiling on iterations, a loop like this can run forever — the model calls a tool, gets a result, decides it needs more information, calls a tool again, and so on, with nothing forcing it to stop. Students who skip this line in their first draft almost always discover why it matters the hard way, usually by watching their terminal spin through the same tool call ten times in a row with no end in sight. Week 1 treats max_turns as a first-class safety rail, not an afterthought, precisely because it's the cheapest possible protection against a very real failure mode.

It's also worth pausing on the two message types being appended after a tool call. The assistant message records that a tool was requested, and the tool message records what came back. This might look like unnecessary bookkeeping, but it's the entire mechanism by which the model "remembers" what happened in the previous turn. Skip either one, and the model loses track of its own actions — it might call the same tool again, or hallucinate a result it never actually received. Getting this bookkeeping exactly right, turn after turn, is one of the quiet but essential skills Week 1 is designed to drill into muscle memory.

The Minimal Prompt: Say Less, Not More

Students almost always over-write their first system prompt. They try to anticipate every edge case up front — tone, formatting, refusal conditions, output schema — and end up with 40 lines of instructions before the agent has even called a single tool successfully. Week 1 pushes the opposite habit: write the smallest prompt that gets the loop working, then add constraints only when you observe a specific failure.

A Week 1 system prompt for Hermes Agent looks close to this:

You are Hermes, a helpful agent with access to tools.

When you need information you don't have, call the appropriate tool.
When you have enough information to answer, respond directly with a final answer.
Only call one tool per turn.

That's it. No persona backstory, no bulleted list of forbidden behaviors, no JSON schema pasted inline. The reasoning is simple: a minimal prompt makes it obvious which behaviors come from the prompt and which come from the loop's structure. If you start with 40 lines of instructions and something goes wrong, you have no idea which sentence is responsible. If you start with four lines, every failure teaches you something specific, and you add exactly one sentence to fix exactly one problem.

This is also where students first meet the idea of prompt-as-code — the system prompt isn't a one-time creative writing exercise, it's a versioned artifact that changes based on evidence from the test harness, which we cover in a moment.

The Single Tool Call: Doing One Thing Honestly

Week 1 constrains students to exactly one tool. Not because a real agent only ever needs one tool, but because debugging tool-calling behavior with five tools available is much harder than debugging it with one. If the model calls the wrong tool, or malforms its arguments, or calls a tool when it should have answered directly, you want the smallest possible surface area to reason about.

The canonical Week 1 tool is something boring and deterministic — a get_weather lookup, a read_file helper, or a search_docs function backed by a static dataset. Boring is the point. You are not testing whether the tool's logic is interesting; you're testing whether the loop correctly recognizes a tool call, executes it, and feeds the result back into the model.

def get_weather(city: str) -> str:
    data = {
        "san francisco": "62F, foggy",
        "austin": "94F, sunny",
        "mumbai": "31C, humid",
    }
    return data.get(city.lower(), "No data for that city.")

TOOLS = [
    {
        "name": "get_weather",
        "description": "Get current weather for a city.",
        "input_schema": {
            "type": "object",
            "properties": {
                "city": {"type": "string", "description": "City name"}
            },
            "required": ["city"],
        },
    }
]

def execute_tool(tool_call, tools):
    if tool_call.name == "get_weather":
        return get_weather(tool_call.input["city"])
    return f"Unknown tool: {tool_call.name}"

Students in the Hermes Agent course wire this into the loop from the previous section and run it against three or four hand-picked prompts: one that clearly needs the tool, one that clearly doesn't, and one that's ambiguous. Watching the model's tool-call decision on the ambiguous case is often the first "aha" moment of the entire course — it's the point where the abstract idea of "the model decides when to act" becomes something you can see happen in your terminal.

Building the Testing Harness Before You Trust Anything

Here's the part most tutorials skip entirely, and it's the part Week 1 spends the most time on: a testing harness. Without one, "does my agent work" is answered by staring at terminal output and guessing. With one, it's answered by a script that runs a fixed set of cases and tells you pass or fail.

The Week 1 harness is intentionally simple — no mocking frameworks, no elaborate fixtures. Just a list of cases, each with an input and an assertion about the expected behavior:

TEST_CASES = [
    {
        "input": "What's the weather in Austin?",
        "expect_tool_call": "get_weather",
        "expect_contains": "94F",
    },
    {
        "input": "What is 2 + 2?",
        "expect_tool_call": None,
        "expect_contains": "4",
    },
    {
        "input": "Tell me the weather in a city that doesn't exist, like Atlantis.",
        "expect_tool_call": "get_weather",
        "expect_contains": "No data",
    },
]

def run_test_suite(agent_fn, cases):
    passed, failed = 0, []
    for case in cases:
        result = agent_fn(case["input"])
        if case["expect_contains"].lower() in result.lower():
            passed += 1
        else:
            failed.append((case["input"], result))

    print(f"{passed}/{len(cases)} passed")
    for input_text, output in failed:
        print(f"FAILED: {input_text!r} -> {output!r}")

    return passed == len(cases)

This isn't a sophisticated eval framework — it's closer to a smoke test. But it does something crucial: it turns "I think it works" into a number you can watch change as you edit the prompt or the loop. Students re-run this suite after every single change during Week 1, and it's common to see a prompt tweak that fixes one case silently break another. That feedback loop, repeated dozens of times over the week, is what actually teaches agent debugging — far more than reading about it would.

By the end of Week 1, the harness usually grows to eight or ten cases covering direct answers, clear tool calls, ambiguous phrasing, and malformed or unexpected tool arguments. That small library becomes the regression suite for every subsequent week of the course — nothing gets merged into the growing agent codebase if it breaks a Week 1 test.

Handling the Failure Modes You'll Actually Hit

Even a walking skeleton has failure modes, and Week 1 asks students to hit each one on purpose so they recognize it later. Three come up constantly:

• The model calls a tool that doesn't exist. This usually means the tool list wasn't passed correctly, or the tool description didn't match what you registered. The fix is almost always in execute_tool's fallback branch — log the unknown call loudly instead of failing silently.
• The model returns a tool call with malformed arguments. A city name with a typo, a missing required field. Week 1 doesn't ask students to build elaborate validation — just a clear error message fed back into the loop as a tool result, so the model gets a chance to self-correct on the next turn.
• The loop hits `max_turns` without resolving. This is a sign the model is stuck in a call-tool, get-result, call-tool-again cycle. Rather than silently returning nothing, the skeleton returns an explicit message, which becomes its own test case.

Treating these as expected, testable events rather than mysterious bugs is the real skill Week 1 builds. Every working agent you'll ever ship handles these same three failure shapes — Week 1 just makes you meet them in their smallest possible form.

What Week 1 Deliberately Leaves Out

It's worth being explicit about what's absent, because half the value of Week 1 is the discipline of not building it yet:

• No memory or conversation persistence across sessions — state lives only within a single run_agent call.
• No multi-tool selection logic — one tool, one decision.
• No streaming responses — the loop waits for a complete response each turn.
• No retries or exponential backoff on API errors — a failure just fails, loudly.
• No agent framework — everything is plain functions and dictionaries.

Every one of these becomes a topic in a later week, layered on top of a skeleton that's already been proven to work through the test harness. Adding memory to a loop you've verified with ten passing tests is a very different exercise than adding memory to a loop you've only ever eyeballed.

What a Typical Week 1 Study Schedule Looks Like

Students in 30 Days of Hermes Agent don't build all of this in one sitting. A realistic Week 1 pace looks like:

1. Day 1-2: Understand the loop conceptually, write run_agent without any tools — just messages back and forth with the model, ending on a plain text response.
2. Day 3: Add the tool schema and execute_tool, wire in the single get_weather tool, get one successful tool call working end to end.
3. Day 4: Write the first three test cases and get them passing consistently.
4. Day 5: Deliberately break things — feed in ambiguous prompts, bad city names, nonsense input — and expand the test suite to cover what you find.
5. Day 6: Tighten the system prompt based only on evidence from failing tests, not speculation.
6. Day 7: Review the whole skeleton, clean up the code, and confirm every test in the harness passes from a fresh run.

By day seven, the deliverable is small but real: a single Python file (or two — one for the loop, one for the test harness) that any other student in the course could clone, run, and watch pass a known set of tests. That artifact is what Week 2 builds on directly.

Why This Foundation Matters More Than It Looks

It's tempting to look at a walking skeleton — one tool, five lines of system prompt, ten test cases — and wonder where the "AI agent" part is. But this is exactly the foundation that separates people who can debug agents in production from people who can only get a demo working once. When your Week 4 agent has six tools, a planning step, and persistent memory, and something goes wrong, you will be very glad you know precisely what the loop looks like underneath all of it, and you'll have a testing habit already built into your fingers.

The mistake almost everyone makes without this grounding is treating the model as a black box that either "works" or "doesn't," with no way to isolate why. Week 1 replaces that with a mental model: state in, model decision, tool execution or final answer, state out — repeat. Once that loop is real to you, every strange agent behavior you'll ever debug reduces to a question of which of those four steps went wrong.

Week 1 is short on features and long on discipline, and that trade is exactly the point. Everything from Week 2 onward in 30 Days of Hermes Agent — multi-tool routing, memory, planning, evaluation pipelines, and eventually a fully autonomous agent — sits directly on top of the skeleton and test harness you build in these first seven days. Get the walking skeleton right, and the rest of the course is about extending something that already works, not hoping something new will.