The hype cycle is over; the reality check is here. Most AI agent projects stall not because the models are bad, but because the scope is nonexistent. Vicky Lalwani’s latest breakdown on DEV.to argues that teams are skipping the boring work—defining the one job, the allowed actions, and the success metrics—before opening a builder. The result is expensive, untrustworthy bots that do nothing useful. If you haven’t answered these nine questions, you aren’t building an agent; you’re building a liability.

The 'Agent' Trap: Do You Actually Need One?

Lalwani draws a hard line between rule-based automation, chatbots, and true AI agents. If a fixed flow covers 90% of your cases, build the flow. Use AI only for the specific step requiring judgment. Agents are for triage, research, and multi-step admin where there is no clear finish line without reasoning. Calling a FAQ bot an 'agent' just to ride the buzzword wave is how you end up with a project that nobody trusts.

The Nine Questions That Save Your Project

The core of the framework is a checklist that forces specificity. Question 1 demands a single-sentence job description with a verb and a finish line. 'Help marketing' is useless; 'Score leads and post top ones to Slack by 9am' is actionable. Question 2 forces you to name the human who actually reads the output. If nobody is waiting for it, the agent dies in a month. Question 3 and 4 map the data inputs and, crucially, the write permissions. Read access is safe. Draft access is safe. Act access—sending emails, deleting records—requires explicit approval or tight limits.

Trust Is Built in the Logs, Not the Demo

The most underrated part of Lalwani’s scope is the fallback and logging strategy. What happens when the agent is unsure? It must ask a named person, park the item, or skip it with a log. Silent guessing is the primary failure mode. Furthermore, every run needs a record of inputs, actions, and skips. This isn’t just for debugging; it’s how you earn the right to move from 'draft mode' to 'act mode.' You don’t give an agent write access because it looks smart in a demo; you give it access because it’s been boringly reliable for weeks.

Key Takeaways

  • Define the job as a single sentence with a clear finish line; vague goals like 'help the team' kill projects.
  • Start every agent in draft mode. Only promote actions to 'act' (write access) after verified accuracy.
  • Identify the human owner who reads the output; if no one waits for the result, the agent will be ignored.
  • Log every run, including skipped actions and uncertainties, to build trust and enable debugging.
  • Measure success with a baseline before launch; you cannot claim time saved if you never measured time spent.

The Bottom Line

Stop trying to build a general-purpose brain. Build a boring, scoped tool that does one thing, asks when it’s confused, and leaves a paper trail. If your scope document is empty, your project is already dead.