Short answer: start from the outcome and the constraints, check whether an existing tool delivers them, and build an agent only for the gap that remains. Compare the whole process, including maintenance, permissions, and failure handling, not just the first demo.
A request like "I need a bot that organizes my tasks" already contains a solution. The outcome can be smaller: a clear list of open tasks with an owner and a date. Sometimes a saved filter in a system you already have is enough.
Write down what needs to happen, who uses the result, where the data comes from, and which actions require approval. The read-versus-write distinction matters even for a small process.
An illustration: a team wants an alert when a task is blocked. Before building an agent that searches conversations and updates tasks, you can check a blocked-by field and a built-in notification in the work management tool. If the system cannot detect the reason from a conversation, that may be the gap where AI adds value.
The example is a proposed process, not a client project. The test should use information that is allowed to be shared, and include a case where nothing changes or there is no answer.
An existing tool can save new code, but it also needs setup and a permissions check. A custom agent can work across systems and understand free text, but you need to define what it does when a source is unavailable, when the answer is unclear, or when the action already ran.
Alongside the outcome, check human work time, errors, duplicates, ease of fixing, and ongoing cost. Do not present demo build time as time saved at work. Record the time the agent spends only waiting as a separate line.
When an existing tool covers most of the path, you can keep the data and actions in it and add an agent for one focused step: summarizing a conversation, classifying a request, or suggesting the next step. That way you can test the addition without replacing the whole system.
In my public grok-bot-skills library, distill-need starts by identifying the need rather than sticking to the proposed solution. It is adapted from AdirD's melech-distill-need, with credit and license in the source. It is a useful decision framework, not proof that every agent or skill was tested in production.
Continue with the option that delivers the outcome with clear boundaries and maintenance you can hold. If an existing tool is enough, that is a good engineering decision. If a clear gap remains, you can define a small agent task with a success check and a way back.
In my post about the AI announcements wave, I described an MCP tool for Jira that looked impressive, and then I found that the plugin I already had was more convenient for my need. Since then, this is a useful question before building: what is missing in the current process, not which new tool can be added.
Start from the outcome and the constraints, check whether an existing tool delivers them, and build an agent only for the gap that remains. Compare the whole process, including maintenance, permissions, and failure handling, not just the first demo.
Define an outcome and test an existing tool on a real example. An agent is needed when a defined gap remains that the current path does not cover.
Check outcome, human work time, errors, duplicates, permissions, maintenance, and ongoing cost. Waiting time is recorded separately.
Often it is enough to add an agent for one focused step and keep the data and actions in the existing system.
This is an English adaptation of my Hebrew guide. My professional background and selected work.