AI at work
Hiring an AI automation consultant: what to ask first
A good AI automation consultant starts by watching how your work is done, builds in your own accounts, and leaves you with something your team can run without them. Before you hire one, ask whose accounts and code the work will live in, what a person approves, how it is documented and handed over, how success is measured, what it costs to run afterwards, and what happens when it breaks.
Clear answers to those six questions tell you more than a demo does. I do this work myself, so read this with that in mind. These are the questions I would ask anyone, including me.
What the work should include
Automating work with AI has four parts, and a consultant should do all of them:
- Understand the work. Sit with the people who do it and write down what really happens, including the exceptions.
- Pick the right jobs: work that repeats, follows rules you can explain, and where a mistake is easy to catch.
- Build it in your tools: email, calendar, CRM, accounting, spreadsheets, and your own databases.
- Run it next to the old way until it is reliable. Then document it and train someone on your team to look after it.
The first and last parts are the ones that get skipped, and they are where most of the value is. Without the first, the agent automates a version of the job that only exists in meetings. Without the last, it stops working the first time something changes, and nobody knows why. There is more on the first part in Most work is never written down.
Six questions to ask first
1. Whose accounts and code will it run in?
The answer should be yours. The automations, the subscriptions, the API keys, and any code should sit in accounts your company owns from the first day. If everything lives in the consultant’s workspace, you are renting it from them.
Also ask which login each agent uses. Anthropic’s documentation notes that a custom connector with a shared credential can reach whatever that credential can access. An agent connected as an administrator can see everything an administrator can.
2. What does a person approve?
Ask them to name the actions that wait for a person. A good answer is specific: the agent drafts customer replies and a person sends them, or the agent prepares payments and a person approves each one. Anything that sends, pays, deletes, or publishes should wait for a person until you decide otherwise.
In the same conversation, ask where your data goes and whether the provider can train on it. As of October 2026, OpenAI’s business plans and Claude’s Team plan do not train on your content by default. A consultant should know which plan your work runs on and say so plainly.
Sources: Anthropic, Connectors; OpenAI, Enterprise privacy; Anthropic, Claude plans.
3. How is it documented and handed over?
You should get a short, plain description of each automation: what starts it, what it reads, what it does, who approves, and where its records are. Ask who on your team they will train, and how. If the answer is one meeting at the end, ask for more.
4. How will we know it worked?
Before anything is built, agree on what to measure. That might be how long the job takes now, how often it goes wrong, or how much has to be redone. Measure it before and after. If nobody measures the starting point, nobody can say what changed.
5. What does it cost to run afterwards?
The project price is only part of the cost. Ask about subscriptions, API costs that grow with use, any new tools, and the hours someone on your team will spend checking runs and fixing small problems. Many automations run on a ChatGPT or Claude plan you already pay for. Some need a business plan, an API account, or a connector, and you should know which before you start.
6. What happens when it breaks?
At some point it will. A website changes, a supplier sends a new invoice format, an app updates its permissions. Ask how a failure shows up, who gets told, and who fixes it. Every run should leave a record, so you can see what happened. Ask whether the consultant stays available after the handover, on what terms, and whether your team could fix it without them.
Warning signs
- Promised savings. A percentage of time saved, quoted before anyone has looked at your work. Nobody can know that number until the work is written down and measured.
- The tool comes first. The pitch starts with a platform and your process is fitted to it. The work should decide the tool.
- No handover. Accounts in their name, no documentation, or a monthly fee you can’t stop without losing the automations.
- No approvals. Agents that send, pay, or delete on their own from the first day.
- Every job is a good fit. Someone who can’t name a job that shouldn’t be automated hasn’t looked closely at yours.
- Vague answers about data. “It’s all secure” instead of which provider, which plan, and what happens to your data.
A sensible first project
A good first project is small enough to finish and real enough to matter. Pick one job that repeats every week, follows rules you can explain, and where a mistake is easy to catch before it does harm. A few hours saved each week is a good result.
It should take a few weeks. It is done when the automation has run next to the old way until it is reliable, when someone on your team knows how to look after it, and when you have numbers from before and after. By then you know what working with agents is like, and whether you want the consultant back for the next job.
For a team, that is what my two-to-four-week automation sprint is for. For your own week, a personal setup works the same way on a smaller scale. Both are on the services page.
If you would like to talk about a first project, write to me and tell me which job you would hand off first.