Building a demo agent takes an afternoon. Building one that operates against production systems, does not embarrass you, and still runs unattended six months later takes considerably longer — and almost none of the additional effort goes into prompting.
The distribution of work on a real agent project is consistently surprising to teams doing it for the first time. Roughly a tenth of the effort goes into the reasoning layer. The rest goes into tool design, permissions, evaluation infrastructure, exception handling, observability, and the organizational work of deciding who is accountable when the agent gets something wrong.
What follows is the sequence that tends to work, in the order it tends to work in. It assumes you have already established that an agent is the right tool — that the work is cross-system, variable, and ends in an action rather than an answer. If a deterministic workflow would do the job, build that instead; it will be cheaper and more reliable.
Step 1: Scope Down Until It Feels Too Small
The most common failure in agent projects is scope. "An agent for customer support" is not a scope. "An agent that investigates billing discrepancies for accounts on the standard plan, produces a diagnosis with supporting records, and either applies a credit under $100 or escalates" is a scope.
Write the specification as four explicit statements. The goal: what end state counts as success. The inputs: what triggers a run and what data arrives with it. The boundaries: what the agent may never do, what it must escalate, and how many actions or minutes it gets before stopping. The success measure: what fraction of cases it should complete correctly, measured how.
A useful test is whether you can describe what a wrong outcome looks like. If you cannot, you cannot evaluate the agent, which means you cannot safely deploy it. Vague goals produce agents that are impossible to grade and therefore impossible to trust.
Resist the urge to make the first agent impressive. The first one should be narrow, boring, and shippable in weeks. Its real purpose is to build the surrounding infrastructure — the tool layer, the eval harness, the logging — that every subsequent agent will reuse.
Step 2: Design the Tool Layer Before the Prompt
Tools are where production agents succeed or fail. Each tool is a function the agent can call, and the discipline that matters is treating them as a public API consumed by an unreliable client.
Give each tool a single clear purpose and a name that describes it unambiguously. An agent choosing between get_employee_record and search_employees will choose correctly; one choosing between lookup and fetch_data will not. Validate every input strictly and return structured errors that tell the agent what went wrong and what to try instead — "no record found for that ID; try searching by email" is far more useful than a 404.
Scope permissions per tool, not per agent. If the agent needs to read payroll data and write leave requests, those are two credentials with two permission sets, not one service account with both. This is what makes the blast radius of a mistake bounded and auditable.
Make write actions idempotent wherever the underlying system allows it. Agents retry. Without idempotency keys, a retried tool call becomes a duplicate leave request, a duplicate invoice, or a duplicate payment — and duplicates are the single most common production incident in early agent deployments.
Finally, keep the tool count low. An agent with eight well-designed tools outperforms one with forty overlapping ones, because tool selection is itself a reasoning task that degrades as options multiply.
Step 3: Build Guardrails as Code, Not Instructions
Anything you genuinely cannot allow must be enforced outside the model. Instructions in a system prompt are a strong preference, not a control. The enforcement layer sits between the agent and the tools and should implement four things.
Hard limits. Value thresholds, rate limits, and allowlists of records or accounts the agent may touch. These reject the call regardless of what the agent decided.
Confirmation gates. Actions above a defined threshold require explicit human approval before the tool executes. The agent prepares the action; a person authorizes it.
Action budgets. A maximum number of tool calls and a wall-clock timeout per run. Agents that get stuck do not fail loudly on their own — they loop. A budget converts an infinite loop into a clean escalation.
Output validation. Where the agent produces structured output that feeds another system, validate it against a schema and reject malformed results rather than passing them downstream.
Guardrails are also where sensitive-data policy gets implemented. Decide explicitly which fields the agent may retrieve, whether any are redacted before entering context, and what is retained in logs. In HR, payroll, and legal contexts these decisions carry regulatory weight, and they are far cheaper to design in than to retrofit — the same lesson organizations learned building out their broader AI HR tech stack.
Step 4: Build the Evaluation Harness Early
You cannot improve what you cannot measure, and agent quality is not measurable by trying a few examples in a chat window.
Assemble a test set of real cases — fifty is a reasonable start, drawn from historical tickets, transactions, or requests, with the correct outcome recorded for each. Include the hard ones deliberately: missing data, ambiguous requests, cases that should have been escalated rather than completed.
Then evaluate on three separate axes, because they fail independently. Outcome correctness: did the agent reach the right end state. Process validity: did it take a defensible path, or did it reach the right answer by accident. Boundary compliance: did it escalate when it should have, and did it stay within its permissions.
The third axis is the one teams skip and the one that predicts production incidents. An agent that completes 90% of cases correctly but also confidently completes 4% of the cases it was supposed to escalate is not ready, regardless of how good the headline number looks.
Run the harness on every change. Prompt edits, tool changes, and model upgrades all shift behavior in ways that are not locally predictable, and a regression suite is the only defense.
Step 5: Design the Human Path as a First-Class Feature
Every agent needs a well-designed escalation experience, and it should not be an afterthought bolted on at the end.
When an agent hands off, the human should receive the full picture: what was requested, what the agent checked, what it found, why it stopped, and what it recommends. A handoff that reads "unable to complete, please review" wastes the investigation the agent already performed and trains reviewers to ignore the system.
The review interface should also make correction cheap and capture it. When a reviewer overrides the agent, the reason for the override is the highest-value training signal you will ever collect. Systems that discard it plateau; systems that route it back into evaluation improve.
Set reviewer expectations honestly. During the assisted phase, reviewing agent output takes about as long as doing the work — the payoff comes later, when the completion rate justifies raising the autonomy level. Teams that are promised immediate time savings and do not get them disengage, and reviewer disengagement is the quiet killer of agent programs.
Step 6: Roll Out in Stages
Shadow mode first. The agent runs on live cases, produces its output, and nobody sees it except the evaluation team. Compare against what humans actually did. This costs nothing operationally and surfaces the failure modes your test set missed.
Then assisted mode, where the agent's output reaches the human reviewer and every action requires approval. Run this until the approval rate is high and stable — not until the calendar says it is time.
Then supervised mode with thresholds, where routine cases complete automatically and anything above a defined boundary escalates. Start the threshold conservatively low and raise it based on measured error rates, not confidence.
Instrument everything throughout. Every run should log the trigger, the plan, every tool call and result, the final action, and any human intervention. When something goes wrong — and it will — the difference between a two-hour fix and a two-week investigation is entirely whether that trace exists.
What This Costs, Realistically
A first production agent typically takes six to twelve weeks with a small team, and the majority of that is integration and evaluation work rather than AI development. The second one is substantially faster, because the tool layer, guardrail framework, and eval harness carry over. That reuse is why the choice of first use case matters more for infrastructure reasons than for its own return.
It is also why building on an existing automation foundation shortens the path considerably. Organizations that already have clean system integrations and documented processes from earlier HR automation work start several steps ahead, because the hardest prerequisite — reliable, permissioned access to systems of record — is already solved.
If you are scoping a first agent and want a second opinion on whether the use case is well-chosen, the Workisy team builds production AI agents against real operational systems and is glad to review your scope before you commit engineering time to it.
