The 3 Documents Your AI Agent Vendor Should Hand Over Before You Sign

You buy a car, you get a title. You sign a lease, you get keys and a lockbox code. You hire a contractor, you get a contract, a schedule of works, and a lien waiver at the end.

You hire an AI agent for $2,000 a month, and what do you get?

A Slack invite. A Loom video. Maybe a Notion doc if the vendor is fancy.

That is not a professional handover. That is a login. When something breaks or you want to walk away, you own nothing. The vendor owns everything. The prompts, the data mappings, the memory, the account credentials, the workflow, the fixes they made behind the scenes. All of it lives on their machine, in their format, under their control.

There are three documents you should demand before you sign. Not after. Not "we'll get you those in month two." Before. If a vendor refuses, walk away and save yourself the migration cost 18 months from now when you finally figure out how badly you got locked in.

#Document 1: the runbook

This is the operating manual for the agent. Not marketing copy. Not a features tour. A runbook is the doc that describes, in plain language, exactly how the agent behaves.

At minimum it contains:

• What the agent does, in one paragraph. The scope. Nothing outside this paragraph is the agent's job.
• What triggers it. Inbound email, Slack message, cron, webhook, human click. Every entry point named and mapped.
• What it decides. The rules or model behavior that produce an action. If it's an LLM prompt, the current prompt template goes here (or a versioned pointer to it).
• What it does. The list of actions it can take (send email, create ticket, update record) with the exact tool or API each one uses.
• What it will NOT do. The refuse-list. The confidence thresholds. When it escalates and to whom.
• How to turn it off. One command, one URL, one toggle. Documented, tested, and in your hands.

A good runbook is 3 to 8 pages. A bad one is either 40 pages of buzzwords or 2 paragraphs and a screenshot. If the vendor cannot produce this doc for you in the first week, they do not have one themselves, which means nobody at the vendor company can tell you what the agent will actually do next Tuesday.

The runbook is not a nice-to-have. It is the difference between an appliance you own and a service that owns you.

#Document 2: the data map

This one is boring, technical, and the single most valuable doc in the pile.

The data map lists every place the agent reads from and writes to. That is it. Sounds simple. It never is.

For each data flow, you want three columns:

Direction	Source / destination	What data
Read	Your Gmail inbox	Full message bodies, attachments, headers
Read	Stripe API	Customer email, last 4 of card, subscription status
Write	Your CRM (HubSpot)	Contact create/update, deal notes, activity log
Write	Your outbound SMTP	Reply drafts sent as your team address
Read/Write	Vendor's own DB	Conversation memory (customer PII cached for 90 days)

The last row is the row that will surprise you. Most agents keep a "memory" or "context store" of your customer data on the vendor's infrastructure. It is often not documented anywhere in the sales deck. It has a retention policy the vendor chose, not you.

Why does this doc matter now, not later?

• Compliance. If you handle regulated data (health, finance, EU personal data), you are legally responsible for knowing where it goes. "The vendor knows" is not a defense in an audit.
• Termination cost. When you eventually leave this vendor, every read/write flow is a piece of glue you have to unwind. If you don't know they exist, you can't unwind them.
• Blast radius. If the vendor gets breached, your risk is whatever is in the "read" column. If you don't have the doc, you don't know what you lost.

Ask for it as a spreadsheet. Not a diagram. Diagrams hide gaps. Spreadsheets force every row to be listed.

#Document 3: the exit clause

This is not a doc the vendor writes. It is a clause you insert into the contract, and a promise attached to it.

The clause needs to say four things:

#1. Termination-for-convenience with a short notice period

30 days, ideally. Anything longer than 60 is a red flag. Auto-renewals for 12 months are the industry's favorite trap. Do not sign one for an AI product. The tech is moving too fast to lock in for a year.

#2. Data return in an open, machine-readable format

Not "we will share your data." That's a screenshot of a dashboard. You want:

"Upon termination, vendor will deliver all customer-owned data, including but not limited to conversation logs, memory stores, custom prompts, and any derived artifacts, in a documented open format (CSV, JSON, or SQL dump) within 14 calendar days, with a data dictionary describing each field."

If they push back, they are telling you they have not thought about your exit. Fix that on paper before you sign.

#3. A named human on the exit

Not a support queue. A specific person, with a role, whose job it is to handle your off-boarding. Put the name in the contract or in the SOW. When you leave in month 11, you don't want to be arguing with a shared inbox.

#4. Reasonable transition cooperation

30 to 60 days after termination where the vendor will still respond to reasonable questions about how the agent worked, what the data means, and how to reproduce a specific behavior in your new system. Cap it at 8 to 12 hours of support at a fixed hourly rate. Not blank cheque, not zero.

Every one of these clauses will feel awkward to bring up during a sales cycle. That is the point. If the vendor gets defensive, that defensiveness is the data. The good vendors will nod, add it to the redline, and move on. The bad ones will say "we'll cross that bridge when we come to it."

You will not. Because you will not get to cross it, and neither will they.

#What "before you sign" actually means

The most common mistake is asking for these docs after the contract is signed, as part of onboarding.

Don't. The moment you sign, your leverage evaporates. Ask during the pilot. During the trial. During the "we'll do a proof of concept for you" phase where the vendor still needs to earn the deal. That's when a runbook gets written. That's when a data map gets shared. That's when an exit clause gets accepted without a fight.

If you are already on a monthly retainer without these three, you are not in trouble, but you are in a weaker spot. Ask for them at the next quarterly review. Frame it as "we're doing a governance review across all our vendors." Watch what comes back and how quickly.

#What we hand over to our clients on day one

At BrainAI Team, the runbook, data map, and exit clause are non-negotiable deliverables in every engagement. We write the runbook before the first line of prompt gets written, because if we can't describe the agent in 3 pages, we don't know what we're building either. The data map lives in a shared spreadsheet we both edit as the scope changes. The exit clause is boilerplate in every SOW, and the named human is us, by role, in writing.

This is not virtue signaling. It is the boring plumbing of a professional vendor relationship. If your current AI agent vendor doesn't offer it, ask them why not. If we can help you build the runbook and data map for something you already have running, we do that as a one-week audit. Free. You keep the docs at the end. Start here.