AI Agent Development Projects: Requirements Documents and Contracts

AI agent development projects share some parts with ordinary system development and differ in others. The difference is that you cannot rule out errors in AI output. So you write down in the requirements document and the contract what you commit to and what you do not.

This article is based on public documents from Japan's Ministry of Economy, Trade and Industry (METI), the Information-technology Promotion Agency, Japan (IPA) and Japan's Ministry of Internal Affairs and Communications (MIC), and on legal texts in e-Gov Law Search (Japan's official legal database), checked in October 2026. Consult a professional for drafting contracts and for decisions about your own case.

The flow of an AI agent development project

Running an AI agent development project in the following order reduces misunderstandings along the way. The flow is the same when you build workflows, as in n8n projects.

METI's “Contract Checklist for the Use and Development of AI” (February 2025) addresses cases where risks cannot be fully analyzed when the contract is signed. In those cases, it says, adjusting risks step by step through later contracts may fit reality better than adjusting them in a single contract. Contracting the proof of concept separately from the main development follows this approach.

What to confirm in the proof of concept

• Whether the AI returns output in the required form using the client's real data
• Which kinds of input produce errors
• How much the AI model usage fees come to at the expected volume
• Whether the APIs of the connected services support the needed operations

Summarize the results in a short report and give it to the client. These results become the basis for the requirements document.

Items in the requirements document

Besides the usual list of features, a requirements document for an AI agent states the scope handed to AI and how results are verified. Example items are as follows.

Input and output are also central ideas in the checklist. It calls what the user gives the vendor “input” and what the vendor outputs or provides “output”, and asks parties to first identify the information and deliverables covered by the contract. Writing concrete inputs and outputs at the requirements stage makes the later contract discussion easier.

How to commit on accuracy: state what you do not guarantee

The checklist says that because AI models are built inductively from training data, setting an obligation to complete or guaranteeing performance is not always easy. On the other hand, it says that systems including AI models need a design that accounts for uncertainty in output.

So in the requirements document and the contract, write separately what you commit to and what you do not.

For example, in a project to classify inquiries, you write that you will select evaluation inquiries together with the client and measure how many of them are classified correctly. The pass threshold is also set as a number measured on those examples. You do not commit to classifying every inquiry correctly. Include in the requirements the steps people follow to fix errors.

Contract types: contract for work and quasi-mandate

When you take on development, think about the contract type using two forms in Japan's Civil Code: the contract for work (ukeoi) and the quasi-mandate (jun-inin). Article 632 defines a contract for work as one where a party promises to complete a piece of work and the other pays for the result. A quasi-mandate entrusts tasks that are not legal acts, and the rules on mandates apply to it (Article 656).

Under a quasi-mandate, the party taking the work must handle the tasks with the care of a prudent manager (Article 644). If the parties agree to pay for results and the results must be handed over, the fee is paid on handover (Article 648-2). Under a contract for work, the fee is paid on handover of the work (Article 633). Under a contract for work, if the ordering party does not give notice within 1 year of learning of a non-conformity, it can no longer demand a cure or a fee reduction (Article 637).

Also decide what happens if the project ends midway. Under a contract for work, the ordering party may cancel at any time before the work is complete by compensating for damages (Article 641). Under a mandate, either party may cancel at any time (Article 651). Because AI projects can be stopped based on proof-of-concept results, write in the contract how work done up to that point will be paid.

However, the checklist says the issue is often not an abstract debate over contract for work vs. quasi-mandate, but how far the user expects a certain content and level of results. The agile development model contract published by IPA assumes a quasi-mandate so it can respond flexibly to added features and changed priorities. IPA also publishes a model contract (second edition) covering contract development and maintenance and operations. It includes clauses and commentary, which help when drafting a contract. Another approach is to use a quasi-mandate for the proof of concept and a contract for work once the deliverable is clear.

When an individual with no employees takes the work, the Act on Ensuring Proper Transactions Involving Specified Entrusted Business Operators (Japan's Freelance Act) also applies. The ordering business states the details of the work, the fee, the payment due date and other terms in writing or by electronic means (Article 3).

Rights to data and deliverables

The checklist notes that in development contracts, the terms for using input are often an important point of negotiation. A typical case is when the vendor wants to use the input to develop its own technology beyond the purpose of providing the service. Decide whether that is allowed and, if so, to what extent.

Decide the rights to deliverables early as well. The checklist calls intellectual property created in development “foreground IP” and intellectual property each party holds independently of the development “background IP”. Because the line between the two tends to blur as work progresses, it recommends aligning on this early in development.

• Entrusted data: purpose of use, where it is stored, and whether it is deleted or returned when the contract ends
• Workflows and prompts you build: who holds the rights, and whether the client may modify them
• Components you already own: if you use your own shared components, the scope of use you grant the client
• Tool licenses: whether the use complies with the terms of tools such as n8n or Dify

The checklist points out that if the input includes personal data, you must follow the third-party provision rules (Article 27) of the Act on the Protection of Personal Information (Japan). It also summarizes points to watch when using foreign AI services. In projects that handle personal data, write in the input section of the requirements document what information is included and how it is handled.

If you keep your own shared components, you can reuse them in other projects. Once you deliver the same system to several companies, you also have the option of switching from client work to selling.

How to set delivery and acceptance

For delivery and acceptance, decide the following points.

1. What to deliver: workflow files, setup instructions, and the evaluation examples and results
2. How to deliver: where and in what format. Do not hand over secrets such as API keys. Write steps for the client to set them up
3. How to accept: measure on the evaluation examples in the requirements document and check whether the pass threshold is met
4. Acceptance period: how many days the client has to check, and what happens if there is no response in that time
5. Payment: when payment is made after acceptance

If the ordering party is a business with employees and the party taking the work is an individual with no employees, Article 4 of the Freelance Act requires the payment due date to be set as short as possible within 60 days from the day the work is received. Even if the acceptance period is long, this due date is counted from the day the work is received.

After delivery, you move to a maintenance contract. How to handle AI model updates and changes in connected services is covered in AI agent operations and maintenance. For the ordering side's view, see Outsourcing AI agent development. For checks when taking this work as a side job, see Before starting an AI agent side job. If you want to offer the same AI to several companies, also see the seller guide.