# Choose an AI tool by the bottleneck, not the demo

A small builder picks an AI tool after naming one repeated task, its source records, its reviewer and its failure path. The right tool fits the workflow you already run, limits access, exports usable records and holds output for human approval. A polished demo counts for less than ownership, traceability and what happens when the tool stops.

## What do you decide before looking at tools?

Which bottleneck gets the attention. "We need AI" is not a job. "Our service lead rewrites incomplete warranty submissions before review" is a job. So is "the principal turns scattered meeting notes into follow-up drafts after every prospect call."

Write out the current manual path: where the information starts, who corrects it, what decision follows and where the approved record lives. That page belongs in your [operating profile](/glossary/operating-profile/). If the team cannot agree on the current process, a new tool adds another inbox and fixes nothing.

### Which first tasks are easiest to control?

Text-heavy preparation work that already has a reviewer. Meeting summaries, intake organization, approved follow-up drafts and required-field checks are easier to test than estimating, schedule commitments or unsupervised buyer communication. The [AI for builders hub](/articles/ai-for-builders/) lays those use cases out one by one.

## Which criteria matter in a building company?

Judge the tool inside the real job. Load representative redacted inputs, including incomplete and conflicting ones. Check whether the output shows its source, marks uncertainty and follows the required format. Then inspect ownership and access, not only answer quality.

| Criterion | Question to ask | Builder test |
| --- | --- | --- |
| Task fit | Can it produce the required work product? | Run complete and incomplete examples |
| Source control | Can approved files stay apart from old drafts? | Feed it conflicting revisions |
| Permissions | Can access be limited by role and task? | Confirm what each user and connection can reach |
| Review | Can output wait for a named approver? | Test rejection and correction paths |
| Records | Can inputs, drafts and approvals be exported? | Retrieve a past item with its history |
| Failure | What happens when data or a connection is missing? | Disconnect a source and inspect the result |
| Exit | Can you leave with usable files? | Export instructions, templates and records |

## How do you compare a shortlist?

Same test packet, same scorecard, every tool. Do not bend the task to suit a demo. A tool that writes an impressive paragraph and loses the project identifier or the current revision is not fit for project work.

1. **Prepare a redacted test packet.** Ordinary, missing and conflicting inputs.

2. **Define acceptance checks.** Required fields, prohibited actions and source references.

3. **Run the same assignment.** Help no tool more than another.

4. **Measure review effort.** Factual corrections, formatting changes and unresolved questions.

5. **Inspect administration.** User roles, connected accounts, logs and export controls.

6. **Test failure.** Remove an attachment, break a connection, feed it an unknown status.

7. **Practice exit.** Export the records and finish the work by hand.

The [AI operations stage](/process/ai-operations/) runs this controlled test before a workflow becomes routine.

## How much integration does the first tool need?

Less than the demo suggests. A first workflow may need only a reviewed upload and a draft returned to an existing queue. That is safer and easier to inspect than wiring up email, project files, CRM, accounting and messaging on day one.

Add a connection when the workflow needs it and the owner understands the permissions. A meeting-note tool does not need payment records. A content drafting tool does not need the buyer database. A warranty intake tool needs the service submission and the project identity, not every contract folder.

### What do you own?

The account, the source files, the connected services, the instructions, the approved templates, the outputs and the runbook. Know how to remove a user, revoke a connection and export records. A consultant's login is never the only place the workflow exists.

The [builder data privacy article](/articles/ai-for-builders/ai-and-builder-data-privacy/) covers the questions to ask before you hand over project or buyer information.

## Who reviews and maintains the tool?

An operating owner and a subject reviewer. The operating owner maintains access, instructions and routing. The subject reviewer knows whether the output is right. In a small company one person may hold both roles. Write both down anyway.

Review output more closely when the source changes, the tool changes or the workflow grows. Keep a manual method. If the only person who understands the setup leaves, the runbook lets another responsible person recover the process without digging through old chats.

### How does an agent fleet fit without adding sprawl?

A fleet is a division of work, not a reason to buy more interfaces. AgAI Labs runs a fleet of Claude and Codex AI agents on research, drafting, building and checking. People set direction and review every output. Those roles share one controlled source and deliver into one existing review queue.

Start with the minimum roles. One agent drafts, a second checks fixed rules. Add a third only when it removes a visible failure or [handoff](/process/handoff/). The [AI agents explanation](/articles/ai-for-builders/ai-agents-explained-for-builders/) shows how to define each role.

## When do you reject a tool?

When it wants broad access for a narrow job, hides source history, cannot hold output for review or traps records in a format you cannot use. When the team would have to maintain a second copy of every project fact for the tool's benefit.

Reject a workflow, too, when it saves drafting effort and adds more correction, routing and administration than it removed. The article on [AI cost and time tradeoffs](/articles/ai-for-builders/ai-cost-and-time-tradeoffs/) shows how to see that full burden.

For the foundation, read the [AI for home builders guide](/guides/ai-for-home-builders/). Tool selection follows the same rule as everything else here: agents prepare and check, accountable people decide and approve.

### What else gets asked during an AI tool trial?

### Do we need a construction-specific AI tool?

Not necessarily. Test whether each candidate follows your sources, your controls and your review path for the chosen job.

### Should we connect every system at the start?

No. Start with the smallest access set that supports the task. Add connections after controlled testing.

### Who should own the account?

You. The AI account, its administrators, connected services, records and exports stay under the builder's control.

### How long should a tool be tested?

Until ordinary, incomplete, conflicting and failed cases have all been reviewed. Readiness comes from evidence in the workflow, not a fixed number of days.