When automation, not an agent

An agent decides. A workflow executes. If the next step is always the same given the same input, you don’t need an agent — you need automation, and the tooling for that has been mature for a decade. The mistake we see most often is teams reaching for a language model to make a deterministic decision, paying inference costs and accepting non-determinism for no benefit.

Automation is the right call when:

• The decision tree is small and known
• Every branch can be enumerated
• The cost of an LLM call would dwarf the value of the work being done

About 60% of what gets pitched as “AI workflow” inside SMBs we audit is actually well-suited to plain automation. We tell people that on the discovery call, even when it’s a smaller engagement for us.

What we build with

We don’t have a preferred tool — we have a preferred fit. The tool depends on who owns it after we ship and how much custom logic the workflow needs.

• n8n — our default for SMB and public-sector engagements where we need self-hostable, source-available, real branching logic, and integrations with internal tools that don’t exist on Zapier. We run n8n internally for our own MSP.
• Zapier — when the org already runs on Zapier, the workflow stays inside SaaS apps with first-party Zapier integrations, and the operator-owner is non-technical. Zapier’s strength is the “non-technical owner” case.
• Make — when the visual flow logic gets dense enough that Zapier feels limiting but n8n self-hosting is overkill.
• Microsoft Power Automate — when the workflow lives entirely inside the M365 tenancy and the data is in SharePoint, Outlook, Teams, or Dataverse. For most municipal IT teams already on M365, this is the right starting point.
• Custom Node or Python services — when none of the above fit cleanly. Same caveat as on the agents page: custom code is long-term maintenance cost. We use it where the alternative is fighting the framework.

n8n vs Zapier vs custom: the short version

Three real-world signals we use to pick:

1. Who owns it after we leave? Non-technical operator → Zapier. Technical operator who can read JSON → n8n. Engineering team → custom.
2. Where does the data live? Mostly SaaS with Zapier connectors → Zapier. Internal tools, on-prem systems, anything self-hosted → n8n.
3. Is it allowed to live in a SaaS vendor’s cloud? For some municipal and HIPAA-adjacent work, no. n8n self-hosted is the answer. We’ve shipped this stack for school districts that couldn’t move ticket data outside their own infrastructure.

What we ship in an automation engagement

A typical automation pilot for us is 2-4 weeks and includes:

• Discovery: 1-2 working sessions where we map the current process, the data sources, and the failure modes
• Build: the workflow itself, in the chosen tool, with monitoring and error handling
• Documentation: a runbook your team can use without us — including how to fix the workflow when an upstream API changes
• Hand-off: a 90-minute training session for the named owner, and 30 days of email support post-ship

We charge a fixed price for this, quoted in the proposal once we’ve scoped the integration count. No retainer-by-default.

Where we draw the line

We don’t build automations that touch payment authorization, contract execution, or HIPAA-protected data without an explicit security review and the right org-level governance in place. Those engagements take longer because they have to. We’ll tell you that on the call.

Where to start

If you’re choosing between automation and an AI agent, read both pages and take the AI Readiness Assessment — the use-case clarity dimension will surface whether the workflow is data-shaped or vibe-shaped. If you already know you want automation, book a 30-minute call and bring the workflow. We’ll scope the right tool live on the call.