DEV Community: Lars Winstand

My AI agent failed obvious tasks, and 49% fewer retrieval misses changed how I debugged it

Lars Winstand — Mon, 21 Sep 2026 22:09:46 +0000

I used to blame the model.

If an agent missed a refund rule, forgot a tool result from 10 seconds ago, or grabbed the wrong SKU from docs, I’d assume GPT-5 or Claude had a reasoning problem.

I don’t think that anymore.

A lot of "agent is dumb" bugs are retrieval bugs.

That sounds obvious in hindsight, but it changes how you debug everything: n8n flows, OpenAI File Search, support bots, internal copilots, and custom agent stacks held together with Redis, Postgres, and optimism.

Anthropic’s Contextual Retrieval writeup put hard numbers on something a lot of us have seen in production:

49% fewer failed retrievals with Contextual Retrieval
67% fewer failed retrievals when reranking is added

That is not a small lift.

That is a giant sign that many agent failures happen before the model even starts reasoning.

The failure looked like reasoning. It wasn’t.

Here’s the pattern I kept seeing.

The agent could:

summarize a long PDF
call an API correctly
produce a decent customer reply
follow a multi-step workflow

Then it would fail one painfully obvious step:

miss the refund window in the policy doc
use the wrong product SKU
forget a prior tool result
ignore a customer-specific exception

When that happens, it feels like bad reasoning.

But usually one exact fact was missing at one exact moment.

That’s not a reasoning failure.

That’s failed fetch.

The debugging mistake: treating all memory as one thing

A lot of teams say "memory" like it’s one subsystem.

It isn’t.

In practice, you usually have at least 3 different layers:

| Memory type | Scope | Best for |
|----------|----------|
| Session/chat memory | Current conversation or run | Short-term continuity |
| Durable memory | Across runs, users, or sessions | Preferences, state, long-lived facts |
| Retrieval | Pulling external facts on demand | Docs, policies, tool outputs, exact references |

If your n8n agent forgets a tool result from the same run, that’s probably session memory.

If it loses a customer preference from yesterday, that’s durable memory.

If it can’t find the refund rule that definitely exists in your docs, that’s retrieval.

Different bug. Different fix.

This is why debugging gets weird when people throw Redis, Postgres, vector search, chat history, and tool outputs into one bucket called "memory."

Long context does not magically fix retrieval

I still hear this one a lot:

We gave the model the docs, so retrieval can’t be the issue.

Not true.

The Lost in the Middle result is still one of the most annoying realities in production: models often do worse when the relevant info is buried in the middle of a long prompt.

So you can have both of these problems:

The agent never retrieves the right fact
The agent retrieves it, then buries it where the model is less likely to use it

That means "the info was technically present" is not a useful defense.

If the right fact is hidden in a wall of context, your agent can still fail in a way that looks like reasoning.

Pure vector search loses stupid fights

This is where I’ll be blunt.

If your agent needs exact strings, pure embedding search is not enough.

I’m talking about:

order IDs
policy titles
product SKUs
workflow names
error codes
ticket IDs

Semantic retrieval is great until you need literal precision.

That’s why hybrid retrieval keeps winning in real systems.

Keyword search + semantic search + reranking is just more reliable than hoping embeddings will infer everything.

Even OpenAI’s retrieval stack leans this way. That should tell you something.

A practical OpenAI File Search setup

If you’re using OpenAI-compatible tooling, retrieval should be in the agent loop instead of relying on the model to remember everything from prior turns.

Example:

from openai import OpenAI

client = OpenAI()

vector_store = client.vector_stores.create(name="Support FAQ")

client.vector_stores.files.upload_and_poll(
    vector_store_id=vector_store.id,
    file=open("customer_policies.txt", "rb")
)

That gives the agent something to query instead of forcing conversational recall to do all the work.

You can also upload remote files directly:

from io import BytesIO
import requests
from openai import OpenAI

client = OpenAI()

response = requests.get(
    "https://cdn.openai.com/API/docs/deep_research_blog.pdf",
    timeout=30,
)
response.raise_for_status()

file_content = BytesIO(response.content)

result = client.files.create(
    file=("deep_research_blog.pdf", file_content),
    purpose="assistants",
)

None of this is glamorous.

That’s exactly why it matters.

A lot of agent reliability comes from boring retrieval plumbing.

Sometimes the right move is: stop doing RAG

This is the part more people should talk about.

Anthropic makes a strong point: if your knowledge base is under roughly 200,000 tokens, you may be better off putting the whole corpus in context instead of building a retrieval pipeline.

That runs against the default instinct a lot of teams have now, which is:

chunk everything
embed everything
build RAG first
debug forever

For smaller corpora, that can be overengineering.

Anthropic also says prompt caching can reduce latency by more than 2x and costs by up to 90%.

So the tradeoff looks more like this:

Approach	Best fit	Common failure mode
Long-context prompting	Smaller corpora, roughly under 200k tokens	Relevant fact is buried or badly ordered
Retrieval pipeline	Larger or changing corpora	Wrong chunk retrieved or exact term missed

I like this framing because it forces a better question:

Do you actually need retrieval, or are you building retrieval because that’s what everyone does?

How I’d debug this before blaming GPT-5 or Claude

Here’s the checklist I wish more teams used.

1. Log the exact context the agent saw

Not what was in your database.

Not what you intended to send.

The exact:

retrieved chunks
prior messages
tool outputs
system prompt
injected memory

If you can’t inspect the final prompt state, you’re debugging blind.

2. Separate session memory from durable memory from retrieval

Ask:

Did the agent forget something from this run?
Did it fail to load something from prior runs?
Did retrieval miss the source doc entirely?

Those are 3 different incidents.

Treat them that way.

3. Add keyword search for exact-match terms

If the bug involves IDs, SKUs, policy names, or literal strings, semantic retrieval alone is a bad bet.

Use hybrid retrieval.

4. Rerank before switching models

Bad top-k results poison everything downstream.

Reranking is often cheaper and more effective than migrating from one frontier model to another because you’re fixing the input, not arguing about benchmark deltas.

5. Test prompt position, not just prompt content

Move the critical fact.

Seriously.

If it’s buried in the middle of a long prompt, put it near the end or surface it in a structured summary.

6. Check whether your corpus is small enough to skip RAG

If the full knowledge base fits comfortably in context, try the simpler architecture first.

Fewer moving parts means fewer ways to fail.

Quick local experiment: inspect exact-match retrieval behavior

If you want a simple sanity check, compare semantic-only retrieval against a hybrid strategy for exact identifiers.

A toy example in Python:

queries = [
    "What is the refund window for SKU-8472?",
    "Find policy for order ID ORD-19384",
    "What does workflow billing_reversal_v2 do?",
]

exact_terms = [
    "SKU-8472",
    "ORD-19384",
    "billing_reversal_v2",
]

for q, term in zip(queries, exact_terms):
    print(f"query={q}")
    print(f"must not lose exact term: {term}")
    print("---")

That looks trivial, but it’s the whole point.

If your retrieval layer can’t preserve exact identifiers reliably, the model is being asked to reason from incomplete evidence.

The table that changed how I think about agent reliability

Approach	Retrieval method	Reported failure reduction	Needs reranking/BM25
Standard RAG	Basic chunking plus semantic retrieval	No specific reduction cited here	Usually yes
Anthropic Contextual Retrieval	Contextualized chunks plus semantic retrieval and Contextual BM25	49% fewer failed retrievals	Yes, benefits strongly
Contextual Retrieval plus reranking	Contextualized retrieval with reranked results	67% fewer failed retrievals	Yes

That table is the argument.

A lot of agent unreliability is not model IQ.

It’s underbuilt retrieval.

Why this matters more when you run agents at scale

This gets more painful when agents run continuously in automations.

If you have workflows in:

n8n
Make
Zapier
OpenAI-compatible custom stacks
internal cron-driven agents

...then retrieval misses turn into repeated production failures.

And if you’re paying per token, debugging gets even more annoying because every retry, replay, and prompt experiment has a visible cost attached to it.

That’s one reason I think predictable API infrastructure matters for agent teams.

If you’re iterating on retrieval, memory, reranking, and long-running automations, flat-cost OpenAI-compatible compute is a lot easier to work with than watching token spend while trying to fix reliability.

That’s the appeal of Standard Compute: same OpenAI-compatible API shape, but built for teams running agents and automations all day without per-token anxiety.

When you’re testing retrieval fixes, prompt changes, and multi-step workflows repeatedly, predictable cost matters almost as much as model quality.

My current rule

When an agent fails an "obvious" task, I no longer start with:

maybe GPT-5 is worse at this
maybe Claude should replace it
maybe we need a bigger model

I start with:

what did retrieval return?
where did the fact appear in context?
did exact-match search exist?
was reranking applied?
did the agent actually see the right thing in usable form?

That question is less fun than debating models.

It’s also the one that usually fixes the bug.

If your agent keeps failing in dumb ways, there’s a good chance the model isn’t the first thing you should blame.

I finally figured out what people mean by the best uncensored LLM after watching 17 agent workflows fail

Lars Winstand — Mon, 21 Sep 2026 14:09:39 +0000

A few months ago I noticed something weird about how teams ask for the “best uncensored LLM.”

The request sounds dramatic.

The actual production problem usually isn’t.

Nobody on a serious team is saying, “I need a model that will do literally anything.”

What they’re really saying is:

my security agent refused to summarize a phishing kit
my moderation pipeline refused to classify explicit text
my coding agent bailed when the prompt mentioned Bash, scraping, auth flows, or packet capture
my n8n or Make automation got weirdly cautious right when it needed to do real ops work

That is a completely different problem.

And once you frame it that way, a lot of bad model choices suddenly make sense.

Most teams asking for an uncensored model are really asking for fewer false refusals

This is the quiet version of the conversation.

If you run internal security workflows, you do not want your model moralizing when you need it to:

summarize malware behavior
extract IOCs from a phishing kit
explain an exploit proof of concept
compare two suspicious payloads

If you run moderation, the model has to actually read ugly content.

If your pipeline is classifying:

sexual content
hate speech
harassment
violent threats

then refusing to process the raw text is not safety.

It’s just failure with better branding.

And coding agents hit this wall all the time.

A normal internal automation might need to:

write a Playwright script
generate a credential rotation job
build a SQL migration helper
parse packet captures
inspect logs containing slurs or threats
reproduce an auth bypass bug so engineering can patch it

None of that is edgy.

But some APIs get twitchy the second the prompt includes words like bypass, exploit, scrape, or shell.

So when developers search for an uncensored LLM API, what they often mean is:

please stop refusing legitimate internal work just because the text looks scary

That distinction matters a lot.

The workloads that actually need lower-refusal behavior

Not every workflow needs this.

Most don’t.

But the ones that do really do.

1. Security triage and exploit reproduction

This is the clearest case.

A security team might need a model to:

summarize malware behavior
extract domains, hashes, or indicators from a phishing kit
explain an exploit PoC
reproduce a bug internally so it can be patched

Frontier models like GPT-5 or Claude Opus can be excellent at reasoning.

That’s not the issue.

The issue is provider policy.

If your workflow lives near security-sensitive content every day, a lower-refusal open-weight model can be more useful than a stronger closed model that keeps slamming the brakes.

2. Moderation and trust-and-safety pipelines

This one sounds ironic because it is a safety use case.

But it still benefits from lower-refusal behavior.

If you need to classify explicit or abusive user-generated content at scale, over-refusal is counterproductive.

The safer pattern is usually:

let the model read the ugly content
keep the workflow contained
add logging and downstream policy checks
restrict tool access

The model should process the mess.

Your system should contain the risk.

3. Internal coding agents and automations

This is where the “uncensored” label gets abused, but there is a real issue underneath it.

An internal agent in:

n8n
Make
Zapier
OpenClaw
a custom Python runner
an internal Node service

might need to generate:

Bash scripts
scraping logic
packet parsers
credential rotation jobs
debugging helpers for auth flows

Those are normal tasks.

If your model starts refusing every time shell access or security-sensitive APIs show up, your agent fails exactly where ops teams need it most.

The real question is not “which model is least censored?”

The better question is:

which exact task is getting falsely refused?

That question forces better decisions.

Because sometimes the answer is “switch models.”

And sometimes the answer is “your workflow is sloppy.”

API compatibility matters more than rebellious branding

This is the part a lot of teams miss.

Nobody wants to rebuild an agent stack just to test one model with fewer refusals.

That’s why OpenAI-compatible APIs matter so much.

If your app already speaks the OpenAI API shape, you can swap the backend without rewriting your whole system.

That is why tools like vLLM are so useful for this category.

You can serve open-weight models behind an OpenAI-compatible endpoint and test them in your real workflow instead of arguing in Slack about screenshots and benchmarks.

A minimal example looks like this:

vllm serve meta-llama/Llama-3.1-70B-Instruct

Then point your existing client at the new base URL:

export OPENAI_BASE_URL=http://localhost:8000/v1
export OPENAI_API_KEY=dummy

And your app code may barely change:

from openai import OpenAI

client = OpenAI(
    base_url="http://localhost:8000/v1",
    api_key="dummy"
)

resp = client.chat.completions.create(
    model="meta-llama/Llama-3.1-70B-Instruct",
    messages=[
        {"role": "system", "content": "You are a security analysis assistant."},
        {"role": "user", "content": "Summarize this phishing kit and extract indicators."}
    ]
)

print(resp.choices[0].message.content)

That kind of swap is a big deal.

Because if your n8n flow or Python worker can point at a different base_url, you can test behavior inside the real automation.

That beats theoretical debate every time.

The 3 practical architecture options

Here’s the cleanest way I’ve found to think about it.

Option	What you actually get
Open-weight model via vLLM	Lower refusal potential depending on model choice, OpenAI-compatible serving, but you have to self-host and build your own guardrails
Closed API like OpenAI, Anthropic, or xAI	Strong reasoning and coding quality, managed infrastructure, but provider-enforced policies limit flexibility on sensitive workflows
Router layer with an OpenAI-compatible endpoint	Easy model swapping and workload-based routing, but still constrained by provider policy unless you route to open or self-hosted models

My opinion:

if your problem is occasional false refusals in a mostly normal coding workflow, routing between GPT-5, Claude Opus 4.6, and Grok 4.20 is often enough
if your problem is persistent refusal on malware analysis, exploit reproduction, or explicit-content moderation, you probably need an open-weight route somewhere in the stack

That’s not ideology.

That’s just operations.

A lot of teams do not need an uncensored model. They need better workflow design.

This is the part people hate hearing.

I’ve seen teams blame the model when the actual issue was:

vague prompts
junk retrieval context
broad tool permissions
no separation between analysis and action
no logging before side effects

In those cases, switching to a looser model just gives you a more confident failure mode.

A boring workflow cleanup often fixes more than people expect.

Here’s the checklist I usually recommend first:

tighten the system prompt
separate classification from action-taking
restrict tool permissions by task
scope retrieval to only relevant docs
log model decisions before external side effects

A quick example.

Bad pattern:

# One agent can read tickets, write scripts, execute shell commands,
# and call external APIs with almost no boundaries.

Better pattern:

# Agent 1: classify issue
# Agent 2: propose remediation steps
# Agent 3: execute only approved, scoped actions

That split alone removes a surprising amount of chaos.

Lower refusal does not automatically mean better for production

This is where the “uncensored” conversation usually gets unserious.

Lower refusal rates are useful for some workloads.

They are not automatically good.

If your agent touches:

customer data
regulated workflows
autonomous tools
production systems

then stricter provider behavior may be a feature, not a bug.

A model that willingly helps with exploit reproduction in a security lab may also be more willing to generate dangerous instructions in the wrong context.

A moderation model that reliably processes explicit content may also mishandle regulated material if your downstream checks are weak.

So the real evaluation questions are:

Which workload needs lower refusal?

Be specific.

Security triage is not customer support.

Malware analysis is not a healthcare assistant.

What containment do you have?

You want:

logging
approval gates
read-only tools where possible
scoped retrieval
audit trails
post-generation policy checks

Can you swap models without rewriting everything?

This is why OpenAI-compatible endpoints matter so much.

If you can route by workload, you don’t need one model to be perfect at everything.

The setup I keep seeing work

The smartest teams are usually not betting everything on one “uncensored” model.

They do something much more boring and much more effective:

use stricter closed models where policy alignment is helpful
use lower-refusal open models only where legitimate internal work keeps getting blocked
keep everything behind the same API shape so routing is easy

That’s the grown-up version.

And honestly, it’s also the only version that survives contact with production.

Where Standard Compute fits

This is exactly why I like OpenAI-compatible router layers for agent workloads.

If your team is already running automations in n8n, Make, Zapier, OpenClaw, or custom code, the best setup is usually the one that lets you swap models without rewriting clients.

That’s the useful part of Standard Compute.

It gives you an OpenAI-compatible endpoint with flat monthly pricing, so you can route workloads across models like GPT-5.4, Claude Opus 4.6, and Grok 4.20 without doing pricing math every time an agent loops harder than expected.

That matters a lot for automations.

Especially when your real problem is not just refusals.

It’s also cost predictability.

Per-token billing makes teams weirdly conservative with agents. They shorten prompts too aggressively, avoid useful retries, and babysit workflows that should just run.

Flat-rate compute changes that behavior.

If you’re building agents that run all day, that pricing model is often as important as model quality.

My practical takeaway

If you’re searching for the best uncensored LLM, stop asking which model has the loudest anti-censorship branding.

Ask which exact task is failing.

If it’s:

browser automation
SQL migrations
packet parsing
internal shell scripting

then fix prompts and permissions first.

If it’s:

malware triage
exploit reproduction for patching
explicit-content classification

then yes, a lower-refusal open-weight model served through something like vLLM may be the right answer.

Just don’t confuse “less likely to refuse” with “better for production.”

The winning setup is usually the one that:

fits your existing agent stack
speaks OpenAI-compatible API
handles the ugly parts of your workload
gives you enough guardrails that Monday morning doesn’t start with an incident review

That’s a much less exciting answer than “find the most uncensored model.”

It’s also the answer that actually works.

My AI cron job looked cheap at 5 runs/day. At 96 runs/day it turned into 1,728 model calls

Lars Winstand — Mon, 21 Sep 2026 06:08:25 +0000

I learned this the annoying way: the expensive part of an AI cron job usually isn't the prompt.

It's the production behavior around it.

A workflow that looks basically free in testing can turn into a small army of billable model calls once you add retries, polling, multi-step chains, and separate environments.

I had an n8n cron running every 15 minutes. In testing, it seemed harmless. Then I turned on retries, added a Claude Opus 4.6 summary step after a GPT-5.4 extraction step, mirrored the workflow in staging and prod, and suddenly my neat little automation had very different economics.

The prompt wasn't the problem.

The architecture was.

The testing version lied

My original mental model looked like this:

cron -> fetch data -> call model -> done

And in testing, that was kind of true.

I ran it manually a few times. Maybe let the cron fire 5 times in a day. Cost looked tiny. Everyone moved on.

Production looked more like this:

cron -> fetch records -> GPT-5.4 classify -> Claude Opus 4.6 summarize
     -> retry on timeout -> poll downstream status -> send output

And then there were three copies of it:

dev
staging
prod

That is how "one workflow" becomes a swarm.

The math that changed the conversation

Here's the simple version.

Scenario	Calls per day
Testing assumption: 5 runs/day × 1 model call	5
Real production schedule: 96 runs/day × 3 model calls	288
Add 2 retries across the workflow	576
Multiply across dev, staging, and prod	1,728

That 1,728 number is not some nightmare edge case.

It's very normal if you build scheduled automations the way they're actually supposed to be built.

Retries are normal.
Polling is normal.
Separate environments are normal.
Multi-step pipelines are normal.

The spreadsheet was wrong because it modeled the happy path, not the real system.

Why AI cron jobs blow up in production

Because production is where all the reliability features show up.

Here's the kind of stack that quietly multiplies usage:

n8n cron trigger every 15 minutes
webhook or HTTP step to pull new records
GPT-5.4 classification call
Claude Opus 4.6 summary call
retry queue when the upstream API times out
polling step to wait for downstream completion
separate dev, staging, and prod environments

None of that is weird.

That's just what happens when a workflow graduates from demo to useful.

If you're running Make scenarios, Zapier schedules, OpenClaw agents, or custom Python workers on cron, the same pattern shows up fast.

A quick way to estimate the real cost

If you're still estimating AI automation cost with "how much does one prompt cost?", you're probably undercounting by a lot.

A better back-of-the-napkin formula is:

total_daily_calls = scheduled_runs_per_day
                  × model_calls_per_run
                  × retry_multiplier
                  × environment_count

Example:

96 runs/day
× 3 model calls/run
× 2 retry multiplier
× 3 environments
= 1,728 calls/day

If you want to make this concrete in code:

function estimateDailyCalls({
  runsPerDay,
  modelCallsPerRun,
  retryMultiplier,
  environments,
}) {
  return runsPerDay * modelCallsPerRun * retryMultiplier * environments;
}

const dailyCalls = estimateDailyCalls({
  runsPerDay: 96,
  modelCallsPerRun: 3,
  retryMultiplier: 2,
  environments: 3,
});

console.log(dailyCalls); // 1728

Or if you're more shell-script-brained:

runs_per_day=96
model_calls_per_run=3
retry_multiplier=2
environments=3

echo $((runs_per_day * model_calls_per_run * retry_multiplier * environments))
# 1728

This still won't be perfect, but it's a lot closer to reality than pricing one prompt in isolation.

The expensive part is usually not the first prompt

This is the part I think a lot of teams miss.

People spend hours trying to shave 8% off a prompt while ignoring the bigger multiplier:

one model call becomes three
one run becomes 96 runs/day
one clean execution becomes retries + polling
one environment becomes dev + staging + prod

I've seen workflows where GPT-5.4 does extraction, Claude Opus 4.6 does summarization, and Grok 4.20 gets pulled in for a second pass or rewrite.

That can absolutely improve quality.

It also means your "simple automation" is now several billable inference steps deep before the retry queue even wakes up.

That's not bad engineering. Sometimes it's the right architecture.

But it does mean usage-based pricing gets painful fast.

The real problem with per-token pricing for scheduled workflows

Per-token pricing is fine when you're experimenting.

It's much worse when you're running always-on agents and scheduled automations that are supposed to be boring and reliable.

Because every sensible production improvement makes cost forecasting worse.

Add retries? More spend.

Add staging? More spend.

Increase polling because a partner API is flaky? More spend.

Split one prompt into extraction + summarization because output quality improved? More spend.

That is a bad incentive structure.

Better engineering should not make the bill harder to predict.

What I changed

The shift for me was treating AI automation like infrastructure, not like a one-off API experiment.

That changed how I thought about pricing.

For cron-heavy workflows, flat-rate compute is just a better fit than per-token billing.

If you're running n8n, Make, Zapier, OpenClaw, or custom cron jobs through an OpenAI-compatible API, you want the reliability features turned on:

retries
polling
background processing
multiple environments
multi-step model chains

You do not want engineers doing token math every week because the workflow is finally behaving like production software.

What this looks like in practice

If your code already talks to an OpenAI-compatible API, swapping providers should not require a rewrite.

Example with the OpenAI SDK pattern:

import OpenAI from "openai";

const client = new OpenAI({
  apiKey: process.env.STANDARD_COMPUTE_API_KEY,
  baseURL: "https://api.standardcompute.com/v1"
});

const response = await client.chat.completions.create({
  model: "gpt-5.4",
  messages: [
    { role: "system", content: "Classify incoming support tickets." },
    { role: "user", content: "Payment failed after checkout" }
  ]
});

console.log(response.choices[0].message.content);

If your workflow is in n8n, Make, Zapier, or a custom worker, the point is the same: keep the workflow architecture you need, without turning reliability into a budgeting problem.

Standard Compute is built for exactly this kind of workload: AI agents, automations, scheduled jobs, and OpenAI-compatible integrations that need predictable monthly cost instead of surprise usage bills.

Practical checks before you ship an AI cron job

If I were reviewing one of these workflows now, I'd ask:

How many scheduled runs happen per day in production?
How many model calls happen per run, including summary/rewrite/classification steps?
What is the retry behavior under partial failure?
Are there polling loops?
How many environments are active?
Are there hidden fan-out steps for batches or records?
Does the pricing model still make sense after all of that?

If you can't answer those, the workflow is probably more expensive than you think.

My actual takeaway

Testing lies by omission.

Production tells the truth.

And the truth is that always-on AI automation does not stay cheap just because the first five runs were cheap.

If your workflow is scheduled, retried, polled, duplicated across environments, and expected to run 24/7 without babysitting, then the billing model matters as much as the prompt.

That was the part I missed at first.

If you're building cron-heavy AI workflows and you're tired of per-token pricing turning normal engineering into a finance problem, Standard Compute is worth a look: https://standardcompute.com

My AI agent self-healing fix was embarrassingly simple once I stopped retrying the whole thing

Lars Winstand — Sun, 20 Sep 2026 22:08:43 +0000

My AI agent self-healing fix was embarrassingly simple once I stopped retrying the whole thing

I finally snapped after watching an agent die on step 8 of 12, then restart from step 1 like it had learned absolutely nothing.

The workflow was not exotic:

pull leads from a form
enrich them
summarize the account
draft outreach
push results into a CRM
notify the team in Slack

The failure was dumb: one HTTP timeout during enrichment.

But because I had wired the workflow to retry the entire run, it:

re-did earlier model calls
re-fetched records I already had
almost created duplicate CRM updates
burned compute on work that had already succeeded

In n8n, that meant another full execution.

In LangGraph, that meant replay unless I handled state correctly.

Either way, I was paying for my own bad design.

I thought the answer would be better prompts.

It was not.

The answer was teaching the agent how to resume.

The best ai agent self-healing pattern is not a smarter prompt. It is durable execution: save explicit state, retry only failure-prone steps, and resume with a stable execution ID.

If you are building long-running agents with n8n, LangGraph, Temporal, Make, Zapier, or custom workers, this is the line between "kind of works" and "survives production."

The real problem with full-workflow retries

Full-workflow retries feel safe when the workflow is tiny.

They become a disaster when your agent spans:

multiple LLM calls
external APIs
human approvals
writes into systems that really do not like duplicates

My original logic was painfully common:

try {
  await runWorkflow(input)
} catch (err) {
  await runWorkflow(input)
}

That is not resilience.

That is replay.

And replay causes a bunch of avoidable problems:

successful LLM calls get repeated
tool calls hit external systems again
token usage and latency go up for no reason
logs get noisier on every retry
one flaky step turns into a full pipeline failure

If Clearbit times out, or Salesforce rate-limits you, or a webhook returns 502, a better system prompt does not help.

This is why I stopped asking:

"How do I make the model less fragile?"

And started asking:

"What already succeeded, and how do I avoid doing it again?"

The fix: stable execution IDs + explicit state + step-level retries

What finally worked was boring in the best way.

I gave every run:

a stable execution_id
explicit persisted state after each meaningful step
hard retry boundaries around the steps that actually fail in production

The state shape was not fancy. It looked like normal application plumbing.

{
  "execution_id": "lead_9f3d7c2a",
  "current_step": "summarize_account",
  "lead_id": "lead_123",
  "artifacts": {
    "enrichment": { "company": "Acme", "employees": 120 },
    "summary": "B2B SaaS company expanding sales ops"
  },
  "side_effects": {
    "crm_upserted": false,
    "slack_notified": false
  },
  "idempotency_keys": {
    "crm_write": "crm:lead_123:v1",
    "slack_post": "slack:lead_123:v1"
  },
  "last_error": {
    "step": "enrichment",
    "message": "HTTP timeout"
  }
}

That one change killed most of the chaos.

The new rule became:

retry model or HTTP calls at the step level
never repeat a side effect unless the step is idempotent
resume from the last completed checkpoint using the same execution ID

That is what self-healing looked like in practice.

Not the agent becoming smarter.

The agent becoming less forgetful.

What step-level retry logic actually looks like

Here is the pattern in plain TypeScript.

type WorkflowState = {
  executionId: string
  currentStep: string
  artifacts: Record<string, unknown>
  sideEffects: {
    crmUpserted: boolean
    slackNotified: boolean
  }
}

async function runLeadWorkflow(state: WorkflowState) {
  if (state.currentStep === "start") {
    state.artifacts.enrichment = await retryStep(() => enrichLead(), 3)
    state.currentStep = "enriched"
    await saveState(state)
  }

  if (state.currentStep === "enriched") {
    state.artifacts.summary = await retryStep(() => summarizeAccount(state.artifacts.enrichment), 2)
    state.currentStep = "summarized"
    await saveState(state)
  }

  if (state.currentStep === "summarized" && !state.sideEffects.crmUpserted) {
    await upsertCRM({
      data: state.artifacts.summary,
      idempotencyKey: `crm:${state.executionId}`
    })
    state.sideEffects.crmUpserted = true
    state.currentStep = "crm_written"
    await saveState(state)
  }

  if (state.currentStep === "crm_written" && !state.sideEffects.slackNotified) {
    await postToSlack({
      message: "Lead processed",
      idempotencyKey: `slack:${state.executionId}`
    })
    state.sideEffects.slackNotified = true
    state.currentStep = "done"
    await saveState(state)
  }
}

async function retryStep<T>(fn: () => Promise<T>, maxAttempts: number): Promise<T> {
  let lastError: unknown

  for (let attempt = 1; attempt <= maxAttempts; attempt++) {
    try {
      return await fn()
    } catch (err) {
      lastError = err
      if (attempt < maxAttempts) {
        await sleep(500 * attempt)
      }
    }
  }

  throw lastError
}

The important part is not the syntax.

It is the boundary.

Each expensive or failure-prone step gets its own retry policy.

Each successful step gets checkpointed.

External writes are protected with idempotency keys.

Resume, don’t restart

The key mental shift is this:

Separate workflow state from step execution.

Once I did that, the tooling got much easier to reason about.

LangGraph: reuse `thread_id` and persist graph state

LangGraph gets a lot better once you stop treating every run like a fresh conversation.

If you use a checkpointer and keep the same thread_id, you can resume from existing state instead of replaying the graph from the top.

Conceptually:

from langgraph.graph import StateGraph
from langgraph.checkpoint.memory import InMemorySaver

checkpointer = InMemorySaver()

graph = builder.compile(checkpointer=checkpointer)
config = {"configurable": {"thread_id": "lead-123"}}

graph.invoke({"lead_id": "lead-123"}, config=config)
# later, after failure or human review
graph.invoke({"resume": True}, config=config)

If you pause with interrupt() for human review, you can continue with Command(resume=...) instead of rerunning the whole graph.

That is a much better model for real automations.

Temporal: retry Activities, not the whole business process

Temporal is probably the cleanest expression of this pattern.

The Workflow keeps deterministic state.

Activities do the flaky work:

HTTP calls
database writes
LLM tool invocations
queue operations

That split matters.

If the enrichment API times out, retry the enrichment Activity.

Do not rerun the entire lead-processing workflow.

Pseudo-example:

// workflow.ts
export async function leadWorkflow(input: LeadInput) {
  const enrichment = await enrichLeadActivity(input)
  const summary = await summarizeLeadActivity(enrichment)
  await upsertCrmActivity(summary)
  await notifySlackActivity(summary)
}

Then attach retry policy where failure actually happens.

const activities = proxyActivities<typeof import('./activities')>({
  startToCloseTimeout: '2 minutes',
  retry: {
    maximumAttempts: 3
  }
})

That is the whole point.

Retry the unstable edge, not the entire process.

n8n: manual, but still worth doing

n8n is great for orchestration.

But if you want resumability, you have to design it intentionally.

Useful pieces:

execution.retryOf to detect retries
Error Trigger for remediation flows
external state in Postgres, Redis, Airtable, or another store keyed by execution ID
branching logic to skip completed steps

A practical pattern in n8n is:

create an execution_id at the start
save progress after each major step
on retry, load prior state
skip steps that already completed
only rerun the failed node or subflow

That gives you something much closer to continuation instead of "start over and hope."

Quick comparison: restart vs resume

Approach	What happens after step 8 fails?
Full workflow retry	Steps 1-7 run again, model calls repeat, external writes may duplicate
Step-level retry + checkpoints	Only step 8 retries, prior outputs are reused, external writes stay protected

The cost problem is not subtle

This part matters a lot if you run agents all day.

Every full replay multiplies model calls.

If your workflow has six LLM steps and one API timeout near the end, a naive retry can turn one failure into:

six extra inference calls
repeated tool work
more queue time
more logs to untangle
more chances to duplicate side effects

Under per-token pricing, this gets expensive fast.

And even if you are on flat-rate AI compute, wasted retries still hurt throughput.

You are burning capacity on work that already succeeded.

That is one reason I care about this pattern so much.

If you are running agents in n8n, Make, Zapier, OpenClaw, or custom frameworks, step-level retries are one of the fastest ways to make the system both cheaper and less annoying.

And if your stack still points at the OpenAI API with usage anxiety hanging over every replay, it is worth looking at a drop-in alternative like Standard Compute.

Standard Compute gives you unlimited AI compute for a flat monthly price and works with existing OpenAI-compatible SDKs and HTTP clients. So when you fix your retry design, you are not also stuck babysitting per-token costs every time an automation gets noisy.

That does not replace durable execution.

It just means your cost model stops fighting your architecture.

The pattern I would use again from day one

If I were rebuilding that workflow today, I would do this immediately:

Assign a stable execution ID at the start.
Persist state after every expensive or meaningful step.
Store outputs in a structured state object, not scattered logs.
Put idempotency keys on every external write.
Retry only failure-prone steps like LLM calls, HTTP requests, and queue operations.
Resume from the last checkpoint instead of replaying the workflow.
Send true failures to a human or remediation flow instead of blindly looping.

If you want a minimal checklist for production agents, use this:

# production sanity checklist
[ ] stable execution id
[ ] persisted checkpoint after each major step
[ ] idempotency key on every external write
[ ] step-level retry policy
[ ] resume path tested
[ ] duplicate-write protection tested
[ ] human escalation path for hard failures

My actual takeaway

My agent did not need a more inspirational prompt.

It needed:

memory
boundaries
permission to continue where it left off

Once I stopped retrying the whole thing, the self-healing part was embarrassingly simple.

If your agent keeps "recovering" by replaying everything, it is not self-healing.

It is just forgetting more aggressively.

My refund agent looked smart until it lied about Shopify, Stripe, and Zendesk 3 different ways

Lars Winstand — Sun, 20 Sep 2026 14:16:12 +0000

I thought I had a prompt problem.

I didn’t.

I had a state problem.

My support agent could read a Zendesk ticket, find the Shopify order, issue a Stripe refund, update the ticket, and reply to the customer. In staging, it looked great. In production, it started doing something much worse than "being wrong."

It was confidently telling customers their refund was complete when the workflow had only fired an API call and hoped for the best.

That distinction matters.

Because once an LLM can call real systems like Shopify, Stripe, and Zendesk, the failure mode changes. The model doesn’t need to hallucinate a tool name to hurt you. It just needs to overstate what happened after a valid tool call.

That’s the trap.

The real bug: valid tool calls, invalid conclusions

A lot of teams hit an "agent failed a task" moment and immediately do one of these:

tighten the prompt
add more warnings
enforce stricter JSON schemas
switch models
add more examples

Sometimes that helps.

But if your agent can already call the right API with the right arguments, prompt work stops being the main lever.

OpenAI’s Structured Outputs are a real improvement here. Their published evals showed gpt-4o-2024-08-06 hitting 100% schema adherence on complex JSON schemas, versus less than 40% for gpt-4-0613.

That’s great.

But schema adherence is not operational truth.

You can have perfect JSON and still ship a support workflow that:

reports success before money moved
retries without preserving certainty
drifts out of sync with async systems

That’s what bit me.

1) Shopify: a Refund object is not proof that money moved

This was my first clue.

The agent called Shopify refundCreate, got back a Refund object, and then told the customer:

Your refund has been processed.

Looks reasonable, right?

Not really.

Shopify’s docs are explicit: the existence of a Refund object does not guarantee the financial transaction completed. The actual outcome lives on the related OrderTransaction objects, which can be pending, processing, success, or failure.

So this pattern is broken:

call refundCreate
see refund.id
tell the customer it’s done

That’s not confirmation. That’s optimism with JSON.

The mutation is not the problem

mutation RefundOrder @idempotent(key: "refund-order-123") {
  refundCreate(input: {
    orderId: "gid://shopify/Order/123",
    note: "Customer requested partial refund"
  }) {
    refund { id }
    userErrors { field message }
  }
}

The bug happens after the mutation.

You need a second step that checks the transaction state before customer-facing messaging.

Safer pattern

async function refundInShopify(orderId: string) {
  const refund = await shopify.refundCreate({ orderId });

  if (refund.userErrors?.length) {
    return { status: "failed", reason: refund.userErrors };
  }

  const txns = await shopify.getOrderTransactions(orderId);
  const refundTxn = txns.find(t => t.kind === "refund");

  if (!refundTxn) {
    return { status: "unknown", reason: "No refund transaction found" };
  }

  switch (refundTxn.status) {
    case "success":
      return { status: "completed", refundId: refund.refund.id };
    case "pending":
    case "processing":
      return { status: "pending", refundId: refund.refund.id };
    case "failure":
      return { status: "failed", refundId: refund.refund.id };
    default:
      return { status: "unknown", refundId: refund.refund.id };
  }
}

That one extra verification step changes the customer message from guesswork into something defensible.

2) Stripe: timeouts turn "retry" into a reliability bug

Stripe is where this gets dangerous.

Imagine this flow:

your agent sends POST /v1/refunds
network hiccup
worker times out
response never gets persisted
model decides to "try again"

Now you have uncertainty.

Did Stripe create the refund?
Did it fail?
Did it succeed and you just lost the response?

This is exactly why Stripe idempotency keys exist.

And too many agent workflows still treat idempotency as optional.

It’s not optional.

It’s the thing that lets you retry without destroying your chain of evidence.

Correct Stripe call

curl https://api.stripe.com/v1/refunds \
  -u "sk_test_...:" \
  -H "Idempotency-Key: 8b5b9f2e-6f8d-4f3d-a6d8-2f0f4d7f9c21" \
  -d charge=ch_123

Stripe stores the first result for a given idempotency key and returns the same status code and body on retries, including 500 errors. If you reuse the same key with different parameters, Stripe rejects it.

That means your workflow needs to persist the key before the call, not after.

Bad retry logic

async function badRefundRetry(chargeId: string) {
  try {
    return await stripe.refunds.create({ charge: chargeId });
  } catch {
    // terrible: new request identity, no certainty
    return await stripe.refunds.create({ charge: chargeId });
  }
}

Better retry logic

import { randomUUID } from "crypto";

async function createRefundWithRecovery(chargeId: string, existingKey?: string) {
  const idempotencyKey = existingKey ?? randomUUID();

  await db.refundAttempts.upsert({
    chargeId,
    idempotencyKey,
    status: "started"
  });

  try {
    const refund = await stripe.refunds.create(
      { charge: chargeId },
      { idempotencyKey }
    );

    await db.refundAttempts.update({
      chargeId,
      idempotencyKey,
      status: "completed",
      refundId: refund.id,
      rawResponse: JSON.stringify(refund)
    });

    return refund;
  } catch (err) {
    await db.refundAttempts.update({
      chargeId,
      idempotencyKey,
      status: "unknown",
      error: String(err)
    });

    throw err;
  }
}

That unknown state matters.

A lot of teams try to avoid it because it feels messy. But "unknown" is honest. Telling the model to guess is not.

3) Zendesk: async jobs and rate limits expose toy workflows fast

Zendesk is where polished demos usually fall apart.

Two reasons.

Rate limits are not a suggestion

Zendesk Support and Help Center API limits vary by plan. Responses can include headers like:

X-Rate-Limit: 700
X-Rate-Limit-Remaining: 699

If you hit the limit, you can get 429 Too Many Requests plus Retry-After.

A model that keeps hammering the API because it wants to be helpful is not helping.

It’s just an expensive loop.

Some actions are jobs, not immediate completion

Bulk ticket updates are a classic example.

The workflow sends the update, gets an acknowledgment, and assumes the tickets changed.

But Zendesk job statuses can sit in:

queued
working
failed
completed

If your agent refunds 40 orders and bulk-updates 40 tickets, you cannot assume the ticket side finished just because the first call returned 200 or 202.

You need to poll the job URL and reconcile failures.

Minimal polling example

async function waitForZendeskJob(jobStatusUrl: string) {
  for (let attempt = 0; attempt < 20; attempt++) {
    const job = await zendesk.get(jobStatusUrl);

    switch (job.status) {
      case "completed":
        return job;
      case "failed":
        throw new Error(`Zendesk job failed: ${job.id}`);
      case "queued":
      case "working":
        await sleep(3000);
        continue;
      default:
        throw new Error(`Unknown Zendesk job state: ${job.status}`);
    }
  }

  throw new Error("Zendesk job did not reach terminal state in time");
}

This is not glamorous engineering.

It is, however, the difference between a support agent that sounds polished and one that actually behaves reliably.

Prompt fixes vs orchestration fixes

This is the distinction I wish I had made earlier.

Approach	What it actually solves
Better prompts and tighter tool descriptions	Reduces bad reasoning and malformed calls before execution
Structured Outputs in GPT-4o or GPT-5	Improves schema adherence and valid arguments
Idempotency keys in Stripe and Shopify patterns	Prevents uncertainty and duplicate side effects during retries
Polling Shopify transactions and Zendesk jobs	Confirms real-world completion instead of assuming it
Durable state in LangGraph, n8n, or Make	Lets you recover after timeouts, 429s, crashes, or partial completion

This is why I think a lot of "LLM tool use reliability" discussions are framed too narrowly.

Once you touch money, tickets, orders, or customer records, you’re not debugging a chatbot anymore.

You’re doing distributed systems work.

The LLM is just one component in the chain.

What I trust now

If I had to compress this into one rule:

Never let the model communicate success from the first side-effecting response.

Here’s the cheat sheet.

| Check | Shopify refund flow | Stripe refund flow |
|----------|----------|
| Does the initial object guarantee money movement? | No. A Refund object alone is not proof the refund settled | Usually the refund response is the main record, but retries must preserve idempotency to keep certainty |
| Do you need post-call verification? | Yes. Check associated OrderTransaction status like pending, processing, success, or failure | Yes, especially after timeouts or network failures; verify using the same idempotent request history or follow-up retrieval |
| What should retries rely on? | Stored workflow state and explicit verification logic | The same idempotency key with the same parameters |

That last row is where a lot of agent workflows quietly fail.

Not because Shopify or Stripe are flaky.

Because the workflow was stateless during retries.

Do you need LangGraph, or are n8n / Make enough?

My opinion: not every support automation needs a full agent runtime.

If the flow is mostly deterministic:

look up order
issue refund
update ticket
send reply

Then n8n, Make, or even Zapier with explicit branches can be safer than an autonomous loop.

You can hard-code:

retries
wait steps
rate limit handling
persisted IDs
human escalation branches

If the workflow is more open-ended and needs resumability across long windows, partial failure recovery, or branching investigation, then LangGraph starts making more sense.

Tiny LangGraph skeleton

from langgraph.graph import StateGraph, MessagesState, START, END

def mock_llm(state: MessagesState):
    return {"messages": [{"role": "ai", "content": "hello world"}]}

graph = StateGraph(MessagesState)
graph.add_node(mock_llm)
graph.add_edge(START, "mock_llm")
graph.add_edge("mock_llm", END)
graph = graph.compile()
graph.invoke({"messages": [{"role": "user", "content": "hi!"}]})

That example is trivial.

The important part is the mindset shift: state transitions, checkpoints, resumability, deterministic recovery.

Not "maybe GPT-5 or Claude Opus 4.6 will be more careful next time."

The pattern that finally stopped the lying

What actually fixed this for me was boring.

I split the workflow into phases:

prepare the action with validated inputs
execute with an idempotency key or equivalent request identity
persist external IDs and raw responses immediately
verify downstream state in Shopify, Stripe, or Zendesk
communicate only from verified state
escalate ambiguous or non-terminal cases to a human

That did more for reliability than all the prompt tuning combined.

If you’re running AI agents in production, cost pressure makes this worse

There’s one more thing people don’t talk about enough: per-token pricing pushes teams toward bad reliability decisions.

When every retry, poll, verification step, and recovery branch feels like metered spend, people start trimming the boring parts.

They skip verification.
They shorten retries.
They avoid durable state.
They let the model improvise because it looks cheaper in the moment.

That is exactly backwards.

Production-grade agent workflows need room for:

retries
polling
recovery steps
reconciliation passes
long-running automations

That’s a big reason tools like Standard Compute are interesting to teams building support agents, n8n flows, Make scenarios, and custom automations. If you’re using the OpenAI-compatible API shape but want predictable flat-cost compute instead of per-token anxiety, it changes how aggressively you can design for reliability.

You stop asking, "Can we afford another verification pass?"

You start asking the better question:

"What would make this workflow stop lying to customers?"

That’s the right optimization target.

Final takeaway

If your refund agent sounds smart but sometimes lies, don’t assume the fix is a better prompt.

Check whether your workflow is doing any of these:

confirming success from an initial API response
retrying without idempotency
failing to persist request identity
skipping async job polling
sending customer-facing messages before reconciliation

That’s usually where the real bug lives.

The painful lesson for me was simple:

Side effects are not chat turns.

They’re distributed transactions wearing a chatbot costume.

And once you treat them that way, your agents get a lot less charming and a lot more trustworthy.

We rebuilt 47-node n8n flows until we admitted script-first AI workflows are just better

Lars Winstand — Sun, 20 Sep 2026 06:08:48 +0000

We rebuilt 47-node n8n flows until we admitted script-first AI workflows are just better

At 2:07 a.m., an n8n run failed because GPT-5.4 returned one ugly JSON blob that didn’t match what the next node expected.

Not a big outage. Not a total failure.

Just one malformed field buried inside a 47-node flow with branches, retries, fallback prompts, webhook handling, and a couple of emergency fixes living in an n8n Code node.

So we did the usual thing:

opened execution history
clicked through branches one by one
checked whether the parser broke
checked whether retry logic fired
checked whether Claude Opus 4.6 behaved differently on the previous run
tried to remember why one branch existed at all

An hour later, we were still debugging a flow that was supposed to save time.

That was the moment we stopped pretending visual AI workflows scale cleanly.

My opinion now is pretty simple:

Use n8n, Make, and Zapier for orchestration. Put the AI decision layer in code.

If your workflow has real branching, retries, schema validation, provider switching, and tests, script-first wins.

The problem isn't n8n

I like n8n.

It's great for:

webhooks
cron jobs
Slack notifications
database writes
approvals
app-to-app glue

Same story with Make and Zapier. They are useful because they remove a lot of boring integration work.

The problem starts when your workflow tool becomes your application runtime.

That works fine for deterministic automations.

It gets ugly fast when the core logic depends on LLMs.

AI workflows break in ways normal automations don't

A normal automation is usually predictable enough that a visual graph stays readable.

A lead comes in. You enrich it. You write to a CRM. You send a message.

Done.

AI automations are different.

Now you need to handle things like:

GPT-5.4 returning valid JSON 95 times and weird prose on the 96th
Claude Opus 4.6 extracting the right answer but missing your exact schema
Grok 4.20 being good enough for one classification step but not another
retries for rate limits, but not retries for bad outputs
fallback prompts only after validation fails
parsing rules shared across multiple automations
provider swaps without rewriting the whole flow

You can model all of that with nodes and branches.

We did.

That's also how you end up with a workflow nobody wants to touch.

The hidden tax is confidence

The biggest problem wasn't breakage.

It was confidence.

Once your business logic lives across dozens of workflow nodes, every change feels dangerous.

Rename one field? Maybe three branches break.

Swap one model? Maybe parsing changes in five places.

Add one retry path? Maybe a fallback branch now loops in a way nobody expected.

This is where Make routers and Zapier Paths hit the same wall too. They look manageable at first. Then AI edge cases pile up and the whole thing turns into a visual choose-your-own-adventure with no real test suite.

What we tried before moving logic into code

We tried to be disciplined inside the workflow builder.

We:

cleaned up node names
added comments
split branches more clearly
pushed parsing into an n8n Code node
tightened prompts
added validation steps
added retries

That helped for about five minutes.

The real problem was architectural.

We were using orchestration software as an app runtime.

That meant:

versioning was bad
reviewing changes was bad
reusing logic was bad
testing was mostly "run it and see"
rollback was clumsy
provider comparisons were annoying
debugging meant clicking through execution trails instead of reading logs

The breaking point came when we wanted to swap providers without rewriting the automation.

That should be a config change.

Inside a node maze, it turns into surgery.

What should stay in n8n vs what should move to code

Here's the split I wish we'd used earlier.

Keep in n8n / Make / Zapier	Move to code
Triggers	Prompt construction
Webhook entry points	JSON schema validation
Schedules	Retry policy
Human approvals	Fallback logic
App-to-app handoffs	Provider abstraction
Slack / email / CRM actions	Shared parsing rules
Database writes	Testable business logic

Short version:

workflow tools should orchestrate
code should decide

What script-first actually looks like

You don't need to throw away n8n.

Just stop asking it to own the hardest part.

A much better pattern is:

n8n receives the trigger
n8n sends data to a script or internal service
the service handles prompts, validation, retries, and model routing
the service returns a stable payload
n8n handles downstream actions

That service can be tiny. It doesn't need to be a giant platform.

It just needs to put the AI logic somewhere that Git, tests, logs, and refactors actually work.

A practical example

Let's say you have an n8n workflow that triages inbound support tickets.

The fragile version

Inside n8n:

call GPT-5.4
parse JSON
branch on category
retry on failure
call Claude Opus 4.6 if parsing fails
reformat output
branch again on urgency
send to Slack or Zendesk

This works until it doesn't.

The better version

n8n just calls your service:

curl -X POST http://internal-ai-service/triage \
  -H "Content-Type: application/json" \
  -d '{
    "ticket_id": "123",
    "subject": "Customer cannot log in",
    "body": "I reset my password twice and still get an error"
  }'

Your service handles the messy part.

import OpenAI from "openai";
import { z } from "zod";

const TicketSchema = z.object({
  category: z.enum(["billing", "bug", "account", "other"]),
  urgency: z.enum(["low", "medium", "high"]),
  summary: z.string(),
  needs_human: z.boolean()
});

const client = new OpenAI({
  apiKey: process.env.STANDARD_COMPUTE_API_KEY,
  baseURL: "https://api.standardcompute.com/v1"
});

export async function triageTicket(input: { subject: string; body: string }) {
  const response = await client.chat.completions.create({
    model: "openai/gpt-5.4",
    messages: [
      {
        role: "system",
        content: "Classify support tickets and return strict JSON only."
      },
      {
        role: "user",
        content: `Subject: ${input.subject}\n\nBody: ${input.body}`
      }
    ],
    response_format: { type: "json_object" }
  });

  const raw = response.choices[0]?.message?.content ?? "{}";
  const parsed = TicketSchema.parse(JSON.parse(raw));

  return parsed;
}

Now your workflow gets one stable response:

{
  "category": "account",
  "urgency": "high",
  "summary": "User cannot log in after password reset attempts.",
  "needs_human": true
}

That is way easier to reason about than 8 branches and 3 parser nodes.

Why this is better for developers

Once the AI layer is code-first, you get normal engineering tools back.

1. Real version control

You can review prompt changes in Git.

git diff

You can see exactly what changed in validation logic, retry policy, or provider selection.

2. Tests

You can write tests for the parts that matter.

import { describe, it, expect } from "vitest";

describe("triageTicket", () => {
  it("classifies login issues as account", async () => {
    const result = await triageTicket({
      subject: "Locked out",
      body: "Reset password twice, still can't log in"
    });

    expect(result.category).toBe("account");
  });
});

No, LLM tests won't be perfectly deterministic.

They're still better than clicking "Execute Workflow" and hoping.

3. Shared logic

One parser. One schema. One retry policy.

Used everywhere.

Not copied across five automations.

4. Provider abstraction

If GPT-5.4 is best for one task but Claude Opus 4.6 is better for another, that should be hidden behind one internal interface.

Something like:

export async function classify(input: string, provider: "gpt" | "claude" | "grok") {
  const modelMap = {
    gpt: "openai/gpt-5.4",
    claude: "anthropic/claude-opus-4.6",
    grok: "xai/grok-4.20"
  };

  return client.chat.completions.create({
    model: modelMap[provider],
    messages: [{ role: "user", content: input }]
  });
}

That is a small change in code.

Inside a giant workflow, it often becomes a full rewrite.

Why this matters even more for 24/7 agents

If a workflow runs twice a day, you can tolerate some mess.

If an agent runs all day processing tickets, leads, documents, or support threads, every weak spot turns into operational drag.

A flaky branch isn't a minor annoyance anymore.

It's a permanent tax.

This is also where cost and throughput start to matter.

Teams running AI agents in n8n, Make, Zapier, OpenClaw, or custom workflows usually do not want to babysit token spend while background jobs keep firing.

They want the automation to run.

That is one reason Standard Compute is interesting in this setup.

It gives you an OpenAI-compatible endpoint, so you can keep using the OpenAI SDK or any compatible HTTP client, while routing across GPT-5.4, Claude Opus 4.6, and Grok 4.20 behind the scenes.

More importantly, it's flat-rate instead of per-token.

That matters a lot for always-on automations, because architecture decisions stop being distorted by token anxiety.

You can keep the script-first pattern, keep your orchestration layer the same, and avoid rebuilding workflows every time model pricing or provider quality shifts.

A simple architecture that works

If I were starting over, I'd use this split:

n8n / Make / Zapier
  -> trigger, schedule, webhook, notifications
  -> call internal AI service

Internal AI service
  -> prompt construction
  -> model routing
  -> schema validation
  -> retries
  -> logging
  -> tests

Downstream systems
  -> Slack
  -> CRM
  -> database
  -> email

Boring architecture is underrated.

This one is boring in the best possible way.

Actionable rule of thumb

If your workflow has any of these, move the AI logic into code:

more than one model provider
strict JSON requirements
retries based on failure type
shared prompt logic
reusable validation
complex branching
production consequences when it breaks

Keep the workflow builder for orchestration.

Keep the brain in code.

Final take

The issue was never that n8n was bad.

The issue was that we kept asking n8n to do a job better handled by code.

Use n8n for orchestration.
Use Make for orchestration.
Use Zapier for orchestration.

But if your AI workflow has real logic, real retries, real validation, and real provider switching, put that part in a script or service.

We learned that after rebuilding broken flows more times than I'd like to admit.

I wouldn't go back.

If you're already running AI automations this way, I'm curious where you draw the line between workflow builder and code.

I tested VM vs Docker security for agent workers because “just use Docker” stopped feeling like an answer

Lars Winstand — Sat, 19 Sep 2026 22:09:07 +0000

A few months ago, I caught myself saying something I’d heard a hundred times before:

Just run it in Docker.

And the second it came out of my mouth, it sounded weak.

Because we weren’t talking about a boring internal cron job.

We were talking about agent workers that:

open browser sessions
run generated code
call external APIs
ingest weird files and HTML
sometimes touch customer data

That’s a very different threat model from “containerize the app and move on.”

So I went back to the docs instead of repeating container folklore.

The answer I landed on is not “Docker is unsafe” and it’s not “VMs everywhere.”

It’s this:

Docker shares the host Linux kernel. VMs and microVMs add a stronger isolation boundary. For trusted internal jobs, hardened rootless Docker is often enough. For browser agents, generated code, or multi-tenant data, I’d choose a VM or microVM.

If you’re building workers for n8n, OpenClaw, Playwright, custom GPT-5 workflows, Claude-powered automations, or anything that looks like an AI agent runtime, the distinction matters.

The sentence in Docker’s docs that changed the whole conversation

Docker is actually pretty clear if you read the security docs.

Containers are not tiny VMs.

They rely on the host Linux kernel for isolation.

VMs don’t. They add a hardware virtualization boundary between guest and host.

That sounds obvious, but people still talk about Docker like it creates a hard wall by default. It doesn’t.

Docker’s security model explicitly points you toward four areas:

kernel namespaces and cgroups
the Docker daemon attack surface
container configuration loopholes
kernel hardening features

That list tells you a lot.

If your security argument is just “it’s in a container,” you’re skipping the part where Docker itself says configuration, daemon exposure, and kernel hardening all matter.

That was my first real takeaway:

Containerization is a starting point, not an isolation guarantee.

When Docker is actually enough

My opinion after re-reading all this:

Docker is often fine for trusted, single-tenant internal workers.

Example:

internal automation triggered by your own team
structured inputs
calls to Notion, HubSpot, Salesforce, PostgreSQL
no arbitrary code execution
no hostile user content

That does not automatically require a VM.

But there’s a huge difference between hardened Docker and lazy Docker.

The lazy version vs the version I’d actually trust

The lazy version

This is the version I see all the time:

rootful Docker
default seccomp
broad Linux capabilities
writable filesystem
wide-open egress
loose volume mounts
default networking
no AppArmor tuning

That setup is common.

It’s also the exact setup behind a lot of false confidence.

The version I’d trust for lower-risk workers

For a lower-risk internal worker, I’d want at least:

rootless Docker
dropped Linux capabilities
read-only filesystem where possible
tight volume mounts
outbound network restrictions
AppArmor or another LSM policy
a reviewed seccomp profile

That still does not give you VM-grade isolation.

But it does materially reduce risk.

Rootless Docker is the first upgrade I’d make

If I inherit a sketchy worker box running Playwright, Python job runners, or n8n sidecars, the first thing I’d check is whether Docker is running rootless.

Why?

Because in rootless mode, both the Docker daemon and containers run as a non-root user.

That changes the blast radius in a meaningful way.

You can check the subordinate UID/GID mappings like this:

grep ^$(whoami): /etc/subuid
grep ^$(whoami): /etc/subgid

Docker rootless mode expects subordinate ID ranges, typically at least 65536 IDs.

Setup looks like this:

dockerd-rootless-setuptool.sh install

That’s not a marketing checkbox. It’s a real change to how privilege is handled.

If your current answer to agent isolation is “we use Docker,” but you’re still running rootful with broad defaults, I would fix that before arguing about anything fancier.

Seccomp helps, but it doesn’t turn a container into a VM

This is another place where people overstate things.

Docker’s default seccomp profile is useful.

It blocks a set of syscalls and reduces attack surface.

That’s good.

But it is not a magic sandbox.

You can run with a custom seccomp profile like this:

docker run --rm -it \
  --security-opt seccomp=/path/to/seccomp/profile.json \
  hello-world

And if the workload is sensitive enough, you probably should.

Same story for:

dropping capabilities
using no-new-privileges
applying AppArmor
locking down mounts

Example:

docker run --rm \
  --read-only \
  --cap-drop=ALL \
  --security-opt no-new-privileges:true \
  --pids-limit=256 \
  my-worker:latest

That’s real hardening.

But the core fact does not change:

A hardened container is still a shared-kernel model.

That matters a lot once your workers start doing agent-like things.

The moment I stop trusting plain containers

This is where my opinion gets less diplomatic.

If a worker does any of the following, I think VM or microVM should be the default:

runs browser agents with persistent sessions
executes generated code from an LLM
handles customer data across tenants
pulls untrusted files, repos, PDFs, or HTML
needs a security story that survives audit or review

Why?

Because these workloads are messy.

A browser agent is basically an automation engine pointed at untrusted content.

A code-executing agent is literally running output you didn’t hand-write.

A multi-tenant worker means one mistake can become a cross-customer incident.

At that point, “we hardened Docker pretty well” starts sounding less like a strategy and more like a hope.

Why gVisor, Kata Containers, and Firecracker exist

The industry has already answered this problem several times.

That’s why tools like these exist:

gVisor
Kata Containers
Firecracker

They all try to close the gap between container ergonomics and stronger isolation.

gVisor

gVisor adds an extra defense layer by interposing a user-space kernel boundary.

That’s useful when you still want container UX but don’t love the idea of untrusted code talking so directly to the host kernel.

Kata Containers

Kata Containers uses lightweight VMs as a second isolation layer.

That makes sense for teams that want something container-shaped operationally, but with stronger boundaries.

Firecracker

Firecracker is the one that made me take microVMs more seriously.

It’s purpose-built for lightweight virtualization with minimal device surface and fast startup.

And this is not lab-only infrastructure.

Firecracker underpins AWS Lambda and AWS Fargate-style isolation patterns at enormous scale.

That matters because it proves the model is practical, not theoretical.

My practical map of the options

Option	What I’d use it for
Rootless Docker	Trusted or moderately risky internal workers where shared-kernel isolation is acceptable and the team will actually harden the runtime
gVisor	Untrusted code where container UX still matters and you want stronger syscall isolation than plain Docker
Kata Containers / Firecracker microVMs	Browser agents, code execution, or sensitive multi-tenant workflows where stronger isolation is worth the operational complexity

That’s the trade space as I see it.

Not ideological. Just matching the boundary to the workload.

What you pay for stronger isolation

Nothing about stronger isolation is free.

You usually pay in some combination of:

startup latency
throughput
memory overhead
compatibility quirks
operational complexity
debugging pain

That’s why I also don’t agree with “always use VMs.”

If the workload is low-risk and trusted, the VM tax can be unnecessary.

But if the workload is externally influenced, chaotic, or tenant-sensitive, that tax starts looking cheap.

A concrete way to think about it

Here’s a rough decision tree I’d use.

Use hardened rootless Docker when

the worker is single-tenant
inputs are mostly trusted
it does not execute arbitrary user-supplied code
it does not process especially sensitive cross-customer data
your team is willing to maintain hardening over time

Use a VM or microVM when

the worker runs browser automation or browser agents
the worker executes generated code
the worker processes untrusted files or web content
the worker serves multiple customers or tenants
you need a cleaner security story for compliance or review

That’s the practical answer I wish people gave more often.

Example: a low-risk internal worker

This is the kind of job I’m comfortable running in hardened Docker:

triggered by an internal webhook
reads rows from PostgreSQL
calls HubSpot and Slack
writes results back
no arbitrary code execution
no browsing random websites

A run command might look something like:

docker run -d \
  --read-only \
  --cap-drop=ALL \
  --security-opt no-new-privileges:true \
  --pids-limit=256 \
  --memory=512m \
  --cpus=1 \
  --network=internal_only \
  -v /app/tmp:/tmp:rw \
  my-internal-worker:latest

I still wouldn’t call that bulletproof.

I would call it proportionate.

Example: a worker I would move to a microVM immediately

This one is different:

accepts prompts from users
launches Playwright or Chrome
logs into third-party sites
downloads files
runs generated Python or JavaScript
stores session state
serves multiple customers

That is microVM territory for me.

Not because containers are useless.

Because the workload is too exposed, too dynamic, and too difficult to reason about with a shared kernel boundary.

This gets more relevant as AI agents get cheaper to run

There’s also an operational angle here.

As more teams run agents continuously, cost pressure pushes them toward denser infrastructure and more automation.

That’s exactly where people start making dangerous simplifications like:

put more workers on the same host
let them run longer
allow browser sessions to persist
execute more generated code
stop watching per-run cost so closely

I actually think predictable compute pricing makes this easier to reason about operationally.

If you’re running lots of agent calls through an OpenAI-compatible endpoint like Standard Compute, you can stop obsessing over token billing and spend more time deciding where the real risk boundary should be.

That’s the part people miss.

Cheap or flat-rate model access does not remove the need for isolation.

It increases the odds that you’ll run more autonomous workloads, more often, with less human supervision.

Which makes the isolation decision more important, not less.

The part that surprised me most

I expected the answer to be mostly about technology.

It wasn’t.

It was about honesty.

If someone says:

We run it in Docker.

That can mean two very different things:

we put a risky workload in a shared-kernel environment and did serious hardening
we put a risky workload in a shared-kernel environment and hoped the defaults were enough

Those are not the same sentence.

For simple internal automations, Docker is often fine.

For browser workers, code-executing agents, and customer-data workflows, I think VM or microVM is the safer default.

Not because I’m anti-container.

Because the docs are pretty clear once you stop treating “just use Docker” like a complete answer.

My current rule of thumb

If I trust the inputs and the blast radius is small, I’ll use hardened rootless Docker.

If the worker browses the web, runs generated code, or touches multiple customers’ data, I want a VM or microVM boundary.

That’s the line.

And honestly, I think more agent infrastructure should start there.

If you’re building AI workers on n8n, Make, Zapier, OpenClaw, or custom frameworks, this is also a good reminder to separate two decisions that people keep mixing together:

how you call the model
how you isolate the worker

For the first problem, using an OpenAI-compatible endpoint with predictable pricing like Standard Compute can make agent workloads much easier to operate at scale.

For the second problem, don’t let flat-rate inference lull you into weak runtime isolation.

Different layer. Different risk. Same production system.

We kept arguing about GPT vs Claude and missed the 2x long-context cost blowing up our agent runs

Lars Winstand — Sat, 19 Sep 2026 14:09:28 +0000

A thing finally clicked for me while debugging an agent trace:

we were spending way too much time arguing about model choice, and not enough time looking at the giant pile of context getting replayed on every step.

Not user intent.
Not fresh instructions.
Just baggage.

Old tool output. Debug blobs. Previous assistant replies. Summaries of summaries. Random thread history nobody trimmed.

That stuff is easy to ignore because it accumulates one harmless-looking decision at a time.

But in a lot of agent workflows, especially tool-heavy ones, that is where the bill gets weird.

The hidden cost wasn't the model switch

The contrarian take:

For a lot of agent pipelines, repeated input context matters more than the headline per-token rate.

OpenAI's current pricing makes this painfully obvious. Long-context input is priced at 2x short-context input across the lineup, and long-context output is 1.5x higher too.

One concrete example:

gpt-5.6-terra short-context input: $1.00 / MTok
gpt-5.6-terra long-context input: $2.00 / MTok
gpt-5.6-terra short-context output: $6.00 / MTok
gpt-5.6-terra long-context output: $9.00 / MTok

Same model. Same app. Same team.

The only difference is that one request is dragging around more history.

That means a bloated thread can become a pricing decision all by itself.

What this looks like in real agent code

A lot of memory bugs don't look like bugs.

They look like normal code:

from langchain.agents import create_agent
from langgraph.checkpoint.memory import InMemorySaver

agent = create_agent(
    model="google_genai:gemini-3.6-flash",
    tools=[get_user_info],
    checkpointer=InMemorySaver(),
)

thread_config = {"configurable": {"thread_id": "1"}}

Nothing scary there.

But if that thread stays alive across multiple tool-heavy runs, the agent can keep pulling old state into new calls unless you explicitly trim or summarize it.

And once tools are involved, each turn can add:

system instructions
user messages
assistant replies
tool calls
tool outputs
intermediate state
summaries
more summaries later

A simple chatbot grows slowly.
A workflow agent grows like a log file nobody rotates.

The biggest source of junk: tool output

This is the one I see most often.

A tool returns a huge JSON payload, and someone decides to pass the whole thing back into the next model call "just in case."

Example:

{
  "customer_id": "cus_123",
  "tickets": [... 400 records ...],
  "recent_orders": [... 80 records ...],
  "audit_log": [... 1200 events ...],
  "crm_notes": "very long string..."
}

Then the next step asks something tiny like:

Should we escalate this support ticket?

That decision probably needs 10 facts, not 10,000 tokens.

A better pattern is:

raw_result = fetch_customer_context(customer_id)
store_raw_result(raw_result)

summary = {
    "customer_id": raw_result["customer_id"],
    "open_ticket_count": len(raw_result["tickets"]),
    "recent_order_count": len(raw_result["recent_orders"]),
    "has_refund_last_30_days": has_recent_refund(raw_result),
    "priority_signals": extract_priority_signals(raw_result),
}

messages.append({
    "role": "tool",
    "content": json.dumps(summary)
})

Keep the raw data outside the prompt.
Pass only the facts needed for the next decision.

Observability data is not prompt data

LangSmith traces are useful.
OpenTelemetry spans are useful.
Debug logs are useful.

That does not mean they belong in your next model call.

I've seen teams accidentally turn observability into recurring token spend by mirroring traces back into prompts so the model is "fully informed."

That usually does two bad things at once:

increases cost
makes the model worse

Too much stale context doesn't just cost more. It distracts the model.

If your agent keeps seeing old tool results, outdated instructions, and irrelevant history, it starts anchoring on the wrong stuff.

So this is not only a pricing problem.
It's also an accuracy problem.

Doesn't prompt caching solve this?

No.

It helps, but it does not make sloppy context free.

OpenAI still charges for cached input and cache writes.
For gpt-5.6-terra:

cached input short-context: $0.10 / MTok
cached input long-context: $0.20 / MTok
cache write short-context: $1.25 / MTok
cache write long-context: $2.50 / MTok

Anthropic has the same basic story with different numbers. Claude Opus 4.6 pricing includes:

input: $5 / MTok
output: $25 / MTok
5-minute cache write: $6.25 / MTok
1-hour cache write: $10 / MTok
cache hit/refresh: $0.50 / MTok

Google Gemini also treats caching as a paid feature. Gemini 3.8 Flash in the paid tier is:

input: $1.50 / MTok
output: $3.75 / MTok
context caching: $0.15 / MTok
cache storage fee starts in 2027

So yes, cache stable instructions and repeated reference material.

But don't confuse:

discounted repetition

with:

no consequence

The pricing differences that actually matter

Model pricing matters.
Model quality matters.

If Claude Opus 4.6 solves a planning task that Claude Haiku 4.5 keeps fumbling, paying more can be completely rational.

If GPT-5 handles tool use or reasoning better for your workload, same story.

But if your workflow is replaying irrelevant history on every step, even the cheaper model becomes an expensive habit.

Here's the cleaner way to think about it:

Model / pricing view	Key numbers
OpenAI short vs long context	`gpt-5.6-terra`: short input `$1.00/MTok`, long input `$2.00/MTok`; short output `$6.00/MTok`, long output `$9.00/MTok`; cached input `$0.10/$0.20`; cache writes `$1.25/$2.50`
Anthropic Claude Opus 4.6	Input `$5/MTok`, output `$25/MTok`, 5-minute cache writes `$6.25/MTok`, 1-hour cache writes `$10/MTok`, cache hits/refreshes `$0.50/MTok`
Anthropic Claude Sonnet 5	Input `$2/MTok`, output `$10/MTok`
Anthropic Claude Haiku 4.5	Input `$1/MTok`, output `$5/MTok`
Google Gemini 3.8 Flash	Input `$1.50/MTok`, output `$3.75/MTok`, context caching `$0.15/MTok`, batch pricing is 50% lower

If you only compare vendors, you'll debate forever.

If you inspect your traces, you'll ask the better question:

why is this workflow paying to remember things it no longer needs?

5 practical fixes that reduce context without breaking the workflow

You do not need a PhD in memory architecture for this.

You need rules.

1. Stop replaying raw tool output by default

If Salesforce, Jira, GitHub, Discord, or your internal API returns a giant object, do not feed the whole thing back into the model unless the next step actually needs it.

Summarize first.
Store the raw payload elsewhere.

2. Split working memory from audit memory

Your prompt is not your log sink.

Keep detailed traces in LangSmith, OpenTelemetry, Datadog, ClickHouse, BigQuery, or wherever you want.

But only pass the model what it needs for the next decision.

Working memory and audit memory should be different structures.

3. Summarize at step boundaries

After every major tool call, compress the result into:

facts
decisions made
unresolved questions
next action

Example:

def compress_tool_result(result: dict) -> dict:
    return {
        "facts": extract_facts(result),
        "decisions": extract_decisions(result),
        "open_questions": extract_open_questions(result),
        "next_action": suggest_next_action(result),
    }

This is one of the easiest ways to keep multi-step agent runs from ballooning.

4. Reset threads more often

A lot of workflows should start fresh more often than they do.

If an n8n flow or Make scenario is really a new job, give it a new thread.

Don't let today's invoice lookup inherit yesterday's support escalation history just because both touched the same account.

5. Keep stable instructions stable

Large reusable instructions can benefit from caching.

But volatile task state should stay separate.

A small message list is often healthier than a giant rolling transcript:

messages = [
  {"role": "system", "content": "You are a helpful assistant."},
  {"role": "user", "content": "Summarize the latest support ticket and decide whether it needs escalation."}
]

response = model.invoke(messages)

Simple beats clever more often than agent builders like to admit.

Quick way to audit your own agent

If you want a fast sanity check, log token counts and payload sizes per step.

For example:

def log_prompt_stats(step_name: str, messages: list[dict]):
    total_chars = sum(len(m.get("content", "")) for m in messages if isinstance(m.get("content"), str))
    print({
        "step": step_name,
        "message_count": len(messages),
        "approx_chars": total_chars,
    })

Or if you're debugging a workflow locally, dump request bodies and inspect them:

jq '.messages | length' request.json
jq '.messages[].role' request.json
jq -r '.messages[].content' request.json | wc -c

You will usually find one of these:

repeated system instructions
giant tool payloads
stale conversation turns
duplicated summaries
debug data that should never have been in the prompt

What if you actually need long context?

Sometimes you do.

Codebase-wide reasoning, contract analysis, compliance workflows, and deep research can genuinely need large windows.

I'm not saying long context is fake.
I'm saying default long context is lazy architecture.

If you need it, use it deliberately.
Route to it selectively.
Budget for it.

Treat expensive inference modes like an operational choice, not an accidental side effect of thread sprawl.

The weird part: oversized context can make agents dumber

This was the part that surprised me most.

I expected bloated context to cost more.
I didn't expect it to so reliably make agents worse.

But once you see it, it's obvious.

The agent starts:

anchoring on stale instructions
revisiting old tool results
answering the question from three turns ago
slowing down because every call carries too much baggage

So yes, model choice matters.

But if your memory policy is a mess, benchmarking GPT-5 vs Claude Opus 4.6 vs Grok 4.20 is a little like comparing race cars while towing a dumpster.

My practical takeaway

Before you switch models, inspect what your agent is dragging into every call.

Cut stale turns.
Summarize tool output.
Separate traces from prompts.
Reset threads more often.
Use long context only when the task actually needs it.

Most teams do not have a model problem first.

They have a context hygiene problem with a pricing symptom.

One more thing: this is exactly why flat-rate AI compute is appealing

If you're running agents all day in n8n, Make, Zapier, OpenClaw, or custom workflows, per-token billing pushes teams into constant cost babysitting.

And the worst part is that a lot of the cost comes from architecture mistakes like context sprawl, not from doing more useful work.

That's a big reason products like Standard Compute are interesting: you get an OpenAI-compatible API, flat monthly pricing, and dynamic routing across models like GPT-5.4, Claude Opus 4.6, and Grok 4.20 without every extra tool trace turning into another finance discussion.

You still want clean prompts. Bad context can still hurt quality.

But removing per-token anxiety makes it much easier to build agents that run continuously without treating every long thread like a budget incident.

If you're building serious automations, that's a much better default than staring at token dashboards all week.

OAuth redirect URI mismatch ate more time than my agent logic — 5 setup changes that finally fixed Google, Slack, and HubSpot

Lars Winstand — Sat, 19 Sep 2026 06:09:15 +0000

I lost more time to oauth redirect uri mismatch than to the actual agent logic.

Not the Gmail classification prompt.
Not the Slack bot scopes.
Not the HubSpot sync code.

Just OAuth.

The pattern was always the same:

localhost worked
staging mostly worked
production failed with a vague callback error

If you're building AI automations with Node.js, n8n, Slack apps, HubSpot apps, or Google integrations, this usually isn't random bad luck.

It's architecture.

The fix for us was boring but effective:

one credential set per environment
exact callback registration for each provider
stable public base URLs
logging the actual redirect_uri being sent
restarting workers after config changes

Once we did that, the "mystery OAuth bug" disappeared.

The real problem: your callback URL is telling two different stories

Most teams assume OAuth failures mean the integration logic is broken.

So they start debugging:

prompt formatting
token storage
webhook handling
SDK versions
queue workers

Meanwhile the actual problem is usually this:

Expected redirect URI:
https://app.example.com/auth/google/callback

Actual redirect URI sent:
https://api.example.com/auth/google/callback

Or this:

https://app.example.com/auth/slack/callback

https://www.example.com/auth/slack/callback

Or this:

http://staging.example.com/auth/hubspot/callback

when the provider expects HTTPS.

OAuth is extremely literal.

Your app can be conceptually correct and still fail because one URL string doesn't match exactly.

What bit us across Google, Slack, and HubSpot

Here's the short version.

Provider	What bites builders most often
Google OAuth 2.0 for Web Server Apps	Redirect URI must match exactly. Teams also confuse localhost/native app patterns with real web-server OAuth.
Slack OAuth v2	If you send `redirect_uri` in the authorize step, you must send the exact same `redirect_uri` again during token exchange.
HubSpot OAuth 2.0	`redirect_uri` is required, production redirects must use HTTPS, and app install often fails because the user is not a Super Admin.

None of these providers are especially weird.

The weirdness comes from our stack:

frontend on one domain
API on another
reverse proxy in front
background workers with stale env vars
an automation tool generating callback URLs from the wrong base URL

That combination creates bugs that feel random until you log the exact values.

1) Google: exact match means exact match

Google was the easiest to misunderstand because local prototypes create bad habits.

A lot of teams build something that works on localhost, then move it behind Vercel, Nginx, Cloud Run, or a custom Express server and assume the OAuth flow will survive the move.

Sometimes it doesn't.

For Google web-server OAuth, the registered redirect URI must match the one you send exactly.

Not "same route, different host." Not "same callback, but HTTPS gets added later by the proxy."

Exact.

Example

Registered in Google Cloud Console:

https://app.example.com/auth/google/callback

Generated by app code:

const redirectUri = `${process.env.PUBLIC_API_BASE_URL}/auth/google/callback`;

If PUBLIC_API_BASE_URL is accidentally set to:

PUBLIC_API_BASE_URL=https://api.example.com

then your flow is dead before your agent code runs.

A simple Node example

import { google } from "googleapis";

const oauth2Client = new google.auth.OAuth2(
  process.env.GOOGLE_CLIENT_ID,
  process.env.GOOGLE_CLIENT_SECRET,
  process.env.GOOGLE_REDIRECT_URI
);

const authUrl = oauth2Client.generateAuthUrl({
  access_type: "offline",
  scope: [
    "https://www.googleapis.com/auth/gmail.readonly",
    "https://www.googleapis.com/auth/drive.readonly"
  ],
  prompt: "consent"
});

console.log("Google auth URL:", authUrl);
console.log("Google redirect URI:", process.env.GOOGLE_REDIRECT_URI);

That last log line matters more than people think.

2) Slack: the same redirect URI has to appear twice

Slack was the one that felt unfair until I reread the docs carefully.

The trap is simple:

you send users to Slack's authorize URL
you include redirect_uri
Slack sends back a code
your backend exchanges the code for a token
but your backend uses a different redirect_uri, or omits it

Result: failure.

If you include redirect_uri during authorization, Slack expects the exact same value during token exchange.

Authorize step

const params = new URLSearchParams({
  client_id: process.env.SLACK_CLIENT_ID,
  scope: "chat:write,channels:history",
  redirect_uri: process.env.SLACK_REDIRECT_URI
});

const url = `https://slack.com/oauth/v2/authorize?${params.toString()}`;
console.log(url);

Token exchange step

const body = new URLSearchParams({
  client_id: process.env.SLACK_CLIENT_ID,
  client_secret: process.env.SLACK_CLIENT_SECRET,
  code,
  redirect_uri: process.env.SLACK_REDIRECT_URI
});

const response = await fetch("https://slack.com/api/oauth.v2.access", {
  method: "POST",
  headers: {
    "Content-Type": "application/x-www-form-urlencoded"
  },
  body
});

If those two redirect_uri values differ, Slack is not the problem.

Your app is.

Another Slack gotcha: scopes are split

Slack also separates:

scope for bot scopes
user_scope for user scopes

I've seen teams mis-spec scopes, then blame OAuth in general.

That bug looks a lot like redirect trouble at first because the install flow still fails.

3) HubSpot: sometimes the URL is fine and the installer is wrong

HubSpot gave us the most annoying fake OAuth bug.

The flow itself is straightforward:

send user to HubSpot authorize URL
user approves scopes
HubSpot redirects back with code
backend exchanges code for token

Basic example:

const params = new URLSearchParams({
  client_id: process.env.HUBSPOT_CLIENT_ID,
  redirect_uri: process.env.HUBSPOT_REDIRECT_URI,
  scope: "crm.objects.contacts.read crm.objects.contacts.write",
  state: crypto.randomUUID()
});

const installUrl = `https://app.hubspot.com/oauth/authorize?${params.toString()}`;
console.log(installUrl);

The obvious rule is that redirect_uri is required.

The less obvious operational rule is that production redirects need HTTPS.

But the one that wasted the most time for us was permissions.

A user often needs Super Admin rights to install the app in a HubSpot account.

So if your rollout fails, don't immediately assume:

your token exchange code is wrong
your callback route is broken
your state parameter failed

Sometimes the installer just isn't allowed to approve the app.

That is not a code bug. It's an account-role problem wearing a code-bug costume.

The 5 setup changes that finally fixed it

This is the part I wish someone had handed me on day one.

1. One credential set per environment

Stop trying to make one OAuth app serve localhost, staging, and production cleanly.

Use separate credentials.

Examples:

Google OAuth client for local
Google OAuth client for staging
Google OAuth client for prod
separate Slack app config or redirect setup per environment
separate HubSpot app settings where needed

Example env files

# .env.local
GOOGLE_REDIRECT_URI=http://localhost:3000/auth/google/callback
SLACK_REDIRECT_URI=http://localhost:3000/auth/slack/callback
HUBSPOT_REDIRECT_URI=http://localhost:3000/auth/hubspot/callback

# .env.staging
GOOGLE_REDIRECT_URI=https://staging.example.com/auth/google/callback
SLACK_REDIRECT_URI=https://staging.example.com/auth/slack/callback
HUBSPOT_REDIRECT_URI=https://staging.example.com/auth/hubspot/callback

# .env.production
GOOGLE_REDIRECT_URI=https://app.example.com/auth/google/callback
SLACK_REDIRECT_URI=https://app.example.com/auth/slack/callback
HUBSPOT_REDIRECT_URI=https://app.example.com/auth/hubspot/callback

This feels tedious right up until it saves you two days.

2. Register every exact callback URL

Not just the base domain.

Not just one callback path you hope can cover everything.

http://localhost:3000/auth/google/callback
https://staging.example.com/auth/google/callback
https://app.example.com/auth/google/callback
https://app.example.com/auth/slack/callback
https://app.example.com/auth/hubspot/callback

If your app uses different subdomains for API and UI, decide which one owns the callback and stick to it.

3. Use one stable public base URL

A lot of OAuth bugs are really bad URL generation.

The app builds redirect URIs from:

request headers
internal container hostnames
editor URLs
proxy-forwarded hosts
stale env vars

That is how you end up with callbacks pointing at the wrong domain.

I prefer making the public base URL explicit.

Example

PUBLIC_APP_URL=https://app.example.com
PUBLIC_API_URL=https://api.example.com

Then build callbacks from one canonical value:

const GOOGLE_REDIRECT_URI = `${process.env.PUBLIC_APP_URL}/auth/google/callback`;
const SLACK_REDIRECT_URI = `${process.env.PUBLIC_APP_URL}/auth/slack/callback`;
const HUBSPOT_REDIRECT_URI = `${process.env.PUBLIC_APP_URL}/auth/hubspot/callback`;

If you're using n8n or similar tools, the public URL config matters a lot.

Example:

export VUE_APP_URL_BASE_API=https://n8n.example.com/

If the editor thinks it's running at one URL and the backend tells Google or Slack another story, you'll keep chasing ghosts.

4. Log the outbound authorize URL and inbound callback details

This was the biggest practical win.

Log:

full authorize URL
exact redirect_uri
exact state
callback host/path/query
token exchange payload fields

Not secrets, obviously.

Just enough to compare what you intended with what actually happened.

Express middleware example

app.get("/auth/google/start", (req, res) => {
  const redirectUri = process.env.GOOGLE_REDIRECT_URI;
  const state = crypto.randomUUID();

  const authUrl = oauth2Client.generateAuthUrl({
    access_type: "offline",
    scope: ["https://www.googleapis.com/auth/gmail.readonly"],
    state
  });

  console.log("[google:start] redirect_uri=", redirectUri);
  console.log("[google:start] state=", state);
  console.log("[google:start] authUrl=", authUrl);

  res.redirect(authUrl);
});

app.get("/auth/google/callback", (req, res) => {
  console.log("[google:callback] host=", req.get("host"));
  console.log("[google:callback] originalUrl=", req.originalUrl);
  console.log("[google:callback] query=", req.query);

  res.send("ok");
});

The first time you compare these logs across local, staging, and prod, the mismatch usually becomes obvious.

5. Restart workers after config changes

This sounds embarrassingly basic because it is.

But long-running processes love stale config:

queue consumers
webhook handlers
background job runners
AI agent workers

You update the dashboard or environment variables, but a worker still has the old redirect base cached in memory.

Typical restart commands

pm2 restart all

docker compose restart

kubectl rollout restart deployment/my-api
kubectl rollout restart deployment/my-workers

We had workers generating old callback domains hours after the fix was supposedly deployed.

That bug felt supernatural until we realized the processes had never reloaded.

A quick debugging checklist

When OAuth fails, this is the checklist I use now.

Redirect URI sanity check

echo $GOOGLE_REDIRECT_URI
echo $SLACK_REDIRECT_URI
echo $HUBSPOT_REDIRECT_URI

Confirm what the app is actually sending

grep -R "redirect_uri" ./src

Inspect the callback route in logs

tail -f logs/app.log | grep callback

Verify HTTPS in production

curl -I https://app.example.com/auth/google/callback
curl -I https://app.example.com/auth/slack/callback
curl -I https://app.example.com/auth/hubspot/callback

Check for proxy/header weirdness

app.set("trust proxy", true);

app.use((req, _res, next) => {
  console.log({
    protocol: req.protocol,
    host: req.get("host"),
    forwardedProto: req.get("x-forwarded-proto"),
    forwardedHost: req.get("x-forwarded-host")
  });
  next();
});

If your app is behind a proxy and doesn't trust forwarded headers correctly, it may generate the wrong public URL.

One question that can remove a lot of OAuth pain

Do you actually need user OAuth?

A lot of internal automations don't.

If you're acting on shared infrastructure or project-owned resources, service accounts can be much simpler than user-consent flows.

That won't replace Slack workspace installs or HubSpot app installs, obviously.

But for some Google workflows, it's the difference between:

handling consent screens
storing refresh tokens
managing callback URLs

and just using system-level credentials.

Ask that question early.

It can save a stupid amount of time.

Why this matters more for AI agents and automations

This problem gets worse when your stack includes:

n8n
Make
Zapier
custom Node.js backends
Slack bots
CRM sync workers
Gmail or Drive agents
long-running background jobs

Agent systems are already distributed.

Now add OAuth on top and every blurry architecture boundary gets exposed immediately.

That's why these bugs feel so expensive.

You're not just debugging one app.

You're debugging identity across multiple services, multiple environments, and multiple callback assumptions.

The lesson I took from this

OAuth isn't hard because the protocol is mysterious.

It's hard because it forces your architecture to stop lying.

If local, staging, and production are fuzzy, OAuth will find the fuzziness.

If your callback URL depends on whichever host answered the request, OAuth will punish that.

If your HubSpot installer doesn't have Super Admin rights, no amount of token debugging will save you.

The practical fix is boring:

separate credentials by environment
register exact callback URLs
use a stable public base URL
log what you actually send
restart every process that might cache config

Do that, and your agents can go back to failing for interesting reasons.

One last thing: this is exactly the kind of problem that gets worse when every retry, every background worker run, and every agent loop has a per-token or per-call cost attached.

If you're running lots of AI automations and agent workflows, predictable infrastructure matters just as much as correct OAuth setup. That's a big part of why Standard Compute exists: flat monthly AI compute for teams running automations all day, without watching token burn every time a workflow retries.

If that's your situation, Standard Compute is worth a look: https://standardcompute.com

The most expensive part of my agent stack wasn’t tokens — it was the invoice roulette

Lars Winstand — Thu, 17 Sep 2026 22:09:54 +0000

I hit a weird point with my agent stack a few months ago.

Not when prompts were bad.
Not when tools were failing.
Not when n8n was half-broken.

It happened after everything started working.

The flows were stable. The AI Agent node in n8n was calling tools correctly. OpenClaw was keeping assistants alive across Slack and Discord. Background jobs were running. Users were happy.

Then I opened the invoice.

And I had that very specific engineering feeling: I understood every moving part individually, but I still could not predict the total cost.

That was the moment I stopped thinking about AI cost as “price per token” and started thinking about billing volatility as an architecture problem.

If you run agents 24/7, especially across n8n, Make, Zapier, OpenClaw, or custom workflows, this matters more than most pricing pages admit.

The trap: tokens are not the real unit of cost

At prototype stage, token math feels clean.

You estimate:

average prompt size
average response size
expected request volume
maybe a little buffer

That works for chat demos.

It breaks for automations.

An agent workflow is not one request. It is a chain reaction.

A single inbound event can trigger:

one LLM call to interpret the task
one or more tool calls
another LLM call to summarize tool output
retries after a timeout
fallback to another provider after a rate limit
an error workflow that replays part of the execution

What looked like “1 event = 1 model call” turns into “1 event = 7 billable things plus side effects.”

That is why production cost gets weird fast.

A simple example from n8n

Here is the kind of flow that looks cheap on a whiteboard and expensive in production:

Webhook receives a support ticket
n8n AI Agent classifies urgency
Agent calls CRM tool
Agent calls search or knowledge base tool
Agent drafts a reply
Timeout happens on step 3
Execution retries
Draft step runs again

Now the pricing problem is not prompt length.

It is workflow behavior.

If you are tracking retries in n8n, you already know this pattern exists. Retry metadata like execution.retryOf is a reminder that retries are normal in automation, not rare edge cases.

The bill changes even when prompts don’t

This is the part that made me stop trusting per-token forecasts.

People describe usage-based pricing as transparent. In practice, for agent systems, it often isn’t.

Why?

Because your bill is shaped by more than token volume:

request bursts
rate-limit backoffs
queueing
fallback chains
cache hit rate
background jobs
sync vs batch routing
tool fan-out

Two months can have roughly the same user demand and still produce different costs.

Not because prompts changed.
Because execution shape changed.

Maybe traffic got burstier.
Maybe a nightly summarization job collided with interactive traffic.
Maybe one provider throttled and your fallback path activated more often.
Maybe your cache hit rate dropped because prompt prefixes drifted.

That is invoice roulette.

Background jobs are where pricing models go to die

The least honest part of many AI cost estimates is that they ignore background work.

But real agent systems are full of it:

nightly classifiers
memory refresh jobs
ticket summarization
thread cleanup
webhook-triggered enrichments
multi-channel assistants sitting idle-but-not-really-idle

An OpenClaw assistant connected to Slack, Discord, Telegram, WhatsApp, and Teams may look quiet from the outside.

It is still maintaining context, reacting to events, preserving sessions, and sometimes running scheduled tasks.

That means cost keeps accumulating even when no human is actively chatting.

The vendor pricing features are useful — and also kind of a confession

This was the part that surprised me most.

Every major model vendor now has pricing features designed to reduce cost:

batch APIs
prompt caching
context caching
separate rate-limit pools
grounding quotas

These features are real and useful.

They also quietly admit the same thing: raw synchronous per-request billing is a bad fit for a lot of production automation.

OpenAI Batch: good feature, loud signal

OpenAI Batch is a solid option for offline work.

What you get:

50% lower cost than synchronous API usage
separate, higher-rate-limit capacity
completion within 24 hours

That is great for:

bulk classification
enrichment
nightly summarization
offline evaluation jobs

Example shape:

# pseudo-workflow
# 1. collect jobs during the day
# 2. ship them to batch overnight
# 3. read results later

The pricing win is real.

But the architectural implication matters more: now cost depends on execution mode, not just token count.

You are no longer asking “how many tokens did I send?”
You are asking “which jobs can tolerate delay, and did I route them correctly?”

That is a workflow design problem.

Anthropic prompt caching: powerful, but easy to overestimate

Anthropic caching looks fantastic on paper.

Typical pricing structure for Claude tiers includes:

base input pricing
separate cache write pricing
much cheaper cache hit pricing
output pricing

That can be a huge win if your prompt prefixes are stable and requests arrive inside the cache window.

Example:

import anthropic

client = anthropic.Anthropic()

response = client.messages.create(
    model="claude-opus-4-1",
    max_tokens=1024,
    system="You are a support triage assistant.",
    messages=[
        {"role": "user", "content": "Classify this ticket and suggest next action."}
    ],
    cache_control={"type": "ephemeral"},
)

The problem is forecasting.

Your savings now depend on:

whether prefixes actually stay stable
whether requests land inside the cache lifetime
whether your agent architecture reuses context consistently
whether tool outputs keep mutating the prompt shape

Teams often assume caching will save a lot, then discover their traffic pattern is too messy.

For always-on agents, this is one of the easiest optimizations to model optimistically and realize pessimistically.

Google Gemini Batch and caching: same story, more variables

Google Gemini has the same pattern.

There are real discounts for batch execution. There is context caching. There can also be extra costs around storage duration and grounding.

Example batch call shape:

from google import genai

client = genai.Client()

job = client.batches.create(
    model="gemini-2.5-flash",
    src=[
        {
            "contents": [
                {
                    "role": "user",
                    "parts": [{"text": "Summarize this ticket in one sentence."}]
                }
            ]
        }
    ],
    config={"display_name": "ticket-summary-batch"},
)

Again, nothing is wrong with this.

But now your cost model depends on:

sync vs batch routing
cache duration
storage time
grounding frequency
request shape over time

That is not simple token accounting anymore.

Which cost-saving feature is actually worth using?

My opinion, after dealing with this in production:

Option	Best use case
OpenAI Batch	Best for boring offline jobs like nightly classification, summarization, and enrichment
Anthropic prompt caching	Best when prompts are highly stable and traffic repeatedly hits the same prefixes
Google Gemini Batch + caching	Best when you can cleanly separate async work and actually manage caching/grounding behavior

My practical ranking:

Batch APIs are the easiest clear win
Prompt caching is useful but easier to overestimate
Complex multi-provider fallback systems create the worst forecasting problems

If you run an always-on assistant across Slack, Discord, Telegram, Teams, or WhatsApp, with memory, tools, webhooks, and scheduled jobs, the hardest part is not finding a low token price.

It is explaining next month’s bill before next month happens.

The real problem is invoice volatility

This is the shift that changed how I think about AI infrastructure.

The expensive part is not always the model.
Sometimes it is the unpredictability.

That matters because unpredictable spend changes engineering behavior.

Teams start doing weird things when they cannot trust the bill:

throttling useful features too early
avoiding background automation that would actually help users
over-optimizing prompts instead of fixing workflow design
delaying launches because finance wants tighter cost bounds

That is why predictable pricing becomes attractive long before raw per-token pricing becomes objectively expensive.

What I do now instead of naive token forecasting

I still care about model pricing.
I just do forecasting differently.

I model execution paths, not average prompts.

That means I count:

retries per workflow
average tool fan-out
fallback frequency
sync vs batch split
cache hit assumptions
background job frequency
burst behavior under load

A rough spreadsheet is still useful, but only if it reflects system behavior.

A better way to think about cost

Bad forecast:

monthly_cost = avg_prompt_tokens * avg_response_tokens * requests * token_price

Better forecast:

monthly_cost =
  interactive_requests * avg_interactive_execution_path
+ batch_requests * avg_batch_execution_path
+ background_jobs * avg_background_execution_path
+ retry_overhead
+ fallback_overhead
+ cache_miss_penalty

That is much closer to reality for agent systems.

Observability matters more when pricing gets harder to reason about

If your workflows are complex, tracing becomes non-negotiable.

For example, if you are debugging model behavior with LangSmith and OpenAI-compatible tooling:

export LANGSMITH_TRACING=true
export LANGSMITH_API_KEY="<your-langsmith-api-key>"
export OPENAI_API_KEY="<your-openai-api-key>"

That will not reduce the bill by itself.

But it helps answer the question that always shows up too late:

Why did this workflow call the model four times?

Without tracing, cost debugging turns into archaeology.

When usage-based pricing is still totally fine

I do not think every team should abandon per-token billing.

It is still a good fit when:

Traffic is low-volume
Workflows are simple
Prompts are stable
Retries are rare
Background jobs are limited
You can actually use batch or caching reliably

In that world, usage-based pricing can absolutely be cheaper.

But once agents run continuously, touch tools, operate across channels, and keep doing work while you sleep, predictability starts to matter more than benchmark token price.

Where flat-rate compute starts making more sense

This is exactly why products like Standard Compute exist.

If your stack already speaks the OpenAI API, swapping endpoints is much easier than rebuilding your workflows around five different pricing tricks.

The appeal is simple:

flat monthly pricing
no per-token billing
works with OpenAI-compatible SDKs and HTTP clients
better fit for always-on agents and automations
less time spent playing pricing Tetris across GPT, Claude, and Grok

That does not remove the need for good architecture.

You still need:

tracing
guardrails
sane retry policies
separation between real-time and batch work
good tool design

But it removes one category of chaos: surprise invoices caused by workflow behavior you did not model perfectly.

For teams running n8n, Make, Zapier, OpenClaw, or custom agents, that tradeoff is often worth more than squeezing out the cheapest theoretical token path.

My takeaway

The clean mental model is wrong.

AI automation cost is not just model quality multiplied by token count.

It is the sum of:

retries
rate limits
fallback chains
cache windows
batch queues
grounding requests
tool loops
background jobs
all the tiny workflow decisions that compound at scale

If your biggest monthly question is no longer “which model is cheapest per token?” but “why can’t I predict this invoice at all?”

That is not a finance problem.

That is architecture.

And once you see it that way, a lot of pricing decisions start looking very different.

I built a headless Mac mini AI server and by week two I was debugging sleep, plist files, and Redis

Lars Winstand — Thu, 17 Sep 2026 14:10:25 +0000

The moment I knew my cute little local AI box had turned into actual infrastructure was when a folder stopped moving files at 3:14 a.m.

Nothing crashed.

Disk was fine.

Ollama was still up.

The machine had just quietly stopped being useful.

That was my headless Mac mini setup: a Mac mini on a shelf, no monitor, Ollama serving local models on http://localhost:11434/v1, a few Python helpers, and n8n running background automations.

For six days, it felt elegant.

Then week two started.

The first real failure wasn't inference

I expected model serving to be the hard part.

Maybe Llama would be too slow.
Maybe Qwen would eat RAM.
Maybe Ollama would fall over under concurrent requests.

Nope.

The first reliability problem was sleep.

A headless Mac mini loves to look alive while doing nothing useful.

Your file watcher still exists.
Your local API still responds sometimes.
Your helper process is technically running.

But if the machine slept, or the session changed in a way your setup didn't handle, your "automation server" became desktop theater.

That was the first lesson:

If you don't explicitly manage power behavior, you're not running a server. You're running a desktop that occasionally pretends to be one.

The two commands that fixed the obvious nonsense

If you're trying to keep a headless Mac mini alive for background jobs, you meet caffeinate and pmset fast.

caffeinate -i python3 watch.py

That prevents idle sleep while the command runs.

For broader power settings:

sudo pmset -a sleep 0
pmset -g assertions

That does two useful things:

disables system sleep across power profiles
shows which processes are currently asserting power management

A practical pattern is:

caffeinate -i ollama serve

or wrapping a long-running worker:

caffeinate -i /usr/local/bin/python3 /Users/you/ai-helper/watch.py

One footgun worth calling out: caffeinate -u defaults to a 5 second timeout if you don't pass -t.

That is exactly the kind of detail that makes a test look fine and an overnight job fail.

Why `launchd` matters more than another shell script

A lot of people approach this with Linux habits.

Start a process in the background.
Add &.
Maybe use nohup.
Call it a service.

On macOS, that gets messy fast.

If the Mac mini is going to be headless and useful, launchd is the real primitive.

And Apple is pretty clear about one thing: jobs launched by launchd should not daemonize themselves with the old fork-and-exit pattern.

That means a lot of generic "run this as a service" tutorials are subtly wrong for macOS.

Once I stopped fighting that, things got cleaner.

A minimal `launchd` watcher that actually behaves like a service

For file-triggered helpers, a plist beats a Terminal tab every time.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
  <key>Label</key><string>com.example.aihelper</string>
  <key>ProgramArguments</key>
  <array>
    <string>/usr/local/bin/python3</string>
    <string>/Users/you/ai-helper/watch.py</string>
  </array>
  <key>KeepAlive</key><true/>
  <key>WatchPaths</key>
  <array>
    <string>/Users/you/Inbox</string>
  </array>
  <key>RunAtLoad</key><true/>
  <key>StandardOutPath</key><string>/tmp/aihelper.out.log</string>
  <key>StandardErrorPath</key><string>/tmp/aihelper.err.log</string>
</dict>
</plist>

The three keys doing most of the work are:

KeepAlive: restart the helper if it dies
WatchPaths: react to directory changes
RunAtLoad: start immediately when loaded

Load it with:

launchctl load ~/Library/LaunchAgents/com.example.aihelper.plist

Or on newer macOS versions, bootstrap it explicitly:

launchctl bootstrap gui/$(id -u) ~/Library/LaunchAgents/com.example.aihelper.plist
launchctl kickstart -k gui/$(id -u)/com.example.aihelper

Check status:

launchctl print gui/$(id -u)/com.example.aihelper

Tail logs:

tail -f /tmp/aihelper.out.log /tmp/aihelper.err.log

This is the point where your Mac mini starts acting like a background worker instead of laptop cosplay.

The downside is also immediate.

You stop debugging only your Python code.
Now you're debugging:

plist syntax
launchctl
process environment differences
restart behavior
macOS logging

That is a very different hobby.

Ollama is easy right up until it becomes infrastructure

I still think Ollama is the easiest on-ramp for local AI.

Point your app at:

http://localhost:11434/v1

and use the OpenAI-compatible API.

That means existing SDK code changes very little.

Example with Python:

from openai import OpenAI

client = OpenAI(base_url="http://localhost:11434/v1", api_key="ollama")

resp = client.chat.completions.create(
    model="llama3.1",
    messages=[
        {"role": "user", "content": "Summarize this file in 3 bullets."}
    ]
)

print(resp.choices[0].message.content)

For experiments, this rules.

You can swap models, test a summarizer, wire up an agent, and get the "wait, this actually works" feeling in under an hour.

Then you realize Ollama is not a vibe.

It's a server.

And a server needs:

startup behavior
logs
restart behavior
predictable uptime
some answer to "what happens after a crash?"

If your AI helper is doing useful work while you're asleep, a Terminal tab is not a deployment strategy.

The real pain starts when one automation becomes five

This is where local AI setups get oversold.

A single user with a few lightweight jobs? Great.

A Mac mini with launchd, Ollama, and a couple scripts can be genuinely nice:

private
fast on LAN
fixed hardware cost
no cloud bill anxiety

But add:

webhooks
file triggers
scheduled jobs
overlapping LLM calls
retries
multiple users

and your tiny local setup starts acting like a small production system.

That is where orchestration becomes the problem, not inference.

n8n gets real about concurrency faster than most people do

n8n is a good example because the docs are pretty honest.

In regular mode, production executions can pile up unless you cap them.

The practical env var is:

export N8N_CONCURRENCY_PRODUCTION_LIMIT=20

In Docker:

environment:
  - N8N_CONCURRENCY_PRODUCTION_LIMIT=20

That sounds like a tuning detail.

It isn't.

It's the point where you admit overlapping work can absolutely make one box unresponsive.

And once you need more than one busy process path, the architecture changes.

Queue mode is where your "local box" becomes a system

n8n queue mode exists for a reason.

It separates trigger handling from execution workers and uses Redis in the middle.

That's the right move when jobs overlap heavily.

It's also the point where your Mac mini is no longer just a local automation box.

Now you have:

an n8n main instance
one or more workers
Redis
shared encryption key management
a database setup that should not be SQLite

That is a real operational jump.

Here's the cleanest summary I can give:

Option	What week two feels like
`launchd`	Native macOS fit for headless jobs, solid for watchers and helpers, but debugging moves into plist files and system behavior
n8n regular mode with concurrency cap	Fine for a single instance and moderate load, but easy to outgrow once executions overlap
n8n queue mode	Much better scaling story, but now you're operating Redis, workers, and actual workflow infrastructure

That is the local-first tax.

Not API compatibility.
Not whether Ollama can answer a prompt.

Orchestration is where the maintenance cost shows up.

Remote admin is where the cute Mac mini story gets thin

The internet makes headless Mac mini setups sound adorable.

Tiny box.
Silent.
Efficient.
Put it on a shelf and call it your AI server.

Sure.

But the minute you need reliable remote administration, you start touching way more of macOS than expected.

SSH, power settings, permissions, launch agents vs launch daemons, login state, Full Disk Access edge cases.

This is the part YouTube tutorials usually skip because it's less fun than benchmark screenshots.

None of it is impossible.

It's just not the clean little "local is simpler" story people like to tell.

So was the Mac mini a bad idea?

No.

It was a good idea for exactly the amount of complexity I had on day one.

That's the part I wish more people said out loud.

Local hosting is not bad.

A Mac mini can absolutely win on:

privacy
LAN latency
fixed hardware cost
fast iteration for one person

Ollama plus launchd plus a couple helpers is a sane setup.

The mistake is assuming a useful helper stays small.

Useful helpers attract:

more jobs
more triggers
retries
logs
webhooks
other users
uptime expectations

And that's when local orchestration stops being fun.

My rule now

If I'm:

testing prompts
running a private summarizer
building one-user automations
experimenting with local models

I still like the Mac mini.

If I'm depending on:

overlapping background executions
reliable webhook handling
worker behavior
24/7 automations
something I don't want to babysit at midnight

I stop pretending I'm "just running it locally."

At that point I'm operating infrastructure, and I make decisions like it.

The part most local AI posts skip

The breaking point wasn't model performance.

It wasn't even Apple being weird.

It was realizing that local-first breaks down around orchestration long before it breaks down around inference.

That's why I think local model serving and production automation should be treated as separate decisions.

You might absolutely want Ollama locally for privacy or speed.

But if your agents, n8n workflows, or background automations are running constantly, the thing that hurts is usually not token generation.

It's concurrency, retries, uptime, and cost predictability once usage stops being "a few tests" and turns into always-on work.

That's also why flat-rate API infrastructure is more interesting than it used to be.

If you're building agents or automations that hit LLMs all day, per-token pricing changes how you design everything. You start rationing calls, skipping useful steps, or watching cost dashboards instead of shipping.

Standard Compute is interesting because it flips that tradeoff: OpenAI-compatible API, flat monthly pricing, and routing across models like GPT-5.4, Claude Opus 4.6, and Grok 4.20 without the usual per-token anxiety.

That's a very different fit from a shelf Mac mini, but it's solving the exact problem week two exposed for me: once the workflow matters, predictability matters more than the demo.

Practical advice if you're building this right now

If you're setting up a headless Mac mini for AI workflows, here's the short version:

Use Ollama for local experiments and private one-user tools.
Use caffeinate and inspect pmset before blaming your app.
Move long-running jobs into launchd early.
Add logs from day one.
Cap concurrency in n8n before the box teaches you why.
Be honest about when "local" has become infrastructure.
If your workflows run constantly, evaluate whether predictable API compute is actually simpler than self-hosting orchestration.

That's the whole lesson.

Week one was AI.

Week two was operations.

I thought lead routing was a prompt problem until the AI assigned a California lead to nobody

Lars Winstand — Thu, 17 Sep 2026 06:10:50 +0000

I stopped trusting AI-first lead routing the day a valid inbound lead from California got assigned to… nobody.

Not the wrong rep.

Not the fallback SDR queue.

Nobody.

That’s the moment the whole architecture changed in my head.

The prompt was fine. The model output looked reasonable. The bug was in the workflow logic around it.

If you’re building CRM automation in n8n, Make, Zapier, OpenClaw, or a custom agent stack, this is the part that matters: LLMs are good at suggesting. They are bad candidates for being the final source of truth on ownership.

The safe pattern is boring:

Let GPT-5 or Claude propose a segment or owner
Validate with deterministic routing rules
Send conflicts and low-confidence cases to a human queue
Only then write the final owner to HubSpot or Salesforce

That sounds less exciting than “AI handles lead routing end-to-end.”

It also works.

The real bug wasn’t the prompt

The original workflow looked clean on a whiteboard:

read the lead
infer segment
assign owner

Modern. Minimal. Very demo-friendly.

But production systems don’t fail on whiteboards.

Here’s what actually happened:

the model suggested an owner based on company description and geography
one branch checked territory
another branch excluded house accounts
another checked existing ownership rules
two conditions overlapped
one validation failed
nothing handled the collision properly

So the record fell through the cracks.

That’s not a prompt failure.

That’s a control-plane failure.

Why LLMs feel better at routing than they actually are

Ask GPT-5, Claude Opus 4.6, or a solid open model to read a lead and suggest an owner.

You’ll usually get something plausible.

That’s the trap.

Plausible is not governable.

Real lead routing has rules like:

named accounts always stay with the account executive
EMEA enterprise goes to one team except strategic partners
California startup leads route one way unless they came from a partner form
existing open opportunities override fresh inbound logic
low-confidence enrichment should never trigger auto-assignment

An LLM can summarize those rules.

It should not be the final authority on those rules.

If it is, you’re going to spend Friday explaining weird ownership changes to RevOps.

The architecture I trust

This is the split I’d recommend for most teams:

Component	Best owner
Normalize messy form input	LLM
Summarize enrichment	LLM
Infer probable segment from incomplete data	LLM proposal only
Enforce named account exclusions	Deterministic rules
Enforce territory and geography	Deterministic rules
Resolve conflicts	Human review
Write final owner to HubSpot or Salesforce	Workflow after validation

That split keeps the model in the fuzzy-data lane and keeps the workflow engine in the policy lane.

If your routing is already based on clean fields like country, state, company size, or named account lists, you may not need an LLM at all.

Seriously.

A lot of teams add AI where a Switch node would have been enough.

n8n is a good example of where routing gets weird

n8n makes the mechanics visible, which is useful.

The Switch node has a few settings that matter a lot in lead routing:

Rules vs Expression mode
Fallback Output behavior
send to first matching output vs send to all matching outputs

That last one is not cosmetic.

If your routing rules overlap, these two settings create very different behavior:

first matching output: quietly picks a winner
all matching outputs: exposes that your rules collide

For lead routing, I want collisions exposed.

If two territory rules match the same lead, that should go to review. I do not want the workflow silently pretending the first branch was obviously correct.

Example: bad routing shape

// Pseudocode
if (country === "US") {
  owner = "US Team";
}

if (state === "CA" && company_size === "SMB") {
  owner = "West SMB";
}

if (named_account === true) {
  owner = account_executive;
}

Looks harmless.

But if multiple branches run and overwrite owner, your audit trail becomes nonsense.

Better pattern: propose, validate, resolve

const aiSuggestion = {
  proposed_owner: "West SMB",
  proposed_segment: "California Startup",
  confidence: 0.72,
  reason: "HQ in San Francisco, 42 employees, SaaS category"
};

const validation = {
  namedAccount: lead.named_account === true,
  hasExistingOppOwner: Boolean(lead.open_opportunity_owner),
  matchesWestSMB: lead.state === "CA" && lead.company_size === "SMB",
  matchesPartnerException: lead.source === "partner_form"
};

if (validation.namedAccount) {
  return assign(lead.account_executive, "named_account_rule");
}

if (validation.hasExistingOppOwner) {
  return assign(lead.open_opportunity_owner, "existing_opp_owner_rule");
}

if (aiSuggestion.confidence < 0.85) {
  return sendToReview("low_confidence_ai_suggestion");
}

if (validation.matchesWestSMB && !validation.matchesPartnerException) {
  return assign("West SMB", "territory_rule_ca_smb");
}

return sendToReview("no_clear_owner");

That version is much less magical.

It is also much easier to debug three weeks later.

HubSpot already hints at the right answer

HubSpot talks a lot now about AI-assisted workflow creation.

Fine. Useful, even.

But the part that actually keeps lead routing safe is still the old-school automation machinery:

enrollment triggers
re-enrollment controls
permissions
action history
publishing controls

That’s the real story.

The safe pattern inside HubSpot is not “AI decides owner.”

It’s “AI helps annotate the lead, then governed workflow logic decides owner.”

That distinction matters.

Human fallback is not a cop-out

It’s the correct design.

n8n has documented a human fallback pattern for AI workflows, and it maps perfectly to lead routing.

Use this flow:

AI proposes owner, segment, or missing structured fields
deterministic rules validate territory, exclusions, and account ownership
low-confidence or conflicting cases go to Slack
human approves final owner
workflow writes the owner back to HubSpot or Salesforce

Cases I would always send to review

enrichment confidence below threshold
two territory rules match the same lead
named account conflicts with geography routing
existing opportunity owner conflicts with inbound owner
the model inferred a critical field instead of reading it directly

That’s not anti-AI.

That’s just adult supervision.

OpenClaw makes action easier, which raises the stakes

Agent tooling is getting fast.

OpenClaw, for example, is easy to stand up:

curl -fsSL https://openclaw.ai/install.sh | bash

Or:

npm i -g openclaw
openclaw onboard

That’s great if you want to get an agent running quickly.

But easy action is not the same thing as governed action.

This is the pattern I keep seeing across agent stacks:

agents are getting better at doing things
teams are still bad at explaining why those things happened

For CRM ownership, explanation is the whole game.

Make the assignment auditable

If you only take one thing from this post, make it this checklist.

1. Make AI output advisory

Have GPT-5, Claude, Qwen, or Llama return a suggestion and confidence score.

Not a final writeback.

2. Keep hard rules outside the prompt

Named accounts, do-not-route lists, existing opportunity ownership, and territory exceptions should live in workflow logic or application code.

Not buried in prompt prose.

3. Design for collisions on purpose

If overlapping rules are possible, treat that as an exception path.

Don’t hide it.

4. Keep an exception queue

Slack works.

So does Jira, a HubSpot queue, or an internal review UI.

Uncertain records need a place to go.

5. Store the reason for the final assignment

Persist:

AI suggestion
confidence score
deterministic rule that won
whether a human approved it
timestamp

If someone asks why a rep got a lead, “the agent decided” is not an answer.

A minimal implementation shape

Here’s a simple pattern using an OpenAI-compatible client plus deterministic validation.

import OpenAI from "openai";

const client = new OpenAI({
  apiKey: process.env.OPENAI_API_KEY,
  baseURL: process.env.OPENAI_BASE_URL
});

async function suggestRouting(lead) {
  const prompt = `
Suggest a sales segment and owner for this lead.
Return JSON with: proposed_owner, proposed_segment, confidence, reason.
Lead: ${JSON.stringify(lead)}
`;

  const res = await client.chat.completions.create({
    model: "gpt-5.4",
    messages: [{ role: "user", content: prompt }],
    temperature: 0.2
  });

  return JSON.parse(res.choices[0].message.content);
}

function validateRouting(lead, suggestion) {
  if (lead.named_account) {
    return { final: lead.account_executive, reason: "named_account_rule" };
  }

  if (lead.open_opportunity_owner) {
    return { final: lead.open_opportunity_owner, reason: "existing_opp_owner_rule" };
  }

  if (suggestion.confidence < 0.85) {
    return { review: true, reason: "low_confidence" };
  }

  if (lead.country === "US" && lead.state === "CA" && lead.company_size === "SMB") {
    return { final: "West SMB", reason: "territory_rule_ca_smb" };
  }

  return { review: true, reason: "no_matching_rule" };
}

That’s the shape.

AI for interpretation.

Code for policy.

Humans for ambiguity.

The cost problem shows up faster than people expect

There’s another issue teams hit once they start doing this at volume: cost.

Fallback-heavy workflows are expensive to iterate on when every test run is billed per token.

Every one of these adds cost:

retries
branch testing
confidence threshold tuning
comparing GPT-5 vs Claude on segmentation
sending borderline cases through multiple models
testing human-review thresholds

When you’re building AI automations in n8n, Make, Zapier, OpenClaw, or custom OpenAI-compatible stacks, pricing affects architecture.

If every experiment feels metered, teams test less.

That usually means worse routing logic in production.

This is exactly why flat-rate AI access is useful for workflow builders. With Standard Compute, you can keep the OpenAI-compatible API shape, route across models like GPT-5.4, Claude Opus 4.6, and Grok 4.20, and iterate on real automation logic without treating every workflow run like a taximeter.

That matters a lot when your workflow includes retries, fallbacks, and human-review loops.

My opinionated take

If an LLM is directly assigning owners in production without deterministic validation, you have not automated lead routing.

You have automated future arguments.

The easy part was getting Claude or GPT-5 to output a rep name.

That demo works in five minutes.

The hard part is building a system where:

ownership rules are explicit
confidence is checked
collisions are visible
exceptions stop for review
every assignment is explainable later

That’s the version that survives contact with actual sales teams.

And if you’re doing it at scale, predictable AI cost matters almost as much as correct logic.

Because a workflow you can’t afford to test properly is not production-ready either.

DEV Community: Lars Winstand

My AI agent failed obvious tasks, and 49% fewer retrieval misses changed how I debugged it

The failure looked like reasoning. It wasn’t.

The debugging mistake: treating all memory as one thing

Long context does not magically fix retrieval

Pure vector search loses stupid fights

A practical OpenAI File Search setup

Sometimes the right move is: stop doing RAG

How I’d debug this before blaming GPT-5 or Claude

1. Log the exact context the agent saw

2. Separate session memory from durable memory from retrieval

3. Add keyword search for exact-match terms

4. Rerank before switching models

5. Test prompt position, not just prompt content

6. Check whether your corpus is small enough to skip RAG

Quick local experiment: inspect exact-match retrieval behavior

The table that changed how I think about agent reliability

Why this matters more when you run agents at scale

My current rule

I finally figured out what people mean by the best uncensored LLM after watching 17 agent workflows fail

Most teams asking for an uncensored model are really asking for fewer false refusals

The workloads that actually need lower-refusal behavior

1. Security triage and exploit reproduction

2. Moderation and trust-and-safety pipelines

3. Internal coding agents and automations

The real question is not “which model is least censored?”

API compatibility matters more than rebellious branding

The 3 practical architecture options

A lot of teams do not need an uncensored model. They need better workflow design.

Lower refusal does not automatically mean better for production

Which workload needs lower refusal?

What containment do you have?

Can you swap models without rewriting everything?

The setup I keep seeing work

Where Standard Compute fits

My practical takeaway

My AI cron job looked cheap at 5 runs/day. At 96 runs/day it turned into 1,728 model calls

The testing version lied

The math that changed the conversation

Why AI cron jobs blow up in production

A quick way to estimate the real cost

The expensive part is usually not the first prompt

The real problem with per-token pricing for scheduled workflows

What I changed

What this looks like in practice

Practical checks before you ship an AI cron job

My actual takeaway

My AI agent self-healing fix was embarrassingly simple once I stopped retrying the whole thing

My AI agent self-healing fix was embarrassingly simple once I stopped retrying the whole thing

The real problem with full-workflow retries

The fix: stable execution IDs + explicit state + step-level retries

What step-level retry logic actually looks like

Resume, don’t restart

LangGraph: reuse thread_id and persist graph state

Temporal: retry Activities, not the whole business process

n8n: manual, but still worth doing

Quick comparison: restart vs resume

The cost problem is not subtle

The pattern I would use again from day one

My actual takeaway

My refund agent looked smart until it lied about Shopify, Stripe, and Zendesk 3 different ways

The real bug: valid tool calls, invalid conclusions

1) Shopify: a Refund object is not proof that money moved

The mutation is not the problem

Safer pattern

2) Stripe: timeouts turn "retry" into a reliability bug

Correct Stripe call

Bad retry logic

Better retry logic

3) Zendesk: async jobs and rate limits expose toy workflows fast

Rate limits are not a suggestion

Some actions are jobs, not immediate completion

Minimal polling example

Prompt fixes vs orchestration fixes

What I trust now

Do you need LangGraph, or are n8n / Make enough?

Tiny LangGraph skeleton

The pattern that finally stopped the lying

If you’re running AI agents in production, cost pressure makes this worse

Final takeaway

LangGraph: reuse `thread_id` and persist graph state