# What should you ask before hiring an AI automation studio?

> Ask about scope, data access, who owns the code and data, handover, failure handling, and what happens after launch.

Short answer: before hiring anyone to build automation or AI work for your business, get clear answers on what exactly is in scope, what data they need access to and how it will be handled, who owns the resulting code and data once the project ends, how you and your team will be handed over and trained, what happens when the system gets something wrong, how success will actually be checked, and what support looks like after launch. A studio confident in its work will answer all of this plainly and in writing.

## What should be defined before any work starts?

Scope is the most common source of disappointment in this kind of work, not technical failure. Ask for the specific workflow, inputs and outputs that will be covered, the exceptions that are explicitly out of scope for the first phase, and how a request to add something partway through will be handled and priced. A studio that resists writing this down, or that describes the scope only in broad terms like "automate your operations", is a sign to slow down and ask for more precision before agreeing to anything.

It is also worth asking what "finished" means for the first phase specifically: which examples will be tested, what an acceptable error rate looks like if one applies, and who signs off that the agreed scope has actually been delivered.

## Who owns the code and the data?

Ask directly whether the code that gets built is yours to keep, modify and move to another provider if you choose to, or whether it is licensed to you only for as long as you keep paying that particular studio. The same question applies to your data: where it is stored, who can access it, and what happens to it if you end the relationship. A studio that cannot answer this clearly, or that treats the question as unusual, is telling you something about how the engagement will go if it ever needs to end.

## What should you ask about failure handling?

Every automated system will eventually meet an input it was not built to handle well. Ask what happens in that case: does the system pause and flag it for a person, does it guess and continue, or does it fail silently in a way nobody notices until later. Ask how you would find out that something had gone wrong, and how quickly. A studio that has thought seriously about failure will have a specific, concrete answer here rather than a general reassurance that "it works well".

## The checklist to bring to the first call

1. What specific workflow, inputs and outputs are in scope, and what is explicitly not included?
2. What data and systems will the studio need access to, and how will that access be limited and later revoked?
3. Will the resulting code and data be owned by your business, and can you take it elsewhere if you need to?
4. Who is trained to operate and adjust the system once it launches, and what documentation comes with it?
5. What happens when the system encounters an input it cannot handle confidently?
6. How will success be measured for the agreed scope, and who checks it?
7. What does support look like after launch, and for how long is it included?
8. What would it cost, in time or money, to change or extend the system later, and who would do that work?

## What a good answer sounds like, compared to a warning sign

| You ask about | A good answer sounds like | A warning sign sounds like |
| --- | --- | --- |
| Scope | A specific workflow, with stated exclusions | "We'll figure it out as we go" |
| Data access | Named systems, limited permissions, a written agreement | Broad access requested with no explanation |
| Ownership | Code and data are yours, in writing | Vague, or tied to an ongoing subscription with no export |
| Failure handling | A defined pause-and-review step for uncertain cases | "It's very accurate, you won't need to worry about it" |
| Success criteria | Specific, testable, agreed in advance | Left undefined until after delivery |

## When this is the wrong choice

Hiring an outside studio is the wrong choice if your team could not describe the workflow well enough to brief anyone, including yourselves; in that case, time spent mapping the work internally first will make any later engagement far more effective, whether you build it yourselves or bring someone in. It is also the wrong choice if your business cannot commit anyone to own the system after launch, since even a well-built automation degrades without a person responsible for noticing when it stops fitting the work. And if the task in question is small, stable and rare, a simple internal fix may cost less than any external engagement, however well run.

## How we approach it at Ribhu Labs

We expect exactly these questions and answer them before any agreement is signed: scope, data access, ownership of what gets built, training and handover, and how failures are handled and reviewed. This checklist is not a sales pitch for us specifically, it is the standard we think any studio should meet. Read more on the [AI & automation](/solutions/automation) page, see a workflow's decision points made visible in the [decision-path study in the Lab](/lab#decision-path), an illustrative browser demonstration rather than a connected system, and work through the [Build with AI lesson](/learn/automation) to practise mapping a workflow before you brief anyone.