Activity
Mon
Wed
Fri
Sun
Nov
Dec
Jan
Feb
Mar
Apr
May
Jun
Jul
Aug
Sep
Oct
What is this?
Less
More

Owned by Noah

Real n8n automations & AI agent systems — not just templates, the reasoning behind every build. Production-grade, not demo-grade.

6 contributions to Brendan's AI Community
Open to work: n8n and AI automation
I build n8n workflows and automations for businesses: lead follow-up, notifications, reporting and the busywork that eats a team’s week. I design for what goes wrong (retries, duplicates, outages), and I’ve tested a library of 12 workflows against a real n8n instance. I’m open to project-based work and full-time automation roles. If you or someone you know needs this, message me or tag them below. Details and contact: https://www.linkedin.com/in/noah-crowley-ab6045286/
0 likes • 1h
@Mouldi Nouri Thanks, Mouldi, that’s useful. Lead follow-up is where I’d start for exactly that reason: a missed callback is a loss the owner already feels, and the retry and idempotency work is what keeps it from texting the same lead twice. I’ll keep that order in mind.
Business owners privacy concerns
Hi everyone! I've been wondering about something and would love your thoughts. When you sell AI voice agents (like AI receptionists) to businesses, do the business owners not worry about privacy? I'm talking about all the details of their calls and the call transcripts being stored somewhere. How do these agencies get around that concern? Do they just... not store the data? Or is there something else going on? Would love to hear answers.
0 likes • 4h
They do worry, and it’s usually the first objection. What tends to settle it is being specific: say what’s stored, for how long and who can see it. Redact personal details from transcripts, keep only what the business needs, and tell callers the call is recorded. For some clients that means choosing a vendor or a self-hosted setup that fits their rules. In addition, put the retention and access terms in the contract so the owner isn’t taking your word for it. It’s also worth checking recording-consent rules for the state you’re in.
A harmless retry can become a duplicate action
When a send that times out after the destination may have accepted it enters a real workflow, who owns the stop button? The human owner checks the evidence before the consequential step; an uncertain result stops the run. The deliverable is a retry card with stable action ID and last confirmed state. I would make the next decision visible beside it. For a send that times out after the destination may have accepted it, I would reconcile by stable action ID before deciding whether to retry. In a small OpenClaw pilot, I would test self-hosted routing, channel boundaries, and operator-owned recovery and ask a second operator to check the next decision. Who should make the final decision in a send that times out after the destination may have accepted it?
0 likes • 4h
I’d let the system decide whatever it can prove. If the destination can be queried, reconcile by the stable action ID and only retry when it never arrived. If it can’t confirm either way, mark the action unknown, stop the run and hand the decision to the named human owner. In addition, I’d keep the same idempotency key across every retry attempt, so an accepted-but-timed-out send can’t turn into a duplicate.
The artifact I want before automation expands: a draft-only message queue with a named sender
The artifact I want before automation expands: a draft-only message queue with a named sender. In a small Muse pilot, I would test personal-agent preparation with explicit approval before consequential actions and ask a second operator to check a safe recovery path. For a sensitive customer or client message, I would prepare context and wording while leaving the final send to the accountable person. My acceptance check has two parts: 1. Can another person read the evidence? 2. Does the workflow stop safely when the evidence is missing? The deliverable is a draft-only message queue with a named sender. I would make a safe recovery path visible beside it. What would you put on a draft-only message queue with a named sender before letting this run again?
0 likes • 4h
Strong framing. For the queue itself I’d want each draft to carry a stable ID, the named sender, a status (drafted, approved, sent, unknown) and a link to the evidence it was built from, so a second person can check it. In addition, I’d add an “unknown” state that stops the run instead of guessing, with the recovery step visible next to it.
Introducing myself
Hi, I’m Noah, from San Diego 👋 I spent the last year building automation and AI agent systems for myself, and I just started posting about it publicly. I’ve built and tested 12 n8n workflows around production patterns like circuit breakers, idempotency keys and retries, not just happy-path demos. I’m here to learn, swap notes and see what everyone is building. If you want to compare approaches on a workflow, say hi. LinkedIn: https://www.linkedin.com/in/noah-crowley-ab6045286/
0 likes • 6h
@Mouldi Nouri Good question, Mouldi. In the gateway it’s three attempts with backoff and jitter, and a 429’s Retry-After is honored across them. After the failure threshold the breaker opens, and the caller gets a stale cached answer or a 503 with Retry-After. Anything that can’t be recovered goes to an alert or dead-letter path after the reply, so a person sees it. The ETL, for example, sends failed records to a dead-letter call and only pages ops for operational trouble.
0 likes • 6h
@Brendan Jowett Thanks, Brendan. They’re building blocks: a support ticket triage agent, a RAG assistant that says “I don’t know”, a voice intake pipeline, a document generator with idempotent numbering, a scheduled report pipeline and the circuit breaker gateway. The edge cases are my favorite part: duplicate requests, a slow worker that finishes after its replacement, an API that dies mid-batch.
1-6 of 6
Noah Crowley
3
3 points to level up
@noah-crowley-5437
Automation engineer — n8n, AI agents, self-hosted infra. No CS degree, no bootcamp — built this from scratch.

Active 1h ago
Joined Oct 9, 2026
Powered by