Don't Build Agents for Everything: The Procurement Mindset for AI Use Cases
Key insights from AWS Community Day Bengaluru | July 11, 2026
Series: AWS Conference Tour (39 articles)
- …
- 39Don't Build Agents for Everything: The Procurement Mindset for AI Use Cases This article
I had a great opportunity to attend AWS Community Day, Bengaluru on 11th July 2026. The energy was outstanding, and while there were dozens of amazing presentations covering everything from cloud infrastructure to the latest in machine learning, one presentation dramatically changed my perspective on how we create with Artificial Intelligence.
The session was presented by Dhaval Nagar, AWS Serverless Hero. In his discussion he addressed a major elephant in the room with the current AI hype cycle. Let’s face it, we are in a period where every developer wants to put a "Agent" label on their product. But Dhaval addressed a key question: do we really need all these autonomous agents or are we overcomplicating things?
Below is an in-depth look at the session, broken down with a few of my own insights and real-world examples to make them digestible concepts:
The AI Hype vs. Reality
We’re at the stage now where it feels like everyone’s developing agents for everything. Look around the tech ecosystem today and every product demo includes an AI agent and every RFP requests “Agentic AI.”
But here’s the thing: This enthusiasm masks a brutal reality. Dhaval pointed to a disturbing Gartner data that more than 40% of agentic-AI projects will be discontinued by the end of 2027. Does that sound familiar? It’s the old loop of buying shiny new tech before you know if it genuinely solves a business issue.
The sector is also suffering from “agent washing”. Of the thousands of vendors that claim to provide agentic solutions, there are only about 130 actual agentic suppliers in the marketplace. The conclusion is as follows: The autonomous loop of an AI agent is certainly remarkable, but just because it’s impressive doesn’t imply it’s the right tool for your use case.
The Agentic Loop vs. The Workflow Pipeline
Why does this matter? Let’s open the hood. Dhaval nicely illustrated the distinction between 2 execution models: The Agentic Loop vs The Workflow Pipeline.
The Agentic Loop
Think of the Agentic Loop like bringing in a super creative, independent chef to your kitchen. You give them a general goal (“Make me a great dinner”) and they decide all the rest.
- How it works: The model goes through a cycle of Reason, Act and Observe.
- The Process: It takes context from memory, utilizes tools, gets a result, and reasons about what to do next.
- The Catch: The AI model itself decides how many “laps” or iterations are needed, only stopping when it believes the work is done.
- The Cost: It's model driven, and the path is selected at run-time, so you're burning tokens (and money) every single lap it takes.
The Workflow Pipeline
Now think of a fast food assembly line. It’s quite organized. You don’t need a master chef. You need several things done properly, in a certain order.
- How it works: This is a code-driven method with a narrow definition of the path.
- The Process: It utilizes AI to take inputs . Then it applies strict rule checks based on code . Then it uses AI again to make particular judgment calls . Then it finishes with a programmed outcome .
- The Benefit: It follows the same path every run, and the Large Language Model (LLM) is only applied when it really matters.
Either way you get a verdict. The difference is in how you get there, and just how much each lap costs you.
The Procurement Mindset
So you may be asking, how do we decide which one we use? Now here is where it gets interesting. Dhaval introduced what he calls “The Procurement Mindset.”
We as developers and cloud engineers are making these types of judgments everyday without even thinking about it. When we choose compute alternatives, we don’t just follow the latest trends, we consider the nature of the job.
- Virtual Machines: We use VMs when we want full control, have long-lived state, and are willing to patch ourselves.
- Containers: We choose these when we require portability, orchestrated workloads, and the capacity to scale per pod.
- Serverless Functions: We utilize these for event driven tasks with constrained runtimes to achieve zero idle costs.
We make these choices based on needs, not on hype or habit. Dhaval pointed out that choosing between an agent and a process is the same choice. First we need to establish the requirement then select the tool that fits. The agent surely can solve the problem but we must question whether the problem genuinely requires the autonomous loop. Or, might a workflow using AI in a surgical way accomplish the task faster, cheaper, and consistently every single time?
Real-World Example: KYC Document Validation
To put this in perspective, Dhaval took us through a classic use case: “Know-Your-Customer (KYC) document verification.
Imagine you are signing up for a new bank account or a stock-trading program. You submit a set of papers to be checked against a fixed set of rules. The system asks you to.
- Inputs: A PAN Card, an Aadhaar Card and Address Proof (such a utility bill).
- The Ruleset: “The rules are hard. PAN card and Aadhaar card must be there. The PAN has to be of a specified format (5 letters, 4 digits, 1 letter) and the Aadhaar has to pass the 12 digit Verhoeff checksum. In addition to this, the names must be uniform throughout all documents and the address evidence must not be older than 90 days.
The rules are the same for every candidate in this process. It is to be bounded, repeatable and must be strictly auditable. This is the sort of problem shape that should make you say to yourself, “Why would I use an agent for this?”
The Agent Way (Autonomous Loop)
If we toss this at an autonomous agent, using a model like GLM 5.2, the model will take control. In Dhaval’s sample run, the agent used tools to evaluate the checksum and date recency, considered the outputs, and then the agent realized the address proof was 120 days outdated.
- LLM Calls: It took me 5 questions to the model to figure this out.
- Tokens: That was 8,466 tokens.
- Latency: It took 31.5 seconds to complete.
In a modern web app, forcing a user to sit through 30+ seconds of a spinning loading spinner is a bad user experience. Furthermore, the agent’s logic for coming to this conclusion is completely unclear.
The Workflow Way (Fixed Control Flow)
Now, let’s give the process strategy a shot using Claude-haiku-4.5 on Amazon Bedrock. This approach uses a special extraction stage to handle input. LLMs process three documents in parallel to pull data out, the pulled data is fed into a code based rule engine.
The preset policy code immediately validates the PAN format, the Aadhaar checksum and the address status. The code will promptly indicate any rule failures, such as an address proof that is older than 90 days. The LLM is only employed as a "surgical" instrument in the end for semantic consistency.
- LLM Calls: This took only 4 calls.
- Tokens & Cost: A genuine production extraction of 4 example documents required 18938 input tokens and 1743 output tokens, and cost only $0.022122 in total.
- Latency: The modeled delay was reduced drastically to a mere 13.5 seconds.
So, long story short, we get an explicit rule trail for auditability, we cut latency and we save money by employing a code guided workflow.
Applying the Framework
So when do we know which one to use? Dhaval gave a wonderful 30 second framework on evaluating use cases based on three aspects, if the task is limited, its need for determinism and amount of requests.
- KYC Document Validation: The checks are fixed, approval needs strict determinism, and the volume is high. The decision? Use Workflow.
- Invoice Entry into an ERP: The fields are set, the audits are tight and the volume is big. The choice? Use a Work Flow .
- Support Triage Over Changing Policies: Customer issues are on a case-to-case basis. Some variation in the answer is acceptable. Volume is medium. The outcome? A fantastic place to put a Lean Agent.
Infrastructure Matters
Nor can we ignore the infrastructure required to run these systems.
A workflow is code, after all. Runs within the computing you already run today - whether it be a Lambda function, container or VM. It runs on the same deployment pipelines, the same monitoring and the same security models your team is already familiar to. It is straightforward to include as there is nothing new to operate.
Agents, however, normally require a run-time session. They have a long running loop of 'thinking'. They struggle against the normal request/response compute models that have hard time-outs and per-request pricing . Each session must have a sandboxed environment, including state, memory and observability. You either have to construct this sophisticated session-oriented runtime yourself, or pay a premium for it managed.
Key Takeaways
The key lessons I learned from the workshop were:
- Write the spec first: Always state your particular needs before you choose to “buy” or construct an agent.
- Default to workflows: Use the autonomous loop only when the problem is really needed.
- Mix code and AI: Combine surgical AI with deterministic code and you have a system that is fast, cheap, auditable, and predictable.
Conclusion
"Don't run Kubernetes to serve simple web application", was the ideal comparison Dhaval left us with at the conclusion of the day. That’s a good lesson to not utilize big, complicated, autonomous artificial intelligence systems for something basic, predictable programs can do.
AI is a fantastic tool, but it’s only a tool. With a procurement approach, we can design smarter, more efficient, and more dependable applications on AWS and farther.
About the Author
As an AWS Community Builder, I enjoy sharing the things I've learned through my own experiences and events, and I like to help others on their path. If you found this helpful or have any questions, don't hesitate to get in touch! 🚀
🔗 Connect with me on LinkedIn
References
Event: AWS Community Day Bengaluru
Speaker: Dhaval Nagar
Topic: Don't Build Agents for Everything: The Procurement Mindset for AI Use Cases
Date: July 11, 2026
Series: AWS Conference Tour (39 articles)
- …
- 39Don't Build Agents for Everything: The Procurement Mindset for AI Use Cases This article
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article