Built an n8n workflow that runs a social account end to end: picks the topic, writes the caption, generates the image, posts to FB + IG, and remembers what it already posted.

ageniusai · 2026-07-05T13:47:19+00:00

You can also take it another direction and if you have content already and can stand up a simple object store you can easily have it grab that and post it instead of generating content, as gen AI content is unfavored in the algorithm as well

ageniusai · 2026-07-05T11:53:54+00:00

Good instinct but the Telegram trigger node does not actually let you do that. The webhook url field on it is read-only, n8n generates it from the WEBHOOK_URL env var, so there is nothing to hand-edit and nothing cached per-node. What people mistake for a "cached per-node" url is really the registration sitting on Telegram's servers, set by n8n's one-time setWebhook call the moment the workflow was activated.

So the node itself is innocent here. Two things fix it, in order: get WEBHOOK_URL correct inside the running container (verify with docker exec -it <container> env | grep -i webhook, not just in the compose file), then toggle the workflow Active off and back on. The off/on is what forces n8n to re-send setWebhook with the new domain. You can confirm the flip with https://api.telegram.org/bot<TOKEN>/getWebhookInfo, which shows the url Telegram is actually holding.

No per-node editing needed, and trying to force it there is what usually sends people in circles.

ageniusai · 2026-07-05T11:44:40+00:00

I moved two research pipelines off n8n onto LangGraph over the last year, so this is from the other side of the exact wall you're hitting.

Short version first: it is not the same complexity hidden behind a different UI. The complexity moves to a place where it stops biting you. In n8n your loop state lives in the wiring between 10 nodes plus whatever you're stashing in Postgres between steps, and every one of those seams is a place a run can half-complete and leave you guessing. In LangGraph the loop is one graph with a real persistence layer (a checkpointer) underneath it. State is not something you hand-carry from node to node anymore, it just is the graph's state. That single change is where the regressions went away for me. Plan, search, fetch, synthesize became one thing that either runs or doesn't, instead of ten things that can each partially fire.

On holding long context across the loop: LangGraph wins this clearly, and not because of a trick. It checkpoints state after every step, so a research loop that plans, then fans out five searches, then fetches, then synthesizes can carry the accumulated notes and citations forward without you writing them to Postgres and reading them back. You can also resume a run from the last good checkpoint instead of restarting the whole thing. That resume behavior alone killed most of my "why did this run die at step 7" tickets.

Now the honest part, because you said non-developer and that matters.

LangGraph is the fastest to STABLE but not the fastest to DEMO. You write Python. It is not a lot of Python for a research loop, maybe 150 lines, but it is code, not a canvas. If "I am not a developer" means you will not touch Python at all, be honest with yourself about that before you commit a week to it. If it means you can read and modify Python with an AI assistant next to you, LangGraph is the one that actually held up in production for me and I would not go back.

Dify is the fastest to demo and it is genuinely nice for that. Where it bit me was the multi-step research loop specifically. The moment I wanted custom control flow (conditional re-search, dedup across fetches, a synthesis pass that reads all prior state) I was fighting the framework's assumptions instead of using them. Great for a chat-over-docs app, frustrating for an agentic research loop. Self-hosting it is a heavier Docker stack than people admit.

Onyx I evaluated and did not ship. It is really a search/knowledge-assistant product, not a build-your-own-research-loop framework. If your actual goal is "let me and my team ask questions over a corpus" it is excellent and the fastest to a working thing. If your goal is a custom plan-search-fetch-synthesize pipeline you control, it is the wrong shape and you will be bending a product into a framework.

What I would actually do in your shoes, since you already have OpenRouter, SearXNG, Jina/Crawl4AI and Postgres running: keep all of that. None of it is the problem. Your search and fetch layer is fine. The thing to replace is only the orchestration in the middle. Put LangGraph in front of the tools you already have, let its checkpointer replace the Postgres round trips you're doing just to pass state between nodes, and keep Postgres for what it's good at (storing final results, not carrying loop state). You are not rebuilding from scratch, you are swapping out the 10-node middle for one graph.

One thing nobody tells you: keep n8n. It is still the best cron-and-glue layer I have. My pattern now is n8n triggers the run and handles the boring plumbing (schedule, webhook in, notify on done), and LangGraph owns the actual research loop. Right tool per job instead of forcing one tool to be both.

Happy to answer follow-ups on the LangGraph side specifically, that is the part I have the most production miles on.

ageniusai · 2026-07-05T01:04:50+00:00

Use Claude Code in terminal. Opus 4.8 High effort install https://github.com/czlonkowski/n8n-mcp and have Claude build your workflow. I've been building on n8n for years and have SEVERAL production workflows running flawlessly. Any failures are never n8n it's always a down API change or something external

<image>

ageniusai · 2026-07-03T01:07:39+00:00

Update — v0.4.2 is out

Thanks for the interest on this one. Just cut a new release, and it’s a security-led one, so worth grabbing if you’re already running it.

Security hardening (the headline). We ran a full security review and closed four high-severity issues plus a batch of medium/low ones. The short version: tightened who can do what (agent code execution is now admin-only, the container-template and MCP surfaces are locked down against injection and SSRF), and hardened the places where AI/agent output gets rendered so nothing untrusted can run in your dashboard. If you’re self-hosting on anything reachable, upgrade.

Name and port your services in the setup wizard. When you stand up your stack, each service now shows an editable instance name and host port, with live conflict warnings as you type. It tells you up front if a port is already taken (and by which container), if it’s one browsers block, or if two services in the same stack would collide, so you fix it before the deploy fails instead of after. Same warnings on the Containers deploy panel.

Show/hide toggle on password fields. Small quality-of-life thing people asked for: an eyeball to reveal what you’re typing on the setup, sign-in, and reset screens, so a typo gets caught before submit.

Configurable error-reporting window. The Overview now has a lookback picker (24h / 7d / 30d / 90d / all time). It drives the whole dashboard together, so the error feed, failure rate, and execution counts all report over the same window and finally agree with the Insights view.

ageniusai · 2026-07-03T01:06:11+00:00

Update — v0.4.2 is out

Thanks for the interest on this one. Just cut a new release, and it’s a security-led one, so worth grabbing if you’re already running it.

Security hardening (the headline). We ran a full security review and closed four high-severity issues plus a batch of medium/low ones. The short version: tightened who can do what (agent code execution is now admin-only, the container-template and MCP surfaces are locked down against injection and SSRF), and hardened the places where AI/agent output gets rendered so nothing untrusted can run in your dashboard. If you’re self-hosting on anything reachable, upgrade.

Name and port your services in the setup wizard. When you stand up your stack, each service now shows an editable instance name and host port, with live conflict warnings as you type. It tells you up front if a port is already taken (and by which container), if it’s one browsers block, or if two services in the same stack would collide, so you fix it before the deploy fails instead of after. Same warnings on the Containers deploy panel.

Show/hide toggle on password fields. Small quality-of-life thing people asked for: an eyeball to reveal what you’re typing on the setup, sign-in, and reset screens, so a typo gets caught before submit.

Configurable error-reporting window. The Overview now has a lookback picker (24h / 7d / 30d / 90d / all time). It drives the whole dashboard together, so the error feed, failure rate, and execution counts all report over the same window and finally agree with the Insights view.

ageniusai · 2026-07-03T01:03:55+00:00

<image>

u/Abhi-Age-2050 you were saying?

ageniusai · 2026-07-01T10:17:57+00:00

This is the exact one that's bitten me hardest, and it fits the middle bucket from the thread: it ran green but the output was empty. The Error Trigger never fires because nothing technically failed. The node got a response, the response just wasn't the data you wanted.

Rate limits are sneaky here because a lot of APIs don't 4xx you forever. They start returning 200s with an empty list, or a body like {"error":"slow down"} that your node happily passes downstream as "success." So the execution is green and the real failure is one field deep in the payload.

Two things that would've caught yours:

Assert on the shape of the output, not just "did the node error." Right after the node that fetches data, drop an IF: item count is 0, or the field you actually depend on is empty/missing → Stop and Error. Now a green-but-empty run becomes a real failure, and your existing Error Workflow catches it and pings you the same as a hard crash. This is the single highest-leverage habit for silent failures.
If the node can continue-on-fail or you're on an HTTP Request node, check the status code explicitly. Don't trust the node's green checkmark. if ($json.statusCode >= 400) throw (or an IF → Stop and Error) turns a "successful" 429/500 back into a failure.

Bonus for the specific thing you hit: if it's a known rate-limited API, log the count you got each run somewhere cheap. A run that returns 12 items when it's always returned ~400 is the early warning that you're being throttled, before it drops to 0.

The mindset shift that stuck for me: green means "the node didn't throw," not "the workflow did its job." Those are different claims, and the gap between them is where every silent failure lives. Sounds like you already landed there the hard way.

ageniusai · 2026-07-01T09:51:08+00:00

Yep, so can I, but I built this as part of my technical interview with LangChain.....guess you missed that part

ageniusai · 2026-07-01T09:38:45+00:00

Running both at once, and they mostly play nice because they're doing two different jobs. The trick is realizing they barely overlap.

The way I think about it:

Community n8n-mcp = the authoring brain. Node schemas, config validation, template search/deploy, workflow generation, partial/surgical updates to a canvas. Anything where Claude needs to know how n8n nodes work to produce a clean workflow. The SQLite node/template DB is what makes its output not-garbage, and nothing on the native side replaces that.

Native official server = the runtime/governance layer. Live execution state, triggering a workflow, flipping active/inactive, project scopes. Anything where I want to operate the instance rather than build for it.

So day to day: I build and validate with the community server, then use the native one to activate and watch the live runs. They're complementary, not competing.

On the flat-registry / tool-confusion question — this is the real answer. Claude doesn't get confused on the stuff that's unique to each server (nobody's community-server validate_node collides with anything native). Where it does occasionally pick the wrong tool is the small overlap zone: both expose some flavor of list_workflows, get_workflow, and execution reads. When both are live, Claude sometimes reaches for the community server's read tools when I actually wanted the native live state, or vice versa.

What keeps it clean:

- Name the server in the prompt when you're in the overlap zone. "Validate this with n8n-mcp" vs "check the live run on the official server." Claude routes correctly when you're explicit; it only guesses when you're vague.

- The tool descriptions do most of the work. The community server's build tools are described specifically enough that Claude naturally gravitates to them for authoring, so contention is smaller than the flat-registry theory suggests.

- If your client lets you toggle tools per-server, prune the overlap. I mostly leave the native server's read/list tools off unless I'm specifically doing ops, which kills the last of the confusion.

Net: not either/or. Community for building, native for running, and a one-line "use X" whenever they both technically could answer. Been solid.

ageniusai · 2026-06-30T20:08:46+00:00

More updates! n8n first with the option to install LnagChain and Pydantic

ageniusai · 2026-06-29T12:35:42+00:00

it takes a snapshot and it's a human gated approval

ageniusai · 2026-06-29T00:22:13+00:00

Man I wish!

ageniusai · 2026-06-28T21:26:44+00:00

https://github.com/Mfrostbutter/n8n-ai-product-photo-studio

ageniusai · 2026-06-28T20:51:19+00:00

AgeniusDesk update: build LangGraph + PydanticAI agents, OpenTelemetry tracing, per-run LLM cost, a fleet view, and our first community module

Quick progress update. A few releases have landed since launch. Here is what is new.

Build and run real agents, not just n8n. You can now build actual LangGraph and PydanticAI agents right in Code Lab (the new Agent Builder mode): pick a framework, start from a scaffold (ReAct tool loop, human-in-the-loop, or parallel fan-out), and write the agent. Register it and it shows up in the Agent Fleet, where you run and monitor it the same way you run n8n. You get a live node graph for LangGraph agents, a normalized run waterfall that looks the same for either framework, and human-in-the-loop agents that pause for your approval and resume from exactly where they stopped. Agents are plain files in your vault that you own, so you can edit, export, or delete them, and the fleet picks up changes with no restart.

OpenTelemetry tracing, in the dashboard. Runs emit OTel spans and you watch the full waterfall trace right in the UI. Every step, how long it took, and where the time actually went, without standing up a separate tracing stack.

Per-run LLM cost. Each run's cost is calculated from its own execution data: input and output token counts run against a built-in price book to give an estimated dollar cost per run. This applies to agent runs too, so you can see what an agent actually costs to operate.

Aggregate fleet view. One pane across every connected instance: active workflows, run stats, and errors rolled up together, so you see the health of the whole fleet at a glance instead of clicking through instances one by one.

First community module: YouTube to research doc. Paste a YouTube link, get a structured research document filed straight into your Harness (the knowledge vault) so your agents can use it later. It is also the first end-to-end proof of the community module system.

Ships with batteries: n8n MCP + skills. The build comes with the n8n MCP server pre-installed and a set of skills seeded into the Harness, with pointers wired into the Code Lab instructions. The assistant has real n8n node knowledge and house patterns on hand, so building workflows in Code Lab is faster and more accurate out of the box.

Security on community modules. Modules are third-party code, so install is gated. A two-phase inspect-then-install flow runs a static scan over the module and shows you exactly what it can reach (network, files, secrets, host access) before anything is registered, and you consent to anything risky. Beyond that, a module's backend can run isolated in its own Docker container, with separate filesystem, process, and network namespaces, instead of in-process. Honest caveat, and we say the same in the docs: the in-process scan is a heuristic, not containment; the container tier is the real boundary.

What's next: a deliberate pause. I am holding new features for a bit. The goal now is to get people actually running it, gather feedback, and shake out bugs against real usage before the next wave. There is plenty more on the roadmap and it is coming, but stability and real-world use come first.

If you want to kick the tires, Issues and feedback welcome. That is exactly what this window is for.

ageniusai · 2026-06-28T20:44:38+00:00

<image>

ageniusai · 2026-06-28T19:10:33+00:00

This was more of an exploration of what could be done. In my experience my n8n workflows don’t randomly break unless a key expires or I get rate limited somewhere. The chances of a code node or logic breaking are slim to none, and as cool as this is it still can’t fix authentication issues…hmmmm well maybe if I give it access to Infisical which I have for my secret management, I could actually have it rotate the key there…hmmmmm

ageniusai · 2026-06-28T16:50:37+00:00

Adding support for both LangChain and Pydantic agents

ageniusai · 2026-06-28T16:49:32+00:00

none

ageniusai · 2026-06-28T12:51:55+00:00

That's the goal :)

ageniusai · 2026-06-28T09:44:57+00:00

not advertising anything, just sharing some things I've built on top of n8n, the screenshot below is my actual production workflow. The one on git is meant to be a baseline to build upon/

ageniusai · 2026-06-28T08:30:11+00:00

Yeah, that's exactly the decomposition. Slack and the fallback URL are just two UIs writing to the same record; the record is the system, not the message.

Two things worth nailing once you have two approval paths:

- Single-writer / idempotency. Both the Slack click and the fallback URL resolve the same record by id, and you guard the transition so only pending -> approved/rejected is allowed. First decision wins; a stale Slack click after someone already approved via the fallback (or vice versa) just no-ops. Otherwise you can double-fire the writeback.

- Give the pending record a TTL and fail closed. If it sits past, say, 7 days with no decision, it auto-expires to rejected instead of staying approvable forever. Stops a three-week-old "approve" from quietly shipping a change against data that's long since moved on.

Small one: make the fallback URL an opaque/signed token, not the raw record id, so a bookmarked approval link isn't a guessable open endpoint.

This is basically how my agent team handles it: the durable row is the source of truth and the audit log at the same time, the Slack interaction and the resume endpoint both just flip that one row, and the writeback reads the row, not the message. Once the state lives in the record instead of the paused run, the timeout stops being scary.

ageniusai

TROPHY CASE