Open to opportunities in Developer Relations, Forward Deployed Engineering, DevOps/SRE, AI automation, and developer experience - especially roles where I can build, solve real engineering problems, communicate technical ideas, and work closely with developers and users. Also open to technical writing, engineering collaborations, and speaking opportunities around AI, DevOps, cloud, automation, and developer tooling.
Thank you for reading and for sharing these thoughtful questions Prompt injection is definitely an important challenge, especially when agents interact with external content and tools. It highlights why we need to think beyond the model itself and consider trust boundaries, permissions, and validation. On cost, I think cost per token still matters, but it doesn't tell the whole story. For agentic systems, cost per successful outcome can provide a more practical perspective, while tracking failed attempts and retry costs separately helps us understand where resources are being spent. I've started publishing the continuation blogs, expanding on the individual layers of agentic AI one by one. I hope they help build a clearer picture of how these systems work and the challenges involved. Really appreciate you taking the time to read and think deeply about the article!
This is an excellent catch. Thank you for taking the time to explain it so clearly! You're absolutely right: a successful tool call doesn't necessarily mean the result is complete enough to support a conclusion. Pagination, truncated output, and incomplete evidence can easily lead an agent to make an incorrect decision while believing it has the full picture. Your suggestion about returned_count, has_more or a continuation token, and a truncation indicator helped me think about structured tool results more carefully. I've updated the blog to incorporate this distinction between execution success and result completeness. I especially like your idea of testing with a decisive error just beyond the first page. It turns the concept into something measurable: we can verify whether the agent retrieves the additional evidence instead of prematurely concluding that everything is fine. This is exactly the kind of feedback that makes technical writing. Really appreciate it!
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!