The First Agent to Deploy in a Company That Has None

The first agent an organization deploys shapes everything afterwards — how much latitude the next one gets, whether the funding continues, whether anyone trusts the category. Choosing it well is more consequential than building it well.

The right first choice is usually not the most valuable use case. It's the one most likely to succeed visibly.

The criteria

Bounded blast radius. A wrong action should be an inconvenience. This is the first filter and it eliminates most exciting candidates.

A mechanical check. Something that verifies correctness without a human deciding — otherwise you can't tell whether it's working, and you can't operate what you can't measure.

Complete inputs. Everything needed present in artifacts. Anything requiring unwritten context will fail in ways that get blamed on the technology.

An internal audience. Colleagues tolerate rough edges and give useful feedback. Customers don't and won't.

A clear before-and-after. Someone should be able to say "this used to take four hours a week and now it doesn't." Ambiguous benefits don't build the case for the next one.

Volume high enough to matter, low enough to watch. Enough that the value is real; few enough that you can read the outputs.

Good first candidates

Internal document processing. Extracting structured data from forms, invoices, or reports that someone currently rekeys. Checkable against a schema, internal, tedious, and the before-and-after is obvious.

Mechanical code migration. A framework upgrade or an API rename across many files. Verifiable per file, and the alternative is weeks of work nobody wants.

Test coverage for an under-tested module. Contract-driven, mutation-checkable, and the gap is visible.

Log and trace triage. Read-only, genuinely useful, and the failure mode is an unhelpful summary.

The internal tool nobody had time for. ✅ Frequently the best first project: something the team has wanted for a year that never cleared the bar. Low risk, visible gratitude, and it demonstrates the category's value without anyone having to be convinced.

⚠️ Bad first candidates

Anything customer-facing. A wrong answer to a customer is a company problem, and it will define the category internally for years.

Anything touching money. Same, with regulators.

The most valuable use case. It's usually the hardest, and failing at it first poisons the well.

Something requiring organizational change to adopt. You'll be fighting the change management and the technology simultaneously.

A general-purpose assistant. Unbounded, unmeasurable, and it fails by being unused rather than by being wrong — which is the hardest failure to learn from.

What to do alongside building it

The first project is also where you establish practices that are expensive to retrofit:

• Instrument from the start — runs, outcomes, cost, what a human would have done.
• Build the eval set, even small. It becomes the template.
• Put the tool dispatch behind a seam.
• Decide who owns quality, with a number.
• Write down what would count as success, before starting.

None of these slow the first project meaningfully, and each is much harder to add later.

💡 The success that matters

Not the metric. Someone in the organization who wasn't involved saying it's useful.

That's what funds the second project and grants the next one more latitude. Which means visibility is a legitimate selection criterion — a smaller win people notice beats a larger one nobody sees.

The takeaway

Choose the first agent for likelihood of visible success rather than for value: bounded blast radius, a mechanical check, complete inputs, an internal audience, and a clear before-and-after. Avoid anything customer-facing, anything touching money, and the most valuable use case. Build the instrumentation and the eval set alongside it because they're the template for everything after. And optimize for someone uninvolved saying it's useful — that's what buys the next one.