You should own your AI code. Why we ship into your repo on day one.

Here is a story that is too common to be a story.

A growing services business hires an AI agency to build a custom lead-scoring model. Six weeks later the model is live. It uses a fine-tuned LLM, a vector database for retrieval, and a small Python service that wraps the inference logic. Conversion is up 11%. Everyone is happy.

Twelve months later, the founder calls the agency to ask for a small change. The agency partner has left. The replacement engineer needs three weeks to "get familiar with the codebase." The codebase is in the agency's GitHub org. The vector database is on the agency's Pinecone account. The fine-tuned model is on the agency's OpenAI workspace. The deployment runs on the agency's AWS, billed to the agency's card and reimbursed via invoice.

The founder owns nothing.

That is the default. It is not malice. It is the path of least resistance for a small AI shop running multiple clients on a shared bench. Spinning up a fresh client account on every vendor for every project is real overhead. Easier to keep one account, run the work in it, and bill back the costs.

We do not do this. We have never done this. We will never do this. Here is the reasoning.

The four things that should always be yours

1. The repository

On day one of every Mozr engagement, you give us push access to a repo in your GitHub or GitLab organization. Every commit lands there from the first hour. There is no "internal Mozr branch" we sync over. There is no "we will hand it over at the end." The work is in your repo from the moment work starts. The license is yours. The history is yours. If you fire us tonight, the repo is unchanged tomorrow.

This sounds obvious. It is not the default in AI consulting. Most engagements have an explicit IP transfer clause that fires "upon final payment of the engagement fee." Read your current contract. The clause is usually buried in section 14.

2. The cloud accounts

We do not run your infrastructure on our cloud. The deployment lives in your AWS, GCP, Azure, Cloudflare, or Vercel. The bills come to you, paid by you. We have IAM access scoped to the work, with audit logging on. The day you offboard us, you revoke our access in five minutes and the system keeps running.

Vendors who run client systems on vendor cloud accounts have a structural conflict of interest. The cost of leaving is "we have to migrate everything." Migration is hard, expensive, and always feels like the wrong week to do it. So you stay. The vendor knows this and prices accordingly.

3. The model artifacts and training data

If we fine-tune a model, the weights live in your account. If we build an embeddings index, the data and the index live in your account. If we curate a training set, the dataset lives in your account. We do not stash artifacts on our laptops or in Mozr-owned buckets.

This matters less for off-the-shelf API calls and more as the work compounds. By month nine, your AI surface area includes a dozen artifacts that took real time and money to produce. Those are operating assets. They should not be on a third-party's drive.

4. The vendor accounts

OpenAI, Anthropic, Cohere, Pinecone, Weaviate, Modal, Replicate, Hugging Face, every other vendor in the AI stack. The accounts are yours. The keys are in your secret manager. The billing is on your card. We use access that you provision and revoke.

The most common shape we see when founders bring us in to clean up after a previous vendor: every vendor account is in the prior firm's name. The keys rotate when the firm rotates engineers. The cost reporting is opaque because the prior firm is also using the same OpenAI workspace for three other clients. Disentangling this takes weeks.

The objection: "But what about your tooling?"

The reasonable objection from agencies who do not work this way is that vendor-owned everything is more efficient. Spinning up your own everything for every client adds setup time. The agency's preferred tools, configurations, and shortcuts do not transfer. Onboarding takes longer.

All of that is true. It is also the price of doing the work right.

Mozr engagements take an extra few days at kickoff because we provision your accounts properly. We document the access. We script the IAM policies. We write the runbooks. The cost shows up in the first week. The benefit shows up in month twelve when the offboarding clause is "thirty days notice and we revoke our access."

The work is the same either way. Where the work lives is the question.

What this looks like in practice

We have an internal kickoff checklist that runs in the first week of every engagement. It is twenty-three items. About sixty percent of them are about ownership and access. The rest are about the actual work.

Some examples:

• Client provisions a fresh GitHub repo (private) under their organization. Mozr engineers added with write access via SSO group, not personal accounts.
• Client provisions a dedicated AWS account (or sub-account in their existing org) for the work. Mozr access via cross-account IAM role with a 90-day rotation.
• Client provisions OpenAI / Anthropic workspaces in their own billing. We use scoped API keys that the client can revoke.
• Secrets land in the client's secret manager (AWS Secrets Manager, GCP Secret Manager, 1Password Vault) from day one. Not in a Mozr password manager that gets shared.
• All deployment scripts and infrastructure-as-code live in the client repo. We do not run anything from a Mozr-owned CI runner that the client cannot inspect.

None of this is exotic. It is what good in-house engineering teams do. The novelty is that an outside firm is doing it for you, structured so the offboarding cost is zero.

Why we built it this way

The reason is selfish, in the long run. A relationship structured so the client can leave at thirty days notice produces a different kind of work. We have to keep being the right answer every month, not just at the contract renewal.

That is a stronger constraint than we would put on ourselves voluntarily. The work gets better because of it. The clients we have stayed embedded with longest are the ones who could have walked out the door any month and chose not to.

Sovereignty over your code is the precondition for that relationship. If the offboarding cost is high, you stay because you are stuck. We do not want anyone to stay because they are stuck.