A framework for building AI tools

When people decide to build an AI-powered tool, the first instinct is usually to open a chat window and start describing an architecture: what should call what, which pieces should be automated, what the interface should look like. That instinct produces systems fast, but it also produces the wrong systems more often than it should. The fix is not a better prompt. It is a change in order. Architecture should be the last thing you plan, not the first.

Start with the problem, not the tool

Before naming a single feature, write one paragraph that states the outcome you are trying to produce, who it is for, and what “done” looks like. If you cannot write that paragraph, you are not ready to design anything yet, no matter how clear the technology choice feels.

This matters because “I want to use AI to help with X” is not a problem statement. It is a solution looking for a justification. A real problem statement names a specific, checkable result: “Every new customer request should be answered or routed to the right person within one business day” is a problem statement. “Let’s build an AI ticket assistant” is not.

Find where the pain actually is

A single problem statement usually hides several distinct pain points, and they rarely have the same shape. Break the statement apart and ask, plainly, where time is currently lost, where mistakes creep in, and where a person is doing something repetitive that does not require much thought. Write these down as a list, not a paragraph. Some items on that list will turn out to be about missing information, others about inconsistent judgment, others about pure manual labor. Treating them as one undifferentiated blob is how a project ends up solving the easy 20 percent and ignoring the part that was actually costing the most time.

Sort each pain point into rules or judgment

This is the step people skip, and it is the one that matters most. For every pain point on your list, decide which of two buckets it belongs in.

Some pain points can be fully systemized: if a request contains a specific keyword, route it to a specific folder; if an invoice is over a fixed dollar amount, flag it for a second signature. These are deterministic. They do not need a language model at all — they need a rule, a filter, or a line of plain code, and adding AI to them only adds cost and unpredictability.

Other pain points genuinely require judgment: deciding whether a customer’s tone signals they are about to churn, or whether a paragraph of loose meeting notes actually contains a commitment someone made. AI is well suited to this kind of work, but only if you hand it clear criteria to judge against rather than leaving it to guess at your intent. “Decide if this is urgent” is vague. “Mark it urgent if the customer mentions a service outage, a billing error over $200, or uses the words ‘cancel’ or ‘refund’” is a judgment call with a fence around it, and that fence is what makes the AI’s output consistent enough to trust.

Only now, design the workflow

With your pain points sorted, trace the actual path information takes: where it originates — an inbox, a form, a shared document, a recorded call — through each processing step, to the point where a result is produced. At each step, decide explicitly whether a human needs to check the output before it moves forward, or whether it is safe to let it run unattended. This is also the point where you finally get to hand things to AI or a coding agent for technical design, because by now the rules are fixed, the judgment boundaries are written down, and the agent is filling in a well-scoped structure instead of guessing at the whole problem from a blank page.

A worked example: sorting a shared support inbox

Suppose the problem statement is: “Every message in the team’s shared support inbox should be categorized and assigned to the right person within fifteen minutes, without anyone re-reading messages that were already handled.” Breaking it down, the pain points are: messages sit unread because nobody owns triage, duplicate replies get sent because two people answer the same message, and urgent issues get buried under routine questions.

Some of this sorts into fixed rules: messages from a known billing-system address always route to billing, and a message is marked duplicate if a reply already exists in the thread. Other parts need judgment: whether a vaguely worded message counts as urgent. You give the AI a short prescribed checklist — mentions of outages, refund requests, or repeated contact within 24 hours count as urgent — rather than asking it to eyeball the tone.

The resulting workflow: new messages arrive from the inbox, pass through the fixed routing rules first, then anything unresolved passes through the AI’s urgency check against your written criteria, and only borderline or high-stakes messages get flagged for a human to confirm before assignment. The architecture — what connects to what — falls out naturally once that much is settled.