Hiring your first AI worker: a two-week field manual

Twenty deployments later, the same pattern shows up every time. The customers who get a workable AI worker into production in two weeks are not the ones with the cleanest stacks or the largest budgets. They are the ones who pick the right first workflow.

This is the manual we hand the CIO before kickoff. It costs nothing to read and saves a lot of expensive mistakes.

Day 1: pick the workflow that pays for itself

Most companies want to start with whatever feels strategically interesting. Renewal forecasting. Demand-gen email sequences. The CEO's special project. Those almost never work as first workflows, because the success criteria are fuzzy and the data dependencies are deep.

Pick something boring instead. Vendor invoice reconciliation. Ticket triage. Onboarding kit provisioning. Three properties matter:

• Someone is already doing it by hand, every day, for hours.
• The right answer can be checked against a system of record in under a minute.
• If the agent is wrong, a human can catch it before anything moves money or breaks a customer commitment.

If your candidate workflow meets all three, you can ship a live agent in two weeks. If it meets fewer than two, push it back and find another.

Day 2: name the people in the room

A pilot fails when nobody in the customer's org has a clear seat in the decision chain. Before we begin, we ask for four names:

• The operator. Whoever is doing this work today. They will review every output for the first week.
• The approver. Whoever signs off on the work today. They keep that signature; nothing ships without them.
• The owner. The director or VP whose KPI moves when this works. They get the weekly readout.
• The engineer. Whoever in your org will eventually maintain the workflow. They sit in every authoring session.

If you cannot fill all four seats in the first week, the workflow is not ready. Pick a smaller one.

Day 3 through 9: build the agent, in your stack, on your data

We do not build in a sandbox. We build on your real systems, with your real data, behind your real approver. This sounds risky and is mostly not. Production permissions are tightened down so the agent can read everything but write nothing during the build phase. By day four it is producing draft outputs against this week's actual work. By day seven the operator is reviewing every output and marking up the ones that are wrong.

Those markups are the spec. We add each one to the eval suite. By the end of week one, the workflow has thirty to fifty real cases pinned, and a clear list of where the model gets confused. The agent is rewritten to handle those cases. By day nine, the operator's markups stop accumulating.

Day 10 through 14: live, supervised, accountable

On day ten the agent gets write permissions, scoped to the smallest envelope that still does the work. Every write is logged, every approval recorded. The operator's job changes from doing the work to approving the work. The approver's job changes from approving the work to spot-checking the operator's approvals.

By day fourteen, the agent has cleared most of the queue with no human intervention. The exceptions, the cases where the agent paused and asked, are the most valuable artifact of the whole pilot. They tell you what is genuinely hard about your business. Those exceptions become the next agent.

What to expect after the pilot

The first workflow is the hard one. It costs more than it saves in the first month, breaks even in the second, and pays for the next twelve workflows by the end of the quarter. Every subsequent agent inherits the integrations, permissions, and audit infrastructure of the first. The compounding is real.

If you want to talk through your first workflow, write to mira@natoros.com. We answer within a day.