When You Hire Someone to Build an AI Agent

Who Owns the Code When You Hire Someone to Build an AI Agent?

You own it, if your contract explicitly says so with a work-for-hire or IP assignment clause. Without that clause, the contractor or agency retains copyright by default under most jurisdictions, including the US and EU.

I am Mahmoud Zalt, an independent senior AI systems architect with 16 years building production software. I founded Sista AI, where building a production workforce of autonomous agents over the past year has made clean code ownership and handover a contract I take seriously. I provide AI agent development for product teams and scale-ups who need production-grade systems, not demos. You can read more about my background here. What follows is the IP and handover framework I apply on every engagement, and the exact clauses I tell clients to refuse when they come to me after a bad experience with another vendor.

What IP Covers in an AI Agent Engagement: More Than Just the Code

Most clients negotiate the source code and stop there. That is a serious mistake because an AI agent system has four distinct layers of intellectual property, and each one can be withheld or retained separately if your contract does not name it.

• Source code: the agent orchestration logic, tool-calling code, API integrations, backend services, and frontend interfaces.
• Prompts and system instructions: the system prompt, few-shot examples, chain-of-thought templates, and persona definitions. These are often the highest-value artifact in a production agent. A well-tuned system prompt for a customer support agent can represent dozens of hours of iteration.
• Eval sets and test suites: the labeled input/output pairs used to measure quality, regression datasets, red-team scenarios, and benchmark scripts. Without these, you cannot safely update the agent after handover.
• Infrastructure configurations: Terraform or Pulumi configs, Docker Compose files, Kubernetes manifests, CI/CD pipelines, environment variable schemas, and observability dashboards.

A contractor who hands you only a GitHub repository but keeps the eval sets and the system prompts has handed you an engine without the fuel or the gauges. You will not get far.

The Lock-In Clauses to Refuse Before You Sign

These are the five clauses I see most often in agency and freelancer contracts that quietly strip client ownership. Read every contract for these before you sign, regardless of how reputable the vendor appears.

1. 'We retain a license to use deliverables in our portfolio and tooling'

Sounds harmless. It is not. If their 'tooling' includes a proprietary prompt library or orchestration framework they reuse across clients, your system prompt and eval data can become training material or a reusable asset for their next client. Require a clause that explicitly excludes your prompts, eval data, and configuration from any portfolio or internal tooling license.

2. IP assignment limited to 'custom code only'

This phrase excludes prompts, configs, and data on the theory that those are not 'code.' Replace it with: 'All work product, including but not limited to source code, prompt templates, evaluation datasets, configuration files, and documentation, is assigned to Client upon final payment.'

3. Dependency on a proprietary orchestration framework

Some agencies build on a private framework they license separately. After handover, you owe them a monthly fee to run your own agent. Ask before the engagement starts: 'Does this system require any proprietary runtime, SDK, or framework that is not open-source or transferable?' If yes, negotiate a source-available license into the contract or choose a different vendor.

4. Model fine-tune weights retained by vendor

If fine-tuning is in scope, the resulting weights are among the most valuable deliverables. Contracts sometimes treat them as a vendor asset because the vendor ran the training job. Require explicit assignment of all fine-tuned model weights, adapter layers, and training scripts.

5. Hosting-tied contracts with no exit path

Some vendors bundle development with managed hosting. The code is 'yours,' but it only runs on their infrastructure and they control the deployment keys. Require a clause that includes a 30-day offboarding window with full infrastructure access transfer, credential rotation support, and written runbooks.

What a Clean Handover Actually Includes: My Standard Checklist

I use this checklist as a deliverables contract schedule on every AI agent engagement. If a vendor cannot commit to every item in writing before the engagement starts, that is the signal you need.

This is not an unreasonable ask. A professional engagement produces all of these as a matter of course. Resistance to providing any of them is a red flag, not a negotiation position.

Worked Example: What Gets Missed Without a Handover Contract

A mid-size SaaS company hired an agency to build an internal AI agent that triaged customer support tickets and drafted replies for human review. The engagement ran for four months and cost $120,000. At handover, the client received a GitHub repo with a working FastAPI backend and a React interface. Here is what they did not receive and discovered only after the agency relationship ended:

• The system prompt (700 lines, heavily engineered) lived in an environment variable on the agency's deployment platform. The agency considered it their 'proprietary methodology.'
• The eval set (300 labeled ticket/draft pairs) had been built inside the agency's internal LangSmith organization. The client had read-only access that expired 30 days after the engagement closed.
• The agent used a private orchestration library the agency had built in-house. It was not on PyPI and had no public license. Every time the client tried to update the agent, they needed to call the agency for a patch.
• Observability was routed through the agency's Datadog account. The client had no dashboards of their own.

The total cost to remediate: three months of internal engineering time to reconstruct the prompt from production logs, rebuild the eval set from scratch, replace the orchestration layer with LangGraph (open-source), and stand up independent observability. The original $120,000 engagement effectively cost $180,000 after remediation.

None of this required bad intent from the agency. It required a bad contract. Every one of these gaps would have been prevented by the handover checklist above.

Prompt Ownership Is the Real Fight, Not the Code

Experienced AI engineers know this. Most clients do not discover it until after handover. A well-tuned production system prompt is the result of dozens of iterations: A/B testing against eval sets, manual review of failure cases, calibration of guardrails, and refinement of tone and scope. It encodes real product judgment. It is not boilerplate.

The code that calls the LLM API is commodity. The system prompt that makes the agent behave correctly in your specific context is not. I have seen agents where the orchestration code took two weeks to write and the prompt took six weeks to get right. Handing over the code without the prompt is handing over the chassis without the engine.

When negotiating, be specific: require a clause that names 'prompt templates, system instructions, few-shot examples, chain-of-thought scaffolds, and persona definitions' as assigned deliverables. Do not rely on the phrase 'all creative works' because a court argument about whether a system prompt is a 'creative work' is not where you want to spend money.

Prompts and the fine-tuning boundary

If your engagement includes fine-tuning a base model (for example, using LoRA on Llama 3 or fine-tuning GPT-4o), the prompt ownership question extends to training data and adapter weights. Require assignment of: the curated training dataset, the fine-tuning script, the adapter weights (safetensors or GGUF), and the evaluation results from the training run. The base model is not yours (it belongs to the model provider), but everything layered on top of it is.

Open-Source Dependencies and the License Risk Most Clients Ignore

AI agent systems pull in a large number of open-source dependencies: orchestration frameworks, embedding libraries, vector store clients, chunking utilities, and evaluation tools. Each carries a license. Most are permissive (MIT, Apache 2.0). Some are not.

Licenses to watch for in AI tooling:

• AGPL-3.0: Used by some vector databases and tooling. If your agent runs as a network service, AGPL requires you to release your source code. LangChain itself is MIT, but some plugins in its ecosystem are not.
• Commons Clause additions: Some 'open-source' AI tools add a Commons Clause that prohibits selling the software. This can affect your ability to deploy the agent as part of a commercial product.
• BSL (Business Source License): Used by several databases. Converts to open-source after a defined period but has commercial use restrictions until then.

Require a written third-party license audit as a handover deliverable. A simple pip-licenses or license-checker run produces this in 10 minutes. There is no excuse for not including it. An undisclosed AGPL dependency in a commercial SaaS product is a legal liability, not a technical footnote.

Observability, Guardrails, and Evals Must Be Under Your Control at Launch

Three operational systems belong to you from day one of production, not from some future migration milestone. If any of them live in the vendor's accounts at handover, you do not have full operational control of your agent.

Observability

Every LLM call should be traced. Tools like Langfuse, LangSmith, and Arize Phoenix all support self-hosted or bring-your-own-account configurations. Your traces, your logs, and your latency dashboards must be in an account you own. Traces contain user data. You should not want a vendor holding them.

Guardrails

Input and output guardrails (content filters, PII detection, topic classifiers, schema validators) should be deployed in your infrastructure or via a vendor account you own directly. If a contractor wires guardrails through their own API key and that key expires or they rotate it after the engagement, your agent runs unprotected. Require that all guardrail configurations and API credentials are transferred as part of handover.

Eval infrastructure

This is the one clients most often defer and most often regret. You need a runnable eval suite from day one because the first time you want to update a prompt, swap a model, or change a retrieval strategy, you need to know whether the change made the agent better or worse. An eval set is not optional documentation. It is the safety net for every future change. If your vendor did not build one during the engagement, require a retrospective eval-building session before closing the contract.

Frequently Asked Questions

Who owns the code when I hire a freelancer to build an AI agent?

The freelancer owns it by default under copyright law in the US and most of Europe, unless you have a written work-for-hire agreement or IP assignment clause. 'I paid for it' does not transfer ownership. You need the clause in writing, signed before work begins.

Are AI prompts considered intellectual property?

Yes. Prompts are protectable as trade secrets and potentially as copyrightable literary works depending on their length and originality. More practically, they are your most operationally sensitive deliverable. Treat them as IP in your contract regardless of the legal classification debate.

What should a handover package include when building an AI agent?

At minimum: full source code with history, all prompt templates and system instructions, eval dataset and scoring rubrics, infrastructure configs (IaC, Docker/K8s, env schemas), observability setup (traces, dashboards, alert rules), all API credentials and rotation instructions, and a written runbook. Anything missing from this list is a gap that will cost you time and money after the engagement closes.

How do I avoid vendor lock-in with an AI agent development firm?

Avoid proprietary orchestration frameworks with no open-source alternative. Require open-source or BSL dependencies. Ensure all hosting credentials are yours. Confirm the agent can be deployed from scratch by your team using only the handover materials. Test this before final payment.

Can a contractor keep the system prompt after building my AI agent?

They can attempt to, if your contract does not explicitly assign it. The phrase 'custom code' in a contract often excludes prompts, configs, and data. Name prompts explicitly in the assignment clause. If a vendor insists on retaining the system prompt after you paid to build the agent, walk away.

What happens to fine-tuned model weights when I hire someone to build an AI agent?

Fine-tuned weights are a separate deliverable from the base model and from the source code. They must be named explicitly in your IP assignment clause. Require transfer of the adapter weights, the training dataset, and the fine-tuning scripts. The vendor ran the job, but the weights encode your data and your product decisions.

Work With Someone Who Gives You Full Ownership at the End

Every engagement I run for AI agent development delivers all eight categories on the handover checklist: code, prompts, evals, infra, observability, credentials, runbook, and license audit. You get a system your team can operate, modify, and evolve without ever calling me again. That is the point. If you are evaluating vendors right now or untangling a bad handover from a previous engagement, I am available for a direct conversation at /contact.

See how I structure AI agent engagements with full IP transfer from day one.