Agentic Workflows: From a Single Prompt to Multi-Step Tool Use

A single prompt is not an agent

The starting point of the agentic track I worked through was a useful distinction: a single LLM call that answers a question is not an agent, no matter how good the prompt is. An agent is a loop: the model decides an action, an action gets executed (often a tool call), the result comes back into context, and the model decides the next action, until it decides it's done. That loop is the whole ballgame.

The building blocks

• Tools: functions the model can choose to call, each described with a name, purpose, and argument schema (the same idea covered in my MCP post). The model doesn't execute anything itself; it emits a structured request, and your code runs it.
• State/context: everything the agent "remembers" across steps: prior tool results, the original goal, intermediate reasoning. Context window limits mean this has to be actively managed, not just left to grow.
• A control loop: the code that actually calls the model, executes whatever tool call comes back, feeds the result in, and decides when to stop (success, max steps reached, or an explicit "done" signal from the model).

Where it gets genuinely hard: not the happy path

Getting a single tool call to work correctly is not the hard part. The hard part is everything that happens when the plan doesn't survive contact with reality:

• A tool call fails or returns unexpected data. Does the agent retry, try a different tool, or surface the failure? This has to be designed deliberately, not left implicit.
• The model calls a tool with plausible-looking but wrong arguments. Validation needs to happen at the tool boundary, the same way you'd validate any external input, because from the tool's perspective, the model is external input.
• The loop needs a hard stop. Without an explicit max-iteration or cost budget, a confused agent will happily keep calling tools indefinitely.

That list reads a lot like the failure-mode list from distributed systems and API integration work: retries, idempotency, timeouts, bounded loops. That overlap is exactly why full-stack/backend experience transfers into agent engineering more directly than it might first appear.

Multi-step doesn't mean unstructured

The other thing I had to unlearn: "agentic" doesn't mean "let the model figure out everything." The more reliable agents I've built or studied constrain the model's choices at each step: a smaller, well-described tool set beats a large, loosely-described one, because the model's job at each step is a choice among options, not open-ended improvisation. Good tool design (scoped, single-purpose, clearly named) does more for reliability than a cleverer prompt.

Next

The natural follow-up question, how do you actually know if an agent is working well beyond "it seemed to work when I tried it," is evaluation, which I'm still early on. That's a topic for a future post once I have more than a first impression to share.