AI automation agency for workflows that run without you.

An automation is only finished when somebody else can run it. That is the standard the whole practice is built around, and it is why every engagement ends with a runbook, a named owner on your side and a session two weeks after go-live rather than on the day.

It is also why we start with a process map instead of a tool. The tool is the last decision, not the first one, and picking it before you know the shape of the work is the most common reason automation projects end up half-built and quietly abandoned.

Not the most annoying process. The one with the best ratio of hours to complexity, attached to a person who wants it to happen.

Week one is a process map built by observation rather than a workshop. We sit with the people doing the work, time the steps, count the exceptions, and find where the real decisions get made, which is almost never where the process document says. Coastline’s order flow was documented as nine steps and ran as fourteen.

Candidates then get ranked on four axes: hours per month, how stable the process is, how many systems it crosses, and whether those systems have usable APIs. High hours plus stable plus two systems with APIs is a three-week pilot. High hours plus a process that changes every month is a trap, and the honest advice is to fix the process first.

The map is yours either way. Several clients have taken it and made changes worth more than the automation would have been, which is a good outcome even though it is a smaller invoice.

Most automation does not need a model, and pretending otherwise is the fastest route to something slow, expensive and unreliable.

A deterministic workflow is right whenever the rules can be written down: if the invoice matches the purchase order within tolerance, post it. Those run in milliseconds, cost almost nothing, never invent an answer, and can be audited by reading them.

A model earns its place where the input is unstructured or the judgement is genuinely fuzzy. A supplier email that says send the usual. A ticket that has to land in one of forty categories. Fields extracted from a PDF whose format nobody controls. A thread summarised for a human who has to decide something.

An automation that works on the happy path is a demo. What makes one survive is what it does on the day the supplier portal is down, the export has an extra column, or somebody triggers the same batch twice at nine in the morning.

Every run we build is idempotent and checkpointed. Running it twice does not double-invoice. A failure stops at the step, alerts the channel with the context needed to fix it, and resumes from the checkpoint once cleared instead of starting again from the top.

Exceptions are designed rather than handled. There is a defined queue, a named owner and a target clearing time, and it lives where people already are — a Slack channel, not another dashboard nobody opens. At Coastline the team clears exceptions over coffee and everything else has already run.

We also plan for the automation being wrong. Anything that writes to a system of record is reversible and logged, and where the stakes justify it, held for a human click. Recovering from a bad run should be a five-minute job, not an incident.

Every run writes a timestamped log: what triggered it, what it did, what it skipped and why, and how long each step took. Not a black box you are asked to trust because the output looks right.

Three things are watched by default: run success rate, time per run, and exception volume. A workflow that starts failing five per cent of the time is a problem you want to see in week two, not in a quarterly review when somebody notices the numbers stopped adding up.

The weekly report is usually the quiet win. Most teams assemble one by hand — Coastline spent two hours a week on theirs, and it was a day out of date by the time anyone read it. When the automation already knows everything that happened, the report appends itself per run and is correct the moment it is opened.

That change tends to outlast the hours saved. Decisions made on Monday against Friday’s numbers are a different quality of decision.

The most common way an automation project fails is not technical. The thing works, and nobody changed how they work.

So handover is a phase rather than an email. A recorded walkthrough of the workflow itself, not only its output. A written runbook covering the failure modes that will actually occur. A half-day session with the team who own the exception queue. And a second session two weeks later, once people have used it for real and have the questions they could not have had on day one.

Most automation work is integration work, and most integration work is decided by how cooperative the system on the other end is. The ones with good APIs are quick: NetSuite, Salesforce, HubSpot, Xero, QuickBooks, Shopify, Stripe, Zendesk, Intercom, Slack, Google Workspace and any Postgres or SQL Server you can give us a read replica of.

Then there are the awkward ones, and they are usually the ones holding the hours: a warehouse system whose only interface is a nightly file drop, a supplier portal with no API at all, a carrier that emails a PDF, a bank export that changes column order without warning, a shared inbox that is effectively the system of record.

Those have more routes than teams expect. A scheduled export, a mailbox the system already writes to, a read replica, a reporting endpoint nobody documented, and browser automation as a genuine last resort because it breaks when a button moves. We test the actual connection during the mapping week rather than trusting the documentation, which is why our integration estimates hold.

Where the only available route is fragile, we say so before you buy and price the risk into the plan. An automation built on something that will break every third month is worse than no automation, because somebody still has to notice it broke.

Three lines on the monthly bill: the platform, the compute, and where a step needs a model, the model calls.

Self-hosted n8n is the cheapest at volume and costs you a small server plus somebody to keep it patched. Make and Zapier charge per task or operation, which is comfortable at hundreds of runs a month and gets expensive in the tens of thousands. That crossover is the usual reason a flow eventually gets rewritten in code, and it is worth knowing which side of it you will be on before you choose.

Model calls, where used, are small. A classification step on a short input costs a fraction of a cent. Reading long documents is where a bill grows, so we cache aggressively, trim context and batch anything that does not need an answer in the next second.

The running cost goes into the plan during the mapping week, so the payback maths includes it. An automation that reclaims forty hours a month and costs a few hundred dollars a month to run is still an easy decision. You should simply know which one you are buying before you sign.

We work with the least access that does the job, scoped to named service accounts, with credentials held in your secret store rather than pasted into a workflow node. Where a platform holds a connection we document which one it is and everything it can reach.

Everything runs in your infrastructure or your platform account. When the engagement ends you rotate the credentials we used and nothing of ours remains. Where a workflow calls a model, it uses zero-retention endpoints by default, and your data is not used to train anything. The full posture is on the security page.