Run · Agentic workflows on your own infrastructure
Own the layer that connects your whole stack.
The work between your systems is the work nobody sells an app for. We build it as software — n8n workflows, custom Claude and OpenAI agents, MCP integrations — and we build it on infrastructure you keep.
-
10×
what per-task billing does to a ten-step workflow, versus per-execution
-
80–90%
of the platform bill removed at volume by self-hosting the layer
-
$0
per-task platform fees once it runs on your own infrastructure
Billing units as Zapier and n8n publish them (vendor-stated). The multiple and the saving are our own arithmetic on those two models — the working is in the table below.
The problem
A cold-pressed juice brand runs two co-packers and one 3PL. Every morning somebody exports yesterday’s orders out of Shopify, opens the 3PL portal in a second tab and reconciles the two by eye — because the inventory feed lags a day and the subscription app has no idea which facility a given box ships from. Forty minutes, every morning, for two years. It has never been written down, and on the mornings that person is away it simply does not happen.
That is not one broken process. It is dozens, and they all live in the same place: the space between two systems that each work perfectly well on their own. A supplement brand answers the same month-three question — should I keep taking this past week eight — by assembling a reply out of a FAQ page, a product description and three old tickets. A roaster changes green lots every eight weeks, and every change means tasting notes, grind options, marketplace attributes and reorder points all have to move together, by hand, across four systems. A snack brand drafts every purchase order off a stock figure somebody eyeballs on a Tuesday.
Each of those systems has an app store, and every app in it owns one box. Almost nothing is sold for the space between the boxes, so the space between the boxes gets staffed with people — and the hiring plan quietly turns into an integration plan nobody has written.
It stays that way because fixing it is not a configuration job. It is software: API clients, pagination and rate limits, idempotency so a retried job does not send a second purchase order, schema drift when a 3PL renames a column, credential rotation, and somebody noticing when the Shopify Admin API deprecates the version you built against. A marketing-led agency is not staffed for that work and does not want it. This is the one page on this site where the differentiator is simply that we write code for a living instead of configuring other people’s.
It is worth saying the unflattering half too. A good deal of what gets sold as an “AI agent” in this category is a rule with a language model bolted on for decoration. Some of what we build is exactly that — a rule — because a rule is cheaper per run, testable, and incapable of inventing an answer. The model earns its place only where the input is genuinely unstructured: a customer’s actual sentence, a supplier’s PDF, a review, a product description that has to be written rather than looked up.
And there is a second reason these projects never get built: the tools most agencies reach for bill in a way that punishes exactly this shape of work — many steps, run many times — so the automations that would pay for themselves get quoted out of existence before anyone writes a line. That arithmetic is worth doing in public.
Where this sits in the market
Our own read of the 2026 automation landscape, not a third-party index — we have an obvious interest in that assessment, so treat it as a point of view rather than a finding.
What we build
Named objects in named systems, built in your accounts and documented as they go. Most engagements start with three or four of these, not all ten.
- The runtime, on your infrastructure n8n deployed on a modest VPS in your own hosting account, with your credentials, your database and your backups. Not a seat on our platform, and not something you lose access to if we stop working together.
- Order-status agent Reads the Shopify order, the subscription record in Recharge, Skio or Smartrr and the 3PL’s tracking event, then answers “where is my box” in your helpdesk from the actual fulfilment record rather than a template with a tracking link pasted in.
- Returns agent Applies your real policy to the real order — window, opened bag versus sealed, subscription versus one-off, which facility it shipped from — and drafts the RMA and the label. The refund itself stays with a human.
- Review-response drafting Drafts replies to Judge.me, Okendo or Yotpo reviews with the order, the SKU and the subscription history in context, in your voice and inside your claims constraints. Somebody approves before anything posts.
- Catalogue enrichment Titles, descriptions, ingredient and feeding-guide fields, guaranteed-analysis tables, allergen flags, alt text and marketplace attributes generated from your source of truth and written back through the Shopify Admin GraphQL API in batches you can roll back.
- Purchase-order drafting Reorder points read against real velocity and real supplier lead times, with the draft PO — quantities, costs, dates, the lot or roast date where it matters — landing in Slack for a human to send.
- Data reconciliation A nightly job that compares Shopify against the subscription app against the 3PL against the ad platforms, and reports the rows that disagree — instead of you discovering the disagreement a quarter later inside a P&L.
- Reporting agents Scheduled runs that pull the numbers, write the summary in plain language, flag what moved and post it to Slack or email. The Monday spreadsheet, without the Monday.
- MCP integrations Every system the agent can touch reaches it through a tool we wrote, scoped and logged — Shopify Admin, the subscription platform, Klaviyo, Gorgias or Zendesk, your 3PL, your warehouse, your data warehouse. No screen-scraping, no shared admin login, no unbounded access.
- Boundaries, logs and escalation Every run logged with its inputs, tool calls and output, so any decision can be replayed and argued with. Explicit escalation paths, explicit refusal cases, and a kill switch that someone on your team can reach without calling us.
How the build runs
Six weeks from access to a supervised launch, on a fixed scope. Nothing runs unsupervised on day one, and nothing gets a model where a rule would do.
-
01
Inventory & triage
Every manual process named, timed and costed, then sorted into three piles: things a deterministic workflow should do, things an agent should draft for a human, and things nobody should automate. The third pile is real, and we argue for it.
Week 1
-
02
Infrastructure
n8n stood up on your VPS, credentials in your vault, staging separated from production, backups tested, and the MCP tool layer built with per-tool scopes so an agent can read what it needs and write only what it should.
Week 1
-
03
Deterministic first
The plumbing gets built as plain workflows before a model is involved anywhere. Anything a rule can do, a rule does — it is cheaper per run, it is testable, and it cannot invent an answer.
Week 2–3
-
04
Agent build & evaluation
Prompt, tools, boundaries. Then a test set assembled from your own past tickets, purchase orders and catalogue rows, replayed until the failure modes are known, bounded and written down rather than discovered by a customer.
Week 3–6
-
05
Supervised launch
Agents run in draft mode first: they write, a person sends. Autonomy is granted one action at a time, after the logs have earned it — never as a launch-day default.
Week 6
-
06
Handover & operation
Runbooks, exported workflow definitions, a credential inventory and a recorded walkthrough. After that: monitoring, model and API version changes, and new builds as the processes underneath them change.
Ongoing
The arithmetic, in public
The whole cost argument turns on one distinction: what the platform counts as a billable unit. Take a single workflow with ten steps, running a thousand times a month, and price it three ways.
| Model | Billed unit | What 1,000 runs bills | Where the ceiling is |
|---|---|---|---|
| Zapier | Per task — one step is one task | 10,000 tasks | Your plan’s task quota |
| n8n Cloud | Per execution — one run is one execution | 1,000 executions | Your plan’s execution quota |
| n8n, self-hosted on your VPS | Nothing per run | Unlimited executions | Your server |
Billing units are as the two vendors publish them on their own pricing pages — vendor-stated, and worth re-reading before you sign anything, because they change. The multiplication is ours and you can check it in your head: ten steps, a thousand runs, ten thousand tasks. We deliberately do not reprint plan prices here; the honest comparison is your own workflow’s step count against your own run volume, not a screenshot of a pricing page from last year.
At the volumes a $3M-plus ecommerce brand generates, moving that same workflow from per-task billing onto a self-hosted execution model removes roughly 80–90% of the platform bill. That figure is our own arithmetic on the two billing models above, not a vendor claim and not an independent study — the reason it holds is structural rather than promotional: the step count stops being a multiplier.
What replaces the platform bill is a modest VPS, paid by you to your own host, plus model API usage on your own key. Both of those are line items you can see, cap and audit, in accounts we do not control. The trade is real and worth naming: a self-hosted runtime is infrastructure you now own, which means somebody has to patch it, back it up and watch it. That is what the retainer is for, and it is why we hand over runbooks rather than a phone number.
Where we will not put an agent
The boundary is the most useful thing an engineering firm can tell you about this category, so here is ours, in three parts.
Anything where a wrong answer costs more than a human minute
The test is not “can a model do this” — it usually can. The test is what a mistake costs. If being wrong means a compliance problem, an incorrect ingredient or feeding statement, a claim you cannot make, or a subscriber who leaves, then the expected value of automating it is negative even at a two-percent error rate. Agents belong on work where the worst outcome is that somebody redoes it.
Anything touching money, without a person on the end
Refunds, discounts, payment-method changes, credits, cancellations that trigger a refund, subscription price changes. An agent may assemble all of them — gathering the order, the policy and the history, and drafting the action — but a human presses the button. That is a deliberate boundary rather than a technical limit, and it is the same one we hold on payment recovery: billing is the one place where an automated mistake compounds instead of ending.
Anything sitting on data that is not already reliable
An agent reading a catalogue where a third of the ingredient fields are stale will produce confident, fluent, wrong answers considerably faster than a person could. The same is true of a 3PL feed nobody reconciles and a subscription record that disagrees with Shopify. Fix the source of truth first — usually catalogue and feed work or a reconciliation job — then automate on top of it. We will say so in the audit rather than sell the agent anyway.
There is a fourth, quieter one: anything a rule already handles. Deterministic workflows are cheaper per run, easier to test and impossible to talk out of their logic. Most of what a brand actually needs from ops automation is rules, and the agent layer is a smaller, sharper thing sitting on top of them.
Autonomous resolution rate across our own agent builds
—
Metric to confirm. We will publish it when there are enough builds behind it to publish something honest. Any resolution or deflection rate you have seen quoted for this category is almost certainly vendor-reported — the vendor’s own customers, and the vendor’s own definition of “resolved.” Independent measurement of agent performance in e-commerce support is thin, and where a vendor’s number and a measured one exist side by side they rarely agree. Treat the marketing figure as marketing until you have measured your own account, and see customer service automation for how we measure it.
What it costs
Two tables, kept apart on purpose. The first is what the market charges. The second is what we charge.
| Engagement | Market range |
|---|---|
| One-time workflow build — n8n, Make or Zapier with an LLM step | $3,000–$15,000 |
| E-commerce SMB workflow cluster | $3,000–$8,000 |
| Custom AI agent build | $5,000–$25,000+ |
| Multi-agent system | $15,000–$50,000+ |
| Monthly retainer | $500–$8,000 · median ≈ $2,800–$7,000 |
| Productized monthly package | ≈ $997–$4,500/mo |
| Embedded agent, per client | $300–$1,500/mo |
| Hourly, US and EU | $100–$300 |
Market rates, aggregated from roughly twelve public sources on 2026 agency pricing — published rate cards, marketplace listings and agency pricing posts. None of them are ours, none are independently audited, and every source defines “agent” slightly differently, so read this as a map of the market rather than a quote. It is here because knowing the spread is the only way to tell whether a proposal you have been sent is normal.
Pointerflow, published
Revenue Recovery Audit — the automation inventory sits inside it
$1,500–$3,000
Workflow build, per system
$3,000–$15,000
Custom agent build
$5,000–$25,000
Multi-agent system — several agents sharing tools and state
Scoped per build
Ongoing operation, monitoring and new agents
By arrangement
Infrastructure and model usage — VPS and API keys, in your own accounts
At cost, to your host
Three of those lines are words rather than numbers, and that is deliberate. A multi-agent build is priced against the estate it has to run inside, and the public market range for one — $15,000 to $50,000 and up — is wide enough to be useless as a quote. The monthly is the same story: market retainers for this work run from $500 to $8,000 with the median clustering somewhere around $2,800–$7,000, and where you land depends on how many agents are running and how fast the systems underneath them change. Infrastructure is a modest VPS and your own model API keys, paid to your host and your provider rather than to us. We publish a number the moment we can quote one honestly; until then it is a conversation, not a hidden price.
Where to go next
Questions
How is this different from hiring an automation agency?
Most automation agencies configure somebody else’s app and hand you the subscription. We write software: API clients, tool definitions, retry and idempotency logic, and the workflows that hold them together — deployed on infrastructure you own. The practical difference shows up twice: in the monthly bill, because there is no per-task platform fee on a self-hosted runtime, and on the day something breaks that the app was never designed to do.
Who owns the agents and workflows if we stop working with you?
You do, without a conversation. n8n runs on your VPS, in your hosting account, against your credentials. You get the exported workflow definitions, the tool and prompt definitions, the runbooks and a recorded walkthrough. Nothing we build depends on a Pointerflow account continuing to exist.
Which models do you use?
Claude and OpenAI models, chosen per job rather than per agency preference — the cheap fast model for classification and routing, the stronger model where the reasoning actually matters. Because the integrations sit behind MCP tool definitions, the model can be swapped without rewriting the plumbing, and API usage is billed to your own key rather than marked up through us.
Do we have to use n8n? We already run Zapier.
No. Make and Zapier are both reasonable when volume is low or your team already lives inside one, and we will build there and say so. What changes the answer is arithmetic: per-task billing multiplies a multi-step workflow by its step count, so as steps and run volume rise it stops making sense. The table on this page is the whole argument, with the example spelled out.
What does it cost to run once it is built?
A modest VPS, paid to your own host, plus model API usage on your own key. There is no per-task platform fee on a self-hosted n8n instance and no seat licence from us. We will give you the expected run volume during the build so you can size the server before you pay for it.
Will an agent talk to our customers directly?
Only inside a boundary we have defined together, and only after it has run in draft mode long enough for the logs to justify it. Anything touching a refund, a discount, a payment method or a cancellation is prepared by the agent and pressed by a person. That is a deliberate boundary, not a technical limit.
How does this relate to your ops automation service?
Ops automation is the deterministic layer — routing, reconciliation, returns, reporting — and most brands need it working before an agent has anything reliable to stand on. This page is the layer above it: the agents, the custom integrations, and the software that gets written when the app you need does not exist.
What happens when Shopify or our 3PL changes their API?
Somebody has to notice, and on a self-hosted stack that somebody is us while we are retained, and your documentation after that. Version deprecations, renamed fields and changed rate limits are the ordinary maintenance cost of an integration layer — we plan for them rather than pretend they do not happen.
Find out what you’re losing.
Before you commit to anything, we tell you exactly what you’re losing and what it costs to stop it. Two weeks. Fixed fee. Credited in full against any build you go ahead with.
- Fee
- $1,500–$3,000, fixed
- Duration
- Two weeks
- Credited
- In full, against any build
- You supply
- Read access + one 45-minute call