What to refuse first

The hardest part of a first AI system is not choosing what to build. It is choosing what to leave out, because the instinct in every scoping session is to add. Someone points out an adjacent workflow, someone else notes that the data is right there, and a four-week build becomes a platform nobody can finish.

A first system has one job: prove the layer works, in production, against real data, with a named owner. Everything that does not serve that job is a candidate for refusal.

Refuse these in the first build

• Anything where the correct answer is genuinely contested inside the business. If two managers would disagree about the right outcome, an agent cannot be judged and will not be trusted.
• Anything that writes to a system of record with no reversal path. Irreversible first actions are how pilots lose their sponsor.
• Anything that depends on data you do not yet have in a queryable form. A first system should not be blocked on a data migration.
• Anything customer-facing where the failure is public. Earn that surface after the internal one works.
• Anything that requires three teams to agree on a schema before a line of code is written.

What to pick instead

Pick a workflow that is high-volume, low-variance, internally owned, and currently done by a person who can describe exactly what good looks like. That last part is the real filter. If nobody can articulate the rule they are applying, you are not automating a process, you are attempting to discover one, and those are different projects with different budgets.

If nobody in the room can describe what a correct output looks like in one sentence, you are not scoping an AI system. You are outsourcing a decision nobody has made.

Fix the scope in writing

Write down the one metric the system exists to move, the exact point a human takes over, the systems it may read from, and the systems it may write to. Four lines. Anything not on that list is out of scope by default, and adding to it is a decision with a cost, not a favour.

Handle the expansion request properly

You will be asked to extend the scope mid-build, usually by someone senior, usually with a good reason. The answer is not no. The answer is that it goes on the list for the second system, and that the first one ships on the date it was scoped for. This is easier to hold if you have said in advance that the first system is deliberately small, that its purpose is to prove the layer, and that the backlog it generates is the real output of the exercise.

Teams that protect the first scope tend to ship three systems in a year. Teams that absorb every good idea into the first one tend to ship the first one late, if at all, and the difference is not talent or budget. It is whether somebody was willing to refuse things in week two.

This is not bureaucracy. It is the difference between a system that ships in six weeks and one that is still being discussed in six months, and the discipline that makes the second system easy to scope because the first one already proved the ground holds.