By the Foxnut team · Updated
Definition
Handing over: what an AI consultant leaves behind
What an AI consultant should leave behind - operational independence, and the means of changing the system safely. The build, own, operate, transfer model Foxnut Studios works by.
By the Foxnut team · Updated
What an AI consultant leaves behind
What an AI consultant should leave behind is operational independence: a working system running in the client’s own accounts, plus enough of the build’s reasoning and test material that the client’s team can change the system without breaking it - and can tell when they have. That material changes hands as a defined set of handover artefacts, itemised in the artefacts of an AI handover. The test of the work is that the studio can leave.
The model: build, own, operate, transfer
The studio does not sell AI strategy documents. It builds AI workflows into commercial operations until they produce measurable outcomes, then hands them over. In a pure consulting engagement, that means scoping the project with the client’s team, structuring it correctly and implementing it together. Where the studio also owns implementation, it builds end to end, including guiding the client through purchasing and setting up every tool the system needs. The model it typically deploys is BOOT: build, own, operate, transfer. The table below is what each stage obliges - and, in the last column, what the client actually holds by the end of it.
| Stage | What the studio does | What the client does | What has changed hands by the end of it |
|---|---|---|---|
| Build | Scopes the system with the client’s team and builds it end to end, inside the client’s own accounts and tools | Names a single point of contact to own the system internally | The infrastructure: the system takes shape in accounts the client already controls |
| Own | Runs the system it built on live business workflows and answers for what it produces | Puts real work through the system and judges the output against it | The proof: weeks of real-world use showing the system holds up, not a demo |
| Operate | Assigns a single point of contact on the studio side and keeps the system running through the support period | Puts its internal owner and a supplementary team through thorough training, with modules for specialised roles | The knowledge: documentation, testing, and a team trained to run the system independently |
| Transfer | Completes the documentation handover, then steps back to on-request troubleshooting and short consulting on new requirements | Runs the system alone | Everything. Transfer happens when the system is proven in real use and the team is trained, or when the project timeline lapses, whichever comes earlier |
One system runs that way today: a D2C cosmetics brand selling to women in India, with multiple SKUs and complex requirements needed its entire supply-chain flow automated. Foxnut Studios built a fully automated, end-to-end supply-chain management tool that does the work of a full procurement and supply-chain team, and the client runs it. The Transfer stage on this engagement was concrete: the tool itself runs on the client’s own servers and API keys, so no data leaves their system; the client also received a troubleshooting framework, a maintenance cadence its own IT team was trained to run, and training sessions for the supply-chain team, senior leadership, and the adjacent parts of the business the tool now feeds. The fuller, dated account of this engagement is written down in the founder’s own words.
A note on scope before the rest of this page: three questions this library will not answer, each for a stated reason. It gives no prescriptive legal or tax answers - the studio is not a law firm, so the regulatory pages describe what the rules ask of operators and what operators do about them, and stop there. It carries no named-client case detail - client permission covers the name, not the project, so every worked example here is anonymised even where the client list is public. And it publishes no vendor rankings or tool listicles - the studio builds on these tools and sells work around them, so a ranking from it would not be worth reading, and it would rather say that plainly than publish one.
What we do not leave behind
A dependency. The deliverable of an AI engagement at Foxnut Studios is operational independence, so the things deliberately not left behind are the ones that create return business for the wrong reason: a system only the vendor can safely change, maintenance framed as a retainer, documentation that describes the system without enabling anyone to run it. The engagement mechanics behind that - including how engagements at Foxnut Studios run, and when the studio says no - apply to AI work the same as to everything else in Foxnut Studios’ consulting practice on AI enablement.
This page describes one part of the practice in depth: what changes hands, and when. For the wider case - which business processes AI actually changes, and the real systems the studio has shipped - see where AI changes a business.
If your supply chain, or anything shaped like it, needs the same treatment the cosmetics brand above got, tell us about it.
Foxnut Studios works on briefs like this one from Bengaluru and Paris. If you want the shape of that before you talk to anyone, here is how an AI engagement is scoped and priced.