Skip to content
Guardrails

How we work, what we will do, and what we will refuse to do.

Plain English. Written before any work starts, agreed in writing, and reviewed every engagement. If we cannot work this way for a piece of work, we will say so and decline it.

Operating principles

Automation Nation is an operations organisation that uses AI as one tool among several. We are not an AI lab. We are not an agency that resells someone else's chatbot. We are a small team that helps small businesses run their work more reliably, with bounded AI assistance where it earns its place.

  1. Workflow before model. If the workflow is unclear, no AI assistant will fix it. We map the work first.
  2. Smallest useful system. The shortest path from "this is painful" to "this is working", with as little new tooling as possible.
  3. Bounded scope. Each assistant gets one job, one set of inputs, and one defined output. Scope creep is treated as a change request, not a feature.
  4. Human in the loop, by default. Anything customer-facing, money-moving, or compliance-touching gets human review until proven otherwise, with a documented sign-off step.
  5. Documented or it does not exist. Every assistant we ship has a one-page operations note: what it does, what it sees, who reviews it, how to disable it, who owns it.
  6. Reversible by design. If the assistant disappears tomorrow, the team can keep operating. We do not build dependencies we cannot hand back.

What we will do

The work we sign up for, and the conditions we sign up for it under.

Map the workflow first

Before any AI is added, we document the actual current process: who does what, with what data, into which system, and where decisions sit. That alone often removes the need for AI.

Define data boundaries in writing

What customer or business data the assistant can read, what it must not see, where it lives, who it is shared with, and how long it is retained. Agreed before build.

Build with human review by default

Drafts go to a human. Triage suggestions go to a human. Routing decisions go to a human until performance is measurable. Auto-send is a deliberate choice, not a default.

Set kill criteria up front

Each assistant ships with the conditions that would cause us to pause or disable it: error rate, customer complaint, drift in tone, off-topic responses, vendor outage, audit failure.

Leave a documented system

Every engagement ends with a runbook the owner can hand to a new staff member. The system should outlive the consultant.

Tell the truth about fit

If a workflow should not be automated yet, we will say so and refuse the work. We would rather lose the project than ship something we cannot stand behind.

What we will refuse to do

These are not negotiable. If a brief requires any of the below, we will explain why and decline.

  • ×Unsupervised customer-facing chatbots on launch day. We may move toward less supervision once data shows the assistant is performing safely. We do not start there.
  • ×Letting an assistant move money, change pricing, or sign things on behalf of a business without a human approval step.
  • ×Pretending an assistant is a human to a customer, supplier, or staff member. AI-assisted communication is labelled as such where it matters.
  • ×Pulling customer or sensitive data into free-tier consumer AI tools with training enabled or unclear retention.
  • ×"Replace the team with AI" projects. We will help one person do messy work better. We will not pretend AI removes the need for the role.
  • ×Building something we cannot disable, audit, hand over, or explain in plain English to the business owner.
  • ×Locking the client into us. Documentation, credentials, prompts, and configs belong to the business, not the consultant.
  • ×Claiming AI did something that was actually a deterministic script. We will not over-attribute results to AI to make a project sound impressive.

Safe pilot principles

Every assistant pilot we run uses the same shape, regardless of the workflow.

1. One workflow, one job, one boundary

An assistant pilot does exactly one thing (e.g. draft a follow-up email from a quote that has gone quiet for seven days). It is not allowed to drift into adjacent work. Adjacent work becomes a separate engagement.

2. A human owns the assistant

A named person inside the business owns the assistant: they review outputs on a defined cadence, raise issues, and have the authority to disable it. Not "the team". A person.

3. Data is bounded in writing

The assistant sees only the data it needs. We document the inputs, the systems it can reach, the outputs it produces, and the data it must not touch. Vendors and retention are listed.

4. Outputs are reviewable

Every output is logged with the input that produced it. A reviewer can sample outputs, flag issues, and trace what went in. No black boxes inside a small business.

5. Off-switch tested before launch

Before any assistant goes live, we test the off-switch. Disable it, confirm the team can keep working without it, then turn it back on. This is non-negotiable.

6. Review on a schedule, not on vibes

Pilots are reviewed weekly for the first month, then monthly. Managed Operations clients get a documented review cadence with dates, sample size, and outcomes recorded.

7. Kill criteria written down

Each pilot has explicit conditions that pause it: error rate above a threshold, drift in tone, customer complaints, or any change to the underlying tool that breaks our assumptions.

Data handling, in plain English

A short version. The full privacy and data page has more.

  • We do not put your data into free-tier consumer AI tools. Where AI is used, it is on paid services configured to not retain or train on your data, and we tell you which ones, in writing.
  • We do not retain customer data after an engagement ends beyond what is needed for accounting and audit. Working files are deleted on a documented schedule.
  • We will not store the data you put into our tools on this website. The self-check and Workflow X-ray run entirely in your browser. Nothing leaves your device unless you choose to email it.
  • If something goes wrong, you find out from us first. If we discover an issue with a workflow we run, you are told before the next scheduled report.

If this sounds like the way you would want it run, that is the idea.

If you would like to talk through a specific workflow, send the messy version. We will tell you honestly whether it is a good candidate and what we would do first.

Email a workflow problem