Agentic Engineering

Loops, tools, and context — the craft of building software around models that act.

Agentic Engineering / Be Creative
Further · 11

Be Creative

The hub ends with you producing something, because understanding you have not used is understanding you will lose. Pick one of three tiers: an idea (a one-page proposal for an agent, a tool redesign, or a failure hypothesis), a review (a written critique of a framework, a published eval, or a real agent trace), or a prototype (a working agent with an eval suite, an MCP server, or an eval harness for an agent you already use). The Apply-it steps from the topics are your raw material — if you did them, you already have a working mini-agent, sharper tools, and a ten-task eval. Share the result somewhere real; an audience raises the bar.

Reading about agents produces the feeling of understanding. Building something produces the understanding — creation forces retrieval (can you actually state the three reasons to go multi-agent without looking?), exposes the gaps the prose papered over, and converts knowledge into the thing employers and collaborators can actually see. The gap between “I read about prompt caching” and “I watched my cache hit rate hit 4% and found the timestamp that did it” is the gap this page exists to close.

Pick one tier. Cost is your time; all three are legitimate.

Output Cost What it is
An idea Low A one-page proposal for something new: a design, a hypothesis, an improvement.
A review Medium A written critique of existing work in the field — forces you to develop standards.
A prototype High A small working artifact: an agent, a tool server, an eval harness — something that runs.

An idea (an evening)

One page, real enough that someone could act on it. Three shapes that work:

  • An agent proposal for your own workflow. Pick a task you actually do — triaging inbound bugs, drafting status updates, reviewing data pipelines. Specify it like a practitioner: where the autonomy dial sits and why, the tool surface (free / guarded / gated), what the context assembly looks like, how you’d eval it, and the cost envelope per run. The discipline is in the constraints, not the vision.
  • A tool redesign. Take a real API or CLI you use and redesign it as an agent tool using Tool Design: before/after schemas, rewritten errors, what you consolidated, and a paragraph on what the model would do differently.
  • A failure hypothesis. Pick an agent product you’ve watched fail at something specific. Diagnose it against Major Problems — which problem is it losing to, what’s the evidence, and what’s the cheapest intervention that would show up in an eval? A falsifiable diagnosis beats a feature wishlist.

A review (a weekend)

Critique forces standards — you can’t call a tool description weak until you can say what strong looks like. Three targets:

  • An agent framework. Take a popular open-source agent framework and review its loop against this hub: where does state live, how do tool errors reach the model, what happens at context pressure, what does it cache? Praise what’s right; be specific about what isn’t and what it costs users.
  • A published eval. Take a public agent benchmark or a vendor’s “our agent scores X” claim and review the methodology with Evals: task realism, grading validity, variance handling, contamination risk. Say what the number does and doesn’t license you to believe.
  • A trace teardown. Capture a real trajectory from any agent you use — a coding assistant, a research tool — and annotate it turn by turn: where the context got polluted, which tool result taught nothing, where the doom loop began, which single change would have saved the run. This is the field’s core skill, practiced in public.

A prototype (a weekend or two)

If you did the Apply-its, you’re closer than you think — they were designed as fragments of exactly these:

  • Grow the mini-agent. Your Agent Loop agent plus sharpened tools plus your ten-task eval is already a system. Push it to genuinely useful on one narrow task — answering questions about one real codebase, say — with a measured pass rate, a cost per task, and a README that states both.
  • An MCP server for a tool you actually use. Wrap something real — your notes app, your time tracker, an internal API — as an MCP server, designed model-first: consolidated operations, teaching errors, distillate returns, risk-gated writes. Working code that any agent can connect to is the field’s most portable proof of skill.
  • An eval harness for an agent you already use. Fifteen real tasks, programmatic checks where possible, a calibrated judge rubric where not, three runs per task, and a one-page report of what you found. Quietly the most employable artifact on this list.

Then show someone

Send it to a colleague, post it where practitioners argue, or put the repo up publicly. An audience — even one reader — raises the quality bar in a way private work never does, and this field is unusually generous with feedback: it’s young enough that a well-argued review or a clean small prototype gets read. Understanding you’ve defended in public is the kind that stays.