Who owns the code when an AI agency builds your agents?

You own the code an AI agency builds for you only if a signed document says you do, and that document needs to cover more than the code. When the contract is silent, the builder who wrote the code is the starting owner in both the US and the UK. And in an AI-built codebase, some of that code may have no copyright owner at all, which makes the contract the strongest ownership you will get.

None of this is legal advice. It is the list we would hand you before a lawyer reads the draft.

Two earlier posts cover the basics: the handover test for agency builds and the work-for-hire trap. This one asks a different question. When the thing delivered is an agent, what exactly is “the code”?

Why “the code” is the wrong unit

An agent build hands over a bundle. The repository is the visible part. The parts that make it work are text files, test cases, accounts, logs and licences, and each one has its own owner unless you say otherwise.

We count seven layers. Name all seven in the contract, because a clause that assigns “the software” will be read narrowly by whoever benefits from reading it narrowly.

The default when the contract is silent: the builder

In the UK, section 11(1) of the Copyright, Designs and Patents Act 1988 says the author of a work is the first owner of the copyright in it. Section 11(2) carves out one exception: works made by an employee in the course of employment belong to the employer. A contractor is not an employee, and the section says nothing about commissioners. Section 90(3) then says an assignment of copyright is not effective unless it is in writing signed by or on behalf of the assignor.

The US lands in the same place by a different route, covered in the post linked above: a signed written transfer is required. A client who paid the invoice and holds an email saying “it’s all yours” is relying on goodwill, not on title.

If your agency subcontracts the build, the chain has to be assigned link by link. Ask whose employees and freelancers touched the code, and whether each of them assigned their work upward.

What you can own in code an AI wrote

The US Copyright Office’s report Copyright and Artificial Intelligence, Part 2: Copyrightability, published in January 2025, states that copyright does not extend to purely AI-generated material, or material with insufficient human control over the expressive elements. It adds that, on current technology, prompts alone do not provide sufficient control.

The same report is not hostile to AI tooling. It says using AI as an assistive tool does not affect the availability of copyright for the work as a whole, and it notes programmers already use automated tools for refactoring and translating code. Human-authored parts, and human selection, arrangement and modification of outputs, stay protectable. The line is drawn case by case.

For a buyer, the consequence is practical. An agency that works with AI coding agents (we do) delivers a codebase with a human-authored part and a machine-generated part, and the boundary is not marked anywhere. We cover the content version of this problem in who owns AI-generated content. For code, three things follow:

• Assign everything the builder can assign, “to the extent protectable”. Do not accept a warranty that every line is copyrightable, because nobody can honestly give one.
• Ask how the builder reviews and edits generated code. Human review is the work that creates authorship, and it is also the work that catches bugs.
• Treat contract and secrecy as the real protection. Exclusive access, confidentiality terms and a repository only you control do more for you than a copyright certificate would.

The seven layers, and who holds each by default

Layer	What it is	If the contract is silent	What to write down
1. Source code	The repository and its history	Builder is the first owner; transfer needs a signed writing	Signed assignment, effective on payment, “to the extent protectable”
2. Prompts and agent configs	System instructions, tool definitions, routing rules	Builder wrote the words, so same default as code	Name them as deliverables, in your repo
3. Test and eval sets	Real inputs plus expected outputs that define “correct”	Often built from your data, stored in the builder’s tooling	Assign the set, deliver it as files you can rerun
4. Accounts and keys	Hosting, database, model provider, API keys	Whoever opened the account holds it	Your accounts from day one, builder granted access and removed later
5. Data and logs	Your inputs, run logs, outputs	Depends on the terms of every tool in the chain	Name each data class, state who may retain it and for how long
6. Third-party and model terms	The licences the system runs under	You inherit the builder’s choice of vendor and plan	List the vendors, plan type and output terms in a schedule
7. The generated parts	Code and text a model produced	May have no owner at all	Assign what is assignable, warrant process, not copyrightability

Prompts and evals are the layers that get skipped

Layer 2 and layer 3 are where an agent build differs most from ordinary software. The prompt set and the evaluation cases hold what the system has learned about your business: the edge cases, the wording that stopped a failure, the examples of what correct looks like. They are plain text, they are small, and they are easy to leave out of an assignment clause drafted for source code.

They also depend on secrecy for their value. Under the US Defend Trade Secrets Act, information qualifies as a trade secret only if its owner “has taken reasonable measures to keep such information secret” (18 U.S.C. 1839(3)). A prompt library that lives in the builder’s shared workspace, alongside prompts written for their other clients, is hard to describe as your secret. A repository in your organization, with access you control, is much easier.

So put them on the list by name. “Prompts, agent configuration, evaluation sets and documentation” is one line in a scope document. It is a very expensive omission to discover later.

Model vendors: the output terms, and the duty that comes with them

Your system also runs under licences you did not write. Two examples we checked on the vendors’ own pages this week.

Anthropic’s Commercial Terms, effective 17 June 2025, say the customer retains all rights to its inputs and owns its outputs. That is the right answer for a business buying through an API account, and it assumes the account is yours. If the builder runs your workload through their own plan, the customer in that sentence is the builder.

GitHub’s Copilot Product Specific Terms say GitHub does not own suggestions and that you retain ownership of your code. They also put responsibility for the code, including suggestions you include, on you. Ownership and liability arrive together, and neither term tells you whether a suggestion resembles someone else’s licensed code.

The contract should say which vendors and which plan tier the builder used, who holds each account, and that the build uses business terms rather than consumer ones. Add a line asking the builder to tell you if a dependency carries a licence that restricts commercial use or demands that you publish your own code. That is a one-hour check at the end of a build and a long argument after launch.

What a builder can fairly keep

A fair deal is not total transfer of everything the builder has ever touched. Agencies reuse methods, and they should. What you should resist is reuse of anything that carries your specifics.

Our published terms draw the line this way: on acceptance and payment, the client owns the delivered code, data and documentation, and we keep the right to reuse general methods, patterns and non-client-specific tooling. Your business rules, your data, your prompts and your test cases are in the first group. A generic retry helper we have written five times is in the second.

Ask any agency to draw that line in writing. If they cannot say where it is, it is wherever they decide it is later.

How to test the contract in ten minutes

1. Search it for “assign”. If the only ownership word is “license” or “work made for hire”, stop.
2. Find the list of deliverables. Does it name prompts, agent configuration, eval sets and documentation?
3. Open your organization’s repository list. Is the code already in it, or “transferred at the end”?
4. Check whose card is on the model provider invoice.
5. Ask which model plans the builder used, and read the output terms for that plan.
6. Ask what the builder keeps, in one sentence, and see whether the answer matches the contract.

If four of the six come back clean, the contract is better than most we are shown.

What this looks like when we build for you

A sprint is a fixed-scope build, from $9,500 over four to six weeks, shipped to your own GitHub, Supabase and Netlify accounts, with a recorded handover and two weeks of written support. We build in your accounts from the first day, so the repository, the data and the keys are already yours at handover, with nothing waiting to be transferred. The AI Workforce Sprint page lists the deliverables.

Direct engagements with the company that owns the problem are our core business, and these seven layers are what we write into each scope. We hold ourselves to the same standard inside our own group. Our fleet had 41 registered agents as of 30 June 2026, each a tomte, our word for one production agent with one defined job, and each one runs on accounts the business owns. The agent fleet proof page has the dated numbers and what “zero failures” does and does not mean.

Send us the contract you were about to sign

Paste the ownership clause, or describe the build you want. You get a written reply within one business day, and no call is needed at any point. If you are comparing us with another agency, ask them the six questions above too, and send us what they say. Start async.