Method and boundaries
How we work on AI automation.
We start with one real business process, document what may and may not happen, build the smallest useful path and expand only when testing and measured use support it.
Last reviewed: 4 August 2026
The entity
A practical automation project with a documented method.
The Free AI Guys is a practical AI automation project run by Levi Quilliam and Luc Redman. The work focuses on bounded, testable workflows for repetitive business processes.
We do not begin by promising a platform, model or sweeping transformation. We begin with the task as it happens today, the person accountable for it and the evidence that would show whether a change is useful.
The working sequence
Each stage makes the next decision more informed.
Fit check
We look for one frequent, bounded process with a named owner, recognisable inputs and an outcome that can be judged. If the problem is too broad, the first task is to reduce the boundary.
Process walkthrough
The person who knows the work demonstrates a real recent case. We record the trigger, systems, informal workarounds, decisions, waiting points and exceptions rather than relying only on a policy description.
Written boundary
The scope states what the workflow may do, what it must not do, which data and accounts it needs, where a person approves work and what evidence will count as acceptance.
Small working path
We connect the minimum useful end-to-end path first. Deterministic rules handle exact conditions; AI is limited to interpretation or drafting that can be checked within the agreed process.
Failure-focused testing
Testing covers expected cases plus missing information, duplicates, unavailable services, inappropriate output and attempts to act outside the boundary. A safe stop is treated as a successful safeguard.
Visible pilot
The process owner reviews the workflow in a narrow pilot, often before actions are allowed to happen automatically. Feedback changes the rules, prompts, approval points or scope.
Handover and decision
We document the trigger, connected systems, actions, approvals, exceptions and operating responsibilities. The measured result supports a decision to keep, revise, expand or stop the workflow.
Before implementation
The boundary belongs in writing.
A shared scope turns assumptions into decisions. It also makes later changes visible, so a seemingly small request does not quietly add new data, permissions or consequences.
The scope should record
- The business problem and the result the process owner wants.
- The exact trigger, finish state and cases that are out of scope.
- Inputs, sources of truth, data recipients and connected systems.
- Permitted actions, account ownership and minimum access required.
- Rules, AI-assisted steps, human approvals and exception owners.
- Failure, duplicate, retry, pause and recovery behaviour.
- Test cases, acceptance checks, baseline and review measures.
- Handover responsibilities and decisions that require a new scope.
Useful work needs an accountable process owner.
We can map and implement a workflow, but the customer remains best placed to explain the process, confirm authority over systems and data, choose acceptable business outcomes and own the decisions the workflow supports.
| Responsibility | The Free AI Guys | Customer process owner |
|---|---|---|
| Discovery | Ask for a real case, map steps and expose assumptions. | Show the actual work, exceptions and current baseline. |
| Boundary | Document permitted actions, safeguards and failure paths. | Confirm authority, approvals and acceptable outcomes. |
| Testing | Build the test set, record results and correct defects. | Supply representative cases and judge business accuracy. |
| Operation | Explain the workflow, handover and agreed support boundary. | Own daily use, human decisions and future change approval. |
Decision boundaries
Some work should stay outside the automation.
A useful boundary protects the people affected by a process and keeps accountability with the person or organisation that owns it. We reduce the scope or decline an approach when the risk cannot be made proportionate and observable.
Reasons to stop or narrow the scope
- No named owner can explain or approve the process.
- Authority to use the systems or data is unclear.
- The source records have no reliable owner or meaning.
- The proposed action makes a high-consequence decision without suitable human review.
- Failures cannot be observed, contained or recovered.
- The process changes faster than it can be tested.
- Success cannot be judged with a practical measure.
See the method applied to familiar workflows.
These pages describe sensible boundaries and safeguards for common process types. They are educational patterns, not claims about a particular customer result.
Start with the process and its owner.
Review our AI automation service and security and data approach, then describe one repeated task for an initial fit assessment.
Apply TodayStart with one repetitive task.
Tell us what your team repeats, which tools are involved and what a good result looks like. We will assess whether it is a sensible first automation.
Apply Today