AI Copilot Development: What It Costs Per Seat and Where It Stops

Most pages from an AI copilot development company describe features. Suggests, summarises, drafts. That tells you nothing about whether to spend the money, because the questions that decide it are what the thing costs per seat every month, how fast it has to respond, and what it has to score before a customer is allowed to see it.

So this is the version with those numbers in it. Per seat running cost at three rollout sizes with the arithmetic shown. The build broken into stages with hours. A latency budget, which is the constraint most proposals ignore. And four evaluation gates, each with a number attached.

Everything below is a planning assumption written out so you can substitute your own. Illustrative, not a claim about any particular project.

What a copilot is, and where it stops

A copilot sits inside a screen somebody is already using and offers help on the task in front of them. It suggests. A person accepts, edits or ignores. That acceptance step shapes the whole design.

Three things follow from it, and they shape the entire build.

The context is the product. A copilot that cannot see the record the user is looking at gives generic advice, and generic advice gets ignored within a week. Most of the engineering goes into assembling the right context for each suggestion, not into the model call.

Latency is a feature. A suggestion that arrives after the user has finished typing is worse than no suggestion, because it interrupts. More on the budget below.

The metric is acceptance, not accuracy. A copilot can be technically correct and still useless if people dismiss it. Acceptance rate is what you instrument on day one and what you report on afterwards.

And the boundary: a copilot does not act on its own. It drafts the email, the person sends it. It proposes the discount, the person applies it. The moment it sends or applies anything without a person, it has stopped being a copilot, which brings us to the decision that actually sets the budget.

Copilot or agent, and why the answer changes the budget

These two words get used interchangeably in sales material and they describe very different builds.

	Copilot	Agent
Trigger	A person, inside a screen	A goal, often on a schedule
Output	A suggestion	An action taken
Failure cost	Someone ignores it	Something changed that should not have
Needs rollback	No	Yes
Needs audit trail	For compliance only	Always
Unit of cost	Per seat	Per task
Typical first build	5 to 9 weeks	8 to 16 weeks

The rollback line is where the money is. A copilot suggests, so the worst case is a bad suggestion nobody takes. An agent writes to systems, so it needs idempotency, reversal and an approval path. Those three requirements are most of the gap between five weeks and sixteen. Custom AI agent development is a materially larger commitment and should be priced as one.

A practical test. Write down what happens when the thing is wrong. If the answer is "the user sees something unhelpful and moves on", build a copilot. If the answer involves the word "reverse", you are scoping an agent whether you meant to or not.

Most teams should build the copilot first. It puts the same retrieval and grounding work in place, it collects real acceptance data, and that data is what makes an agent safe to build later.

The build, stage by stage

Stage	Hours	What it covers
Discovery and context mapping	60 to 110	Which records, fields and documents a suggestion needs
Retrieval and grounding	90 to 160	Index, chunking, freshness, permissions
Suggestion surface in the UI	70 to 140	Inline, panel or both. Accept, edit, dismiss, undo
Evaluation set and scoring	60 to 120	Cases with known good answers, plus the scoring run
Guardrails and permissions	50 to 90	What it may see, per user, and what it must never say
Telemetry	30 to 60	Acceptance, edit distance, latency, dismissals

Work the middle of those ranges and the total lands near 520 hours. At two engineers that is roughly 7 weeks, which matches the 5 to 9 week band above.

Permissions are the stage that surprises people. A copilot inherits the user's access or it leaks. If your underlying systems have coarse permissions, the copilot exposes that immediately and in front of everyone. Budget the fix, or scope the copilot to data everyone can already see.

Put a number on the permissions stage so it is not the thing that slips. If a copilot serves 6 record types and each needs its access rule expressed in the retrieval layer, that is 6 rules to write and 6 to test, which at 4 to 7 hours a pair is 24 to 42 hours before anyone writes a prompt. Teams that treat this as configuration rather than engineering find it in week five.

Retrieval is the stage that decides quality. A suggestion grounded in the right three documents beats a suggestion from a larger model with the wrong context, every time. If a proposal spends more hours on prompting than on retrieval, it was priced from a demo.

What it costs to run, per seat

Copilots are rolled out to people, so model the seat rather than the task.

Planning assumptions: each active user triggers about 35 suggestions a working day, 22 working days a month, 2,500 input tokens of assembled context per suggestion and 200 output tokens, at a blended 3 USD per million input and 12 USD per million output. Substitute your provider's current rates.

Seats	Suggestions a month	Inference	Per seat
40	30,800	about 305 USD	about 7.60 USD
200	154,000	about 1,525 USD	about 7.60 USD
1,000	770,000	about 7,625 USD	about 7.60 USD

Work the first row through. 40 seats at 35 suggestions across 22 days is 30,800 calls. At 2,500 input tokens each that is 77 million input tokens, which at 3 USD per million is 231 USD. The 200 output tokens each give 6.16 million output tokens, at 12 USD per million that is 74 USD. Total 305 USD, so about 7.60 USD per seat per month.

Inference is close to linear. The other three costs are not.

Retrieval infrastructure is mostly fixed. A managed vector store for a mid sized corpus runs in the low hundreds a month whether you have 40 seats or 1,000, so per seat it falls sharply as you grow.

Context assembly is the line that quietly doubles the bill. If a suggestion needs 2,500 tokens of context today and someone adds two more source documents next quarter, it becomes 4,000 and your inference cost rises 60 percent with no feature change. Cap the context budget in code and alert when it is hit.

Human time on evaluation is fixed per release, not per seat. Budget a day a month for someone to review the scored run and the dismissal samples.

A reasonable planning figure for a 200 seat rollout is inference near 1,525 USD, retrieval a few hundred, and a day of review time. Anyone quoting a per seat price under a dollar has either a much smaller context budget than 2,500 tokens or has not measured it yet.

The latency budget nobody plans for

This is the section missing from almost every proposal, and it decides adoption more than quality does.

Surface	Budget	What happens past it
Inline suggestion as the user types	under 400 ms to first token	The user has typed past it. Suggestion is an interruption
Side panel, user asked	1 to 3 seconds	Tolerable if something appears immediately
Long summary on request	up to 10 seconds	Fine with a progress state and a partial stream

The budget drives the model choice, not the other way round. A larger model that answers in 1.2 seconds is the wrong model for an inline surface no matter how much better its output is. Teams discover this after they have built around the larger model, which is an expensive week.

Three things spend the budget: assembling the context, the round trip, and generation. Retrieval is usually the biggest and the most fixable. Cache the assembled context per record, stream the first token rather than waiting for the full response, and keep the inline surface on a smaller model with the larger one reserved for the panel.

The gates before a customer sees it

Four gates, each with a number. Agree them before the build, not after, because after the build every number becomes a negotiation.

Gate one, offline score. Run the evaluation set and score it. A copilot that cannot reach roughly 80 percent on cases you wrote yourself will not survive contact with real inputs. This gate is cheap and catches the worst problems.

Gate two, shadow mode. Generate suggestions and show them to nobody for two to three weeks. Sample and review. You are looking for the categories of wrong, not the rate.

Size the shadow sample properly rather than eyeballing it. At 200 seats and 35 suggestions a day you generate 7,000 a day, and reviewing 150 of them gives you a rate accurate to roughly plus or minus 4 points, which is enough to tell 12 percent from 28. Reviewing 20 tells you nothing and takes a fortnight to prove it.

Gate three, internal acceptance. Release to staff. A well tuned copilot typically lands between 20 and 35 percent acceptance at launch. Below 10 percent something is wrong with the context rather than the model, and shipping it anyway teaches people to ignore it.

Gate four, the safety review. Prompt injection through your own content is the one that gets missed. A customer writes an instruction into a free text field, the copilot reads it as an instruction. Treat everything retrieved as data, never as instruction, and keep privileged instructions out of reach. Securing enterprise AI belongs in the build, not in a later phase.

What goes wrong after rollout

Acceptance decays quietly. It starts at 28 percent and drifts to 14 over two quarters as content changes and nobody notices. Chart it weekly with a named owner or it will not be noticed until someone asks why the copilot is switched off.

Cost the decay so it gets an owner. On a 200 seat rollout at 7,000 suggestions a day, acceptance falling from 28 percent to 14 is about 980 fewer accepted suggestions a day. If each saved a person 40 seconds, that is roughly 11 hours a day of benefit gone, and the monthly inference bill has not moved at all. The copilot costs the same and delivers half as much, which is exactly the shape of problem that survives unnoticed for two quarters.

Context goes stale. The index was built once and the documents moved on. The copilot confidently cites a policy that was replaced in March. Schedule incremental re-indexing rather than a quarterly rebuild.

The permission leak. A user sees a suggestion drawn from a record they should not have access to. This is the one that ends projects. It comes from retrieval running with a service account rather than the user's own access.

Suggestion fatigue. Firing on every keystroke produces more dismissals than accepts and trains people to ignore the surface. Fewer, better timed suggestions beat more of them, and the dismissal rate tells you which you have. A useful threshold: if dismissals run above 3 for every accept, the trigger is too eager rather than the output being poor. Raising the confidence floor usually recovers acceptance within a fortnight and cuts the inference bill at the same time, because you are making fewer calls. It is the only change on this list that improves quality and cost together.

The context budget creeps. Covered above, and worth repeating because it shows up as a cost problem months before anyone traces it back to a content change.

When not to build one

When the task is not on a screen. A copilot helps someone doing something in a UI. Batch processing with no human in the loop is a different build entirely.

When the data is not accessible. A copilot cannot ground a suggestion in a folder of scanned documents nobody indexed. Fix retrieval first. That work is useful on its own and it is the bulk of the copilot anyway.

When permissions are coarse. If your systems cannot answer "what may this user see", a copilot will expose that. Fix it first or scope to open data.

When you cannot measure the before. Capture current handling time and error rate before anything ships. A copilot that lifts acceptance to 30 percent proves nothing if nobody recorded what the task took in week zero, and that is the number finance will ask for in month four.

When nobody asked for it. Adoption is the whole game. A copilot inserted into a workflow whose owners did not want it reaches single digit acceptance and gets turned off, which is an expensive way to learn something a conversation would have told you.

When an agent is what you actually need. If the value is in the thing being done rather than suggested, scope the agent and price it accordingly. AI copilots for business are the cheaper build, but only when suggesting is genuinely enough.

Summary

An AI copilot sits inside a screen someone is already using, suggests, and lets a person accept or ignore. It does not act alone. That boundary is what separates a 5 to 9 week build from the 8 to 16 weeks an agent needs, and the difference is almost entirely rollback, audit and approval.

Running cost is modelled per seat. On the assumptions above, 35 suggestions a day at 2,500 tokens of context lands near 7.60 USD per seat per month in inference, close to linear across 40, 200 and 1,000 seats. Retrieval is largely fixed, so it gets cheaper per seat as you grow. The context budget is the line to watch, because it rises without anyone deciding to raise it.

Latency decides adoption. Under 400 milliseconds to first token for an inline surface, one to three seconds for a panel. The budget picks the model, not the other way round.

And four gates before a customer sees it: 80 percent on your own evaluation set, two to three weeks in shadow mode, 20 to 35 percent internal acceptance, and a safety review that treats every retrieved document as data rather than instruction.