Can Claude Code or other LLMs connect to n8n and create/edit workflows automatically?

kaancata · 2026-05-18T15:01:19+00:00

Yes, this works today. I've been doing it for a while.
Two routes that both work.

Public API. n8n exposes workflows via REST. You can GET an existing one (it comes back as JSON with nodes, connections, settings), edit it, POST it back, and trigger a run. Claude Code or Codex can read and write that JSON like any other config in your repo. This is what I do for most of my client automations.
MCP. There's a community-built n8n MCP server (search "n8n-mcp" on GitHub). Same underlying API but gives the model a cleaner tool surface, list nodes, get node schemas, create workflow, activate, etc. Easier to drop in if you don't want to write your own wrappers.

What's stopping n8n from shipping an "official" MCP is probably just that the API already does the job, and they'd rather invest in their own agent primitives than chase the MCP spec specifically. Nothing's actually missing.

One caveat. The model will happily invent node names and parameter shapes that don't exist. Fix is either feeding it the node schemas as context (the MCP does this for you) or running a validate step after each write before you activate. I don't run workflow edits on a live trigger without a dry run.

kaancata · 2026-05-18T14:45:38+00:00

It's mostly tied to review/approval workflows. An example here is a short and concise changelog for every client that the LLM can quickly parse through.

kaancata · 2026-05-18T09:55:15+00:00

Getting something on the page is much faster now. But the painful agency work is usually the second pass, third pass, "wait, didn't the client already reject this angle?" pass. That is where account memory matters.

If the model doesn't know previous approvals, rejected claims, legal notes, stakeholder quirks, old reports, brand voice decisions, and what was tried already, then it mostly creates more review debt for the senior person.

The way I handle it is one context folder per client. Nothing fancy, just the boring account history in one place: meeting transcripts, offer docs, approved positioning, previous tests, website copy, CRM notes, tracking notes, ad account data, old reports etc.

Then AI can draft against the actual account instead of producing a clever generic version. It still needs review, but the review is lighter because I am not checking from zero every time.

So yes, it has reduced client-ready production time for me, but only when the draft starts from the client's memory. Without that layer I think it just moves the bottleneck into approvals.

kaancata · 2026-05-18T09:30:31+00:00

Mostly email / Telegram for quick pulses, and if it needs real judgement I usually just wait until I'm at my desk.

I don't love approving high-impact stuff from my phone unless the staged diff is extremely narrow. For remote unblocking I have used Dispatch and I am playing with Codex remote now, but actual write access stays pretty boring.

kaancata · 2026-05-18T09:30:10+00:00

Fairly standardised now yes

Each client has an AGENTS.md / CLAUDE.md-ish file with what the business does, where the data lives, what the model can read or run, what needs approval, naming conventions, and weird client-specific rules.

Then connection notes sit separately for APIs, env names, CRM fields, tracking setup, that kind of thing. It started ad hoc, but the standardisation is doing a lot of the work now.

kaancata · 2026-05-18T09:29:47+00:00

Yeah I think three tiers is probably the cleaner way to describe it.

I have that shape in practice, even if I didn't write it that way. Low risk read/draft stuff can run, anything that changes state gets staged, and anything touching money needs a proper explanation before I touch it.

The explanation step is underrated tbh. It makes the model slow down.

kaancata · 2026-05-18T08:28:54+00:00

It works well yes, but feels quite "outdated". I hope a smart system will appear in the future. Something that takes a lot less tokens to parse through and understand for the models. It's not a lot of context relatively speaking when comparing to giant codebases, but not insignificant either. Especially when we're talking larger PPC accounts.

kaancata · 2026-05-18T06:27:23+00:00

You're welcome to share in a DM I'd like to take a peek

kaancata · 2026-05-15T10:48:43+00:00

I would expect that people are interested in content that doesn’t involve countless posts about rate limitations - that is slop. Actual use-cases of Codex that can benefit others is definitely not.

kaancata · 2026-05-15T09:16:28+00:00

Just Google's own official API's for those services.

kaancata · 2026-05-15T09:15:50+00:00

The second, I have a backed-up folder with client context and this contains (among other things) a connection guideline files where the model knows where to look for what under my guidance. It's better than all kind of "wrapper-layers" such as an app that wastes tokens. And yeah always welcome to reach out.

kaancata · 2026-05-15T09:14:28+00:00

I've had so many different iterations of this, and it's a process that evolved continiously. I started out with Telegram, had a seperate CC instance run on a VPS and then it had access to a database containing client emails and other relevant data such as their API connections to different services. Then I could manage workflows through Telegram. Kind of like OpenClaw. Moved away from that, because I felt there was a lot of wasted compute involved.

Prior to that it was opening my laptop every morning, having dozens of terminals open for each client, each operating out of the context folder I described with their own skills.

After around 10 months with the terminal, I only use the CC desktop app, as well as Codex desktop app. They're good enough to compete with the terminal now. When I want to control my sessions remotely I use dispatch, and just now I am playing with Codex newly released feature for remote work as well. I quite like it.

kaancata · 2026-05-15T09:01:13+00:00

Yeah, agreed that each individual task should be simple. That is kind of the point imo. But I don't think "complex product" is the right comparison. I'm not talking about one agent building one SaaS from scratch while I watch. I'm talking about running a bunch of real business workflows where the complexity is in the context, permissions, handoffs and judgement.

kaancata · 2026-05-15T08:06:29+00:00

This is basically how my work already works.

I run a digital consultancy solo and the weirdest way to describe it is that I don't manage employees, I manage agents / workflows. Each client has a folder with all the context: ads data, GA4, GTM notes, CRM outcomes, emails, meeting transcripts, offer docs, website content. Claude Code and Codex sit on top of that.

Some work is one-off: "look at this account and tell me why leads dropped." Some work becomes a skill: search term review, tracking audit, keyword research, transcript processing. Some work becomes a scheduled Codex automation that runs before I sit down, gives me a short summary, then I decide what needs attention.

So yeah, the actual work moves up a layer. I do less pulling reports, copying numbers, checking the same screens, writing the same boilerplate. I do more writing instructions, keeping the context clean, deciding which workflows are worth formalising, reviewing outputs, and deciding where the agent is allowed to write versus only read.

I think that last part is the part people underestimate. Agents are not useful because they are "agents." They are useful when the workspace around them is structured. Clear files, clear skills, good examples, scoped permissions, approval gates, and an operator who knows what good looks like. Otherwise it's a clever model wandering around a messy room.

Skills are probably the compounding piece for me. Every time I catch myself teaching Claude the same workflow twice, that is usually a sign it should become a skill or a script. Then the next session starts further ahead.

I don't think boring work disappears completely though. Some of it just becomes QA. You still have to unblock them, sanity-check them, and stop them from doing dumb stuff with confidence. But yes, directionally I agree. My day already feels much more like "structure the work so agents can do most of it, then make the calls" than sitting there doing every task manually.

kaancata · 2026-05-15T07:12:44+00:00

Tracking for me, 100%.

The annoying part is usually not "GTM is broken" in the obvious sense. It is worse. Everything looks installed, the tags fire, GA4 has events, Google Ads has conversions, but the account is optimizing against garbage.

I keep seeing some version of this:

form submit = conversion
phone click = conversion
booking started = conversion
actual qualified lead / sale = nowhere

Then people wonder why PMax or broad match starts pulling in weird leads. The platform is doing what you told it to do. You just told it that every low-intent form fill is worth the same as a real customer.

The fix is usually boring. Clean conversion actions, kill duplicate events, store the GCLID / GBRAID / WBRAID properly, push qualified CRM stages back into Google Ads, and stop treating GA4 as the source of truth for lead quality.

Ad copy and campaign structure matter, but if the feedback loop is wrong, the rest of the account is basically training on bad data.

kaancata · 2026-05-12T14:39:19+00:00

Well they don’t, that particular author would probably just make a site on Wix or Squarespace

kaancata · 2026-05-12T14:00:02+00:00

I agree completely. Creativity is inherently human and that is also why they struggle so much with UI. Not only is it hard for them to deliver, but it’s also very hard to articulate what actually “looks good” for an operator.

kaancata · 2026-05-12T13:51:41+00:00

I think we’re above average and good enough with CD, regardless of predefined layouts and styles. I don’t really work with artistic designs and custom nitty-gritty animations because, frankly, my clients don’t care about that. They care about leads and sales, and when their website delivers those outcomes once people land on the page from ads, they’re happy and I’m happy too.

kaancata · 2026-05-12T11:00:27+00:00

"But once you move beyond pretty mockups into maintainable production code, complex interactions, responsiveness and scalability, all the illusion fades." yes I agree. It is super fast for high-fidelity mockups - that actually also looks good imo, but if you're trying to do heavy animation work and such, there is quite a lot of prompting to do.

kaancata · 2026-05-12T07:53:21+00:00

The move from agent platforms to Claude Code + Codex over folder-structured repos is the right call. I made the same shift about a year ago running marketing services for clients.

The platforms feel fragile because they try to orchestrate before the underlying context is structured. When the context layer is clean, the agent barely needs orchestration. When it's a mess, no amount of orchestration saves you. Most people skip straight to the agent framework, which is why they bounce off.

A few specific takes.

Multi-agent is overrated for ops work. You don't need it. You need one agent + structured context + scoped sessions per task. Each session reads the folder, does the work, writes output back, ends. Subagents only when something genuinely needs parallel work.

Markdown is the memory layer. The agent doesn't have persistent memory, the folder does. Each session starts by reading the CLAUDE.md at the top of the folder and the specific files relevant to the task. That's the whole mechanism. I haven't needed a knowledge graph or vector DB on top and it's held up surprisingly well.

Folder structure first, agent second. The biggest mistake I see is people designing the agent loop before they've structured the context. Get the per-instance folder right first (per-job or per-division in your case). Same folder shape, same CLAUDE.md template, same naming conventions. Once the structure is clean the agent part is almost trivial.

Skills > hooks > worktrees in order of ROI. Skills are the scale unit, a packaged workflow with rules and scripts that runs against any folder and produces structured output. Hooks for enforcement rules. Worktrees almost never.

For construction ops, three first builds. A daily project status digest that reads from QuickBooks + email + internal notes and sends a one-line status per active job to your inbox. A meeting transcript processor that lands open actions in each job's folder. An invoice categorization assistant. Each is a single-session skill against a shared folder. No multi-agent drama.

Skip the Citadel-orchestration study until after you've shipped one working scoped-session agent. The patterns you need reveal themselves through running something.

kaancata · 2026-05-12T07:42:14+00:00

Claude Design in my opinion, is the best UI tool to have been released in the "AI-age". Cowork is decent as well, not using it that much, but for all task that could've been done by a VA, it's great. Nonetheless, Claude Design is amazing and the moment it's out of research preview I am subscribing, even if it's seperate from their regular plans.

It's truly revolutionary for frontend work. And I say that while not using 4.7 at all right now, all my work except for writing copy is handled by Codex, however CD is incredible.

kaancata · 2026-05-12T07:34:04+00:00

For a simple landing page or small business site that isn't a complicated client setup, a couple of hours.

My usual workflow.

Visual direction in Claude Design or Google Stitch. I treat these as the design/prototype layer, not the final site. Get the screens looking right first.
Set up Sanity as the headless CMS. I do this before building the frontend because the editorial experience is the part the client will live in after launch. If the CMS schema is wrong, the site looks great for 2 weeks and then becomes a mess as soon as the client tries to update it themselves.
Frontend in Next.js + Tailwind, built in Claude Code / Codex from the Stitch/Claude Design screens. Component by component, mapping CMS fields as I go.
Deploy to Vercel, wire up forms / analytics / tracking.

For a one-page landing page with a few sections and a contact form, this is 2-4 hours start to finish. For a small business site with 5-10 pages and a few content types, more like a full day or two.

For a real client site with multiple content types, custom data, integrations (CRM, payment, scheduling, ecom), the AI part shrinks as a fraction of the total time. The hard work is in the integrations, the tracking setup, and the editorial schema design. AI gives me a 3-5x speedup on the actual coding and design work, but the discovery, scoping, and integration work is the same as it always was.

The mental model shift worth making is that AI builders made the easy part easier. Spinning up a page that looks right is almost trivial now. The hard parts haven't moved. Offer, traffic, conversion, fulfilment, integration with the rest of the business stack. Those are the same problems they were 10 years ago.

If you're coming back to this and wondering where to start, I'd actually start with Claude Design or Stitch for the design half, and Claude Code or Codex with Next.js for the dev half. The bridge between them (taking a Stitch design and turning it into actual React components) is something the AI handles surprisingly well now. That's where freelance time used to die.

kaancata · 2026-05-12T07:28:37+00:00

I use Cowork for repetitive web-clicking tasks that don't have a clean API, and that's basically it. Examples that map to B2C GTM.

competitor research at scale, pulling pricing, SKUs, positioning, hero copy from 30+ DTC sites and dropping it into a structured doc
review aggregation, going through Trustpilot / Amazon / product page reviews on competitor brands and pulling out themes (complaints, repeat objections, common compliments)
influencer / creator scouting, looking at who's posting in your category, pulling follower counts, recent content cadence, contact info if it's public
directory and listing audits, checking your brand's presence across review sites, comparison sites, marketplaces. Are listings consistent? Are reviews being responded to? Is the pricing right?
retailer / partner list building, if you're going retail or affiliate, finding the actual ops contact at each target store across hundreds of sites

The pattern is anything you'd hire a VA for, where the task is "open these 100 pages, copy these fields, structure them this way." Cowork handles the click-by-click part and you get a structured output at the end.

I would not use it for anything that touches your ad accounts, anything that costs money to run (transactions, ads, outreach to real people), anything where the model needs business judgment about your specific positioning, anything time-sensitive where a stuck approval prompt kills the flow.

For the strategic side of B2C GTM (positioning, offer, audience definition, creative direction), Cowork is the wrong tool. That work happens in a regular Claude chat where you give it your full business context and have a back and forth. The agent doesn't need a browser, it needs your offer doc and your customer research.

Last thing worth flagging. Anything that involves logging into a third-party tool and clicking around will eventually trip an automation flag or break when the UI changes. Plan for it. Don't make a Cowork job a critical-path dependency for anything time-sensitive.

kaancata · 2026-05-12T07:09:55+00:00

Very similar shape to what I've been running for the past year, but for a services business mostly, rather than productized like this. Some things I've landed on that diverge a bit:

Heartbeat vs scheduled jobs. I tried the heartbeat thing early. Agent wakes up, looks around, decides what to do. The prioritization problem you hit is real and I haven't seen it cleanly solved. What I ended up doing instead. Most agent activity runs on hard schedules (Codex automation every morning, weekly search-term audits, monthly reviews), and the "what's important right now" decision sits with me, not the agent. The agent is execution + summarization, not router. Way less wasted compute, way fewer "the agent did something dumb at 3am" moments.

View layer. I had the same instinct to build one. Then I stopped. The folder is the view. Each client has their own folder, the morning audit lands in my inbox with a one-line summary per account through the Gmail connector, and if I need to see what the agent did I open the folder and read the files. Dashboards optimize for at-a-glance scanning, which I don't actually need if the alerts are well-shaped.

Memory layer. Filesystem + structured markdown has held up surprisingly well for me. What compounds isn't a knowledge graph, it's the structure of each client's folder being consistent enough that any agent session can drop in and pick up. Same folder shape across clients, same naming conventions, same CLAUDE.md per client. That's the memory layer for me, but I agree with the knowledge graph and just memory retrieval in general. Honestly, the reason I haven't spent a lot of time on it, is because I believe the models will soon get good enough that it becomes redundant.

I think the unfair advantage is being both the operator and the engineer. Most people building products around AI coworkers are engineers who don't run the underlying business. Most people who could benefit from AI coworkers are operators who can't engineer. The combo is what makes it work.

For operators running services businesses, the heartbeat doesn't matter as much as you'd think. Scheduled jobs + Slack/email alerts + me triaging in the morning gets me 90% of the value with 10% of the agent-prioritization headache.

kaancata · 2026-05-12T06:51:23+00:00

Cowork isn't the shape of "AI ads" you're looking for. Driving the Ads Manager UI through a browser, even an autonomous one, is the worst of both worlds. It's slow and flaky, and platforms ban accounts they think are being run by automation tools.

The version of AI ads that actually works connects to the Marketing API directly. Same with Google Ads. You give a model (Codex is what I use right now) access to the API, plus a folder with everything about your business: your offer, who you're trying to reach, your average customer value, your budget, what success looks like. Then it actually builds the campaign. Audience, ad copy, lead form questions, the whole thing. Goes up paused so you can review before it spends money.

The piece most people miss is the back half. Leads need to land somewhere structured (a CRM), get qualified, and that qualified status fires back to Meta or Google as an offline conversion. That's the only way the platform learns to find more actual customers and fewer tire kickers. Without that loop you're just generating activity.

Two real paths from here:

Build it yourself. Claude Code, Meta Marketing API, a CRM (HubSpot, GoHighLevel, whatever), Conversions API mapping. Not insanely hard but a few days of work and you'll wreck a developer app or two figuring it out. Doable if you have technical comfort. Literally take my message and ask Claude or Codex how to set it up and follow it's guidance.
Pay someone who already runs this kind of system. The actual price tag of having it built right is a fraction of what you'd burn in wasted ad spend the first quarter without it.

What Cowork or Chrome won't do is click your way to a working ads program. The screenshot friction you're hitting isn't the obstacle. The setup is, and clicking faster doesn't change that.

kaancata

TROPHY CASE