What You Walk Away With After the Project: Code, Models, Documentation

The project is delivered, the agent works, the paperwork is signed. A year later you want to change contractors, hire an in-house developer, or just move the agent to another server, and it turns out you have an admin login and nothing else. The code sits in someone else’s repository, the model keys are registered to someone else’s email, and the one person who knows why the agent answers the way it does has already left.

For an ordinary website, “source code is handed over to the client” was enough. For an agent it is not: code is the smaller part of what makes it work. Below is the full list of what should end up in your hands, and a way to check it in one day.

What an agent actually consists of

• Source code. The agent service, CRM and messenger integrations, the chat widget. A repository with history, not a “final version” archive.
• The agent’s instructions (prompts). The text that defines its behaviour: what to answer, what not to, when to call a human. This is the main result of tuning, and it belongs in the repository next to the code, not in somebody’s account on a third-party service.
• The knowledge base and the way to update it. The documents, the scripts that load and index them, and an instruction for what to do when the price list changes.
• The test set. Questions with reference answers the agent was accepted on, plus the script that runs them. Without it every change is a blind one: you fix one thing, break another and never notice.
• Model settings and weights. Which model, with which parameters. If a model was fine-tuned on your data, then the weights and the training data too.
• Infrastructure. Deployment files, a description of the servers, the update and rollback procedure.
• Logs. Conversation and lead history in an exportable form.
• Documentation. Not a hundred pages, but answers to three questions: how to start from scratch, how to update, what to do when it breaks.

Accounts in your name from day one

The most common trap is accounts, not code. It is convenient for a contractor to register everything to themselves, because it is faster to start. A year later that means the model API keys, the Telegram bot token, the domain and the server are not yours.

The rule is simple: anything that costs money and cannot be recreated is registered to the client, and the contractor gets access.

• accounts with model providers and API keys;
• bots and numbers in messengers;
• servers, domains, certificates;
• the code repository.

As a side effect you see what the models really cost: the bill comes to you instead of dissolving into a “maintenance” line.

A one-day check

This is a procedure, not a rhetorical question. Ask your developer or an outside specialist to follow the documentation on an empty machine. Everything they had to ask the contractor about is a gap in the handover. There are usually three or four: a forgotten environment variable, a script that lives only on its author’s laptop, access that was granted informally.

The second check is to run the test set on the fresh copy. The result should match what you saw at acceptance. If it does not, you were given a different version.

What to put in the contract

• Rights. Exclusive rights to the code and materials created in the project pass to the client. Have a lawyer check the wording: “sources are handed over” and “rights are transferred” are different things.
• Scope of handover. The list from the first section, as an appendix to the contract rather than a verbal promise.
• Third-party components. If the contractor uses their own ready-made libraries, these must be named, and you must keep a licence to use them without the contractor. Open-source libraries come with a list of licences.
• Timing. Not “one archive after the final payment”, but as you go: the repository and accounts are yours from day one.

Why a contractor would want this

It may seem that keeping a client on a leash pays off. In practice the leash works until the first conflict, after which the client leaves and tells everyone about it. A project that can be taken away at any moment stays because of the quality of the work, and that is a sounder basis for a long relationship.

This is how we work: source code, trained models and documentation are fully handed over to the client, and all the code is yours. If you want to check your current project against the list above, including one we did not build, get in touch and we will look at it during the audit.