Buyer guide · Updated October 2026
The first AI project decides whether there is a second. Pick a workflow that is frequent, observable and tolerant of a review step, and you get a measured win in weeks. Pick the most ambitious one and you get a demo. This is the method we use in discovery.
Get a scoped estimateDirect answer
The one that happens many times a week, has a clear trigger and a clear finished state, lives in systems you can connect, can tolerate a person reviewing exceptions, and whose cost today you can measure before you start. In most businesses that is inbound call or email intake, document processing into a system of record, or an internal question-answering workload, not the strategic project the leadership team is most excited about.
Score candidates on the six criteria below. Anything that scores low on observability or data readiness is a second project, however valuable it looks.
Score each candidate workflow from 1 to 5 on every row. A good first project scores 4 or 5 on frequency, observability and review tolerance, and at least 3 everywhere else. One low score on data readiness or system access is usually disqualifying for a first project; it is a fix-the-process project instead.
| Criterion | Question to ask | Scores high when |
|---|---|---|
| Frequency | How many times a week does this happen? | Dozens or more. Enough volume to measure and to justify the build. |
| Clear boundaries | Is there one trigger and one finished state everyone agrees on? | An email arrives, a record is created. A call comes in, an appointment is booked. |
| Observability | Can we count it today, before any AI? | You can state the current volume, time per item and error rate from existing data. |
| Review tolerance | Can a person check exceptions without defeating the purpose? | Exceptions are a minority and a reviewer can clear them in a queue. |
| Data readiness | Do the systems agree about the facts the workflow depends on? | One source of truth for customers, prices, schedules or status. |
| System access | Can we connect to the systems through supported APIs? | Modern SaaS with documented APIs and an admin who can grant access. |
The reason to insist on observability is that it lets you measure the result honestly. Before the build starts, record the current state of the workflow from data you already have. Four numbers are usually enough, and they become the launch criteria.
| Measure | Call intake example | Document intake example |
|---|---|---|
| Volume | Calls per week, by hour of day | Documents per week, by type |
| Coverage or straight-through rate | Share of calls answered within the ring target | Share of documents posted without human touch |
| Time | Minutes of office time per booking | Hours from receipt to posting |
| Errors and exceptions | Missed calls, double bookings, callbacks | Rejected postings, duplicate records, corrections |
A first version should take the workflow from trigger to finished state for the common case, with every exception routed to a person. It should not handle every variant. The test is: if the agent handled only the most common seventy percent of cases end to end and sent the rest to the queue, would the team notice the difference in their week? If yes, that is the scope.
Three things belong in every first version regardless of workflow: a review queue the team will actually use, logging of every input, retrieved source and action, and a way to turn the agent off without turning off the business. Autonomy expands from evidence after launch; it is not a launch feature.
HummingAgent discovery starts at $2,500 and takes the candidates through this method with your team. It produces the scored shortlist, the workflow map for the chosen one (trigger, people, decisions, systems, exceptions, baseline), the architecture including where it runs and which actions need a person, and a scoped estimate with operating costs itemized. The fee is credited against the build if you proceed. Some teams use discovery alone to decide the first project is a process fix, which is a good outcome.
Usually not. The biggest payoff is normally in the most complex workflow, which has the most systems, the least clean data and the highest cost of error. Start with a frequent, observable workflow that can be measured in weeks; the credibility it buys is what gets the bigger project approved.
Five to ten candidates is enough. Have the people who do the work nominate them, not only leadership; the operators know which steps are repetitive and which systems disagree.
Then the first project is a data or process fix, not an AI build, and knowing that before spending on a build is the point of the exercise. Common first fixes are agreeing a source of truth for customer data and getting API access to a system that only has exports today.
Timelines are set at discovery from the scope, integration access and your team's availability for testing. A workflow that scores well on the six criteria is scoped to launch in weeks, not quarters; if the honest estimate is quarters, the scope is too large for a first project.
No. One shipped, measured workflow teaches you more about what AI can do in your business than a strategy document, and it produces the identity, logging and integration foundations the next workflows reuse.
Yes. Score your candidates on the six criteria with the people who do the work, record the baseline for the top one, and you have most of what discovery produces. Bring that to a discovery call and the session goes straight to architecture and estimate.
We will score it with you, map the winner, and give you a scoped estimate. If the right first move is a process fix instead of a build, we will say so.
Schedule a discovery call