This article was originally published on the Dataiku medium publication data from the trenches.
It could be the first or the tenth time you've heard the word "agent" today but, either way, you've made it to this article. If you are looking to get more clarity on all this "agent talk," then you are in the right place. We will start by demystifying the concept of agents so we can then understand where and how they can be used to generate quantifiable value.
Given that 80% of companies have at least one division using AI per McKinsey, it is likely that you have or have been asked about the questions listed above. You probably also noticed that there isn't a real consensus around the topic and answers may vary based on people's backgrounds, industry, or what new agent article they read that week.
Without further ado, let's dive in.
An agent is one of the possible ways of leveraging the raw power of generative AI (GenAI), specifically large language models (LLMs) commoditized by the likes of OpenAI, Anthropic, Google, etc.
Typical agent use cases generate value by automating tasks that have traditionally resisted automation such as solving support tickets, resolving a policy claim, building a marketing campaign, or even answering challenging questions about your data.

A GenAI application qualifies as an agent if it is LLM-powered, exhibits some degree of reasoning and, when triggered, can complete a defined task using a specific set of tools.
Let's dive into the three core concepts of an agent: task, tools, and reasoning.
Any task has a beginning and an end, so does an agent's execution. All agent executions will start with an input trigger such as a chat message, image, email, alert, or signal that will inform the agent of the task at hand. All agent executions will at some point end with a final answer signaling the end of the task.
Tools are what separates agents from LLMs. LLMs are great for reasoning, but their knowledge is limited to the data that they were trained on. Tools give LLMs the option to interact with the outside world elements like the internet, internal corporate data, or email servers. Tools can be categorized in three different buckets:
Context fetchers (Read) Ex: Internet search, vector database search, dataset query/lookup
Persisting actions (Write) Ex: Append to dataset, send email, run procedure
Orchestration (Delegate) Ex: LLM, subagent, set of subagents, human
It is key to remember these categories as they will be needed for the agent identification framework in the following section.
And finally, reasoning, a crucial component of an agent. It gives the agent the ability to dynamically and iteratively choose the actions/tools that need to be taken to achieve the task at hand. If it was not for this reasoning, the task could not be fully automated and would require some level of human judgment or intervention to be completed.
All in all, if you have a GenAI application that has a clear task and that requires reasoning to efficiently use tools to solve a task… then you might just be looking at an agent!
In the world of agent systems, there is another popular type of application commonly known as workflows. Workflows are any predefined acyclical series of steps (ex; Do A, do B, and if A + B >50, do C).
A GenAI workflow can be used for:
Automating the application of sequential business rules.
Applying business logic to the output of an LLM call.
Or even chaining a series of LLM calls.

Workflows, albeit very valuable GenAI applications, are not in the scope of this article but still deserve a mention as they are intimately connected to agents. As a matter of fact, agents can use workflows as part of their execution and workflows can run an agent as part of their execution.
Now that we are comfortable with agents, their three concepts, what they are, and what they aren't, it is time to dive into the deep end and learn how to identify agent use cases in the wild!
To start off this exercise, you will need to first build up a list of as many processes/tasks that you, your team, the teams you work with, and the department and/or the company as a whole have. Don't worry, you do not need to build an exhaustive list!
To help build the list, here are a few prompting questions that can help. Think of tasks that:
Would take less time to validate than to do it from scratch.
Have resisted being automated due to the unstructured nature of the data (mainly text).
Are tasks repeated on a daily, weekly, or monthly basis and could be automated given a bit of common sense
Take a long time to complete given the space distribution of data owned by multiple people from various teams.
Rely heavily on subject matter expert(s) in your organization that can act as process bottlenecks given their limited availability.
Technically speaking, agents, given the right set of tools, can be delegated any task that can be done by only interacting with a computer, so you can be ambitious on the process/tasks to consider in this list.
Once you have a healthy list of processes/tasks, it is time to identify the ones that could be delegated to an agent. For this, we want to single out processes that involve a finite task, reasoning for decision making, and that require interacting with external systems through tools (yes, these are the three core agent components we detailed in the previous section).
Let's get started!
Counterintuitively, the first thing you will have to do is to completely forget that we are talking about agents and instead focus on something much more familiar… coworkers.
Meet Tim. Tim is a new intern who just joined your organization. Tim is smart and well-educated, but he does not know anything about your organization, its core business, its systems, or its processes. Tim also does not take initiatives when the context is too ambiguous. For each of the previously identified tasks, how would you explain the process/task to Tim?
Given the explanation you gave Tim, can he solve the task by following a predetermined set of steps (workflow) or will Tim require reasoning to choose the right company resources and tooling to accomplish the task? If the latter, the task you gave Tim is a good candidate use case to be delegated to an agent, but we are not done yet!
To confirm its agentic nature, the next step is to run this use case using the following Agent Identification Framework.
This Agent Identification Framework aims to qualify and define an agentic use case. After applying this framework, you will have clearly identified the following five characteristics that fully define an agent.
The Input/Trigger of the agent (what is the agent's starting point).
The Objective of the agent (what should come out of the agent).
The Scope of the agent (what are/aren't its responsibilities).
The exhaustive list of Tools the agent needs to use to achieve its goal.
The Playbook/Guidelines that the agent should follow.
This framework is a two-step process:
Step I: Identify and document a set of representative examples of agent runs.
Step II: We extract the five agent characteristics listed above.
To start with the exercise, we need to go back to Tim and identify a set of representative end-to-end examples of the task (typically three to five) that he would need to accomplish. For each example, we want to identify the step-by-step process that Tim would go through to successfully complete the task.
Each example description should contain the following three elements: input, output, and process.
Imagine you'll be on vacation for a week and you need to provide Tim with an email that has enough details to start on a given task without needing further assistance from you.
Describe the output state of the completed task including all the actions performed by Tim and the final output answer. Think of it again as an email that Tim would need to write back to you. It should contain enough information for you, coming back from your holiday, to validate that the task has been done, and done well.
List the set of Thought, Action, & Result that Tim needs to go through to complete the task, from the provided input all the way to the expected output state. Use the following guide to properly document each Thought, Action, and Result.
Thought: Given the current state (everything done so far), what would Tim's next best action be? Specify the reasoning behind it. For example:
I need to check my unread emails to see if anyone has contacted me.
I need to search the web as I need public information on the government's website.
Action: Explicitly define the next action needed including any specifications.
Open inbox and filter for unread emails in the last 30 days.
Call the Google search engine with the query "Top 5 enterprise agent building platforms."
Result: Describe the outcome of the action. This is the new information that Tim has to decide what the best next step is.
The final action of any task is to "end task" and return a final output message.
Business context and objective: Regional sales leaders want answers to their elaborate questions that should rely on data scattered across multiple internal information sources (SharePoint and Snowflake).
Example case #1
Input: (Text) What are the top five revenue-generating customers in the Americas region over the last three years?
Output: (Text) The top five customers in the Americas over the last three years are X, Y, Z, A, & B, in that order.
Process
Step 1:
Thought: The request requires me to leverage data at my disposal. I first need to list all the available tables and their schema descriptions to isolate the relevant tables.
Action: List accessible tables that can be leveraged from the "sales data schema" database.
Result: List of all sales tables and their schema's metadata.
Step 2:
Thought: From the available schemas, the table called product_sales in Snowflake — I will need to leverage the customer_id,year, and amount columns to answer the question, given we are in 2025.
Action
: Generate and run SQL query with input "Filter the product_sales for the region Americas and transaction between 2023 and 2025, group data by customer_id, and sum the revenue. Keep only the top five customer_id."
Result: Resulting summary table listing the five customers.
Step 3:
Thought: I know the answer to the user's question, I am ready to answer.
Action: End task.
Result: Answer the question with the retrieved answer.
Example case #2
Input: (Text) Hello, how are you?
Output: (Text) I am good, thank you, I am your AI Sales Assistant, is there anything I can help you with?
Process
Step 1:
Thought: The user query does not require any internal knowledge. I can reply directly and propose to be helpful.
Action: End task.
Result: Answer with generic helpful message.
Once enough examples have been provided to give a representative sample of the types of tasks the agent might have to tackle, it is time to wrap up the exercise with Step II!
Lucky for us, the input/trigger, objective (output state), and the scope have already been documented for us through the examples above.
The input/trigger can be inferred from all the example inputs documented above. Here the agent is triggered by the regional sales leaders submitting a question about their sales data.
The objective will be the combination of persistent actions (write tools) and the agent's response for all inputs. Here, the agent needs to leverage available sales data to answer all questions from the sales regional leader.
The scope of the agent is the set of tasks of the same nature as the ones documented above. In the case you identified edge-case tasks that were not part of the examples above, feel free to update Step I accordingly.
The remaining two elements to extract are the tools and agent's playbook/guide.
To extract the tools, go through all the Action elements in the examples and classify each as:
No tools needed: All the information is already known, nothing to do.
Tool is needed: Add/update the tool to the list, including:
Tool name (short and explicit)
Tool description (when to use the tool)
Tool input parameters (its signature)
Tool output (content and format)
Tool category (Read, Write, or Delegate)
Note: Make sure to consolidate tools together, as your agent probably used the same tool multiple times.
Tool needs clarification: An action is needed, but we don't have enough information to define the five descriptors of a single tool.
This means that the action is too complex and should be split into different tools or delegated all together to a subagent.
In the examples above, the final tools would be:

You now have an exhaustive list of tools (and possibly subagents) waiting to be built!
To define the playbook/guidelines of the agent, also known as the agent prompt, you will have to go through all of the Thought sections of your examples. For each thought, take note of all the logic based on external business knowledge and not inferred from either the previous tool call results or from common knowledge (i.e., internal business process logic, special naming conventions, specific personality, acronyms, etc).
You now have all the context and guidance needed by the agent ahead of each task ready to be added to the agent prompt!
If you've made it this far, congrats! You now know how to find and narrow down potential agents, rank them by their business value, and run them through the Identification framework on your own.
We learned what an agent was and what differentiated it from its counterpart agentic system: workflows. We learned how to build a shortlist of potential agent use cases and how to leverage the Agent Identification Framework to concretely define the scope, roles, and responsibilities of these agents.
Tags