Every enterprise we work with has a list of processes that “should be automated.” The list is usually long, ambitious, and completely unhelpful for deciding where to start. Scoping the first AI agent project is the single most consequential decision in an enterprise’s agent journey — get it right, and you build momentum; get it wrong, and you confirm every skeptic’s fears.
The goal of the first project isn’t to solve your biggest problem. It’s to prove that agents work in your environment, with your systems, your data, and your team. Everything else follows from that.
The scoping trap
Most organizations scope their first agent project in one of two ways, both wrong.
Too ambitious. “Let’s automate the entire customer onboarding journey.” This sounds impressive in a steering committee, but it touches six systems, three teams, and two regulatory frameworks. Twelve months later, the project is still in development, the budget is blown, and nobody can point to a result.
Too trivial. “Let’s have the agent answer FAQs from our knowledge base.” This ships in two weeks, and nobody cares. It doesn’t change any workflow, doesn’t save meaningful time, and doesn’t demonstrate anything that a search bar couldn’t do. The organization concludes that agents are a toy.
The sweet spot is a project that’s narrow enough to deliver quickly, but impactful enough that people notice.
Five criteria for a good first project
We evaluate candidate processes against five criteria. A good first project hits at least four.
1. High volume, low stakes
You want a process that runs frequently enough to generate visible impact, but where individual errors aren’t catastrophic. Processing 200 invoices a week? Good candidate. Approving regulatory filings? Not for your first project.
Volume matters because it provides the data to evaluate the agent’s performance quickly. If the process runs twice a month, you won’t know if the agent works for six months. If it runs 50 times a day, you’ll know within a week.
Low stakes matters because the first project needs room to learn. The agent will make mistakes — every agent does in the early weeks. Those mistakes need to be correctable, not career-ending.
2. Clear inputs and outputs
The process should have a well-defined trigger and a well-defined result. An email arrives, and a ticket gets created with the right fields populated. A document is uploaded, and the relevant data gets extracted into a structured format. A form is submitted, and the right team gets notified with the right context.
Avoid processes where the definition of “done” is subjective or requires extensive domain judgment to evaluate. You want to be able to look at the agent’s output and quickly determine: correct or incorrect.
3. Existing pain that people feel
The best first project is one where the team already knows the process is broken. They’ve complained about it. They’ve asked for help. They spend hours on it that they know could be better spent elsewhere.
This matters for two reasons. First, it makes the business case obvious — you don’t need a slide deck to explain why automating something that everyone hates is worthwhile. Second, it gives you built-in champions. The people suffering through the manual process will root for the agent to succeed.
If you have to convince people that a process is worth automating, it’s not the right first project.
4. A single system of record
The ideal first project reads from and writes to one primary system — your CRM, your ticketing tool, your document management platform. It might reference other systems, but the core workflow lives in one place.
Multi-system orchestration is powerful, and you’ll get there. But for the first project, every additional integration doubles the complexity, the testing surface, and the number of teams that need to be involved. Start with one system, prove the value, then expand.
5. A willing team
You need a team that’s open to working with the agent — not enthusiastic (that’s a bonus), but at least willing. A team that’s been burned by failed automation before, or that’s politically opposed to the initiative, will find ways to make any project fail regardless of the technology.
The change management work we discussed in our previous post matters here. The willing team becomes your pilot group, your feedback source, and eventually your internal advocates.
Common first projects that work
Based on what we’ve seen succeed, these patterns consistently make good first projects:
Email triage and routing. The agent reads incoming emails, classifies them by intent and urgency, extracts key information, and routes them to the right team or queue with a structured summary. High volume, clear success criteria, immediate time savings for whoever was doing it manually.
Document data extraction. Invoices, contracts, certificates, applications — the agent reads documents, pulls out structured fields, and populates your system of record. The team reviews a sample to validate quality. This works especially well because it’s tedious, error-prone when done manually, and the before/after is measurable.
Status update generation. The agent monitors a system — project tracker, support queue, pipeline dashboard — and generates periodic status summaries for stakeholders. Low risk, immediately useful, and it demonstrates the agent’s ability to understand context and communicate clearly.
Internal request processing. IT access requests, procurement approvals, HR queries — structured requests that follow a predictable pattern but currently require a human to read, interpret, and act on. The agent handles the routine cases and escalates the exceptions.
What to avoid for the first project
Anything customer-facing. Not because agents can’t handle it, but because the risk profile is wrong for a first project. External communication amplifies mistakes and raises the stakes unnecessarily. Start internal, build confidence, then go external.
Anything requiring real-time performance. If the process needs sub-second responses and can’t tolerate the occasional retry, it adds a layer of engineering complexity that distracts from the core goal of proving agent value.
Anything politically sensitive. If the process is the subject of an ongoing turf war, a pending reorganization, or a compliance audit, the agent project will get caught in crossfire that has nothing to do with agents.
Anything that requires changing the process first. If the team says “we need to standardize our process before we can automate it,” that’s a six-month detour before the agent project even starts. Pick a process that works today, even if it’s messy. Agents handle messy better than you’d expect.
Setting up for success
Once you’ve picked the project, three things set the stage for success:
Define success metrics before you build. “How will we know this worked?” should have a concrete answer before any code is written. Time saved per week. Error rate compared to manual processing. Percentage of cases handled without escalation. Pick two or three metrics, establish a baseline, and agree on what “good enough” looks like.
Set a time box. The first project should show results within four to six weeks. Not a polished, fully autonomous system — a working agent that handles the common cases, escalates the edge cases, and demonstrates measurable improvement. If the scope can’t fit in six weeks, it’s too big. Cut it down.
Plan the handoff from day one. Who monitors the agent after launch? Who reviews the escalations? Who decides when to expand the scope? These questions seem premature during scoping, but answering them early prevents the “successful pilot that nobody owns” failure mode.
After the first project
The first project is a foundation, not a destination. Its real deliverable isn’t the automated process — it’s the proof that agents work here, the team that knows how to work with them, and the playbook for the next project.
The second project can be more ambitious. You have production experience, calibrated expectations, and internal champions. The third project is where things accelerate — the pattern is established, the infrastructure is in place, and the organization knows what to expect.
But none of that happens if the first project doesn’t land. Pick something narrow, impactful, and achievable. Prove it works. Then grow from there.