What Happens in the Discovery Phase of an AI Agent Project?

The AI agent discovery phase is a short, structured stretch of work before any build. In it, a company decides one role for the agent, the data and tools that role may use, which actions need a human approval, and a success criterion the team can observe. It ends with a written scope, not a demo, and that scope is what keeps the project from drifting into a vague assistant nobody trusts.

Key takeaways

• Discovery turns a general wish to use AI into one named role with a clear start, finish and owner.
• Data sources are chosen by which one wins when two disagree, not by which one holds the most material.
• Approval boundaries sort every action into three groups: the agent does it alone, the agent proposes and a person approves, or the agent never touches it.
• A good success criterion can be checked in a sample of real work, against a baseline taken before launch.
• The output is a written scope the company owns, clear enough that a different team could build from it.

What is the AI agent discovery phase, and why does it come first?

Most agent projects that disappoint did not fail on technology. They failed because the first conversation was about a tool, and nobody wrote down what the agent was supposed to be responsible for. Discovery reverses the order. It starts with the work, the people who do it, the information they rely on and the mistakes that would hurt, and only then asks what should be built.

Think of it as the equivalent of hiring preparation. Before you recruit someone, you decide what the job is, what they can see, what they can sign off on and how you will know they are doing well. An agent that keeps its own memory, accounts and tools deserves the same preparation. If you want the plain-language definition of what you are scoping, What Is an AI Agent for Business? covers it.

Discovery is deliberately small. It is not a research programme or a company-wide AI strategy. It is enough work to make four decisions well, and to write them down so that building, testing and operating the agent all refer to the same document.

How does a discovery workshop run, step by step?

The format varies, but a useful workshop follows a stable sequence. Remote delivery works fine, as long as the right people join the same sessions and the working documents are shared.

• Name the pain. Each participant describes a recurring piece of work that is slow, inconsistent or dropped. Keep these concrete: a task, a trigger, a person.
• Shortlist candidate roles. Group the tasks into a handful of possible roles and discard anything that depends on judgment the company cannot yet describe.
• Choose one role. Pick the candidate with the clearest inputs, the clearest output and a person who will own the result.
• Walk through real examples. Take recent cases, including the awkward ones, and trace what information was used at each step.
• Map the sources and tools. List where each piece of information lives, who maintains it and what the agent would need to read or write.
• Draw the approval boundaries. Classify every action as autonomous, proposed or forbidden.
• Define the success criterion. Agree on what will be observed, how it is sampled and what the baseline is today.
• Write the scope and review it. The document is read aloud, corrected and signed off by the role owner before anything is built.

Who sits in the room matters more than how long it runs. You need the person who does the work today, the person accountable for its outcome, and someone who knows the systems and permissions. Leaving out the person who does the work is the most common mistake. They know which exceptions happen weekly and which rules exist only in someone's head.

Output one: which role will the agent actually take?

The first output is a role, written like a short job description. It states the purpose, the trigger that starts a piece of work, what a finished piece of work looks like, who receives it and who owns the outcome. For a detailed template, see Write a Job Description for Your First AI Agent Role.

The best first roles share a few traits. The work repeats often enough to learn from. The inputs are mostly written down somewhere. A mistake can be caught before it reaches a customer or a ledger. And one person can say whether the result was good. Triaging inbound requests, preparing a brief before a meeting or drafting a follow-up from existing notes fit this pattern. Anything that needs open-ended negotiation or sensitive judgment probably does not, yet.

Resist the urge to scope a broad assistant. A role named helps with operations is not a role. A role named prepares the order-status reply for the support desk, using the order system and the shipping notes, for a human to send, is. If you are unsure which task to pick, Your first AI workflow should be small enough to prove offers a way to narrow it.

The role section of the scope should also say what is out of scope. Listing what the agent will not do is as useful as listing what it will, because it stops the role from quietly growing during the build.

Output two: which data sources and tools does the role need?

The second output is a source and tool map. For each piece of information the role relies on, the map records where it lives, who maintains it, how fresh it must be, and whether the agent only reads it or may also change it. For each tool, it records the account the agent will use and the actions it can take.

The key question is not what data exists but which source is the source of truth. If the CRM says one thing and a spreadsheet says another, the agent needs a rule for which one wins, and a person needs to be responsible for keeping it correct. How to Give an AI Agent a Reliable Source of Truth goes deeper on this. Discovery is where these conflicts surface, which is far cheaper than finding them after the agent has repeated the wrong version to a customer.

A useful source and tool map answers these questions for every entry:

• What is it, and where does it live?
• Who owns it and who corrects it when it is wrong?
• How current does it need to be for this role?
• Is it read only, or does the role need to write to it?
• Does it contain personal, financial or confidential content that changes how it may be handled?
• Could it contain instructions written by outsiders, such as incoming emails or uploaded documents?

That last question is easy to forget. Text from outside the company can try to steer an agent, so the map should flag which sources are untrusted. The [OWASP Top 10 for LLM Applications](https://genai.owasp.org/llm-top-10/) is a good reference when you decide how to treat them.

The map also settles what the agent should remember between tasks and what it should look up fresh each time. Discovery does not need to design the memory in detail, but it should state which facts are stable, which expire, and who reviews them.

Output three: where do the approval boundaries sit?

The third output is the one that makes a business comfortable giving an agent real access. Every action the role could take is placed in one of three groups.

• Autonomous: low-risk, reversible actions the agent may take on its own, such as reading a record or preparing a draft.
• Proposed: actions the agent prepares and a named person approves, such as sending a message to a customer or changing a field in the CRM.
• Forbidden: actions the agent must never take, regardless of instructions, such as deleting records, moving money or changing permissions.

The test for each action is simple. If it goes wrong, who notices, how fast, and how hard is it to undo? Actions that are visible to outsiders, hard to reverse or tied to money belong in the proposed or forbidden groups until the agent has earned more trust. Writing to a system of record is a good example, and AI CRM updates: propose the change before writing it shows how that pattern works in practice.

Boundaries also translate into access. If an action is forbidden, the agent's account should not have the permission at all, rather than relying on an instruction to behave. Least privilege for AI agents: start with the smallest access explains the reasoning, and the [OWASP Authorization Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html) is a solid general reference for the principle.

Finally, each approval needs a named approver and a fallback. If the person who approves outgoing replies is away, who does it? A boundary without an approver is only a wish.

Output four: what is a success criterion you can observe?

The fourth output is the criterion that tells you whether the role is working. The test is whether someone who was not in the workshop could look at real work and say yes or no. Statements like the team feels more productive do not pass. Statements about what a reviewer will find in a sample of actual cases do.

A good criterion has four parts: what is observed, where the evidence lives, how often it is reviewed, and what the baseline is today. The baseline matters. Without a measurement of how the work is done before the agent, any later improvement is a story rather than a result. For more on measuring honestly, see How to measure AI workflow ROI without inflated claims.

Here is an illustrative scenario, not a real case. A distribution company chooses an order-status role for its support desk. The agent reads the order system and shipping notes, drafts a reply and hands it to a support person to send. During discovery the team agrees on this criterion:

• Each week, a reviewer samples drafted replies from the log.
• A draft passes if it cites the correct order record, states the correct status and needs no factual correction.
• The team also tracks how often drafts are edited heavily or discarded, and the time from request to first reply, both compared with the baseline measured during discovery.
• If correct drafts stop being the norm, the role is paused for review rather than left running.

Notice what this gives the company. It is checkable, it uses evidence the agent already produces, and it includes a trigger for pausing. That depends on logging the right things, which AI agent observability: what should you actually log? covers. The criterion can also seed the first test cases, as described in Build a golden test set for your AI workflow.

What does discovery deliver, and how does Be Human run it?

When discovery is done, you should hold a short written scope that contains the chosen role and what is out of scope, the source and tool map with owners, the three-group approval boundaries with named approvers, the success criterion with its baseline, and a list of open risks and assumptions. It should be readable by someone who joins the project later. It should also belong to the company, not to the team that wrote it, which keeps your options open if you later change builders or providers.

Be Human runs discovery as a first engagement with exactly this shape: one useful role, the memory and tools it needs, approval boundaries and an observable success criterion. The work is remote, in English or Portuguese, and the written scope is the deliverable. If the company continues, the same document guides the build and the managed operations that follow, such as monitoring, recurring evaluations, permission review and controlled improvements. If the company decides not to continue, the scope still stands as a plain record of what was decided.

Discovery is also the right moment to test whether the project is ready at all. If no one can own the outcome, or the source of truth is disputed and nobody will settle it, the honest result is to fix that first. Teams that want a broader frame for these choices may find The Seven Layers of Company AI Infrastructure, Explained useful.

Frequently asked questions

How long does the AI agent discovery phase take? It depends on how many people are involved and how clear the work already is, but it is meant to be short, often a small number of focused sessions plus time to write and review the scope. If it stretches on, the role is usually too broad and should be narrowed.

Do we need clean data before discovery starts? No. Discovery is where you find out which data matters and what state it is in. You do need someone who can describe where the information lives and who can decide which source wins when two conflict.

Who should own the outcome of the agent role? One named person on the business side, ideally the leader of the team whose work the agent supports. That person approves the scope, receives the review results and decides whether to widen or pause the role. Technical owners support them but should not replace them.

Can discovery change our mind about building an agent? Yes, and that is a valid result. Discovery may show that a simpler automation is enough, that the underlying process needs fixing first, or that the risk is not yet acceptable. Learning this before a build is the cheaper way to learn it.

Be Human editorial guidance. Examples are illustrative unless explicitly attributed. Sources provide background; implementation choices depend on your workflow.