Who to Hire First for an Agent Product

The instinct is to hire someone who can do what you do, so there is more of it. That helps only if your constraint is engineering throughput, and in agent products it usually is not. The constraint is more often domain judgement, or the time you are spending on support and delivery.

Work out what actually blocks you for a fortnight before writing a job description. If the blocker is that every build needs decisions only a practitioner can make, another engineer will sit idle waiting for you to answer questions.

This is also the cheapest mistake to avoid. A wrong first hire in a small company costs months of salary and considerably more in attention, and it usually becomes obvious within weeks to everyone except the person who made the decision.

Very little of the work is model work. The day is integrations, schema design, error handling, retries, tracing, and the slow accumulation of eval cases. It is closer to careful backend engineering against unreliable dependencies than to machine learning.

So the skills that predict success are ordinary and specific: comfort with APIs that behave badly, discipline about logging, willingness to read traces rather than guess, and taste in deciding what should be code rather than prompt.

Screen for that rather than for model expertise. A candidate who has debugged a flaky third-party integration end to end is better prepared than one who has fine-tuned a model, because the former is what the job consists of.