AI automation built into the tools you already use

What is AI automation, and how is it different from the automation you already have?

AI automation is ordinary workflow automation with a language model added at the steps where a fixed rule cannot decide. Classic automation moves structured data: when a form arrives, create a row. AI automation also handles unstructured input, such as an email, a PDF, a voice note or a chat message, by reading it, classifying it, extracting the fields and drafting a response for a person to approve.

For a small business that difference matters because most of the work still done by hand is unstructured. What stays manual is the shared inbox, the quote request written in free text, the supplier invoice that arrives as a scanned PDF, the customer asking the same question in a new way. A language model can now do the reading part of those jobs well enough to be useful, as long as the system around it is built with care.

The model is the small part. Most of a working build is plumbing: connections to your tools, validation of what the model returns, error handling, logging, and a clear point where a human says yes or no.

Which business processes are worth automating with AI?

The processes worth automating are repetitive, follow rules a new hire could learn quickly, happen often enough to hurt, and have a clear owner who can review the exceptions. In small and mid-size companies the same ones show up again and again: customer support, quoting, invoicing, moving data between systems, lead handling and internal questions.

The first three have a dedicated page on this site, each with the full build, the guardrails and the limits. You will find them under Related at the end of this page.

How do you choose the first process to automate?

Choose the process where volume is high, the rules are stable, the inputs are already digital, and a mistake is cheap to catch before it reaches a customer. A good first automation is boring: it happens every day and everyone knows what a correct result looks like.

Four questions settle most cases on the discovery call. How often does it happen, and who does it today? Can you describe the rules without saying "it depends" every second sentence? Where does the input arrive, and can software reach it through an API, an inbox or a shared folder? What happens when the output is wrong, and who would notice?

If the answers are clear, the process is a candidate. If the rules live in one person’s head and change every month, the first job is to write the process down, not to automate it.

What does an AI automation build look like?

Every build has the same seven parts: a trigger, the data it needs, a model step, guardrails, a human approval point, a place to run, and a handoff that leaves you as the owner. Take an inbound quote request as the example. The shape is the same for support tickets, invoices or leads.

The trigger is the event that starts the work: an email lands in the sales inbox, a form is submitted, a WhatsApp message arrives. The data step collects what a person would look up by hand: the customer record in the CRM, the price list, stock or availability in the ERP, past quotes. The model step, using the Claude API, the OpenAI API or Google Gemini depending on the task, reads the request, extracts products and quantities, and drafts the quote text. Your own rules do the math. The model never invents a price.

Guardrails sit around all of it: the model’s output is validated against your catalog, failed calls are retried, every run is logged, secrets live in a secrets manager and not in a workflow, and prompts and workflows are versioned so a change can be rolled back. Before anything irreversible happens, such as sending, invoicing or deleting, a person approves it.

It runs in your accounts: your n8n instance or a small Python and FastAPI service, your cloud, your API keys, your database (often Supabase or Postgres). Handoff includes documentation, the exported code and workflows in your repository, and Loom walkthrough videos, so the system does not depend on me to keep working.

What can go wrong with AI automation, and how is it prevented?

Three things go wrong in practice: the model returns something plausible but false, the workflow fails silently when an API changes or an input looks different, and nobody can maintain the system after the person who built it leaves. None of these is a model problem. All three are engineering problems with known answers.

Plausible but false output is handled by never letting the model be the source of truth. Prices come from your price list, policies from your documents, customer data from your CRM. The model’s output is checked against those sources, and anything that reaches a customer or an accounting system passes through human approval first.

Silent failure is handled with error handling, retries, logging and alerts. If a run fails, someone is told, and the item goes to a queue instead of disappearing. Maintainability is handled by the handoff: documentation, versioned workflows in your repository and recorded walkthroughs. I run this same stack in my own operation every day, so these guardrails come from systems that are live. Anonymized cases are on the Work page.

When is AI automation not worth it?

AI automation is not worth it when the volume is low, when the process is still changing, or when a tool you already pay for does the job. In those three cases a custom build costs more than it returns, and I will say so on the first call. I do not resell tools, and I have nothing to gain from a project that should not exist.

Low volume: a task that happens a handful of times a month is cheaper to do by hand than to automate, monitor and maintain. Write a checklist instead. Unstable process: if the steps, the pricing rules or the people responsible change every few weeks, the automation will be out of date before it pays for itself. Stabilize the process first, then automate it.

A feature you already have: many CRMs, helpdesks and accounting tools include routing rules, templates, reminders and basic AI drafting. If turning on a setting solves most of the problem, turn it on. Sometimes the right answer is a forty-line script on a schedule and not an AI system at all.

How much does AI automation cost for a small business?

A custom automation is quoted as a single fixed price after a discovery call, never by the hour. The reference points are the three productized systems with public list prices on this site: Lead Acquisition Engine, USD 4,000 setup (plus an optional USD 490 per month); AI Intake Agent with knowledge base, USD 4,900 (plus an optional USD 1,200 per month); AI Operating System, USD 6,800 (plus an optional USD 1,800 per month).

A custom scope is priced against those references according to what actually moves the effort: how many systems have to be connected, how clean the data is, how many exception paths the process has, and how much human approval has to be designed in. You get the number in a written proposal with a closed scope before any work starts.

Running costs are separate and they are yours: hosting, model API usage and any SaaS subscriptions are billed directly to your accounts, in your name. After handoff, monthly support is optional. The 60-day operational guarantee is included: if something I built breaks in that window, I fix it at no cost.

How does the three-week sprint work?

The sprint has four steps: a free discovery call, a written fixed-price proposal, a three-week build with weekly updates, and a documented handoff followed by the 60-day guarantee. Larger scopes take three to five weeks. You work directly with the engineer who builds, and for large scopes I bring in a second engineer.

On the discovery call we pick one process and check it against the questions above. The proposal states scope, timeline and price. During the build you see progress every week and you approve before anything touches production. I work remotely from Chile with companies in the US, Canada and Europe, in English or Spanish, with full overlap with US business hours.