AI agent development is a young enough category that pricing, deliverables, and even vocabulary vary widely from one vendor to the next. That variance is expensive if you are the buyer. It makes it hard to compare proposals, hard to know what a fair timeline is, and hard to tell whether a delayed pilot is normal or a warning sign.
This piece describes what a corporate team should expect from an AI agent development engagement: what work happens in each phase, what artifacts get delivered, what falls to the internal team, and what the cost drivers actually are. It is written to help you write a better RFP, not to sell you one particular way of working.
Phase one: discovery and scoping
The first two to three weeks are almost entirely non-technical. A serious development partner interviews the people who currently do the work, reads real examples of that work in the systems where it lives, and writes a scope document that describes the agent as if it were an employee: the role, the tools it can use, the decisions it is allowed to make on its own, the decisions that require a human, and the definition of a good outcome.
The single most important artifact from this phase is a list of failure modes. What does this agent do when a tool call times out. When it receives an ambiguous instruction. When a downstream system rejects its write. When it produces an output the human reviewer disagrees with. If the scope does not enumerate these cases, the build will discover them at runtime and the cost of fixing them will land on the client.
Phase two: design and build
As an illustrative planning range, design and build for a first single-workflow agent commonly runs four to eight weeks, though real timelines depend on scope, integration surface, and internal review cadence. The output is running software: an orchestrated agent that reads the required inputs, calls the required tools, produces the required outputs, and logs every step in a form a human can review. It also includes the supporting scaffolding that people underestimate: credential management, retry logic, rate-limit handling, prompt version control, and a small internal admin surface where operators can see what the agent is doing and pause it if they need to.
Build partners who cut corners on that scaffolding can produce agents that look impressive in the demo and are difficult to operate afterward. Scaffolding is a meaningful share of the real build effort. If a proposal is unusually cheap, this is often the line item that was omitted.
Phase three: evaluation and human-in-the-loop
Before an agent runs on real work, it should be evaluated against a written set of cases derived from history. Those cases are graded manually by a subject matter expert, not by a language model grading itself. The grades become a baseline. When a prompt, model, or tool changes, the same cases are re-run and the grades are compared. Regressions have to be explained before the change ships.
Human-in-the-loop is enforced at the orchestration layer, not in a prompt. High-stakes actions such as sending external email, writing to a financial system, or publishing customer-facing content are gated behind an approval queue. Lower-stakes actions run and surface in a review queue after the fact. The agent cannot skip either checkpoint even if it decides it should. This is not a philosophical preference. It is what turns a demo into a production system.
Phase four: launch and supervised operation
Plan for a supervised early operating period after launch. A reasonable pattern is to have an operator on the client side review the queue on a regular cadence, approve or reject the flagged actions, and file any surprises against the failure-mode list. The development partner and that operator run recurring reviews to triage issues, tune prompts, and expand or tighten scope as appropriate; the exact frequency depends on volume and risk.
By the end of that period, the agent has either earned a wider scope or been narrowed. Both outcomes are acceptable. What is not acceptable is a launch with no supervision plan, no operator, and no scheduled review. Agents that ship without those three things end up producing a slow drip of small errors nobody catches until the aggregate becomes a problem.
Integrations, security, and cost drivers
Integration effort is a significant cost consideration in agent projects, not an afterthought. Connecting an agent to a CRM, a ticketing system, a document store, and email can take longer than writing the agent logic itself, especially when least-privilege credentials and audit logging are required. Ask vendors specifically how they scope integrations and where they expect to hit friction inside your stack.
Model and infrastructure spend is a separate cost line to model against expected volume. At higher volumes, per-step model choice matters: a cheaper model for routine classification and a more capable model for the harder judgment calls is a common pattern. A good partner will show a per-step cost model against your projected workload, not just a monthly estimate.
What you own at the end
At the end of a well-run engagement, you own three things. The agent itself, as source code you can read, host, and modify. The evaluation set, so you can regression-test any future change. And the operating documentation your team needs to run the agent without the vendor in the room, including runbooks for the most common failure modes.
If any of those three is missing, you are renting rather than owning. That may be an acceptable trade-off for a first pilot, but it should be a conscious decision, not the default that emerges from an engagement that never quite handed off.
Talk to the NU HAUS AI agents practice.
We consult on and build AI agents for corporate teams. Start with our AI agent consulting & development overview, or start a project.