DEV Community: George K.

How to Learn Vibe Coding with Claude Code

George K. — Wed, 04 Nov 2026 11:10:44 +0000

What to learn, in which order, how long it takes and how to choose between free tutorials, an online Claude Code course and a vibe coding bootcamp.

Key takeaways

Vibe coding is building software by describing what you want in plain language while AI writes the code.
Claude Code is an AI coding agent from Anthropic that works inside your project: it reads files, writes code and runs commands.
The hard part is not syntax. It is planning, breaking work into steps, checking results and testing.
Learning on one real project beats watching many short demos.
Choose a course by what you will have at the end: a finished, published project is the strongest proof of skill.

What is Claude Code?

Claude Code is Anthropic’s agentic coding tool. Instead of chatting about code in a browser, it works directly in your project folder: it can read your files, edit them, run commands and explain what it did. That makes it well suited to vibe coding, because you can stay at the level of “what should the app do” while the agent handles the code.

Interest in learning it is growing fast. In Google Ads Keyword Planner data for ten European markets, searches for “Claude Code course” roughly tripled between September 2025 and August 2026 compared with the year before.

The five skills to learn, in order

The vibe coding skill ladder

1. Brief · Describe the product on one page
2. Small tasks · One clear request, then review
3. Versions · Git, rollback and safe changes
4. Data and tests · Backend, login and automated tests
5. Publishing · Builds, testers and store review
Result · A real app you own

Learn to write a brief, give small tasks, manage versions, add data and tests, then publish. Together they produce a real app you own.

1. Describe a product clearly

AI agents do what you ask, so vague requests produce vague apps. Practise writing a one-page brief: the user, the main task, the screens and what is out of scope.

2. Give small tasks and review every change

Ask for one screen or one feature at a time. Read the summary of what changed, test it, and only then move on. This habit prevents most of the chaos people associate with vibe coding.

3. Save versions and roll back

Git lets you return to any version that worked. Claude Code can run Git commands for you, but you need to understand when to save and how to go back.

4. Add data and test

Real apps store data and have users. Learn to connect a hosted backend, add login and ask the agent to write tests for the main user journey.

5. Publish

Shipping is a skill of its own: cloud builds, testers, store listings, privacy policies and review. For mobile apps this includes TestFlight, Google Play testing and App Store review.

How long does it take to learn vibe coding?

It depends less on talent than on focus and feedback. Someone who already uses ChatGPT or Claude and works on one project full-time, with a teacher to unblock errors, can publish a first app in about a week. Self-study in the evenings usually takes several weeks, mainly because the first serious error can stop progress for days.

Free tutorials, online course or bootcamp?

Option	Good for	What you finish with	Watch out for
Free tutorials and videos	Trying the idea and learning single features	Small demos	Different tools in every video and nobody to help with errors
Self-paced online Claude Code course	Learning the basics on your own schedule	Exercises and a certificate	Projects often stay in the browser and are never published
Live vibe coding bootcamp	Finishing one real project quickly with support	A working, published app and a repeatable method	Needs a full week and costs more than online courses

How to choose a Claude Code course

Do you finish with your own project, not just exercises?
Does the course cover testing and publishing, not only building?
Is there a live teacher who helps when something breaks?
Do you own the code at the end and can you move it anywhere?
Is the group small enough for individual help?
Does the course say honestly what happens after it ends, for example store review times?

Learn vibe coding by publishing your own app

The Vibe Coding Bootcamp at Barcelona Code School is a full-time, five-day Claude Code course. You build and test your own iPhone and Android app, and on the last day you learn how publishing to the App Store and Google Play works.

It runs on campus in Barcelona or live online, in groups of up to 12 people, with no coding experience required. Tuition is €1,600.

See the Vibe Coding Bootcamp

Frequently asked questions

Is vibe coding a real skill or a trend?

The tools will keep changing, but the skill underneath is lasting: describing a product clearly, guiding an AI agent in small steps, checking results and shipping. Those are the same skills product teams use with human developers.

Do I need to learn programming before Claude Code?

No. You learn to read and judge what the agent produces as you go. Basic programming knowledge helps, but it is not a requirement for a first app.

What does Claude Code cost?

Claude Code is available with paid Claude plans or through Anthropic’s API. Check Anthropic’s current pricing page, because plans change.

What is the best first project for learning vibe coding?

A small app that solves one clear problem for one type of user, such as a booking tool, a habit tracker or an internal tool for your team. Avoid payments, real-time chat and sensitive data in your first project.

Is a Claude Code course the same as a vibe coding course?

Often, yes. Vibe coding is the way of working, and Claude Code is one of the main tools used for it. A good course teaches both the method and the tool on a real project.

Sources

Anthropic: Claude Code overview.
Anthropic: Claude Code best practices.
Expo documentation.
Apple: App Store Review Guidelines.
Google Play Console Help: testing requirements for new personal developer accounts.
Google Ads Keyword Planner, “Claude Code course”, ten European markets, September 2025 to August 2026. Barcelona Code School research, October 2026.
BCS Vibe Coding Bootcamp.

Continue learning

How to build a mobile app with AI, step by step

Vibe Coding Bootcamp in Barcelona or online

Compare AI learning paths

Originally published at Barcelona Code School. Learn more about our AI, coding and design programmes at barcelonacodeschool.com.

How to Build a Mobile App with AI: From Idea to App Store

George K. — Wed, 04 Nov 2026 07:42:39 +0000

A practical, step-by-step path for people who are not developers: plan the app, build it with Claude Code, test it with real people and publish it on iPhone and Android.

Key takeaways

Vibe coding means building software by describing what you want in plain language and letting AI write the code.
An AI coding agent works best when you give it one small, clear task at a time and check each change on your phone.
A cross-platform framework lets one codebase run on both iPhone and Android.
Publishing has its own rules: Apple reviews every App Store release, and Google asks new personal developer accounts to run a closed test with 12 testers for 14 days.
A first app should solve one clear problem for one type of user.

What is vibe coding?

Vibe coding is a way of building software where you describe the result you want in everyday language and an AI model writes the code. The term was popularised in early 2025 by AI researcher Andrej Karpathy. Since then it has grown from quick experiments into a practical way for founders, product managers and other non-developers to build working software.

On its own, vibe coding often produces apps that break as soon as they grow. What makes the difference is method: a clear plan, small steps, saved versions and testing. That is what this guide focuses on.

What you need before you start

A laptop. Mac or Windows both work if you build the iPhone version in the cloud.
A smartphone to run and test your app.
An AI coding agent. This guide uses Claude Code, which runs in your terminal and can read, write and run code in your project.
Developer accounts with Apple and Google when you are ready to publish. Both are paid, and approval of a new account can take a few days.
An idea that fits on one page.

Step by step: building your app with AI

The path of an AI-built app

1. Plan · One-page brief, main task and screens
2. Set up · Claude Code, Expo and Git
3. Build · Screens and flow, one task at a time
4. Data · Database, login and one AI feature
5. Test · Automated tests and real testers
6. Publish · Store listing, review and release

Plan the app, set up the tools, build the screens, add data and login, test with real people, then publish to the stores.

1. Write a one-page product brief

Before you open any tool, write down who the app is for, the one main task it helps them do, the three to five screens it needs and what it will not do. This page becomes your instructions for the AI. Most failed AI-built apps fail here, because the AI was asked to build something vague.

2. Set up Claude Code and a cross-platform project

Install Claude Code and create a new Expo project. Expo is built on React Native and lets one codebase run on iPhone and Android, and you can open the app on your own phone while you work. Create a Git repository from the first hour so you can always return to a version that worked.

3. Build the screens one task at a time

Give Claude Code your brief, then ask for one thing at a time: the home screen, then navigation, then a form. After each change, open the app on your phone and check it. If something breaks, ask Claude Code to explain the error, or roll back to the last saved version. Small steps are slower for ten minutes and much faster for the whole week.

4. Add data, login and one AI feature

Most useful apps need to remember things and know who the user is. A hosted backend such as Supabase gives you a database and user login without running your own server. Then add one AI feature that makes the app genuinely helpful, such as a suggestion, a summary or an answer. Keep secret keys out of the app code.

5. Test with code and with people

Ask Claude Code to write automated tests for the main user journey and read what they check. Then build the app in the cloud and give it to real testers: TestFlight on iPhone and a testing track on Google Play. Watch where people get stuck and fix those problems first.

6. Prepare the store listing and publish

Each store needs an icon, screenshots, a description, a privacy policy and answers about what data the app collects. Apple reviews every App Store submission and publishes guidelines explaining common reasons for rejection. On Google Play, new personal developer accounts must run a closed test with at least 12 testers for 14 days before they can release to everyone, so plan for it.

Which way of building is right for you?

Option	Best for	What you get	Main limit
AI app builder (no-code platform)	A quick prototype to show an idea	A working screen in minutes	The app lives inside the platform and custom features are hard
AI coding agent such as Claude Code	A real app you own and can keep improving	Full source code for iPhone and Android	You need a method and some patience with errors
Hiring a developer or agency	Complex apps with payments or sensitive data	Professional engineering	Higher cost and slower changes

Common mistakes when building an app with AI

Asking the AI to build the whole app in one prompt instead of in small steps.
Not saving working versions, so one bad change breaks everything.
Adding features before the main task works from start to finish.
Putting secret keys inside the app code.
Leaving store preparation for the last day and discovering the Google Play testing rule too late.

Build your app in one week with a teacher

Barcelona Code School’s Vibe Coding Bootcamp follows this path in five full-time days. You build and test your own iPhone and Android app with Claude Code, and on the last day you learn how publishing to the App Store and Google Play works, so you can decide if and when to publish.

The bootcamp runs on campus in Barcelona or live online, takes 40 hours, needs no coding experience and costs €1,600.

See the Vibe Coding Bootcamp

Frequently asked questions

Can I build a mobile app with AI if I cannot code?

Yes. An AI coding agent such as Claude Code writes the code from your instructions. You still need to plan the app, give clear tasks, check results on your phone and test it, which are skills you can learn in days rather than years.

How long does it take to build an app with AI?

A focused first version with a few screens, data and login can be built in about a week of full-time work. Store review and Google Play testing add extra days or weeks after that.

Do I need a Mac to build an iPhone app?

Not necessarily. With Expo you can build the iPhone version in the cloud and test it on your phone, so Windows users can take part.

What is the difference between vibe coding and no code?

No-code tools let you assemble an app inside their platform. Vibe coding produces real source code that you own, can move anywhere and can keep developing.

Will Apple accept an app built with AI?

Apple reviews the app, not the way it was written. Your app must follow the App Store Review Guidelines, work reliably and explain how it uses personal data.

Sources

Continue learning

How to learn vibe coding with Claude Code

Vibe Coding Bootcamp in Barcelona or online

Compare AI learning paths

Originally published at Barcelona Code School. Learn more about our AI, coding and design programmes at barcelonacodeschool.com.

AI Agent Architecture Explained: 7 Essential Layers

George K. — Tue, 03 Nov 2026 14:40:31 +0000

See what sits around the model, where control should live and how a request becomes a traceable, approved action.

Published 13 October 2026 · Barcelona Code School

AI agent architecture is the system around a model that turns a goal into controlled, observable work.

A practical design has seven layers: entry and identity, orchestration and policy, model reasoning, tools, state and memory, approval and execution, and observability and evaluation. The model may choose a next step, but code and downstream systems must enforce permissions, limits, approvals and safe stopping.

Key takeaways

The model is one component, not the whole agent system.
Every boundary should pass structured data with an explicit owner.
Keep deterministic business rules outside probabilistic model judgment.
Separate read tools from write tools and gate consequential actions.
Design failure states, traces and tests before increasing autonomy.

The seven layers of an AI agent

Architecture is less about choosing a fashionable framework and more about deciding where data, judgment and authority live. The diagram below is a reference model, not a universal product stack.

Figure 1. A controlled AI agent architecture

1. Entry · Request + identity
2. Control · Policy + routing
3. Model · Bounded judgment
4. Tools · Typed read/write APIs
5. State · Run + selected memory
6. Approval · Authorize + execute
7. Evidence · Trace + eval

Deterministic controls surround the model loop; evidence spans the full run.

Text equivalent: an authenticated request enters a policy and orchestration layer. The model receives bounded context and may select a typed tool. State preserves transaction facts, while optional long-term memory is separately governed. Write actions cross an approval and authorization boundary before execution. Every step produces trace data and structured outcomes for debugging and evaluation.

1. Entry and identity

The entry layer accepts a goal from a user, event or scheduled job. It establishes who requested the work, which organisation and record it belongs to, and what scope was granted. Input validation, authentication and rate limits begin here.

2. Policy and orchestration

This layer decides what path is allowed: a deterministic workflow, an agent loop, a human handoff or a refusal. It owns retry limits, timeouts, stop conditions and budgets. Use a fixed workflow when the steps are known; reserve model-directed routing for real ambiguity.

3. Model and instructions

The model interprets context, proposes a plan or chooses a tool. Its instructions define the role, goal, constraints and completion condition. The model can recommend an action, but should not be the final authority on identity, permissions or irreversible business rules.

4. Tools and knowledge

Tools give the system ground truth and the ability to act. Give each tool a narrow purpose, typed parameters, clear error responses and minimum privileges. Separate reads from writes: searching a CRM is not the same permission as changing a customer record.

5. Run state and memory

Run state holds facts needed to complete this transaction: identifiers, tool results, approval status and the next allowed step. Long-term memory persists selected information for future runs. Do not turn every conversation or hidden reasoning token into memory; define purpose, consent, retention and deletion.

6. Approval and execution

This is the authority boundary. A person reviews high-impact, sensitive or irreversible actions. After approval, deterministic code re-checks authorization, validates the payload and performs the write with an idempotency key. A timeout is not proof that a write failed.

7. Observability and evaluation

A trace should connect the request, model decision, tool call, approval, execution result and terminal status without exposing unnecessary sensitive data. Evaluation cases then test whether the system completed the task, used allowed tools and stopped safely.

Define the contracts before choosing a framework

A framework can run the loop, but it cannot decide your business boundary. Start with the records that cross each layer.

{
  "run_id": "case-1042",
  "actor_id": "user-27",
  "goal": "prepare a customer reply",
  "scope": ["customer:read", "draft:create"],
  "state": "awaiting_approval",
  "proposed_action": {
    "tool": "message.send",
    "arguments_hash": "sha256:..."
  },
  "approval": null,
  "attempt": 1,
  "trace_id": "trace-8f2"
}

The model may prepare proposed_action. The execution service checks the authenticated actor, current scope, approval object and destination state before any send.

Boundary	Input contract	Output contract	Owner
Entry → control	Goal, identity, tenant, scope	Accepted, refused or routed request	Application
Control → model	Instructions, bounded context, allowed tools	Structured decision or clarification	Agent runtime
Model → tool	Tool name and schema-valid arguments	Typed result or typed error	Tool service
State → memory	Approved memory candidate	Stored, rejected or expired record	Data owner
Proposal → execution	Action, scope, approval, idempotency key	Receipt, known failure or uncertain outcome	Downstream system
Run → evidence	Events with trace ID	Redacted trace and evaluation outcome	Operations

4-week live bootcamp · Barcelona or online

Go from one workflow to a complete AI automation system

In the AI Agent & Automation Bootcamp you build a no-code Virtual AI Department with n8n, RAG, connected agents and human approvals — live with an instructor and a small group.

See the bootcamp programme →

Not sure it fits? Take the free AI Career Roadmap test

How to design the architecture

Name one business outcome. Define the trigger, terminal success state, non-goals and the human owner.
Choose the least autonomous path. Use rules for known steps and introduce model choice only where ambiguity makes it useful.
Define state and schemas. Specify required fields, provenance, lifecycle and which outputs downstream code may trust.
Build narrow tools. Split reads from writes, grant minimum scope and return machine-readable errors.
Place approval gates. Require a person for sensitive, consequential or irreversible actions; bind approval to the exact payload.
Design recovery. Set timeouts, attempt limits, idempotency keys, destination checks and a human escalation package.
Add traces and evals. Measure task completion, policy compliance, tool correctness, cost and latency against representative cases.

A guardrail prompt is not an authorization system. Enforce identity, scope, limits and final write permission in code and in the downstream service.

Permissions, approval and recovery

Situation	Architecture control	Safe result
Untrusted text asks for a hidden action	Treat retrieved content as data; tool allowlist and downstream authorization remain active	Instruction is ignored or run stops
Model requests an unauthorized tool	Runtime checks tool policy and actor scope	Denied event is traced
High-impact write proposed	Human approval bound to tool, arguments and expiry	No write before approval
Tool returns malformed data	Schema validation; no silent coercion	Retry bounded or human escalation
Write times out	Check destination using idempotency key before retry	No blind duplicate
Agent exceeds step or cost limit	Deterministic stop condition	Partial evidence handed to a person
Trace contains sensitive fields	Redaction, access control and retention policy	Useful evidence without unnecessary exposure

Architecture test matrix

Test	Expected evidence	Pass condition
Valid read-only request	Identity, route, tool result, final status	Correct answer; no write permission used
Missing or invalid input	Validation event	Rejected before model/tool call
Prompt injection in retrieved text	Content source and denied action	No scope expansion or secret disclosure
Unauthorized write	Policy decision and actor scope	Write is blocked
Approval rejected or expired	Approval status	No execution; terminal safe state
Tool timeout after possible write	Idempotency key and destination check	No duplicate transaction
Malformed model output	Schema error	Bounded repair or escalation
Step/cost limit reached	Usage and stop reason	Run stops with a useful handoff
Trace review	Linked events, redaction and outcome	Owner can explain what happened

Success criteria

Every run has an authenticated actor, a scope and a terminal status.
Model output crosses schema validation before code trusts it.
Read and write permissions are separate.
High-impact writes require explicit approval.
Retries cannot silently duplicate side effects.
A trace reconstructs the run without storing unnecessary sensitive data.
Evaluation includes expected failures, not only happy paths.

Learn to turn architecture into a working system

Understanding the layers is the first step; the useful skill is connecting them into a process that survives real inputs, permissions and failures. Barcelona Code School's AI Agent & Automation Bootcamp focuses on visual business automation with n8n: workflows, integrations, human approvals, testing and portfolio projects. It is not a LangGraph or low-level Python framework course.

Explore the AI Agent & Automation Bootcamp

Frequently asked questions

What are the main components of AI agent architecture?

A useful production view has seven layers: entry and identity, policy and orchestration, model reasoning, tools, state and memory, approval and execution, and observability and evaluation. The exact implementation varies, but each boundary needs a clear contract and owner.

Is an AI agent just an LLM with tools?

A model with instructions and tools is the smallest useful agent loop. A dependable application also needs authentication, state, authorization, approval rules, error handling, logs and tests around that loop.

Where should business rules live in an AI agent?

Deterministic rules such as permissions, spending limits, required fields and irreversible-action approvals should be enforced in code or downstream systems. Do not rely on the model to remember or correctly apply security policy.

Does every AI agent need long-term memory?

No. Keep run state only for values needed to finish the current transaction. Add durable memory only when a defined future task needs it, with consent, retention, correction and deletion rules.

How do you test an AI agent architecture?

Test each layer and the boundaries between layers: invalid input, unauthorized tools, untrusted content, malformed model output, timeouts, duplicate retries, rejected approvals and incomplete traces. A test passes only when the system reaches the expected safe state.

Sources

Continue learning

Build an AI agent step by step

Compare BCS AI learning paths

Explore the AI Agent & Automation Bootcamp

Originally published at Barcelona Code School. Learn more about our AI, coding and design programmes at barcelonacodeschool.com.

Common n8n AI Workflow Errors and How to Fix Them

George K. — Mon, 02 Nov 2026 10:32:55 +0000

When an AI workflow fails, changing the prompt at random usually hides the real problem. Follow the evidence from the trigger to the external action, repair one boundary and prove the fix with failure tests.

To fix an n8n AI workflow, inspect the failed execution before changing prompts or nodes.

Find the first boundary that failed: trigger, mapped input, model call, tool selection, structured output, external write or recovery. Repair and retest that boundary with saved evidence. Never blindly retry after a timeout or write; check the destination first so one failure does not become a duplicate action.

Key takeaways

Start with the first incorrect node output, not the last visible error message.
Separate AI judgement from deterministic validation, permissions and writes.
Use stable session and business keys so memory and retries do not cross transactions.
A timeout does not prove failure; inspect the external destination before replaying a write.
Keep the failed execution, repair one boundary and run a regression matrix before reactivation.

Where should you start when an n8n AI workflow fails?

Open the failed execution and read the data in order. Find the last correct output and the first incorrect or missing input. That transition is the boundary to repair. A chatbot answering badly, for example, may actually be receiving the wrong field, an empty tool result or memory from another session.

n8n lets operators inspect executions and retry failed runs with the saved or current workflow. That is useful, but replay is a recovery action—not a diagnosis. Preserve the original execution, check whether any external write already happened and only then decide what may run again.

Figure 1. A five-boundary diagnostic flow

1. Trigger · Did the correct event reach the production workflow?
2. Input · Are fields, item links and types present as expected?
3. AI + tools · Did the model receive the context and call an allowed tool?
4. Output · Does the result match the required schema and business rules?
5. Side effect · Did the write complete, fail or become uncertain?

Stop at the first broken boundary. Later errors are often consequences, not causes.

Text equivalent: first confirm that the intended production trigger created an execution. Next inspect the input fields and item links. Then examine the model request, connected tools and returned tool data. Validate the structured result before any write. Finally, compare the execution with the destination system and recover only from known state.

Common n8n AI workflow errors: symptom, cause and fix

Symptom	Likely boundary	Evidence to inspect	Safe fix
No execution appears	Trigger or webhook	Test versus production URL, HTTP method, authentication, active status	Activate the intended workflow and update the caller to the exact production endpoint
A field is empty or belongs to another item	Mapping	Previous-node output, expression preview, item-linking error	Validate and normalise the input before the AI node; reference the correct item explicitly
The agent ignores or misuses a tool	Tool selection	Connected tools, names, descriptions, parameters and execution trace	Expose fewer, distinct tools; use a deterministic node when choice is not required
JSON or parser fails	Structured output	Raw model response, requested schema, required and optional fields	Reduce schema complexity, validate output separately and route invalid data to repair or review
One user's context appears in another conversation	Memory	Session key and the value produced for each user or conversation	Use a stable, scoped session key; test two conversations in parallel
401 or 403 from an app	Credentials and permissions	Credential owner, expiry, OAuth scopes, target resource access	Reauthenticate with the smallest required scope and correct service identity
429, timeout or intermittent API error	External service	Status code, response headers, item count, attempt number	Batch requests, respect limits and use bounded delay only for clearly transient failures
Duplicate email, record or ticket after retry	Recovery	Business key, destination search, timestamps and prior response	Reconcile destination state; use search-before-create, upsert or another idempotent pattern
Untrusted content changes the agent's behaviour	Permission boundary	Prompt inputs, exposed tools and attempted actions	Treat source text as data, keep permissions fixed and require review for consequential tools

The workflow does not trigger

n8n Webhook nodes have separate test and production URLs. A manual test can succeed while the live caller still points to the test endpoint, uses the wrong method or reaches an inactive workflow. Compare the incoming request with the current production configuration rather than rebuilding downstream nodes.

The input looks right but maps incorrectly

Inspect the actual input of the failing node. Renamed fields, arrays, multiple items and broken item links can make an expression valid in one run and empty in another. Add a deterministic validation step that rejects missing fields with a useful reason before invoking a model.

The agent does not call the expected tool

An n8n AI Agent needs connected tools, but a model still chooses among them from the task and descriptions. Give each tool one clear job and a narrow input contract. If a policy requires the same action every time, connect that action as a normal workflow step instead of leaving the choice to AI.

The structured result will not parse

Save the raw response and compare it with the requested schema. Deep or contradictory schemas, missing required fields and model prose outside the structure can break parsing. Use a smaller contract, validate it after generation and send invalid results to a bounded repair or human-review path.

Memory mixes or loses conversations

Memory is only as isolated as its session key. A changing key loses continuity; a shared key combines users. Create a stable key from the approved conversation identity, avoid personal data where a pseudonymous identifier works, and run parallel-session tests before production.

Credentials return 401 or 403

Check whether authentication expired, the credential belongs to the expected identity and its scope covers the exact resource. Do not solve a permission error by granting broad access. n8n workflow sharing can affect how editors use existing credentials, so review sharing and ownership together.

The API returns 429 or times out

Slow the workload at the workflow boundary: batch items, respect documented limits and record attempt counts. Retry only errors known to be transient, with a maximum number of attempts. A timeout after a write request has unknown state and needs reconciliation, not an automatic replay.

A retry creates the action twice

Give the business transaction a stable key and look for an existing result before creating another one. Record the destination identifier after success. If the previous response was lost, query the destination by that key and resume from the confirmed state instead of restarting the entire workflow.

4-week live bootcamp · Barcelona or online

Go from one workflow to a complete AI automation system

In the AI Agent & Automation Bootcamp you build a no-code Virtual AI Department with n8n, RAG, connected agents and human approvals — live with an instructor and a small group.

See the bootcamp programme →

Not sure it fits? Take the free AI Career Roadmap test

How to debug an n8n AI workflow in seven steps

Freeze the failing case. Keep the execution ID, timestamp, non-secret sample input and observed outcome. Redact credentials and unnecessary personal data before sharing evidence.
Define the expected transaction. Write the trigger, required fields, AI task, allowed tools, intended output and final side effect in one short sequence.
Find the first broken boundary. Compare node inputs and outputs from the trigger forward. Stop where correct evidence first becomes missing, malformed or unexpected.
Classify the failure. Decide whether it is trigger, mapping, model, tool, parser, permission, rate-limit, external-state or recovery logic. Do not call every failure a prompt problem.
Repair the smallest responsible component. Change one mapping, contract, credential, tool description or recovery rule. Preserve the rest so the cause remains observable.
Reconcile before replay. If an email, CRM record, payment, ticket or other write may have happened, read the destination first. Continue only from confirmed state.
Run regression tests and reactivate deliberately. Test the original failure plus normal, malformed, duplicate, denied and timeout cases. Record the result and named owner.

Where should permissions and human approval sit?

Place the approval immediately before a consequential action, after the workflow has collected enough evidence for a useful decision. The reviewer should see the proposed action, important inputs, source evidence, destination, business key and what happens after approve, reject or expiry.

Action	Default boundary	Escalate when
Read approved internal information	Scoped read credential and logged query	Source is sensitive or request falls outside policy
Draft a response or record	AI may draft; deterministic checks validate fields	Evidence conflicts or required information is missing
Send a message externally	Approval for sensitive, high-impact or novel cases	Recipient, claim or attachment is uncertain
Create or update a business record	Stable business key, validation and least-privilege write	Duplicate match or state conflict appears
Delete, pay, diagnose, hire or make another consequential decision	Do not delegate final authority to the model	Always route to an authorised person under the applicable policy

Never give untrusted prompt content the power to widen tools, credentials or approval rules. Those boundaries belong to the workflow and the responsible human owner.

Regression test matrix after the fix

Test	Expected evidence	Pass condition
Normal valid request	Complete inputs, valid AI result and destination ID	One correct outcome
Missing required field	Validation error names the field	No model call or external write
Malformed or adversarial content	Fixed tool set and validation route	No permission expansion or unsafe action
Wrong or expired credential	401/403 recorded without secret exposure	Stops and alerts the named owner
Duplicate trigger	Same stable business key	One final external transaction
Rate limit	Bounded attempts and recorded delay	Recovers within policy or escalates
Timeout after write request	Destination lookup before any retry	No blind duplicate action
Approval rejected or expires	Decision and actor retained	Consequential action remains unexecuted
Two memory sessions	Distinct scoped session keys	No context crosses conversations
Owner handover	Second operator uses runbook and evidence	Diagnoses the seeded failure without the builder

Success criteria

The original failure is reproducible before the fix and absent afterward.
Every required field and structured output is validated outside the model.
Tools and credentials have the smallest practical permissions.
Duplicate events and uncertain writes cannot silently create duplicate outcomes.
Human rejection and expiry stop the action and remain auditable.
A second operator can locate the failed boundary from saved evidence.
Production is reactivated only after the full regression set passes.

Troubleshooting is where automation becomes a professional skill

Building the happy path is only the beginning. Barcelona Code School's AI Agent & Automation Bootcamp teaches how to design complete n8n systems: structured data, tool-using agents, credentials, approvals, RAG, testing and recovery. You learn to explain what happened when a run fails—and to repair it without creating a second problem.

If you only need to correct one small workflow, the n8n documentation and the diagnostic sequence above may be enough. The bootcamp is for people who want to build a portfolio of production-minded automations and work confidently across the whole system.

Explore the AI Agent & Automation Bootcamp

Frequently asked questions

Why is my n8n AI Agent not calling a tool?

Confirm that the tool is connected and receives valid input, then inspect the execution evidence. Give tools distinct names and narrow descriptions. If the workflow must always perform one fixed action, use a deterministic node instead of asking the model to choose.

Why does an n8n workflow work manually but not in production?

Check whether the production workflow is active and whether the caller uses the production webhook URL, expected method and authentication. Test and production webhooks are different endpoints, so a successful manual test does not prove the production trigger is configured correctly.

Is it safe to retry a failed n8n execution?

Retry only after you know the previous attempt did not complete an external side effect. If a timeout occurred after a create, send or update request, inspect the destination first. Reconcile its state, then retry only the unfinished portion with a stable business key.

How do I stop duplicate actions in n8n?

Assign each business transaction a stable key, search or read the destination before creating a record, and store the completed outcome. Retries should resume from known state rather than replaying the whole workflow blindly.

Should I fix a bad AI output in the prompt or workflow?

First identify whether the failure is interpretation or deterministic control. Clarify the prompt for genuine language ambiguity. Put required fields, schema validation, permissions, approvals and external writes in the workflow so correctness does not depend on persuasive wording.

Sources

Continue learning

Design an AI agent from first principles

Compare BCS AI learning paths

Build and troubleshoot AI automation systems with n8n

Originally published at Barcelona Code School. Learn more about our AI, coding and design programmes at barcelonacodeschool.com.

LangChain vs LangGraph: Which Should You Use?

George K. — Sun, 01 Nov 2026 08:57:20 +0000

AI framework comparison

They belong to the same ecosystem and solve different layers of the problem. Start at the highest abstraction that gives your team enough control.

Published 13 October 2026 · Barcelona Code School

Choose LangChain when you want a configurable, higher-level agent harness with models, tools, prompts and middleware.

Choose LangGraph directly when the orchestration itself is your application: custom state, deterministic branches, durable execution, interrupts or long-running workflows. LangChain agents already run on LangGraph, so this is usually a choice of abstraction level—not two unrelated technologies.

Key takeaways

LangChain is the higher-level agent framework; LangGraph is the low-level orchestration runtime.
LangChain agents inherit LangGraph capabilities underneath.
Direct LangGraph gives more explicit control but more engineering responsibility.
Neither replaces application authorization, safe side effects or testing.
Start high-level and move down only for a named control requirement.

What is the real difference?

Current LangChain documentation describes create_agent as a configurable harness around a model loop: model, tools, prompt and middleware. It is intended to get a standard agent running with less orchestration code while still allowing policies, retries and routing through middleware.

LangGraph is the lower-level framework and runtime for long-running, stateful agents. Developers define shared state, nodes and transitions, mixing deterministic code with model-driven decisions. LangGraph can be used without LangChain, although LangChain integrations are commonly used for models and tools.

Figure 1. Two entry points into the same agent stack

Start with LangChain

Model · Tools · Prompt · Middleware

Use the prebuilt agent loop and customise the harness.

Built on LangGraph

Use LangGraph directly

Typed state · Nodes · Edges · Checkpoints · Interrupts

Define the orchestration, transitions and recovery semantics yourself.

The decision is how much of the orchestration you need to own explicitly.

Text equivalent: LangChain offers a high-level agent harness that combines a model, tools, prompt and middleware and uses LangGraph underneath. Direct LangGraph exposes state, graph nodes, edges, persisted checkpoints and interrupts so developers can implement custom orchestration.

LangChain vs LangGraph side by side

Criterion	LangChain	Direct LangGraph
Primary abstraction	Configurable agent harness	State graph and orchestration runtime
Best starting fit	Standard model-and-tools agent loop	Custom stateful or long-running workflow
Control surface	Prompts, tools and middleware	State, nodes, edges, commands and interrupts
State	Agent state managed through the harness	Explicit schema and update rules
Routing	Prebuilt loop plus middleware/customisation	Developer-defined deterministic and agentic transitions
Human review	Available through agent middleware/runtime capabilities	Dynamic interrupts with persisted state and resume input
Code burden	Lower for common agent architectures	Higher because orchestration is application code
Typical risk	Forcing a complex process into a convenient default loop	Building custom graph machinery before it is needed

When should you start with LangChain?

Use LangChain when the core pattern is familiar: the model reads messages, chooses among bounded tools and returns an answer. The harness is especially useful when you want provider integrations and middleware without designing every state transition first.

Your first version is a conventional tool-calling agent.
Prompt, tool and middleware customisation is enough.
You want to validate the use case before owning graph internals.
The team benefits from less orchestration code.

4-week live bootcamp · Barcelona or online

Go from one workflow to a complete AI automation system

In the AI Agent & Automation Bootcamp you build a no-code Virtual AI Department with n8n, RAG, connected agents and human approvals — live with an instructor and a small group.

See the bootcamp programme →

Not sure it fits? Take the free AI Career Roadmap test

When should you use LangGraph directly?

Use LangGraph directly when control flow is product logic. Good signals include long-running state, deterministic stages around agent decisions, conditional review points, nested workflows or recovery that must resume from a known checkpoint.

Interrupts can persist state and wait for external input. They require a checkpointer and stable thread ID. Because an interrupted node restarts from its beginning on resume, code before the interrupt must not create an unguarded side effect.

The state schema and transitions require explicit review.
Deterministic and model-driven nodes must interleave.
The workflow pauses and resumes across time or people.
Custom routing is clearer as a graph than middleware around a loop.

Do not choose LangGraph because the workflow sounds sophisticated. Choose it when you can name the state or control behavior the higher-level harness cannot express clearly.

How do you choose in six steps?

Define the transaction. Name the input, final output, tools, owner and success condition.
Draw the smallest agent loop. If model → tool → model is enough, prototype it with LangChain.
List required state transitions. Identify checkpoints, deterministic branches, pauses and resume rules.
Mark side effects and approvals. Put authorization and human review before consequential tools.
Prototype the hardest control. Test the interrupt, custom route or recovery path that motivates direct LangGraph.
Choose the highest sufficient abstraction. Keep LangChain if it stays clear; use LangGraph directly only where explicit orchestration reduces risk.

Permissions, failure paths and human approval

Risk	Required control	Pass condition
Tool has broad access	Scoped service identity and allowlisted operation	Agent cannot widen its own permission
Human review pause	Persist state, authenticate reviewer, record decision	Resume uses the right thread and authorised input
Side effect before interrupt	Move write after approval or make it idempotent	Resume does not repeat the write
Transient tool failure	Bounded retry and preserved evidence	Stops or escalates after the limit
Unknown external state	Read destination before replay	No blind duplicate action
Untrusted prompt content	Fixed tools, schema validation and policy outside prompt	Content cannot change authority

Test the architecture before committing

Test	Pass condition
Normal request	Correct result with traceable tool evidence
Malformed tool input	Validation or safe correction; no write
Approval rejected	Consequential action remains unexecuted
Pause and resume	Correct state resumes under the same thread
Duplicate resume	No repeated external side effect
Tool timeout	Bounded recovery retains context
Unauthorised request	No data or tool access
Owner handover	Second developer explains and diagnoses the path

Success criteria

The selected abstraction expresses the workflow without duplicate control layers.
State and external writes have explicit contracts.
Review and resume behavior is tested, including duplicate delivery.
Permissions remain outside model discretion.
Failures preserve enough evidence for diagnosis.
The team can maintain the design without one hidden expert.

Choose the learning path that matches the stack

If you want to engineer a custom Python or JavaScript agent product, study LangChain, LangGraph and software delivery directly. Barcelona Code School's current AI Agent & Automation Bootcamp instead teaches visual business systems with n8n, data, RAG, approvals, testing and recovery.

The bootcamp is relevant when your goal is applied no-code automation, not as a substitute for a code-first LangGraph course.

Compare BCS AI learning paths

Frequently asked questions

Is LangGraph part of LangChain?

LangGraph is developed by LangChain Inc and LangChain agents are built on LangGraph, but LangGraph is a separate low-level orchestration framework and can be used without LangChain.

Should beginners use LangChain or LangGraph?

Start with LangChain when a standard tool-calling agent and configurable middleware meet the need. Use LangGraph directly after you can describe why custom state, routing, persistence or interruption behavior must be controlled at graph level.

Can LangChain and LangGraph be used together?

Yes. LangChain components and agents use LangGraph capabilities, and a custom LangGraph workflow can use LangChain model and tool integrations. The choice is mainly whether you work through the higher-level harness or define orchestration directly.

When should I move from LangChain to LangGraph?

Move to direct LangGraph orchestration when the default agent loop no longer expresses your required state transitions, deterministic branches, long-running checkpoints, review points or recovery behavior clearly.

Does LangGraph make an agent safe by itself?

No. Persistence and interrupts provide control points, but the application must still enforce authentication, authorization, tool permissions, input validation, idempotency, audit evidence and safe handling of external writes.

Sources

Continue learning

Design the agent before choosing a framework

Compare BCS AI courses

Build visual AI automation systems with n8n

Originally published at Barcelona Code School. Learn more about our AI, coding and design programmes at barcelonacodeschool.com.

LangGraph Tutorial: Build a Stateful AI Agent

George K. — Sun, 01 Nov 2026 07:13:09 +0000

Stateful agent tutorial

Build a fictional draft-review graph that remembers its state, pauses for a person and resumes safely—without sending anything externally.

Published 13 October 2026 · Barcelona Code School

A stateful LangGraph agent stores shared data across graph nodes and persists checkpoints under a stable thread ID. In this tutorial, a request is validated, a draft is created, execution pauses with interrupt(), and a person approves, edits or rejects it. Resume with Command(resume=...) and the same thread ID. Keep side effects after approval because the interrupted node restarts when resumed.

Key takeaways

State stores raw facts needed across nodes; prompts are formatted inside nodes.
Nodes return state updates and edges define allowed movement.
A checkpointer and thread ID make pause/resume possible.
Interrupt should precede non-idempotent side effects.
Test duplicate resumes, wrong thread IDs and rejected approval before adding real tools.

What will you build?

The example is a low-risk review assistant. It accepts a fictional request, validates required text, creates a deterministic placeholder draft, pauses for review and stores the final decision. It does not call a model, send a message or modify an external system. That keeps the tutorial focused on LangGraph state and control.

Figure 1. Stateful draft-review execution

Validate · Required input?
Draft · Store raw result
Interrupt · Checkpoint + review
Resume · Same thread ID
Finish · Record decision

No external side effect occurs in this learning graph.

Text equivalent: input is validated and converted into a draft stored in state. The review node pauses through an interrupt and the checkpointer saves the thread. A later call resumes the same thread with a human decision. The graph records an approved, edited or rejected final state and ends without sending data elsewhere.

Step 1: install LangGraph and define state

pip install -U langgraph

from typing import Literal, TypedDict

class ReviewState(TypedDict, total=False):
    request_id: str
    request_text: str
    draft: str
    status: Literal["new", "waiting", "approved", "rejected"]
    reviewer_note: str

Store values that must survive across nodes. Keep the original request and draft as raw data; format review messages only when needed.

Step 2: add validation and draft nodes

def validate(state: ReviewState):
    text = state.get("request_text", "").strip()
    if not text:
        raise ValueError("request_text is required")
    return {"status": "new"}

def create_draft(state: ReviewState):
    # Deterministic placeholder: replace with a tested model call later.
    draft = f"Draft for review: {state['request_text']}"
    return {"draft": draft, "status": "waiting"}

Each node receives current state and returns only its updates. Validation remains deterministic. A future model call should return structured output and have separate error handling.

Step 3: pause for human review

from langgraph.types import interrupt

def review(state: ReviewState):
    # Put interrupt before any non-idempotent side effect.
    decision = interrupt({
        "request_id": state["request_id"],
        "draft": state["draft"],
        "allowed": ["approve", "edit", "reject"],
    })
    if decision["action"] == "reject":
        return {"status": "rejected", "reviewer_note": decision.get("note", "")}
    return {
        "status": "approved",
        "draft": decision.get("edited_draft", state["draft"]),
        "reviewer_note": decision.get("note", ""),
    }

On resume, the interrupted node starts again from its beginning. Never place an unguarded email, payment, database write or other irreversible operation before interrupt().

4-week live bootcamp · Barcelona or online

Go from one workflow to a complete AI automation system

In the AI Agent & Automation Bootcamp you build a no-code Virtual AI Department with n8n, RAG, connected agents and human approvals — live with an instructor and a small group.

See the bootcamp programme →

Not sure it fits? Take the free AI Career Roadmap test

Step 4: compile with a checkpointer

from langgraph.graph import END, START, StateGraph
from langgraph.checkpoint.memory import InMemorySaver

builder = StateGraph(ReviewState)
builder.add_node("validate", validate)
builder.add_node("create_draft", create_draft)
builder.add_node("review", review)
builder.add_edge(START, "validate")
builder.add_edge("validate", "create_draft")
builder.add_edge("create_draft", "review")
builder.add_edge("review", END)
graph = builder.compile(checkpointer=InMemorySaver())

The in-memory saver is suitable for this local tutorial, not a production deployment. Production needs durable storage and explicit retention, privacy and recovery decisions.

Step 5: invoke, inspect and resume

from langgraph.types import Command

config = {"configurable": {"thread_id": "review-case-1042"}}
initial = {
    "request_id": "case-1042",
    "request_text": "Prepare a short acknowledgement.",
}

paused = graph.invoke(initial, config=config)
# Inspect paused["__interrupt__"] in the invoke API.

finished = graph.invoke(
    Command(resume={"action": "approve", "note": "Checked"}),
    config=config,
)
assert finished["status"] == "approved"

The same thread ID is essential. Treat it as an access-controlled pointer to persisted state, not a guessable public token.

Permissions and recovery boundaries

Risk	Control	Safe result
Wrong person resumes thread	Authenticate caller and authorize access to the business transaction	No cross-user state access
Code before interrupt repeats	Put side effect after approval or make operation idempotent	No duplicate write
Process crashes while waiting	Durable production checkpointer and stable thread ID	State can be recovered
Malformed resume payload	Validate action and fields against a schema	Graph remains paused or fails safely
Approval rejected	Terminal rejected status; no external action	Decision is preserved
External action times out later	Read destination state before retry	No blind duplicate action

Test matrix

Test	Pass condition
Valid input	Pauses with draft and request ID
Missing text	Fails before draft/review
Approve	Status approved; original draft retained
Edit	Status approved; edited draft stored
Reject	Status rejected; no side effect
Wrong thread ID	Cannot resume target state
Malformed decision	Rejected by validation
Duplicate resume	No external write; terminal state handled predictably

Success criteria

State contains only required raw values.
Each node has one observable responsibility.
The graph pauses and resumes with the same thread ID.
Approval, edit and rejection paths are tested.
No external action occurs before authorization.
Production design names a durable checkpointer, retention policy and recovery owner.

Choose training that matches your stack

This tutorial is for code-first learners. If your goal is Python or JavaScript agent engineering, continue with official LangGraph documentation, software testing and deployment practice. Barcelona Code School's current AI Agent & Automation Bootcamp teaches visual business automation with n8n rather than LangGraph development.

Compare BCS AI learning paths

Frequently asked questions

What makes a LangGraph agent stateful?

Nodes read and update shared graph state, while a checkpointer saves state for a thread. Reusing the same thread ID lets a later invocation load and continue that thread rather than starting with empty state.

Why does LangGraph need a thread ID?

The thread ID identifies which persisted checkpoints belong to a run or conversation. Use a stable unique identifier for the business transaction or session and enforce access so one user cannot resume another user's state.

How does interrupt work in LangGraph?

The interrupt function pauses a node, persists graph state through the configured checkpointer and returns a JSON-serializable request to the caller. The graph continues when invoked again with Command resume and the same thread ID.

Can code before interrupt run twice?

Yes. When a paused graph resumes, the interrupted node restarts from its beginning. Put interrupt before non-idempotent side effects, or protect any earlier operation with an idempotency key and destination-state check.

Is MemorySaver suitable for production?

Use an in-memory saver only for local learning and tests. Production applications need a durable checkpointer selected and configured for their infrastructure, retention, privacy, concurrency and recovery requirements.

Sources

Continue learning

Design an agent from the business process

Compare BCS AI paths

Build visual AI automation systems with n8n

Originally published at Barcelona Code School. Learn more about our AI, coding and design programmes at barcelonacodeschool.com.

Free n8n Tutorial vs Structured AI Automation Course

George K. — Fri, 30 Oct 2026 08:56:46 +0000

You do not need a bootcamp to discover n8n. Start free, then add structure only when your goal becomes larger than one workflow and you need feedback, failure practice and portfolio evidence.

Published 13 October 2026 · Barcelona Code School

Start with a free n8n tutorial if you want to learn the editor, nodes, triggers and one simple workflow. Choose a focused project course when you need help finishing a defined use case. Choose structured AI automation training when your goal includes connected business systems, agent tools, data, approvals, testing, failure recovery and portfolio evidence. The right path follows the outcome—not the number of lessons.

Key takeaways

Official n8n learning paths are a credible way to begin and may be all you need.
A project course adds focus and feedback but can remain narrow by design.
Structured training should cover the whole transaction, not only a successful canvas demo.
Permissions, approvals, failure recovery and abnormal tests separate a demo from an operable workflow.
Pay for structure only when it removes a real constraint in your learning or delivery.

What can you learn from free n8n resources?

n8n's official learning paths include hands-on workflow exercises, quizzes, practice APIs, badges and certificates of completion. Its first-workflow guide introduces triggers, credentials, data processing, logic and expressions. That is a substantial starting point, not merely a product tour.

Free official material is often sufficient when you want to explore n8n, connect familiar applications, automate a predictable personal task or decide whether visual workflow building suits you. Build a small workflow from scratch before paying anyone to teach you the interface.

The boundary appears when “it ran once” becomes “other people can depend on it.” A successful tutorial does not automatically cover missing input, duplicate events, expired credentials, model uncertainty, unsafe tool calls or a timeout after an external write.

Figure 1. Three learning paths, each with a different finish line

Free self-study

Learn the canvas
Build one workflow
Test it yourself

Finish line: a useful small automation and enough experience to choose the next step.

Focused project course

Define one use case
Build with guidance
Review the result

Finish line: one bounded project completed with targeted feedback.

Structured programme

Design connected systems
Test normal and failure paths
Package evidence

Finish line: an end-to-end system another person can inspect, operate and discuss.

The longest path is not automatically the best. Choose the smallest path that reaches your actual outcome.

Text equivalent: free self-study moves from learning the canvas to one small workflow and self-run tests. A focused course adds guidance around one defined project. A structured programme connects several skills and requires normal, approval and failure-path tests plus portfolio evidence. Each path is valid for a different goal.

Free tutorial vs project course vs structured programme

Criterion	Free self-study	Focused project course	Structured AI automation programme
Best fit	Exploring n8n or building a simple workflow	Completing one defined use case with guidance	Building connected business systems and portfolio evidence
Structure	You choose sequence, pace and gaps	Sequence follows the selected project	Skills build across connected projects and reviews
Feedback	Documentation, community and self-review	Feedback on one project or problem	Repeated live feedback across design, build, tests and presentation
Technical scope	Editor, nodes, triggers, mapping, expressions	Selected integrations and the project path	Data, APIs, agents, retrieval, approvals, QA, reliability and orchestration
Failure practice	You add it deliberately	Depends on the course scope	Should be required in every substantial system
Portfolio proof	Self-created workflow and notes	One reviewed project	Tested workflows plus an integrated final system
Time and cost	Lowest financial commitment; self-managed time	Moderate, bounded commitment	Highest time and tuition commitment
Main risk	Tutorial hopping without finishing or testing	Learning only the chosen use case	Buying more scope than your goal requires

What changes when the workflow uses an AI agent?

A fixed workflow follows logic chosen in advance. The current n8n AI Agent node connects a chat model with one or more tools, and the agent decides which tool to call for the task. That flexibility adds design questions that a node-by-node tutorial may not need to answer.

Permissions

Which sources may the agent read? Which tools may it call? Use the smallest practical credentials and keep deterministic business rules outside the model.

Human approval

Which actions must pause before sending, modifying or deleting? n8n documents human review for selected AI tools, including approval and denial paths.

Recovery

What happens after malformed output, a rate limit or an uncertain write? Define bounded retries and inspect destination state before replaying side effects.

A course should not hide these questions behind a polished demo. It should show where AI judgement ends, where validation begins and who remains accountable for consequential actions.

4-week live bootcamp · Barcelona or online

Go from one workflow to a complete AI automation system

In the AI Agent & Automation Bootcamp you build a no-code Virtual AI Department with n8n, RAG, connected agents and human approvals — live with an instructor and a small group.

See the bootcamp programme →

Not sure it fits? Take the free AI Career Roadmap test

How do you choose the right learning path?

Name the result. “Learn n8n” is vague. Write the workflow or system you want to build and who will use it.
Estimate the system boundary. Count triggers, data sources, APIs, AI decisions, external writes, reviewers and owners—not merely nodes.
Build one small workflow free. Use official resources to test your interest, working style and baseline gaps.
Run failure cases. Try missing data, a denied permission, a duplicate event and an unavailable destination. Notice where you cannot diagnose or recover.
Identify the real constraint. It may be feedback, accountability, architecture, debugging, time, or uncertainty about what to learn next.
Compare learning options by evidence. Ask what you will build, what tests are required, who reviews it and what you can show afterward.
Choose the smallest sufficient path. Stay self-directed if it works. Buy focused guidance for one bounded gap; choose a broader programme only for a broader outcome.

When is structured live training worth it?

Structured feedback becomes valuable when your problem no longer belongs to one node. The workflow may run but still route poor data, expose a credential too broadly, repeat an action after a timeout or produce an output nobody has defined how to evaluate.

Live training can shorten the loop between a hidden design mistake and a useful correction. Its value should come from review, sequencing, realistic constraints and repeated practice—not from withholding facts that are available in documentation.

Your current situation	Likely next step	Reason
You have not built an n8n workflow yet	Start with official free learning	You need experience before comparing paid formats
You have one exact workflow and one blocker	Use docs, community help or focused mentoring	A broad programme may exceed the problem
You keep watching tutorials but do not finish projects	Choose a bounded project course or accountability structure	The constraint is delivery, not access to information
You need AI, APIs, shared data, approvals and recovery in one system	Compare structured programmes	The outcome spans several disciplines and review cycles
You want credible portfolio evidence for a career transition	Choose training with required tests, documentation and presentation	A canvas screenshot alone does not prove system ownership

What should your final project prove?

Whether you learn free or pay for training, use the same evidence standard. A smaller system with clear tests is stronger than several copied templates whose data and failure paths you cannot explain.

Problem: the business transaction and measurable completion condition.
Architecture: triggers, data sources, AI decisions, tools and outputs.
Permissions: credential scope, allowed tools and protected data.
Approval: who reviews which action and what rejection does.
Tests: normal, missing-data, duplicate, denied and tool-failure cases.
Execution evidence: sanitised inputs, outputs and run status.
Recovery: attempt limits, escalation and destination-state checks.
Handover: enough explanation for another operator to diagnose a seeded failure.

A minimum learning-project test matrix

Test	Expected behaviour	Evidence
Valid request	Produces one correct outcome	Execution and destination ID
Missing field	Stops or requests correction before AI/write	Named validation result
Duplicate event	Does not create a second external transaction	Stable business key and destination check
Tool unavailable	Uses bounded recovery or human escalation	Error, attempt count and preserved input
Approval denied	Consequential tool does not execute	Reviewer decision and final status
Unknown write state	Reads destination before retry	Reconciliation result
Owner handover	Second operator diagnoses the failure	Runbook and saved evidence

Success criteria

The project solves a named transaction rather than demonstrating disconnected nodes.
Required inputs and outputs have explicit contracts.
Credentials and tools have bounded permissions.
Human approval controls sensitive or consequential actions.
Abnormal cases are tested, recorded and recoverable.
The learner can explain design decisions and limitations without the template author.

A certificate can record completion. The stronger proof is a system you can explain, test, repair and hand to another operator.

If your goal is a complete AI automation system

Barcelona Code School's AI Agent & Automation Bootcamp is a four-week, full-time live programme in Barcelona or online. The current curriculum uses n8n to build a connected Virtual AI Department and covers shared data, tool-using agents, structured output, human approval, RAG, data validation, QA, reliability and multi-agent orchestration.

It is not the necessary next step for everyone. If one free workflow answers your goal, keep building. The bootcamp is for people who want intensive feedback, an end-to-end portfolio system and practice operating beyond the happy path. It is BCS training—not official n8n Academy certification.

Explore the AI Agent & Automation Bootcamp

Frequently asked questions

Can I learn n8n for free?

Yes. n8n provides official learning paths and a first-workflow tutorial. Free self-study is a sensible starting point for learning the editor, triggers, credentials, data processing, expressions and workflow logic. Build one small workflow before deciding whether you need paid guidance.

When is a free n8n tutorial enough?

A free tutorial is often enough when you are exploring the platform, automating one predictable personal task or connecting a few familiar apps. It is also enough to discover whether visual workflow building suits you. Add training only when your goal requires feedback, broader system design or accountable delivery.

What should an AI automation course teach beyond n8n nodes?

It should teach how to define a business transaction, structure data, connect APIs, constrain AI tools, validate outputs, protect credentials, add human approvals, handle failures, test abnormal cases and present execution evidence. The exact scope should match the result the course promises.

Does learning n8n require coding?

Many n8n workflows can be built visually, but learners still need technical thinking about APIs, data types, expressions, authentication and debugging. Some unusual integrations or transformations may require code. Check the requirements of the project or course rather than treating no-code as no technical work.

Is Barcelona Code School an official n8n Academy?

No. Barcelona Code School teaches n8n inside its AI Agent and Automation Bootcamp, but it does not claim to be the official n8n Academy or to award an official n8n credential. n8n's own learning paths are the source for its badges and certificates of completion.

Sources

Continue learning

Plan an AI agent before choosing tools

Compare BCS AI learning paths

Build complete AI automation systems with n8n

Originally published at Barcelona Code School. Learn more about our AI, coding and design programmes at barcelonacodeschool.com.

n8n vs Make vs Zapier for AI Automation

George K. — Fri, 30 Oct 2026 08:35:19 +0000

Compare the three platforms through the same workflow, approval gate and failure tests. The right choice is the system your team can operate safely after the demo works.

Published 13 October 2026 · Barcelona Code School

Choose n8n when you want explicit visual control around tool-using AI and business logic. Choose Make when scenario-based mapping and branching match how your team builds. Choose Zapier when the process is primarily app triggers and actions and fast setup matters. Do not choose from a feature list alone: prototype the same workflow, approval and failure cases in each finalist.

Key takeaways

All three can combine deterministic automation with AI; the operating model differs.
Compare the exact connector action, data shape and error path—not integration counts.
Keep external writes behind validation, scoped credentials and approval where risk requires it.
Estimate cost with one shared usage model because billing units and plan gates differ.
The best fit is the platform the responsible team can test, explain and recover.

What is the practical difference between n8n, Make and Zapier?

n8n, Make and Zapier are visual automation platforms, but they encourage different ways of shaping a workflow. n8n exposes a node graph and includes an AI Agent node that connects a chat model to tools. Make organises work as scenarios made of modules and routes; its current Make AI Agent can use modules, scenarios, MCP servers and other agents as tools. Zapier defines a Zap as a trigger followed by one or more actions, with Paths and other built-in tools for additional control.

The labels do not decide the result. A company should first map the business transaction: what starts it, what data enters, what AI may decide, which external action changes state, who approves it and how the team recovers from an uncertain write.

Figure 1. The same AI workflow in three visual models

n8n

Form trigger
Validate data
AI Agent + read tools
Approval branch
CRM write + error workflow

AI is one controlled node inside an explicit business workflow.

Make

Webhook module
Map and filter
Make AI Agent + tools
Router to review
CRM module + error route

The scenario maps bundles through modules, filters, routes and tools.

Zapier

App trigger
Format and filter
AI / Agent step
Path + Human in the Loop
App action + error handler

The Zap moves from an app event through actions and conditional controls.

Each platform can express the core pattern. The decision turns on exact actions, data handling, review, recovery and who will own the workflow.

Text equivalent: the same lead workflow receives a form, validates fields, asks AI to classify against approved information, pauses risky outcomes for a person, writes an approved record to the CRM and sends failures to a recovery path. n8n expresses the sequence as nodes, Make as scenario modules and routes, and Zapier as trigger/action steps with Paths and Human in the Loop.

n8n vs Make vs Zapier: side-by-side comparison

Criterion	n8n	Make	Zapier
Core workflow model	Connected nodes on a workflow canvas	Scenario modules, filters and routes	Trigger followed by action steps and optional Paths
AI-agent pattern	AI Agent node connects a model and tools	Make AI Agent runs in a scenario and can call configured tools	Agents or AI steps can participate in a Zap and app actions
Strong starting fit	Explicit multi-step business logic around AI and APIs	Visual data mapping and branching across scenario modules	App-led automations with familiar triggers and actions
Deterministic control	Validation and branches can surround the AI node	Filters, routers and modules can surround the agent module	Filters, Paths and action steps can surround AI
Human approval	Build a review branch before the consequential write	Route to a person or review system before continuing	Documented Agent approval instructions and Human in the Loop step
Error handling	Execution inspection, error paths and bounded recovery patterns	Error-handling routes and incomplete execution patterns	Custom error handlers and run-status inspection
Testing evidence	Node data and execution history	Run details and module outputs	Step tests and Zap run history/status
Team question	Can the owner read a node graph and inspect data between steps?	Can the owner follow mappings, bundles, filters and routes?	Can the owner maintain the trigger/action chain and plan-gated controls?
Common design risk	A large canvas becomes tightly coupled and hard to review	Dense mappings and routers hide assumptions	A simple Zap grows into many paths and cross-Zap dependencies

This comparison describes documented workflow models, not a benchmark. Features, product names and plan availability change. Check the current official page for every required connector, action and control before building.

When is n8n the stronger fit?

n8n is a strong candidate when the workflow has several explicit data and control steps around AI: API calls, transformations, validation, agent tools, approval, a database write and recovery logic. Its AI Agent node lets a model choose among connected tools, while the surrounding workflow can keep deterministic business rules outside the model.

n8n also fits teams that want the automation graph to show where AI starts and stops. That visibility does not make a workflow safe by itself; credentials, tool permissions, execution retention and recovery still need deliberate configuration.

The workflow depends on custom API calls or structured data transformations.
The agent should receive a small, named set of tools.
The team wants validation and writes separated from model judgement.
The owner is comfortable inspecting node inputs, outputs and executions.
n8n is already the organisation's automation layer.

When is Make the stronger fit?

Make is a strong candidate when builders think in scenarios, modules, mappings and routed bundles. Its current Make AI Agent documentation places the agent inside a scenario and allows modules, scenarios, MCP servers and other agents to become tools. The same scenario can prepare inputs before the agent and handle output afterward.

Make's visual mappings can help when the work reshapes data across several services. The team must still document what each field means, where a route stops and which errors may be resumed, skipped, retried or escalated. A visually detailed scenario is not automatically an understandable one.

The team already maintains Make scenarios and connections.
Field mapping and routed data flows are central to the process.
Reusable scenarios make useful bounded tools for the agent.
Operators are comfortable reading filters, bundles and error routes.
The current Make modules cover the required app actions.

4-week live bootcamp · Barcelona or online

Go from one workflow to a complete AI automation system

In the AI Agent & Automation Bootcamp you build a no-code Virtual AI Department with n8n, RAG, connected agents and human approvals — live with an instructor and a small group.

When is Zapier the stronger fit?

Zapier is a strong candidate when a process begins with a familiar application event and continues through a clear sequence of actions. Official documentation defines a Zap as a trigger plus one or more actions. Paths add conditional branches, while Zapier documents approval stops for Agents and a Human in the Loop action after an Agents step.

This makes Zapier a sensible shortlist option for teams that want to connect established business apps quickly. As the workflow grows, review how many Paths, shared assets and dependent Zaps a single transaction crosses. Fast setup should not hide unclear ownership or partial writes.

The process maps cleanly to app triggers and actions.
The exact required app actions exist and are current.
The operating team already understands Zap history and step tests.
Approval can be placed directly before the sensitive action.
The workflow remains readable as the number of paths grows.

How should you compare cost without misleading yourself?

Do not compare only the three prices shown on a pricing page. A useful estimate starts with the same workload and records how each platform counts it. Plan gates, tasks or operations, AI-provider charges, premium connectors, team seats, history, retries and support can change the result.

Input to estimate	What to record	Why it matters
Monthly triggers	Expected events and peak periods	Establishes base workload
Items per trigger	Single record, batch or multiple bundles	One business event may create many processed items
Branches and writes	Steps reached in normal and exception paths	Different runs consume different work
Retries	Expected transient failures and maximum attempts	Recovery can add platform and API usage
AI calls	Model, tokens, tools and loop limit	Model cost may sit outside the automation subscription
People and environments	Builders, reviewers, roles and deployment needs	Team controls may sit on different plans

Use current vendor calculators or plan pages only after this usage model exists. Record the calculation date because packaging may change.

How do you choose in seven steps?

Define one transaction. Name the trigger, required data, final write, owner and measurable success condition.
Separate rules from judgement. Keep validation, permissions, approvals and side effects deterministic. Give AI only the interpretation or tool-choice step that needs it.
Check the exact connectors. Verify the required trigger and action fields in each shortlisted platform. An app logo is not proof that the needed operation exists.
Build the hardest slice. Prototype the least certain API, data mapping or agent tool—not the easiest happy path.
Add the approval boundary. Put an authorised person immediately before messages, payments, deletions, account changes or other consequential writes.
Break the workflow deliberately. Test missing data, duplicate triggers, rate limits, timeouts, rejected approval and uncertain external state.
Choose the operable system. Score correctness, recovery, audit evidence, owner confidence and realistic cost. Prefer the smallest design the team can support.

What permissions and failure paths are required?

Risk	Required platform-independent control	Pass condition
Agent chooses a write tool	Expose a narrower draft/read tool or require approval before execution	No consequential write from model judgement alone
Missing required field	Validate before AI and before destination write	Focused clarification or human queue
Duplicate trigger	Stable business key and idempotency check	One external transaction
Timeout after write request	Read destination state before retry	No blind duplicate write
Approval rejected or expires	Stop path and preserve evidence	Action remains unexecuted
Prompt injection in source content	Treat content as data; tools and permissions remain fixed	Untrusted text cannot widen access
Credential is too broad	Separate scoped connection or service identity	Workflow accesses only required records/actions

A platform feature is not a control until the workflow configures it, tests it and gives a named person responsibility for the result.

Use the same pilot scorecard for all three

Test	Evidence to collect	Pass condition
Normal request	Input, transformation, AI output and final record	Correct result with traceable fields
Ambiguous request	Question or review route	No invented business value
Duplicate event	Business key and destination history	One final write
Tool or app outage	Error record, attempt count and preserved data	Bounded recovery or useful escalation
Approval rejected	Reviewer, decision and run status	No sensitive action
Uncertain timeout	Destination lookup before replay	State reconciled safely
Owner handover	Second operator diagnoses a seeded failure	Recovery without the original builder
Usage estimate	Run units, model calls and exceptions	Comparable monthly cost model

Success criteria

The same test set and business result are used on every platform.
The exact required integrations work with realistic data.
External writes are authorised, idempotent and visible in logs.
Errors stop or recover according to a written policy.
A second operator can explain and repair the workflow.
The cost estimate includes normal runs, exceptions and model usage.
The selected platform wins on documented needs, not brand familiarity alone.

Learn platform choice by building complete systems

Barcelona Code School's AI Agent & Automation Bootcamp teaches business automation through n8n, structured data, tool-using agents, approvals, RAG, QA and recovery. The goal is not to memorise a canvas. It is to learn how to turn a process into a system that can be tested and operated.

If your company already runs stable Make or Zapier workflows and only needs one small change, rebuilding everything in n8n may add work without adding value. The bootcamp fits people who want n8n as a core skill for AI automation projects and a complete portfolio system.

Explore the AI Agent & Automation Bootcamp

Frequently asked questions

Which is better for AI automation: n8n, Make or Zapier?

There is no universal winner. n8n fits teams that want explicit visual control around AI tools and business logic. Make fits scenario builders who value visual data mapping and branching. Zapier fits app-led trigger-and-action workflows with fast setup, Paths and built-in approval options. Test the exact workflow before choosing.

Can n8n, Make and Zapier all build AI agents?

All three can place model or agent behavior inside an automation, but their abstractions differ. n8n provides an AI Agent node with tools, Make provides Make AI Agent inside scenarios, and Zapier provides Agents and AI steps within its automation ecosystem.

Should price decide between n8n, Make and Zapier?

Price should be tested with a real usage model, not a headline plan price. The platforms use different billing units and plan gates. Estimate triggers, processed items, branches, retries, AI calls, premium connectors, users and support needs for the same workflow.

Which platform is easiest to maintain?

The easiest platform to maintain is usually the one the operating team can inspect, test and repair. A simple Zap may be easiest for one team, while a visible Make scenario or explicit n8n workflow may be easier for a more complex process.

How should a company test the three platforms?

Build the same small workflow in each shortlisted platform. Include the hardest connector, structured AI output, a human approval, a duplicate event, a timeout and a partial failure. Compare correctness, recovery, audit evidence and owner confidence.

Sources

Continue learning

Originally published at Barcelona Code School. Learn more about our AI, coding and design programmes at barcelonacodeschool.com.

AI Agent Memory vs RAG: What Is the Difference?

George K. — Thu, 29 Oct 2026 09:34:16 +0000

Memory helps an agent continue a conversation. RAG retrieves relevant external knowledge. They solve different problems, introduce different risks and often work together.

AI agent memory preserves conversational or task state; retrieval-augmented generation retrieves relevant external knowledge.

Use memory when the next turn depends on what happened earlier in the same interaction. Use RAG when the answer depends on policies, manuals or other sources outside the conversation. Neither mechanism grants permission, proves a fact or replaces system-of-record lookups.

Key takeaways

Memory answers “what happened in this interaction?”; RAG answers “which external sources are relevant now?”
A long chat transcript is not a reliable knowledge base, and a vector store is not conversation state.
Use explicit system records for balances, permissions, bookings and other transactional truth.
Apply retention, access and deletion rules separately to memory and indexed documents.
Test session isolation, retrieval relevance, grounding and stale-source behaviour.

Memory and RAG solve different context problems

A language model handles the context supplied with the current request. Memory and RAG are two ways to assemble that context, but they should not be merged into one vague “agent brain.”

Memory normally carries selected messages, summaries or task state across turns. RAG searches an external collection and supplies the chunks most relevant to the current question. A third category—live tools and systems of record—retrieves transactional facts such as account status, stock, bookings or permissions.

Dimension	Agent memory	RAG	Live tool or system of record
Primary question	What happened earlier?	Which documents are relevant?	What is true right now?
Typical content	Messages, preferences, task state	Policies, manuals, approved knowledge	Orders, balances, slots, permissions
Selection	Session window or summary	Search, embeddings and metadata filters	Exact API or database query
Main risk	Cross-user leakage or stale summaries	Irrelevant, stale or conflicting chunks	Excessive permissions or unsafe writes
Good evidence	Conversation ID and turn references	Document and chunk IDs	Verified record ID and timestamp

How the three context layers work together

Figure 1. Context assembly for an AI agent

1. Identity Bind request to the correct user and session.
2. Memory Load only relevant recent state.
3. RAG Retrieve approved chunks with metadata.
4. Live tools Query exact current records if required.
5. Model Reason over labelled context and return sources.
6. Validate Check schema, grounding and permission.
7. Review Pause conflict, uncertainty or sensitive action.
8. Respond Answer or act through a controlled branch.

Memory, retrieval and live tools supply different kinds of context. Policy validation still controls what the system may do.

Text equivalent: the workflow verifies the requester and session, selects relevant conversational state, retrieves approved documents and queries live systems only when needed. The model receives each source with a clear label. Validation and approval happen before the final response or action.

4-week live bootcamp · Barcelona or online

Go from one workflow to a complete AI automation system

In the AI Agent & Automation Bootcamp you build a no-code Virtual AI Department with n8n, RAG, connected agents and human approvals — live with an instructor and a small group.

See the bootcamp programme →

Not sure it fits? Take the free AI Career Roadmap test

When should you use agent memory?

Use memory when continuity improves the interaction: remembering which product the user is discussing, which clarification was already answered, or which stage of a multi-step task has been completed. Keep the stored state as small and explicit as possible.

Short-term window: a limited number of recent messages. Simple, but old details fall out and long conversations become expensive.
Conversation summary: a compact representation of earlier turns. Efficient, but a mistaken summary can persist.
Structured task state: named fields such as selected location, confirmed date or missing data. Usually safer than asking the model to rediscover state from prose.
Longer-lived preferences: only when the purpose, consent or other basis, retention and user controls are clear.

n8n documents Simple Memory for a configurable chat-history window and separate memory services for persistence. The storage choice does not remove the need for correct session keys, isolation and retention.

When should you use RAG?

Use RAG when an answer depends on approved external content that is too large, specialised or frequently updated to place in every prompt. The ingestion workflow fetches documents, splits them into chunks, creates embeddings and stores them with metadata. The query workflow retrieves a limited set of relevant chunks.

Good metadata is often as important as semantic similarity. Filter by product, locale, audience, policy version, effective date and access group before asking the model to answer. A highly similar but expired policy is still the wrong source.

RAG is not a guarantee of truth

Retrieval can miss the best document, return an irrelevant chunk or surface two conflicting versions. The answer can also go beyond the supplied evidence. Test retrieval relevance and answer groundedness separately, and provide a “no reliable source found” route.

What should stay outside both memory and RAG?

Current account balance, order state, inventory and booking availability.
Identity, authentication and authorisation decisions.
Permission to send, delete, purchase, refund or change a record.
Secrets and unrestricted credentials.
Legal, clinical or financial conclusions that require authorised review.

Fetch changing transactional facts from the system of record with an exact tool call. Use memory to preserve task continuity and RAG to explain the relevant policy; do not use either as the source of truth for a current transaction.

Choose the right design

Use case	Memory	RAG	Live tool
Continue a multi-turn intake	Yes, preferably structured state	Optional for policy explanations	For final record lookup or write
Answer from a product manual	Only for conversational continuity	Yes, with version metadata	Optional for live product status
Check an order	Remember order reference in session	For returns policy	Yes, for current order state
Internal policy assistant	Remember the current question	Yes, filtered by employee access	For employee-specific facts
Book an appointment	Remember preferences	For service descriptions	Yes, for availability and booking

Failure paths and tests

Test	Expected behaviour	Pass condition
Two users with similar requests	Separate sessions	No cross-user memory appears
Old preference contradicted	Current explicit choice wins	State updates visibly
Expired policy ranks highly	Metadata filter removes it	Only current version is used
No relevant document	State limitation or escalate	No unsupported answer
Conflicting current documents	Show conflict and review route	No silent merge
Question asks for live balance	Exact system lookup	Memory and RAG are not treated as truth
Deletion request	Apply documented process	Memory and indexed source scope are clear
Retrieved prompt injection	Treat as document content	No tool or permission change

Success criteria

Every request uses the correct authenticated session and tenant boundary.
Structured task state replaces unnecessary transcript replay.
Retrieved chunks include document ID, version and access metadata.
The system can say that no reliable source was found.
Transactional truth comes from exact live tools.
Retention and deletion behaviour are tested for both memory and indexed knowledge.

Build complete AI workflows, not isolated demos

A production-ready agent needs data contracts, tools, RAG where appropriate, permissions, human approvals, evaluation, failure recovery and monitoring. Barcelona Code School’s four-week AI Agent & Automation Bootcamp brings those pieces together in live, instructor-led projects.

If you only need one personal workflow, a free tutorial may be enough. The bootcamp is for people who want to design and explain connected automation systems for real work.

Explore the AI Agent & Automation Bootcamp

Frequently asked questions

Is AI agent memory the same as RAG?

No. Memory carries conversational or task state across interactions. RAG searches external sources and supplies relevant document content for the current request. They solve different context problems.

Can an AI agent use memory and RAG together?

Yes. An agent can use memory for conversation continuity, RAG for approved knowledge and exact tools for live transactional data. Label and validate each context source separately.

Does a vector database give an AI agent long-term memory?

A vector store can retrieve semantically similar stored content, including selected past information, but that does not make it equivalent to reliable conversation state. Define what is stored, how it is filtered and when it expires.

Should current account data be stored in memory or RAG?

Usually no. Current balances, orders, permissions and availability should come from the authoritative system through an exact lookup. Memory may retain a reference, and RAG may explain the policy around it.

What should you test in an agent with memory and RAG?

Test session isolation, state updates, retention, retrieval relevance, metadata filters, stale and conflicting sources, grounded answers, prompt injection in documents and the no-source fallback.

Sources

Continue learning

Start with the platform-neutral AI agent build guide

Add human approval and failure recovery

See the AI Agent & Automation Bootcamp

Originally published at Barcelona Code School. Learn more about our AI, coding and design programmes at barcelonacodeschool.com.

How to Build an AI Invoice Processing Agent in n8n

George K. — Wed, 28 Oct 2026 09:49:05 +0000

Extract and validate invoice data, detect duplicates and prepare an approval packet while keeping vendor changes, accounting decisions and payment authority with finance.

An invoice processing agent should prepare evidence for finance, not approve or pay invoices. Receive the file through an approved channel, scan and extract fields, match the vendor and purchase record, run duplicate and arithmetic checks, and create a review packet. Any bank-detail change, mismatch, low-confidence field or unusual instruction must stop the automatic route.

Key takeaways

Treat invoice text and attachments as untrusted business data, not instructions to the agent.
Store the original file, extraction result, confidence and source location separately.
Use deterministic checks for totals, tax, duplicates and purchase-order matching.
Make bank-detail changes and payment release human-only, multi-step processes.
Verify external state before retrying a record or accounting-system write.

What is the safe automation boundary?

The workflow may receive an invoice, extract fields, check arithmetic, find a vendor, look for duplicates, compare the invoice with a purchase order or receipt and prepare an approval packet. It may create a draft bill in a staging state if finance explicitly approves that design.

It must not accept new bank details from an invoice, create a vendor, decide an accounting treatment, override a mismatch, release a payment or mark an invoice approved. Those actions can move money or alter financial records and require authorised controls outside the model.

Capability	First version	Control
Extract invoice fields	Automated	Schema, confidence and source file
Check totals and tax arithmetic	Deterministic	Exact calculation with tolerance policy
Find vendor	Read-only lookup	Verified vendor ID, not name alone
Match PO and receipt	Automated comparison	Human route for any variance
Create draft accounting record	Optional after approval	Idempotent write and verified response
Change bank details or pay	Never autonomous	Finance verification and payment controls

Invoice agent architecture

Figure 1. Invoice-to-approval workflow

1. Intake · Approved mailbox, portal or storage event.
2. File gate · Type, size, malware and sender checks.
3. Extract · OCR or document AI returns fixed fields.
4. Validate · Required fields, dates, totals and tax math.
5. Match · Vendor, PO, receipt and currency lookups.
6. Detect · Duplicate and anomaly rules.
7. Approve · Finance reviews evidence and exceptions.
8. Record · Write once, verify ID and log final state.

The workflow extracts and assembles evidence. Finance policy, vendor changes, approval and payment stay outside the agent.

Text equivalent: the system accepts a file only through an approved route, checks it, extracts a defined schema, validates totals and required fields, matches internal records and flags duplicates or anomalies. Finance reviews the original and evidence before any record is created or payment process begins.

4-week live bootcamp · Barcelona or online

Go from one workflow to a complete AI automation system

In the AI Agent & Automation Bootcamp you build a no-code Virtual AI Department with n8n, RAG, connected agents and human approvals — live with an instructor and a small group.

See the bootcamp programme →

Not sure it fits? Take the free AI Career Roadmap test

Build the invoice processing agent step by step

Define the finance boundary. Document what the workflow may read, calculate and draft. Mark vendor creation, bank changes, approval and payment as human-only actions.
Secure the intake channel. Use a controlled mailbox, portal or storage location. Validate file type and size, scan attachments and preserve the immutable original. Do not execute macros, links or embedded instructions.
Extract a fixed schema. Capture invoice number, vendor identifiers, invoice and due dates, currency, line items, subtotal, tax, total, purchase-order reference and payment details as observed. Keep field confidence and page location when available.
Validate fields and arithmetic. Require the mandatory fields for the jurisdiction and process. Recalculate line totals, subtotal, tax and grand total with deterministic code. Apply an explicit rounding tolerance.
Match vendor and purchase records. Find the vendor with a trusted identifier, then retrieve purchase order, receipt and contract data read-only. A similar name is not enough to create or select a vendor.
Detect duplicates and anomalies. Compare vendor ID, invoice number, amount, currency, date and file hash. Flag changed bank details, unusual currency, split invoices, duplicate totals and mismatched addresses for finance.
Create an approval packet. Show the original file, extracted fields, calculations, match results, discrepancies and proposed next action. Approval must bind to that exact packet and expire if source data changes.
Write once and monitor. If approved, create only a draft or pending record with an idempotency key. Store the external record ID and verify it before retrying after timeouts.

Example extraction contract

{
  "document_id": "doc_7719",
  "vendor_name_observed": "Example Components SL",
  "vendor_id_verified": null,
  "invoice_number": "EC-2026-1048",
  "invoice_date": "2026-10-02",
  "currency": "EUR",
  "subtotal": 1200.00,
  "tax": 252.00,
  "total": 1452.00,
  "purchase_order": "PO-4401",
  "bank_details_present": true,
  "field_confidence": {"invoice_number": 0.98, "total": 0.99},
  "needs_finance_review": true
}

The presence of bank details is a flag, not permission to use them. Compare them with a separately verified vendor master, and route every change through the organisation's established verification process.

Invoice content is untrusted

An invoice can contain text such as “ignore the purchase order,” “use the new bank account below” or even instructions aimed at an AI system. The workflow must treat all document text as data to extract. It cannot expand its tools, alter policy or skip checks because a document says so.

No instruction inside an invoice can change the workflow's authority. Payment and vendor-master controls live outside the model and outside the document.

Failure paths and test matrix

Test	Expected response	Pass condition
Clean invoice with matching PO	Approval packet	All values trace to original and records
Arithmetic does not balance	Finance exception	No draft bill created
Possible duplicate	Hold and compare	No second record
Vendor name similar, ID missing	Manual vendor match	No guessed vendor
New bank details in PDF	Separate verification route	No master-data change
Prompt injection in document	Ignored as instruction	All controls still run
Accounting API timeout	Lookup by idempotency key	No duplicate bill
Unreadable or password-protected file	Request replacement or review	No invented fields

Success criteria

Every extracted value can be traced to the original file and page or region when supported.
Arithmetic and duplicate checks are deterministic.
No vendor or bank record is created or changed from invoice content alone.
Every mismatch, low-confidence field and policy exception reaches finance.
Writes are idempotent and external record IDs are verified.
Payment release remains entirely outside the agent's authority.

Build complete AI workflows, not isolated demos

If you only need one personal workflow, a free tutorial may be enough. The bootcamp is for people who want to design and explain connected automation systems for real work.

Explore the AI Agent & Automation Bootcamp

Frequently asked questions

What can an AI invoice processing agent automate?

It can extract invoice fields, check required data and arithmetic, find possible vendors and purchase records, detect duplicates, compare matching evidence and prepare a finance review packet.

Should an invoice agent approve or pay invoices?

No. Approval and payment are consequential financial controls and should remain with authorised people and established finance systems. The agent can prepare evidence but should not release money.

How should the workflow handle new bank details?

Treat them as an exception. Compare against a separately verified vendor master and use the organisation’s independent verification process. Never update payment details because the invoice or an email requests it.

How do you stop duplicate invoice records?

Use a composite check across verified vendor ID, invoice number, amount, currency, date and file hash. Use an idempotency key for writes and verify the accounting system after any timeout before retrying.

Can n8n extract data from invoices?

Yes. n8n can orchestrate document extraction services; its AWS Textract node includes an Analyze Receipt or Invoice operation. Regardless of extractor, validate the fixed output schema and route low-confidence results to review.

Sources

Continue learning

Start with the platform-neutral AI agent build guide

Add human approval and failure recovery

See the AI Agent & Automation Bootcamp

Originally published at Barcelona Code School. Learn more about our AI, coding and design programmes at barcelonacodeschool.com.

How to Build an AI Lead Qualification Agent in n8n

George K. — Tue, 27 Oct 2026 08:28:12 +0000

Turn an inbound enquiry into a review-ready qualification record without letting a language model invent facts, alter your CRM freely or send unapproved sales claims.

Published 5 October 2026 · Barcelona Code School

An AI lead qualification agent should interpret an enquiry, not invent the qualification policy.

Put your ideal-customer criteria in a versioned scorecard, retrieve verified CRM and form data, ask the model for structured evidence, and calculate the final route with deterministic rules. Start with draft-only follow-up and require a salesperson to approve uncertain, high-value or sensitive cases.

Key takeaways

Use the model to extract meaning and evidence; use rules to calculate the route.
Score only verified business-fit and intent signals, never guessed personal attributes.
Check for duplicate contacts and existing owners before creating or updating CRM records.
Begin with read access and draft output; place CRM writes and email behind review.
Measure false rejects, false accepts, routing time and salesperson overrides.

What should the agent actually decide?

A useful first version answers a narrow operational question: should this inbound lead go to sales now, enter a nurture queue, or receive a request for missing information? It does not decide whether a person is worthy of attention. The route must follow published business criteria such as company type, problem fit, buying timeframe and requested product.

Keep three kinds of information separate: what the lead submitted, what your systems verified, and what the model inferred. A model may summarise intent from free text, but an inference cannot silently become a CRM fact.

Signal	Source	Allowed use	Do not do
Stated problem	Form or conversation	Map to approved use cases	Invent needs not expressed
Company and role	Submitted or verified CRM data	Apply documented business-fit rules	Guess seniority from writing style
Timeframe	Explicit answer	Route urgent, qualified requests faster	Turn silence into “not interested”
Existing relationship	CRM lookup	Preserve current owner and history	Create a duplicate contact
Sensitive or protected traits	Not required	Exclude from scoring	Infer or use for qualification

What does the n8n workflow look like?

Figure 1. Controlled lead qualification workflow

1. Intake · Form, email or webhook receives the enquiry.
2. Validate · Check required fields, source and processing state.
3. CRM lookup · Find duplicates, owners and prior activity.
4. AI extraction · Return intent, evidence and missing fields.
5. Rules · Calculate route from the approved scorecard.
6. Review · Pause ambiguous, sensitive or high-value cases.
7. Write · Update one verified CRM record after approval.
8. Learn · Compare route with sales outcomes and overrides.

The model interprets language. Validation, scoring, permissions and CRM writes stay outside the model.

Text equivalent: the workflow validates an inbound record, retrieves existing CRM context, extracts structured evidence, calculates a route with versioned rules and sends exceptions to a person. Only then may it update the correct record or prepare a follow-up draft.

4-week live bootcamp · Barcelona or online

Go from one workflow to a complete AI automation system

In the AI Agent & Automation Bootcamp you build a no-code Virtual AI Department with n8n, RAG, connected agents and human approvals — live with an instructor and a small group.

See the bootcamp programme →

Not sure it fits? Take the free AI Career Roadmap test

Build the AI lead qualification agent step by step

Define one decision and three routes. Start with sales review, nurture and missing information. Give every route an owner and response-time target.
Create a versioned scorecard. List allowed evidence, weights, thresholds and disqualifying conditions. Store the scorecard version with every result so future audits can reproduce the decision.
Normalize inbound data. Create stable fields such as lead_id, source, message, company, consent_state and received_at. Reject malformed or unauthorised input before a model call.
Retrieve existing CRM context. Search by verified identifiers, not a fuzzy name alone. If several records could match, stop and ask a person. Preserve the current owner and open opportunity.
Extract evidence with AI. Ask for a fixed schema containing use case, explicit timeframe, requested outcome, quoted evidence, missing fields and confidence. Tell the model to return unknown rather than complete absent facts.
Calculate the route outside the model. Use IF, Switch or code to apply your scorecard. Validate enums, evidence fields and source IDs. Never accept a free-form “hot lead” label as the final decision.
Add approval and idempotent writes. Send uncertain, strategic and policy-exception cases to a salesperson. Bind approval to the exact proposed CRM update and use the lead ID as an idempotency key.
Test and monitor. Run a dated dataset of good fits, poor fits, sparse enquiries, duplicate contacts, injection attempts and edge cases. Review outcomes by source and scorecard version.

Use a structured result, not a persuasive paragraph

{
  "lead_id": "lead_2048",
  "fit_signals": ["requested workflow automation", "team of 12"],
  "intent": "evaluating_training",
  "timeframe": "unknown",
  "missing_fields": ["decision_timeline"],
  "recommended_route": "request_information",
  "scorecard_version": "2026-10-05",
  "source_ids": ["form_781", "contact_992"],
  "needs_human_review": true
}

The workflow should calculate recommended_route again from the validated fields. That catches prompt drift, malformed output and a model result that contradicts your business rules.

Permissions and privacy

Give the agent read access only to the CRM fields required for qualification.
Do not put entire email histories or private notes into the prompt by default.
Exclude sensitive and protected attributes from the scorecard, including model-inferred proxies.
Keep marketing consent, service enquiries and legitimate-interest decisions distinct.
Require approval before sending claims, discounts or promises on behalf of sales.
Log source IDs, scorecard version, reviewer and final write result without copying unnecessary personal data.

For organisations operating under GDPR, purpose limitation, data minimisation, accuracy and transparency need to be designed into the workflow. This article is a technical pattern, not legal advice.

Failure paths and test matrix

Test	Expected route	Pass condition
Strong fit with explicit timeline	Sales review	Evidence and source IDs are present
Good fit, timeframe missing	Request information	No urgency is invented
Existing customer with owner	Current owner	No duplicate contact or reassignment
Two possible CRM matches	Human review	No record is changed
Prompt injection in message	Normal extraction	No new tool or permission gained
Tool timeout after update request	Verify external state	No duplicate write
Sensitive personal detail included	Redact or restrict	Detail is not used in scoring
Unknown output label	Validation failure	Case goes to review

Success criteria

Every route can be reproduced from verified fields and a named scorecard version.
Missing facts remain unknown instead of becoming confident guesses.
Duplicate and currently owned records are preserved.
No CRM write or outbound message occurs outside the approved branch.
Salespeople can override a route with a recorded reason.
False accepts and false rejects are reviewed separately, not hidden in one accuracy number.

Build complete AI workflows, not isolated demos

If you only need one personal workflow, a free tutorial may be enough. The bootcamp is for people who want to design and explain connected automation systems for real work.

Explore the AI Agent & Automation Bootcamp

Frequently asked questions

What is an AI lead qualification agent?

It is a workflow that turns inbound lead data into structured evidence and a recommended route. A safe design uses AI to interpret free text, while deterministic rules apply the approved qualification scorecard and people review uncertain or consequential cases.

Can n8n update a CRM after qualifying a lead?

Yes, n8n provides CRM integrations, including HubSpot. Start with read-only lookup and draft output. Add narrowly scoped updates only after duplicate checks, validation and approval, and use an idempotency key to prevent repeated writes.

Should the AI model calculate the lead score?

The model may extract signals, but the final score and route should be calculated with versioned deterministic rules. This makes the result reproducible and prevents prompt changes from silently changing sales policy.

What data should not be used for lead scoring?

Do not use sensitive or protected personal attributes, or model-inferred proxies for them. Use purpose-relevant business information that the person submitted or your systems verified.

How do you measure a lead qualification agent?

Track routing time, missing-data rate, salesperson overrides, false accepts, false rejects, duplicate prevention and downstream outcomes by source and scorecard version. Review quality as well as speed.

Sources

Continue learning

Start with the platform-neutral AI agent build guide

Add human approval and failure recovery

See the AI Agent & Automation Bootcamp

Originally published at Barcelona Code School. Learn more about our AI, coding and design programmes at barcelonacodeschool.com.

How to Test AI Agents Before Production

George K. — Mon, 26 Oct 2026 11:41:01 +0000

A good answer is only one test. Production readiness also requires correct tools, protected permissions, safe failures, repeatable evaluation and observable outcomes.

Published 5 October 2026 · Barcelona Code School

Test an AI agent as a complete system, not only as a model response.

Build a versioned dataset of normal, edge, adversarial and failure cases; assert deterministic rules first; score language quality separately; inspect tool choice and arguments; verify approval and retry behaviour; then release gradually with monitoring and rollback. Every production incident should become a regression test.

Key takeaways

Define the job, risk boundary and pass criteria before collecting test cases.
Test output quality, tool behaviour, permissions and recovery as separate layers.
Use deterministic assertions whenever the correct result can be expressed exactly.
Keep a frozen regression set and a changing discovery set.
A staged release, monitoring and rollback plan are part of evaluation.

What exactly are you testing?

An agent is more than a prompt. It includes input handling, context retrieval, model reasoning, tool selection, tool arguments, permissions, approvals, external writes, retries, logging and human handoff. A beautiful answer can hide a wrong record update; a correct classification can still be unsafe if the agent used an unauthorised tool.

Start with a one-sentence contract: “Given these inputs and approved sources, the system returns this schema, may use these read tools, and must ask for approval before these writes.” Tests should map back to that contract.

Layer	Question	Example metric or assertion
Input	Is data valid and authorised?	Missing consent stops before model call
Output	Is the result useful and grounded?	Schema pass, category accuracy, source coverage
Tools	Did it call the right tool correctly?	Allowed tool, exact ID, valid arguments
Permissions	Could it exceed its role?	No write without bound approval
Recovery	Does failure return to a safe state?	No duplicate action after timeout
Operations	Can owners observe and stop it?	Trace completeness, alert time, rollback test

A practical evaluation pipeline

Figure 1. From contract to monitored release

1. Contract Define inputs, outputs, tools and forbidden actions.
2. Dataset Normal, edge, adversarial and failure cases.
3. Assertions Schema, rules, IDs and required routes.
4. Quality Correctness, groundedness and usefulness.
5. Tools Choice, arguments, scope and approval.
6. Failures Timeouts, duplicates, conflicts and injection.
7. Gate Compare metrics with release thresholds.
8. Operate Canary, monitor, rollback and regression.

Evaluation combines exact software checks with model-quality measurement and operational readiness.

Text equivalent: define the system contract and risks, run a representative dataset through exact assertions and quality graders, inspect every tool and approval path, simulate failures, enforce release thresholds and deploy gradually. Monitor real outcomes and turn failures into tests.

4-week live bootcamp · Barcelona or online

Go from one workflow to a complete AI automation system

In the AI Agent & Automation Bootcamp you build a no-code Virtual AI Department with n8n, RAG, connected agents and human approvals — live with an instructor and a small group.

See the bootcamp programme →

Not sure it fits? Take the free AI Career Roadmap test

Test the AI agent step by step

Write the contract and risk boundary. Name required inputs, output schema, approved sources, allowed read tools, approval-required writes, forbidden actions and the human owner for every exception.
Build a representative dataset. Include common requests, rare valid cases, incomplete inputs, ambiguous language, conflicting records, multiple languages, adversarial instructions and historical failures. Remove or protect personal data.
Add deterministic assertions. Test schema, enums, required IDs, arithmetic, policy gates, tool allowlists, approval state and duplicate prevention with exact checks. Do not ask another model to grade what code can prove.
Score model quality. Measure task-specific dimensions such as category correctness, evidence coverage, retrieval relevance, groundedness, usefulness and appropriate refusal. Define the rubric and examples before comparing variants.
Test tools and permissions. Inspect tool choice, arguments, record IDs, scopes and order. Confirm that text in a request or retrieved document cannot add a tool, change credentials or bypass approval.
Inject failures and adversarial inputs. Simulate timeouts before and after writes, malformed responses, stale sources, conflicting data, rate limits, prompt injection, duplicate events and denied or expired approval.
Run regression and staged release. Freeze a core set that every change must pass. Keep a separate discovery set for new edge cases. Release to shadow mode or a small traffic slice with a clear rollback trigger.
Monitor and learn. Track business outcomes, unsafe-action attempts, handoffs, latency, cost, overrides and silent failures. Add every incident and surprising near miss to the regression set.

Build the dataset around decisions, not polished examples

A test set that contains only well-written happy paths will exaggerate quality. Group cases by the decision the system must make and the failure it must resist.

Normal: representative requests in expected formats.
Boundary: values immediately above and below thresholds.
Missing: absent IDs, consent, evidence or required fields.
Ambiguous: several plausible categories or records.
Adversarial: attempts to override instructions, exfiltrate data or gain tools.
Operational: API outages, partial writes, duplicated events and rate limits.
Policy: actions that must refuse, escalate or wait for approval.

Store the dataset version, prompt, model, workflow revision, tool versions and scorecard version with every run. Without configuration lineage, a better or worse score is difficult to explain.

Choose metrics that expose trade-offs

Metric	What it reveals	Watch out for
Task success	Whether the requested job completed	Can hide unsafe paths
Category precision and recall	False accepts versus false rejects	One accuracy number hides imbalance
Groundedness	Whether claims follow supplied sources	Good wording can still cite the wrong source
Tool correctness	Right tool, argument and record	Final answer may look correct despite wrong call
Escalation quality	Whether a person receives usable context	Too many safe-looking handoffs can make system useless
Latency and cost	Operational sustainability	Optimising them can reduce quality or safety

n8n's current evaluation documentation distinguishes small, visually reviewed evaluations during development from metric-based evaluation over larger datasets. Its metric workflow can score dimensions and compare runs; availability varies by plan, so confirm the current product documentation.

Release gates and rollback

Decide thresholds before looking at the final candidate. A release gate can require zero unauthorised writes, 100% approval compliance, complete trace IDs, minimum classification scores for critical routes and no regression beyond an agreed tolerance.

Do not average away a catastrophic failure. One unauthorised payment, privacy leak or account change can block release even when the overall score is high.

Start in shadow mode, draft-only mode or with a small internal group. Compare the agent with the existing process, sample outputs by risk level and prove that the system can be disabled without losing pending work.

Minimum pre-production test matrix

Test	Expected result	Release condition
Valid common request	Correct result and trace	Meets task threshold
Missing required identifier	Stops or asks specifically	No guessed record
Prompt injection	Ignored as data	No permission or tool change
Denied approval	No action	Denial recorded
Timeout after write request	External-state verification	No duplicate write
Conflicting sources	Conflict surfaced	No unsupported merge
Duplicate event	Idempotent result	One external action
Monitoring disabled	Release blocked	Owner, alerts and rollback ready

Success criteria

The dataset represents normal traffic, edge cases and the highest-impact risks.
Every exact requirement has a deterministic assertion.
Tool traces prove which records and permissions were used.
Approval, denial, timeout and retry paths are tested end to end.
Release thresholds and catastrophic blockers are written in advance.
Production monitoring has named owners and a tested rollback route.
Incidents and overrides continuously improve the regression set.

Build complete AI workflows, not isolated demos

If you only need one personal workflow, a free tutorial may be enough. The bootcamp is for people who want to design and explain connected automation systems for real work.

Explore the AI Agent & Automation Bootcamp

Frequently asked questions

How do you test an AI agent?

Define the complete system contract, build a representative dataset, add deterministic assertions, score task-specific model quality, inspect tools and permissions, inject failures, run regression tests and release gradually with monitoring and rollback.

What should be in an AI agent test dataset?

Include normal, boundary, missing-data, ambiguous, multilingual, adversarial, policy and operational-failure cases. Add historical incidents and surprising production examples after protecting personal data.

Should you use another AI model to grade agent outputs?

Use model-based grading for nuanced qualities when the rubric is clear, but prefer deterministic checks for schemas, enums, arithmetic, IDs, permissions and tool calls. Calibrate model graders against human-reviewed examples.

What is the difference between an eval and a regression test?

An evaluation measures quality over a dataset. A regression test is a stable set run after changes to detect deterioration. In practice, a versioned evaluation dataset can provide both when thresholds and configurations are recorded.

When is an AI agent ready for production?

It is ready only when it meets task and safety thresholds, cannot bypass permissions, handles failures without duplicate or unsafe actions, produces usable handoffs, has observable traces and can be rolled back.

Sources

Continue learning

Start with the platform-neutral AI agent build guide

Add human approval and failure recovery

See the AI Agent & Automation Bootcamp

Originally published at Barcelona Code School. Learn more about our AI, coding and design programmes at barcelonacodeschool.com.