Your chief technology officer has just said the sentence, and the room went quiet in a particular way. We can build this. Nothing about that is bravado. The demonstration you watched used tools published openly, the reasoning part of it is a fortnight of good work for people already on your payroll, and nobody understands your renewals or your client tone the way they do. Buy instead and you pay a stranger to learn what your own team knows.
So the question is not whether they can. It is what you were both looking at when you sized the job.
What a demonstration puts on screen
Concede the obvious first, because it stays true for the whole of this page. An in-house build gives you something no purchase does: the thing is yours permanently, there is no vendor between you and a change, and the judgement inside it comes from people who sit in your meetings. For some companies that decides it.
The argument is about proportion. A demonstration shows a loop: something reads a request, decides whether it needs a tool, uses it, reads the result, and goes round again until it can answer. That loop is real engineering and not much of it. Around it sits everything turning the same behaviour into something a company can run.
ArkOne’s reference design for an executive agent, the Cabinet, names those surrounding parts, and the list is the point. The Door, the rules running in code that decide what may leave the company and what happens when a rule itself fails. The Signature, where an action stops for a person, with no timer converting silence into consent. The Record, the append-only ledger of every action and its reason. The Directory, the roster the system may address. The Minutes, the decisions read back at the next meeting. The Rehearsal, the scored examination run before any change is trusted. Every value sits on the Register.
Held against a working system, the reasoning machinery is about a fifth of it. Your engineers are right about the fifth they are looking at.
The six rows
Suppose a firm of three hundred people, invented for this exercise, that decides to build. A capable team ships a working internal assistant and everyone is pleased. Then somebody asks whether it may email a client. Here are the six rows that decide, and what the team holds that day.
| The row | Built in-house, at the demonstration | The Cabinet |
|---|---|---|
| Who decides | The loop decides, and the transcript is reviewed after the fact | Each specialist carries one authority setting, and ships at propose and wait; a person writes act, and the change is on the ledger |
| What it can touch | Whatever the stored credentials reach, usually one engineer’s account | A named roster and a named list of tools; a stranger is dropped unanswered |
| What it remembers | The conversation, until the process restarts | Decisions written after each meeting, read back at the next with the open initiatives |
| What it costs to run | The model bill, plus staff time nobody has put a number against | The model bill under per-call routing, plus a named owner for the machinery |
| What happens when it is wrong | The transcript, if kept, and whoever remembers the change | An entry naming the action, the reason, the rule that allowed it, the person who approved |
| Who owns it afterwards | The company on paper, and in practice whoever holds the reasoning | The company, as settings on one page a policy owner reads and changes |
Exhibit 1. Illustrative. Six rows an in-house build and a reference design answer differently.
Take the last row first, because a board recognises it fastest. An in-house build is genuinely yours, and for the first year the reasoning behind it also lives with the two people who did the work. Some of it is in code and some in what they remember about why. That is fine while they are there, and it is an exposure the day one of them moves on and the other is the only person who can say what the system does on Friday.
The fifth row is where a build stops rather than fails. On the morning a client is quoted a discount your company never agreed, what settles it is a record you can read and nobody can tidy. Building that store is a week. Building it so a failed write cannot silently break the working system, and so a correction stands beside the original, is the part that gets deferred, because on the day of the demonstration nobody needed it.
The second row carries the same shape. The rules on the Door are values: nothing near-identical to a message sent to that person in the past six hours, no more than five to one person in an hour, nothing outside their working hours, and an allowed-and-logged path for when the rules themselves error. Each is a small piece of code and a decision somebody makes.
When building is the right answer
Building is right for some companies, and two situations make it clearly right.
The first is when the surrounding machinery sits close to what you sell. A company whose product already carries approval flows, an audit ledger and a permissions model has most of the four fifths built. The agent is genuinely the missing fifth, and buying means paying for a second copy of things you operate well already.
The second is when nothing leaves the building. An internal system that reads your documents and answers your staff needs no outbound rules, no directory of strangers and no ledger a regulator will read. That is a smaller, honest project, and buying is an expensive way to get it.
The question that tells you which situation you are in has nothing to do with models. Take the six rows to whoever proposed the build and ask for a line against each, in days, with a name beside it. A team that has shipped this before fills the second column faster than the first, with unglamorous entries. Where the estimate comes back weighted towards the reasoning, the signal is about pricing rather than about your engineers: the parts which take the time have not been counted yet.
Then ask the question that survives the project: who operates the four fifths in eighteen months, and what happens when they leave. Before you sign treats the same six rows as contract terms, and the Cabinet and an outsourced team puts the ownership question to a supplier.
What to do with this page
Send it to whoever said we can build this, with the six rows and one instruction: put a number beside each. How that conversation goes is worth reading first. They will produce a better estimate than any vendor could, because they know your systems. Either the total is a project you want, and you build it with your eyes open, or it is not, and you learned that in a fortnight rather than two quarters.
component: null
Asked plainly
Should we build our own AI agent or buy one?
It depends on which part of the system you are pricing. The reasoning loop, the part a demonstration shows, is a genuine weekend or fortnight of work for a competent team. The outbound rules, the audit trail, the approval steps, the memory that survives a restart and the standing test suite are the larger share of the effort, and none of them appear on screen. Build when that larger share is work you want to own permanently and staff permanently. Buy when it is not.
How long does it take to build an AI agent in house?
Ask instead which parts are being counted. A working prototype that answers questions using your documents is fast. A system that may send a message to a client, waits for a person on the actions that matter, records what it did in a ledger nobody can edit, and is re-tested every time somebody changes an instruction is a different piece of engineering, and the second one is what goes live. Any estimate that does not name those parts separately is estimating the prototype.
What does an in-house AI agent project involve beyond the model?
Identity and permissions, the rules that decide what may leave the company and what happens when those rules themselves fail, an append-only record of every action and its reason, the step where an action stops for a human, a store for what the system remembers between sessions, connections into systems built for people rather than for software, screens your staff read any of it through, and a scored test suite that runs before every change. Each is ordinary engineering. Together they are most of the work.