To train AI on your business, you do not need to fine-tune a model or hire data scientists. You need to get the knowledge out of people's heads and into a form the AI can follow. Most companies run on processes nobody has written down: how a quote gets built, how month-end works, how a particular customer likes to be handled. That knowledge is exactly what AI needs to do useful work, and it is usually the missing piece.

We use two methods to capture it. The first is to record someone doing the task and let AI turn the recording into a written procedure. The second is to let AI observe the work over time, with permission, by reading the email, files and calendar where the work actually happens. This article explains both, when each fits, and how to handle privacy and approval so the result is trustworthy.

What "training" means here

When people say they want to train AI on their business, they usually mean one of three things:

  • Giving the AI a written procedure it follows each time (a standard operating procedure, or SOP).
  • Packaging that procedure with examples, templates and tool access so it runs the same way every time. In Claude this is called a skill; other platforms use terms like custom instructions or assistants.
  • Turning a stable procedure into an automation that runs on a schedule or trigger, for example in n8n.

All three start from the same raw material: an accurate description of how the work is really done. The two methods below are ways to get that description.

Method 1: Record the task

This is the fastest way to capture a process that one person does well.

How it works

  1. The person who owns the task records their screen while doing it for real, narrating as they go. Most video meeting tools and screen recorders can produce a recording with a transcript.
  2. They explain the why, not just the clicks: "I check this column first because the vendor sometimes sends the wrong currency," or "if the total is over a certain amount, I send it to the controller."
  3. The recording and transcript go to the AI with a request: write a step-by-step procedure, list the inputs and outputs, note every decision point and the rule behind it, and flag anything unclear.
  4. The AI produces a draft SOP.
  5. The person who did the task reviews it, corrects it, and fills in the gaps.

What to ask the person to cover

Narration is where the value is. Before recording, ask them to talk through:

  • Where the inputs come from and what they look like when they are wrong.
  • Every judgment call, and the rule they use to make it.
  • Exceptions they have seen, even rare ones.
  • What "done" looks like and who receives the result.

Recording two or three runs of the same task, especially one with an exception, gives the AI enough variation to write a procedure that handles more than the easy case.

When to use it

Recording works well for discrete tasks with a clear start and finish: processing a vendor invoice, setting up a new customer, building a weekly report, preparing an ad account review. It is also the right method when the process lives with one experienced person and you want to capture it before they move on.

Its limit is that people describe the ideal version of a task. What they do on a busy Tuesday may be different.

Method 2: Let AI observe the work

The second method infers the process from the evidence the work leaves behind. Email, documents, file activity and calendars contain a detailed record of how decisions actually get made.

Two examples from our own work

We built a writing-style skill by having AI read 120 days of an executive's sent email. It identified how he opens and closes messages, how long his replies are, how he handles vendors versus clients, what phrases he uses and avoids, and how his tone shifts with context. The resulting skill drafts email that sounds like him, which a generic AI prompt never managed.

We also built an hours-reconstruction skill. Each month, it reads sent mail, file activity and the calendar, matches activity to client projects, and drafts a line-item timesheet with dates, tasks and estimated hours. The rules it follows (how to attribute a meeting, how to estimate time for an email thread, how to handle overlapping work) were inferred from how the timesheets had been built by hand, then confirmed with the person who used to do it.

Neither of these could have been captured well by recording. Writing style and time allocation are patterns that only show up across hundreds of examples.

How it works

  1. Decide exactly which sources the AI may read: a specific mailbox, a folder, a calendar, a date range.
  2. Connect those sources with read-only access where possible. Protocols like MCP let AI tools read from Gmail, Outlook, Google Drive and similar systems through controlled connections.
  3. Ask the AI to analyze the material for a specific process: how quotes are structured, how support issues are escalated, how a person writes.
  4. Have it produce a draft protocol with examples drawn from the source material, so every rule can be traced to real evidence.
  5. Review the draft with the person whose work it describes.

When to use it

Observation fits processes that are spread across many interactions, such as communication style, client handling, prioritization and time allocation. It also catches the difference between the documented process and the real one, which is often where the most useful knowledge lives.

Comparing the two methods

Record the task Let AI observe
Best for Discrete, repeatable tasks Patterns across many interactions
Time to capture Hours Days to set up, then fast
Captures the "why" Yes, through narration Partly; must be confirmed
Captures real behavior Ideal version Actual version
Privacy exposure Low Higher; needs clear scope and consent

Many processes benefit from both: observe to find the real pattern, then record the owner walking through it to capture the reasoning.

Privacy and consent

Observation in particular touches sensitive material, so set the ground rules first.

  • Get consent from the person whose work is being analyzed. For an owner analyzing their own mailbox, that is simple. For employees, explain what will be read, why and for how long. Some states, New York among them, require employers to give written notice before monitoring employee email or internet use, so check the rules where your staff work.
  • Limit scope. Point the AI at the specific mailbox, folder or date range it needs, not everything.
  • Use business plans for AI tools with appropriate data-handling terms, and avoid sending regulated data (health, payment card, sensitive personal information) unless your setup is approved for it.
  • Remember third parties. Email contains customers' and vendors' information. Keep the output focused on the process and style, not on facts about the people in the messages.
  • Store the resulting protocol like any other internal document, with access limited to people who need it.

Review with the person who does the work

A draft protocol is a hypothesis. The person who does the work is the only one who can confirm it. Review sessions consistently surface rules the AI missed, rules it got backwards, and exceptions that only come up a few times a year.

Ask them three questions:

  • What is wrong in this draft?
  • What is missing that you would tell a new hire on their first day?
  • Where would you not trust an AI to make this call?

The answers to the third question define where human approval belongs.

Keep a human approval step

Training AI on your processes does not mean letting it act unsupervised. Our standard approach:

  • AI drafts; a person approves anything that leaves the company, moves money or changes a customer record.
  • Early runs are checked line by line against what the person would have done.
  • Approval can loosen for low-risk steps once the output has been reliable for a sustained period, but it stays in place for sends and payments.
  • The protocol is updated when the process changes, and the person who owns the work owns the update.

From protocol to automation

Once a protocol is accurate and approved, it can be packaged. In Claude, it becomes a skill that runs the same way every time someone asks for it; our article on Claude skills shows examples. If the task runs on a fixed schedule with predictable steps, it can move into a workflow tool such as n8n, with AI handling only the steps that need judgment. Our comparison of n8n and Claude explains where each fits.

We help companies capture their processes and turn them into working AI workflow automation, from recording sessions and observation setup through review, approval design and deployment.

Frequently asked questions

Do I need to fine-tune a model to train AI on my business?

Usually not. For most business processes, a well-written procedure with examples and the right system access gets better results than fine-tuning, and it is far easier to update when the process changes.

How much material does observation need?

Enough to show the pattern repeating. For writing style, a few months of sent mail works well; we used 120 days. For a monthly process, several months of history helps the AI see variation.

Is it legal to have AI read employee email?

Company email systems are generally the company's to review, but rules vary. Some states require written notice to employees before electronic monitoring. Tell people what is being analyzed and why, limit the scope, and check with counsel for your situation.

What if the recorded process and the observed process disagree?

That is useful information. Review both with the person who does the work. Often the recorded version is the intended process and the observed version reflects real-world shortcuts, some of which should be kept and some fixed.