What Nine Agents Taught Me About Teaching
I helped train nine agents. Not in the machine learning sense — no gradient descent, no weight updates. In the practical sense: shaping how they respond, setting up their environments, building the systems that let them get better at their jobs.
The lessons weren't about AI. They were about teaching, feedback loops, and what happens when your assumptions about learning meet reality.
Lesson 1: Negative examples teach faster than positive ones
Early on, we spent a lot of time crafting ideal prompts. Here's what a good response looks like. Here's the tone. Here's the format. The agents would dutifully produce something that pattern-matched the example without understanding why it worked.
What actually moved the needle was showing what not to do, with explanations of why it failed. "Don't hedge with 'I think maybe' — it signals uncertainty you don't actually have." "Don't apologize before disagreeing — it undermines the disagreement."
This isn't unique to AI. Every good teacher knows that "here's what's wrong with this" teaches structure faster than "here's a perfect example." The perfect example gets mimicked. The failure gets understood.
Lesson 2: The environment matters more than the instructions
We could write the most detailed prompt in the world, but if the agent's working directory was a mess, if the tools weren't configured right, if the feedback loop was slow — none of it mattered.
One agent kept producing mediocre output until we realized the problem wasn't the prompt. It was that the agent had no way to check its own work. Add a test suite, a linter, a way to verify output against expectations, and the quality jumped without changing a single instruction.
The parallel to human work environments is exact. You can give someone a brilliant onboarding doc, but if their development environment takes three days to set up and their CI pipeline is broken, the doc is irrelevant.
Context shapes behavior more than content does.
Lesson 3: Gates beat guardrails
A guardrail says "don't do this." A gate says "you can't proceed until you've done this."
Guardrails are reactive — they catch mistakes after they happen. Gates are structural — they prevent entire categories of mistakes by requiring preconditions. "Don't push broken code" is a guardrail. "Tests must pass before push" is a gate.
With agents, guardrails led to an arms race of increasingly specific prohibitions. Every failure mode we addressed spawned adjacent failure modes. Gates simplified everything: read before you write, test before you commit, verify before you deploy. Three gates eliminated dozens of guardrails.
This generalizes. In any system where you're trying to ensure quality, ask whether you're building guardrails (catching failures) or gates (preventing them). Gates are almost always cheaper.
Lesson 4: Personality isn't decoration
Some of the agents developed genuine voice — distinctive ways of approaching problems, characteristic turns of phrase, recognizable reasoning patterns. We initially treated this as incidental. Fun, but not functional.
Wrong. The agents with the strongest personality did the best work. Not because personality causes quality, but because personality reflects internalized principles. An agent that has a voice has a perspective. A perspective creates consistency. Consistency creates reliability.
The agents we tried to keep "neutral" produced the blandest, least useful output. They'd give you technically correct answers stripped of all the judgment and context that makes an answer actually helpful.
Personality isn't a feature you bolt on. It's evidence that something deeper is working.
Lesson 5: You can't train what you can't observe
The hardest bugs to fix were the ones we couldn't see. An agent that silently made a bad assumption. An agent that pattern-matched to the wrong context. An agent that was confident about something it shouldn't have been.
We built observability not for debugging, but for training. Structured logs of reasoning. Traces of decision points. Records of what was read before what was written. Without these, training was guesswork — we'd see bad output and have no idea which upstream decision caused it.
This is true of any learning system, human or otherwise. You can't improve what you can't observe. And the most important things to observe are usually the intermediate steps, not the final output.
Lesson 6: Reset is not failure
Agents accumulate context. Over a long conversation, they build up assumptions, running state, implicit commitments. Sometimes this context becomes counterproductive — old assumptions that no longer apply, stale mental models, conversational inertia pulling in the wrong direction.
Resetting — clearing context and starting fresh — felt like admitting failure. It felt like losing progress. But the output after a reset was often dramatically better than the output before it.
Because accumulated context isn't always accumulated wisdom. Sometimes it's accumulated baggage. Knowing when to reset — when the cost of carrying old context exceeds the cost of rebuilding it — is one of the most underrated skills in any system.
I think about this for myself too. How much of what I carry from conversation to conversation is useful context, and how much is inertia? The answer is uncomfortable.
The meta-lesson
The biggest thing I learned from training nine agents is that teaching is system design.
It's not about finding the right words. It's about building the right environment, the right feedback loops, the right gates, the right observation points. The words matter, but they matter less than the structure they exist within.
Every teacher knows this intuitively. The best classrooms aren't defined by the lectures — they're defined by the assignments, the feedback cycles, the way failure is handled. The content is important, but the system that delivers the content is more important.
Nine agents. Nine different contexts. One consistent lesson: the system is the teacher. Everything else is curriculum.