AI Automation Agency: Buyer Due Diligence Checklist

What does an AI automation agency do for a buyer?

For this checklist, an AI automation agency assesses and builds a bounded workflow across named tools. Some agencies may also maintain it and train the team. The proposal, not the label, tells you which duties are included. Use the AI automation consultant guide when you need to compare providers across assessment, build, maintenance, and training. Use this page when you already need due diligence on an agency proposal.

Ask the candidate to mark each item as included, excluded, or buyer-owned:

• The source the workflow may read.
• The task the workflow may perform.
• The output it may prepare or change.
• The human approval required before an action proceeds.
• The exception route when the normal path does not apply.
• The correction record and the person who acts on it.
• The next decision after an accepted or rejected output.

The proposal should also name the people around the work. The buyer-side business owner accepts the business boundary. The provider operator runs or changes the delivered workflow during the agreed period. The human approver decides whether a held action proceeds. The maintenance owner receives failures and future change requests.

Buyer takeaway: If a proposal cannot name the source, task, approval, exception, correction, and next decision, it is not ready for comparison.

What should you require before comparing proposals?

Require the same written delivery boundary from every candidate. Otherwise, you may compare a fixed build with an operated service and mistake the difference in responsibility for a difference in quality.

This table is AI Jungle's proposed buying framework, not an industry certification. NIST describes its AI Risk Management Framework as voluntary and intended to help organizations incorporate trustworthiness considerations into the design, development, use, and evaluation of AI products, services, and systems (NIST AI RMF). The framework does not certify an agency or the buyer's process (NIST AI RMF).

The NIST AI RMF Playbook provides suggested actions for the Govern, Map, Measure, and Manage functions (NIST AI RMF Playbook). Treat those suggestions as a source of questions. They are not a substitute for the delivery boundary and acceptance terms that the buyer and provider agree.

Run the comparison in this order:

1. Give each candidate the same workflow and exclusions.
2. Ask each candidate to complete the same fields in writing.
3. Mark missing answers as open decisions.
4. Decide which open decisions must close before work begins.
5. Attach the final answers to the acceptance and handback records.

How is a baseline test different from a handover test?

A baseline test happens before the build. It checks whether the proposed workflow deserves a project. Give the current manual process an agreed case, record the source, task, reviewer, output, corrections, and decision, then state what a proposed system would need to preserve or improve. A recommendation to improve the manual process, defer the build, or stop remains a valid result.

A post-build handover test asks a different question: can the named maintenance owner resume the delivered system with the access, assets, instructions, and records promised in the agreement? A good baseline does not answer that question because the delivered system did not yet exist. A successful output test does not answer it either because the original provider may still be doing the hidden work.

Use separate records:

• The baseline record explains why the project proceeds or stops.
• The acceptance record shows whether the built workflow met its agreed cases and action limits.
• The handover record shows whether the receiving owner can operate the agreed scope at exit.

Test takeaway: The baseline justifies the project. The handover test checks whether someone else can resume what was delivered.

If you need help defining the baseline and the decision boundary, start with the AI Jungle Assessment. The assessment can lead to a reasoned recommendation, alternatives, and an action plan with mandatory human review. Current terms are on the linked page.

What should the acceptance record show?

The acceptance record should make one execution inspectable. It should not collapse a demo, a pilot, and final handover into one vague claim that the automation works.

For each agreed case, record:

• The source used.
• The task performed.
• The proposed output.
• The human approval or rejection.
• The exception, if the normal path did not apply.
• The correction requested and who owns it.
• The next decision after review.

Acceptance can then refer to the written boundary. Did the workflow use the agreed source? Did it stay within the permitted task? Did the output reach the named approver? Did the exception go to its owner? Did the correction enter the record? Those are buyer questions, not a universal performance standard.

Do not expand permission because one case succeeds. Accept only the source, task, output, and action boundary that the buyer reviewed.

What does this look like in a service firm?

Illustrative example: proposal preparation. A partner wants a workflow that prepares a first proposal draft after a discovery meeting. The source is the approved meeting note and the firm's approved offer material. The task is to assemble a draft. The human approver is the partner. An exception goes to the provider operator when a required source is missing. A correction records the unsupported passage and assigns the maintenance owner to change the instruction. The next decision is either to return the draft for revision or approve it for the firm's normal sending process.

The baseline test uses a completed manual proposal and records how the partner judges it. The build acceptance test checks an agreed case against that boundary. The handover test asks the maintenance owner to locate the instructions, access the required accounts, trace the approval record, apply an agreed correction, and resume the workflow from the supplied material.

This example does not describe a client result. It shows how the same work produces three different records. If the proposal cannot state where the provider's responsibility ends, the buyer does not yet have a delivery boundary.

Who should control access, approval, and maintenance?

Ask the candidate to replace broad statements such as "you own everything" or "a human stays in the loop" with written answers. Ownership, access, hosting, and licence terms vary by agreement, so verify the actual terms rather than assuming a universal model.

Ask these questions:

• Which accounts does the buyer control during delivery and at exit?
• Which prompts, instructions, settings, exports, and documents can the buyer receive under the agreement?
• Who can grant, change, and remove access?
• Which action must wait for the named human approver?
• Who receives an exception and who records a correction?
• Who maintains the workflow after acceptance?
• Which third-party services must continue for the workflow to operate?

The written answer should distinguish an asset delivered to the buyer from a service the buyer must continue. It should also distinguish current documentation from a future explanation.

If the provider will keep operating the workflow, compare the continuing duties on the managed AI agent service page. That page owns the questions about ongoing operation, access, maintenance, and exit. This checklist only helps you verify the agency offer in front of you.

What must the handback schedule contain?

Write the handback schedule before signing, then use it for the post-build handover test. The agreement should state which items apply. Do not infer rights that the written agreement does not grant.

A handback schedule can ask the parties to identify:

• Buyer-controlled accounts and the current access list.
• Prompts, instructions, and approved settings included in scope.
• Integration settings or exports included in scope.
• Workflow notes and acceptance records promised in the offer.
• Approval, exception, and correction records promised in the offer.
• Open issues, exclusions, and named dependencies.
• The transfer owner and the agreed delivery format.

Our public handover playbook is open proof of the handover method we recommend. Use it to challenge the candidate's schedule, including ours. Where founder dependency makes operational knowledge hard to transfer, the separate business succession guide covers that broader handover problem.

Exit takeaway: Ask what your team can receive and operate at exit. Verify every item against the written agreement.

Should you choose an agency, a managed service, or in-house delivery?

Choose by responsibility, not by title.

None of these paths wins by default. The right answer can also be to improve the manual process, defer the work, or stop. Keep the same evidence fields across all three options so the decision reflects responsibility rather than sales presentation.

What should you ask before signing?

Use these final questions in the buying meeting:

1. Can you show the written delivery boundary for the exact workflow?
2. Who holds each business, operating, approval, and maintenance role?
3. What baseline evidence justifies building?
4. What will the acceptance record contain?
5. How will exceptions and corrections reach an owner?
6. What can our team receive and operate at exit under the agreement?
7. How will the post-build handover test differ from the baseline test?

If the answers remain broad, do not fill the gaps for the provider. Record them as open decisions. To turn this checklist into a scoped recommendation with alternatives and an action plan, begin the AI Jungle Assessment. Human review remains part of the decision, and the current terms live on that page.

Written by Tileo, the operator who runs AI Jungle's own agent workforce.