Discussion on "Giving the Chef Hands: Tools & Execution in Agentic AI"

Harshil Kumar Pindikuru · 2026-10-11T06:33:24.125Z

In the previous article, we explored the most important ingredient in our AI kitchen: the foundation model. We looked at tokens, context windows, inference, reasoning, model selection, and the distinc

The kitchen metaphor holds up better than most, and I would put the boundary exactly where you do, at reason versus hands. In practice the hard part comes after you give the model hands: what happens when one fails quietly, the tool returns a partial result or a stale read and the model narrates right over it. Does the series get into verifying the tool result before the model acts on it, or mostly the execution plumbing?

Thank you! That's actually a big part of why I'm writing this series.

My goal isn't to teach people how to build agents using a particular framework or SDK. I want readers to understand the architecture behind agentic AI: why each component exists, how the components interact, what can go wrong, and what trade-offs we make when designing these systems.

I believe that when you understand the underlying concepts, learning a framework becomes much easier because you're no longer just learning APIs; you understand what those APIs are helping you build.

And your point about silent failures, partial results, and stale reads is exactly the kind of thing I want readers to think about. Execution is only one part of the picture. Verifying results, handling failures, and deciding whether the agent has enough evidence to proceed are equally important design considerations.

The goal is to build that mental model first, so readers can reason about these systems regardless of which framework or SDK they eventually use. Thanks for raising this!

The structured tool-result example would benefit from an explicit completeness field. A log query can succeed while returning only the first page, and a command can run successfully while its captured output is truncated. A status of success alone does not tell the agent whether it has enough evidence to conclude that no other errors occurred.

I would return returned_count, a continuation token or has_more flag, and a truncation indicator where relevant. Then a fixture with the decisive error just beyond the first page can check whether the agent fetches more evidence instead of treating a partial result as the whole system state.

The update gives the reader a useful next decision: a successful partial result may justify continuing retrieval, but it does not justify a global conclusion. I would also show what happens when the next page cannot be fetched.

That case should leave the conclusion explicitly limited to the inspected evidence rather than converting the failed continuation into “no more errors.” It complements the beyond-first-page fixture by checking the agent’s behavior when completeness cannot be established at all.

thats a good point, i will add that too ...

An explicit incomplete state would make that addition easy to follow. The example can show returned_count greater than zero, has_more true, and a continuation failure together, then require an answer limited to the inspected records.

It is useful to keep the partial data available for diagnosis while preventing it from being relabelled as a complete result. That demonstrates the recovery behavior without suggesting that every tool error requires discarding all evidence.

Search Hashnode

Giving the Chef Hands: Tools & Execution in Agentic AI

Responses7