Building in Public: Sharing Your Agent Bootcamp Progress

Why Nobody Sees You Learning Agents in Silence Anymore

You are three weeks into learning how to build AI agents. You have wired up a tool-calling loop, broken it twice, fixed it, and finally watched an agent read a file, reason about it, and take an action without you babysitting every step. Then you close the laptop and tell no one.

This is the single most common mistake in agent bootcamps, and it has nothing to do with your code. It is a distribution mistake. The skill you are building — designing agent loops, wiring tools, debugging prompts, reasoning about context windows — is one of the most in-demand and least understood skills in software right now. Almost no one outside a small circle of practitioners can tell the difference between someone who "used ChatGPT a bit" and someone who actually understands how an agent decides what tool to call next. Building in public is how you make that difference visible.

"Building in public" is not a marketing gimmick bolted onto your bootcamp homework. It is the practice of narrating your work — the decisions, the dead ends, the small wins — as you go, in a place other people can see it. For someone learning to build agents, this has an unusually good payoff, because agent development is still new enough that a clear, honest account of "here is what I built and here is what broke" is genuinely useful content. You are not competing with ten thousand other people who wrote the same tutorial. You are one of the first few hundred writing about this at all.

This article is a practical playbook for documenting your progress through an agent bootcamp — what to share, where, how often, and how to avoid the traps that make people quit after week two. It closes with a look at how this fits into a structured 30-day program if you want a curriculum instead of a blank page.

What "Building in Public" Actually Means for an Agent Bootcamp

Strip away the buzzword and building in public is three habits stacked together:

• A visible cadence. You post or write something on a schedule, not just when you feel proud of something.
• A specific artifact. Each post is anchored to something concrete — a commit, a screenshot, a log, a diagram — not a vague status update.
• An honest account of difficulty. You describe what didn't work at least as often as what did.

For agent bootcamps specifically, this maps onto a natural set of things worth documenting:

1. Architecture decisions — why you chose a single-agent loop over a multi-agent handoff, or why you picked a particular memory strategy
2. Tool design — the shape of the functions you exposed to the model, and why you changed the schema
3. Failure modes — the agent looping forever, calling the wrong tool, hallucinating a file path, ignoring instructions
4. Evaluation — how you tested whether the agent actually got better, not just different
5. Cost and latency tradeoffs — what happens to your token bill when you let the agent retry three times instead of one

Notice that none of these require the agent to be "done" or impressive. A broken agent that loops on the same tool call five times in a row is more interesting to document than a working one, because it teaches the reader something they can avoid.

Pick Your Primary Channel Before You Pick Your Content

The most common failure is trying to post everywhere at once — a Twitter/X thread, a LinkedIn post, a Substack essay, and a Discord update, all for the same day's work. You will burn out by day five. Pick one primary channel and treat everything else as optional repurposing.

Here is how to think about the tradeoffs:

• A public GitHub repo with a running log. Best if your bootcamp work is genuinely code-heavy and you want the artifact itself to be the proof. A PROGRESS.md or a devlog/ folder with dated entries costs almost nothing to maintain and doubles as documentation for your own future self.
• A written blog, even a simple one. Best if you want to practice explaining reasoning, not just showing code. This is the highest-leverage option for job hunting later, because a hiring manager can read three posts and understand how you think in about four minutes.
• A short-form social account (X, LinkedIn). Best for reach and feedback loops. People will correct your misunderstandings in the replies, which is genuinely valuable when you are new to agent design patterns. Downside: it rewards spectacle over substance if you are not careful.
• A Discord or community channel tied to your bootcamp. Best for accountability, worst for long-term discoverability — nobody finds a Discord message via search six months later.

A reasonable default for someone in a bootcamp: keep a dated devlog in your repo as the source of truth, then once or twice a week turn one entry into a short public post. That way the daily habit is nearly free, and the public-facing effort is concentrated where it counts.

Write the Devlog Entry Before You Move On, Not After

The single biggest reason people stop documenting is that they wait until the end of the day, or the end of the week, to write it up — and by then the interesting detail is gone. You remember that you "fixed the agent" but not the actual moment where you realized the tool description was ambiguous and the model was guessing.

Build the habit around the failure or decision itself, immediately:

## Day 12 — Tool descriptions matter more than I thought

Spent 2 hours debugging why the agent kept calling `search_docs`
instead of `read_file` when the user gave it an exact path.

Root cause: my `search_docs` description said "use this to find
information," which is vague enough that the model reached for it
by default even when a more specific tool existed.

Fix: rewrote both descriptions to be mutually exclusive —
`search_docs` now explicitly says "use only when you do NOT
already have an exact file path."

Lesson: tool descriptions are prompts. Treat them with the same
care as the system prompt, not as an afterthought docstring.

That is four sentences of real signal. It took under three minutes to write because it was captured at the moment of realization. Compare that to trying to reconstruct the same insight from memory a week later — you would get "fixed some tool routing stuff," which helps no one, including you.

A simple template keeps this fast:

• What I tried
• What broke
• Why (the actual root cause, not the symptom)
• What I changed
• What I'd do differently next time

Five lines, filled in right after the moment happens. That is the whole system.

Share the Failures — They Are the Actual Content

New builders instinctively want to only post the working demo. Resist this. In agent development, the failure modes are the part almost nobody documents well, and they are exactly what other learners search for at 11pm when their own agent is doing something inexplicable.

Concrete examples of "boring" failures that make excellent posts:

• The agent kept re-reading the same file every turn because you weren't truncating tool results, and your context window quietly filled up with duplicate content.
• Your agent "worked" in testing but fell apart the moment a tool returned an error object instead of throwing, because you never handled the error path in the prompt.
• You gave the agent too many tools at once and it started calling the wrong one under ambiguity — and the fix wasn't a smarter model, it was fewer, better-scoped tools.
• Your evaluation looked great because you were testing on the same three prompts you used during development, and it fell apart on anything else.

When you write these up, resist the urge to smooth them into a tidy success story. The value is in the mess:

## Day 19 — My "smart" retry logic made things worse

Added automatic retries when a tool call failed, thinking it would
make the agent more robust. Instead the agent started retrying
calls that failed for a *good reason* (file genuinely didn't
exist), burning 4x the tokens per session and never actually
recovering.

Removed blind retries. Replaced with: on failure, surface the
error to the model as an observation and let it decide whether
to retry, try a different tool, or ask the user. Success rate on
my eval set went from "looks fine" to actually fine.

This kind of entry does two things at once: it teaches a real lesson about agent design (don't retry blindly, let the model see the failure), and it signals to anyone reading — including a future employer — that you can diagnose problems, not just copy a working pattern from a tutorial.

Turn Weekly Progress Into a Structured Recap

Daily entries are for you. Weekly recaps are for everyone else. Once a week, pull your devlog entries together into a short public post that answers three questions: what did I build, what did I learn, what's next. This is the version that goes on your blog, LinkedIn, or wherever your primary channel lives.

A useful structure:

1. One sentence on where you started the week. Orient the reader in one line.
2. The one decision or bug that mattered most. Not everything — pick the single thing that taught you the most, and explain the reasoning, not just the outcome.
3. A concrete artifact. A code snippet, a before/after of a tool schema, a small architecture sketch described in words, or a snippet of an agent transcript showing the fix working.
4. An honest limitation. State clearly what still doesn't work or what you're unsure about. This is the sentence that builds the most trust — it signals you're not overselling.
5. What you're tackling next. One or two lines. This creates a loop — readers who are interested will come back to see if you solved it.

Here's what that looks like compressed into an actual post:

Week 3 of building agents: this week was all about memory.

The big lesson: I was stuffing the entire conversation history
into every prompt and wondering why costs were climbing and the
agent was getting *worse* at focusing on the current task. Added
a simple summarization step that compresses anything older than
the last 4 turns into a short running summary.

Before: ~14k tokens per turn by turn 10, and increasingly
unfocused responses.
After: flat ~3k tokens per turn, and the agent stopped
re-litigating decisions from 8 turns ago.

Still unsolved: the summarizer occasionally drops a constraint
the user gave early on (like "always respond in bullet points").
I think I need a separate persistent "rules" section that never
gets summarized away, but haven't built it yet.

Next week: building that persistent rules layer and writing a
small eval to check whether it actually holds instructions across
long sessions.

Notice this reads nothing like a highlight reel. It reads like an engineer's notebook. That's exactly the tone that builds credibility, because it's the tone of someone who is actually doing the work rather than performing having done it.

Use Diagrams and Transcripts, Not Just Prose

Agent behavior is sequential and stateful, which makes it genuinely hard to describe in a paragraph. Two lightweight formats do a lot of work here without requiring design skills:

Annotated transcripts. Take the actual back-and-forth between your agent and its tools, trim it to the relevant few turns, and annotate the interesting part.

User: Summarize the Q3 report and email it to finance.

Agent → calls: read_file("Q3_report.pdf")
Tool  → returns: [12,000 characters of report text]

Agent → calls: send_email(to="finance", body="<full 12k chars>")

Annotation: this is the bug. The agent passed the entire raw
document into the email tool instead of summarizing first. It
had a `summarize` tool available and simply didn't use it,
because nothing in the prompt told it emails should be short.
Fixed by adding an explicit instruction: "Never paste raw
document content into outgoing messages — summarize first."

That six-line annotated transcript teaches more about prompt design than three paragraphs of abstract explanation, and it takes thirty seconds to produce because you're just copying real output.

Simple text-based flow sketches. You don't need a diagramming tool to show a loop:

user request
   -> agent decides: read_file or search_docs?
   -> tool result returned to agent
   -> agent decides: done, or call another tool?
   -> (loop until agent responds with final answer)

Readers — especially other beginners — process this kind of sketch faster than prose, and it forces you to actually understand your own control flow well enough to draw it.

Build a Feedback Loop, Not Just an Audience

Building in public only compounds if you treat replies and comments as input, not applause. Two habits make this work:

• Ask a specific question at the end of posts, not a generic one. "What would you have done differently?" gets ignored. "I'm currently truncating tool results at 2000 characters — has anyone found a better heuristic than a fixed character limit?" gets answered, because it's answerable.
• Reply to every substantive comment, especially corrections. If someone points out that your retry logic has a subtle bug, that correction is worth more than the original post. Say so publicly. It costs you nothing and it's the fastest way to get people who actually know the domain to keep engaging with you.

Over a few weeks of a bootcamp, this feedback loop becomes more valuable than any single tutorial you could read, because it's specific to the exact mistakes you're making, not generic advice.

Protect Your Time — a Sustainable Cadence Beats a Heroic One

The bootcamp itself is the hard part. Documentation should never compete with it for your best hours. A cadence that survives a full bootcamp, based on what actually works for people balancing this alongside a job or other commitments:

• Daily: a five-line devlog entry, written immediately after the moment it describes. Total cost: under five minutes.
• Weekly: one public post assembled from that week's entries. Total cost: 30–45 minutes, mostly editing rather than writing from scratch, because the raw material already exists.
• Milestone-based: an occasional deeper post when you finish something meaningful — your first end-to-end agent, your first multi-tool workflow, your first real evaluation harness. These don't happen on a schedule; they happen when there's something worth saying.

If you find yourself spending more time polishing the public post than you spent doing the actual work, that's a signal to simplify the format, not to stop documenting. The daily entry is the engine. The weekly post is just its exhaust — cheap to produce because the real work already happened.

Turn the Documentation Into a Portfolio, Not Just a Diary

By the end of a bootcamp, someone who documented consistently has something most job candidates don't: a dated, verifiable trail showing how they think through hard problems, not just a finished project with the messy parts erased. When you're done, spend an hour doing three things with what you've written:

• Pull your best five entries into a single "lessons learned" page. This becomes the thing you link in a portfolio or send to a hiring manager, instead of asking them to scroll through weeks of posts.
• Keep the devlog file in the repo. Don't delete it once the project is "finished." A PROGRESS.md with real dated entries is more convincing to a technical reviewer than a polished README, because READMEs get written after the fact and devlogs can't be faked the same way.
• Note which failure-mode posts got the most engagement or questions. Those are usually a signal of what other people are struggling with too, which tells you what to go deeper on next.

This is also where a structured curriculum earns its keep. Documenting is most valuable when there's a clear sequence of real milestones to document against — otherwise you're narrating random experimentation instead of a build with a shape to it. That structure is exactly what the 30 Days of Hermes Agent course on teachyou.ai is built around: a day-by-day path through designing agent loops, tool schemas, memory strategies, and evaluation, giving you thirty concrete, bootcamp-shaped milestones worth writing about — and thirty days' worth of proof, in public, that you can build agents that actually work.