On this page7 sections
This guide is how I find the first AI project worth building, and what it costs to build and to run.
The short version: I don't start with a tool. I start with one piece of work your team already does every week, where the result is easy to judge. Reading incoming documents. Preparing a project brief. Watching a set of sources for changes. Getting a handoff from one system into another without someone retyping it.
Where I look for the first project
I ask to see a normal week. Not the org chart, the actual work: what arrives, who touches it, where it goes, and what happens when something is missing.
Then I look for jobs with four qualities:
- A recognizable result. You can look at the output and say "yes, that's right" or "no, that's wrong" in a minute.
- Usable source material. The information the job needs exists and someone can grant access to it.
- A person who owns it. Someone already cares whether this job gets done well.
- A cost when it's late. A proposal that waits three days, a customer who asks twice, a report nobody has time to read.
I skip the most repetitive task by default. A slower, less frequent job that holds up a sale or a delivery is usually worth more.
| Kind of work | What an AI-assisted system can prepare | What a person still checks |
|---|---|---|
| Project intake and scoping | A structured brief from emails, documents and notes, with gaps flagged | Requirements, and anything that commits you to a price or a date |
| Research and monitoring | A summary of what changed across approved sources, tied to a question you care about | Whether the sources are relevant and the conclusions are supported |
| Document-heavy operations | Fields pulled out of documents, compared, exceptions flagged | Missing values, ambiguous matches, anything that changes a record |
| Content and campaign work | Drafts assembled from an approved brief, with required elements checked | Brand judgment, factual claims, and the decision to publish |
| Customer and project coordination | An update drafted from current records, routed to the next person | The right account, the current status, and the action's result |
Three ways to build it
There are three levels of complexity, and I use the simplest one that does the job.
Defined automation follows fixed rules. When a project is confirmed, create these onboarding tasks. No AI needed, and I'd argue against adding it.
AI inside a workflow uses a model for one step where language needs interpreting, while the route stays fixed. A messy email becomes a structured request. The workflow then does the predictable part.
An AI agent decides its own next step based on what it finds. Research is the classic case: the first document reveals a problem, and that changes the next question. Agents cost more to run and are harder to predict, so I reserve them for work that genuinely needs it.
Anthropic's engineering guidance draws the same line between workflows that follow predefined paths and agents that direct their own process, and it recommends adding complexity only when the task earns it. Building effective agents
Pick a project you can judge
I built this planner so you can pressure-test a candidate before committing to anything. Answer the five questions honestly, including "we haven't decided" where that's true.
Shape a useful first automation project
- Receive the input
- Interpret with AI
- Check the result
- Continue the workflow
Put AI inside a defined workflow
AI can interpret the language or documents. Keep the next steps explicit and check the proposed result before using it.
Your first pilot boundary
Keep the first pilot in draft or internal review. Verify the result before it becomes a customer promise or an authoritative record.
Agree this before the pilot
Use a representative test set. Agree acceptable results, review time, operating cost, stopping conditions, and the person who can release the next version.
Start with an illustrative document workflow. Your choices shape a project hypothesis and review boundary. No AI runs here, and the worksheet does not predict accuracy, cost, or time saved.
The planner gives you a design hypothesis and a boundary for a first pilot. It turns "let's automate intake" into something specific enough to design.
What a first project looks like, start to finish
Here's a fictional but typical one. A service business prepares project briefs from customer documents and meeting notes. Today a coordinator gathers the files, pulls out requirements, checks them against the current service list, and writes a handoff for review.
The first version I'd build collects the approved materials, drafts a structured brief, links each requirement to the document it came from, and lists the questions it couldn't answer. The team reviews that draft before it becomes a commitment.
The system needs more than a clever prompt: a rule for which project the documents belong to, a trusted source for the current service list, a fixed output shape, and a place for unfinished work to sit. If two documents disagree on a date, the brief shows both. It never quietly picks one.
Before launch I test five cases: a normal complete brief, a missing requirement, a conflict, an irrelevant attachment, and a request for something you don't sell. Reviewers check the content and the source links.
Once the brief is approved, a defined integration creates the delivery tasks and records a receipt for each one.
What it costs to build and to run
There are two bills. The build, and the monthly cost of keeping it running.
The build covers defining the process, preparing the sources, connecting the tools, designing the review step, testing, and a limited launch. The model call is a small part of that. For my own work, a connected system sits in an $8,000–$20,000+ planning range and a smaller, bounded automation in $1,000–$3,000; those are planning ranges, not an industry price. Project pricing
The running cost is where people get surprised. It includes platform subscriptions, model usage, and the human review time that remains. I model it from the actual workload: how often the job runs, how much material it reads, how many attempts need correcting.
One trap: assuming one run equals one billable unit. Zapier, for example, counts successful action steps as tasks and accounts for agent activity separately, so a single business event can consume several. Other providers do it differently. I check the plan you're on before projecting a monthly bill. Zapier usage accounting
I put both numbers in the proposal. If the running cost eats the saving, I'd rather we find out on paper.
Keeping a person in control
Two things keep an AI system trustworthy: the information it's allowed to read, and the actions it's allowed to take.
For information, I define which sources are approved and who maintains them. A newer upload isn't automatically newer policy. A draft price sheet shouldn't override the approved one just because it landed last. When the system can't support an answer from approved sources, it says so instead of guessing.
For actions, I separate preparing from doing. The system can research, draft and propose. A person approves anything that reaches a customer, moves money, changes access, or rewrites a record of truth. The software enforces that line. Telling a model to "be careful" is not a control.
The approval guide walks through exactly how that boundary is built. If you're still deciding whether the job needs an agent at all, the agent or automation guide sorts that out first.
Measure before you expand
I record the current process before replacing it: how long it takes, how often it's wrong, how often it's late. Then I run the new version on the same kind of work for a limited pilot and compare.
The measure that matters is accepted results, not impressive drafts. A system that produces ten drafts needing heavy repair hasn't saved anything. Time recovered is real only after you subtract review and correction.
I keep the test cases when we launch, because models, sources and business rules all change. Rerunning them tells us whether the system still does what it did.
Start with one weekly job where the result is easy to judge and someone already owns it. Build the simplest version that works, with a person approving anything that touches customers, money or records. Model the running cost from the real workload before projecting a saving, and measure accepted results, not impressive drafts.