In the previous post, we taught a model to read our documents. It could search a pile of files and answer from them, which was very useful.
But I ...
For further actions, you may consider blocking this person and/or reporting abuse
That executor boundary is the most important mental model. The model should emit a typed request; application code should validate arguments, apply authorization and policy, execute, then return an observed result. Showing that round trip alongside a failed validation example would make the difference between a suggestion and a side effect especially clear.
Love this! THanks for adding that!
I always love to show where things break because thats where the most learning happens.
Read-only tools never really exercise that boundary, so the validation layer looks optional. The next post builds a real agent with Strands Agents, which is exactly where that validate-authorize-execute guard rail belongs.
In short, the break is coming :)
That sounds like the right stress test. I’d make the boundary observable in the demo: log the model’s typed request, then show validation rejecting an unexpected argument before authorization ever runs. That makes it clear Strands is orchestrating the loop, while policy remains application-owned. Looking forward to the break.
Love that! Thanks Alex, adding it to my list! I might also showcase your comment, if thats ok!!! 🙂
The "model is the decision-maker, your code is the hands" line is the part most tutorials skip. I built a tool-calling loop last month and spent more time handling the model handing me garbage parameters — wrong types, missing required fields, calling a tool that doesn't exist — than I spent on the actual loop itself. The four-step diagram is clean; production is not. You need validation on every tool request before you execute anything, or the model will happily ask your
get_weatherfunction for coordinates like"sunny"and your code will crash.This is such a great addition, thank you for bringing the production view. The clean diagram is the happy path, and what you're describing is what it actually feels like once real requests start coming in.
This one's going straight on my list for the next episode. It's exactly the kind of where-it-breaks moment I'd rather show than skip past.
Great explanation of tool calling! I've been building free API services and found that proper error handling and documentation are key for developers trying to integrate these tools. The MCP protocol is really making this easier. Have you tried using it with weather or geolocation APIs?
Thanks! And you're right that error handling and docs are where the real work is once tools go past a demo.
Funny you ask, the weather demo in this post actually runs on a free geolocation and weather API, though I hand-wired it as a plain tool rather than through MCP. MCP itself was concept-only here. Building an actual MCP server is a whole topic I'm saving for later in the series.
Clear write-up, and the four-step loop is the right mental model.
One thing worth flagging for wherever the series goes next: every tool in every tool-calling tutorial is a read. Weather, date, price. Calling those twice is free.
The loop changes shape the moment a tool has an effect. send_email, create_charge, delete_file. Now a step can fail in a way where the model does not know whether it happened, because the call timed out or the response was lost on the way back. The loop's answer to "no result" is to try again, which is correct for a read and a duplicate for a write.
So an effectful tool needs two things a read does not: an idempotency key the caller generates before the first attempt, and a way to ask "did my earlier call land?" that is not another attempt. Neither fits neatly into the four steps, which is probably why most tutorials stop just before it.
Not a criticism of the post. It is the honest place to stop. Just worth knowing the cliff is there.
This is a great point to raise! It lines up well with where the series is headed.
The other thing I keep coming back to in my talks is the cost side of retrying. A plain API retry re-sends one request. In an agent, every step carries the whole conversation so far, so a retry deep in the loop is heavier than one at the start. The failure mode isn't just "did it run twice," it's also "this got expensive and slow the longer it ran." Two different reasons to be careful about blindly retrying.
Thanks for flagging the cliff, it is going on the list.
The line "your tool description is a prompt" is the one I'd highlight for anyone building past two or three tools. Learned this the hard way when we had a tool called search_documents that the model kept calling when it should've called get_user_profile, because both descriptions started with "Retrieves information about". The model was routing by description semantics more than by name. Rewrote both descriptions to lead with the specific entity type and the action direction, and the misrouting dropped to near zero.
This is the comment I'd want people to read twice.
"Routing by description semantics more than by name" is exactly it. You name a function
get_user_profileand assume the name does the work, but the model reads the description. Two tools both opening with "Retrieves information about" look identical to it.Your fix to lead with the specific entity and the action, not a generic verb. Near-zero misrouting makes the point better than my one line did. Thanks for sharing it.
Clear explainer on tool calling. Production agents also need enforceable rights and costs per call. That is the gap we fill with prepaid EUR read-only MCP for EU business checks and checkable receipts.
the read vs write split is the real fork here. with a read tool a retry is free, you just ask again. with a write tool a timeout does not tell you if the call landed before it failed to respond, so a naive retry can double book or double charge. the tutorials that stop at weather and date skip the part where you need an idempotency key before you let an agent call anything that changes state.