The proposal has a start date on it, which is the most persuasive line in the document. Four people, a named lead, work beginning the Monday after next, a monthly figure you can put in a budget without a business case. Set against nine months of trying to hire two engineers who understood any of this, it is the version of this project that begins this quarter, and you have read enough about the ones that never began.
So take the start date as settled and ask the harder question instead. Not what they will build for you. What is standing in your building on the Friday they stop invoicing.
What is rented and what is kept
The strength of an outsourced team is real and should be said plainly. They have built this before, so the first three months skip mistakes you would otherwise pay for. The staffing risk is theirs, so a resignation in their team is their problem and not your quarter. The cost is predictable, and a predictable number is easier to defend to a board than a hiring plan. For a company needing capability this quarter rather than a capability function, that combination is often correct.
The argument is about what the arrangement leaves behind. An agent is a set of standing decisions that keep being made rather than a deliverable that sits still once written, and each of those decisions belongs somewhere.
ArkOne’s reference design for an executive agent, the Cabinet, puts each of those decisions in a named place. A specialist’s instructions are text rather than code, so a policy owner edits them and the next meeting reads the new version. The Record is the append-only ledger of every action and its reason, so a correction is a new entry and the original stands. The Minutes are the decisions read back at the next meeting. Approval rights are named per person. Every value sits on the Register, one page a person who writes no code can read.
The question to put to an agency is not whether their system has these things. It is whose name is on each of them.
The six rows, read twice
Suppose a firm of four hundred people, invented for this exercise, that engages a capable agency for a year of renewals and client correspondence. The work is good. Here are the six rows during the engagement, and the same rows the week after it ends.
| The row | The outsourced engagement, at handover | The Cabinet |
|---|---|---|
| Who decides | Their lead decides, in a weekly call your team attends | Each specialist carries one authority setting, shipped at propose and wait; your policy owner writes act |
| What it can touch | Accounts created by them, in a project they administer | Named tools and a named roster, with approval scopes written against your people |
| What it remembers | A store in their environment, exported on request | Decisions read back at the next meeting, in a store you can reach |
| What it costs to run | A monthly fee, one line, ending when the engagement does | The model bill under per-call routing, plus a named internal owner |
| What happens when it is wrong | Their internal notes, plus a summary in your inbox | An append-only entry naming the action, the reason and who approved |
| Who owns it afterwards | The code, transferred; the reasoning, in four people’s heads | Settings on one page, and the tests that prove a change is safe |
Exhibit 1. Illustrative. Six rows read twice: while the engagement runs, and the week after it ends.
The last row is the whole page. Nobody argues about the code any more; a competent agency hands it over and often puts it in your repository from the first week. What does not transfer by default is the reason each instruction says what it says. Somebody spent six months learning that your renewals need payment terms rather than discounts, wrote that into a specialist’s instructions, and the sentence explaining why lives in a conversation rather than a file. On the Friday they leave, you hold text you can edit and no record of what it was corrected from.
The third row is where this becomes concrete before the engagement ends. If what the system remembers sits in their environment, then every question about last quarter is a question you ask them. That is tolerable while they are engaged and it is the definition of a dependency once they are not. Ask to read that store this week, in your own account, and see whether the answer is a file or a meeting.
The second row is the one to settle in the engagement letter rather than the handover. A system that authenticates as accounts an agency created and administers is a system you cannot fully inventory. The fix is unremarkable and has to happen at the start: the accounts are yours, they are granted access, and access is revoked the way any leaver’s is.
When the agency is the right answer
There are two situations where outsourcing is clearly the better choice, and one of them is common.
The first is when this is a bounded piece of work rather than a function. A company that needs one workflow automated, will not add a second for two years, and has no ambition to operate agents itself is better served by people who do this constantly than by learning it once badly. Owning a capability you use once is expensive.
The second is when you are buying the first three months specifically. An agency that has built this before will find your failure modes faster than your own team will, and paying them to teach yours while they build is a legitimate use of a year. That only works if it is written down as the point of the engagement, with named people on your side sitting in the work.
The question that tells you which situation you are in is not about the agency’s quality. Ask what happens on the Friday. Take the six rows to the lead and ask, for each one, whose account, whose store, whose name. Where the answer is theirs, ask what it costs to make it yours now, while the engagement is being agreed and you hold something they want. A good agency answers quickly, because it has been asked before. The Cabinet and building it in-house puts the same rows to your own engineers, and before you sign turns them into contract terms.
Before the start date
One thing to do before you countersign. Ask for the handover document now, at the beginning, as a condition of starting rather than a task for the final month. A team that can describe what they will leave you in month one will build differently for eleven months, because everything they write has to survive being read by somebody else. A team that would rather discuss it later has told you what the last month will be like.
component: null
Asked plainly
Should we hire an agency to build our AI agent?
It is a reasonable choice when the constraint is time or hiring, and it is the wrong choice when the thing being bought is judgement you will need permanently. Ask what remains in your building at the end: whose accounts the system runs from, whether the decisions it makes are written somewhere your own staff can read, and whether an instruction can be changed by your policy owner without a support request. Where all three answers are yours, an agency is a delivery route. Where they are not, you have rented a dependency.
What happens when an outsourced AI team's engagement ends?
Whatever the handover covered, and nothing more. The risk is rarely the code, which is usually transferred without argument. It is the accounts the system authenticates as, the store holding what it remembers, the reasoning behind the instructions somebody tuned over six months, and the knowledge of which failures were already found and fixed. Ask for each of those by name in the engagement letter rather than in the final week.
Who owns the work when an AI consultancy leaves?
Ownership of the source code is usually settled in the contract and is the easier half. The harder half is operational: who holds the credentials, where the audit trail lives and whether you can read it directly, who may change an instruction, and whether the standing tests that prove a change is safe come with you. A system you own on paper and cannot operate on Monday has been transferred in name only.