DEV Community: AymaneWebDEV

Building an Autonomous B2B Lead Enrichment & ICP Scoring Agent with n8n and LangChain

AymaneWebDEV — Mon, 21 Sep 2026 12:35:42 +0000

Manual lead qualification and CRM updates can become a surprisingly expensive time sink for early-stage SaaS and engineering teams.

The workflow is usually the same:

A lead submits a form → someone checks the company → someone researches the role and company size → someone decides whether the lead matches the ICP → someone updates the CRM or alerts sales.

You can automate most of that pipeline with n8n, a company enrichment API, and an LLM-based evaluation step.

In this guide, we'll build the architecture behind an autonomous B2B lead qualification workflow, look at the evaluation prompt, and walk through the n8n workflow structure.

The goal isn't to make the LLM "decide everything." The goal is to give it structured inputs, explicit qualification rules, and a predictable output that downstream automation can consume.

1. System Architecture

The pipeline processes an inbound lead through four stages:

[ Inbound Lead Webhook ]
          │
          ▼
[ Domain & Company Enrichment ]
          │
          ▼
[ AI / ICP Evaluation ]
          │
          ▼
[ Alert + CRM Routing ]

1. Webhook ingestion

The workflow starts when a lead submits a form, signs up for your application, or sends data from another system.

Example payload:

{
  "email": "alex@example.com",
  "name": "Alex Morgan",
  "role": "CTO"
}

2. Company enrichment

The workflow extracts the domain from the email address and sends it to an enrichment provider.

Depending on the provider, you can retrieve information such as:

Company name
Industry
Employee count
Domain status
Funding information
Company description

This gives the AI evaluator more context than the original form submission alone.

3. ICP evaluation

The enriched lead is passed to an LLM agent.

Instead of asking:

"Is this a good lead?"

we provide explicit qualification criteria and require a structured response.

4. Automated routing

The result can then be used by n8n to:

Send a Slack or Telegram notification
Create or update a CRM record
Add the lead to a nurture sequence
Assign a sales priority
Store the evaluation in PostgreSQL

2. Designing the ICP Evaluation Prompt

The most important part of this workflow isn't the AI model itself.

It's the contract between the AI and the automation workflow.

A useful evaluation prompt should define:

What data the model receives
What qualifies as a good lead
What it should do when information is missing
Exactly what format it must return

For example:

Evaluate the incoming lead against our Ideal Customer Profile (ICP).

Input Data:
- Lead information: {{lead_data}}
- Enriched company data: {{company_data}}

Qualification Criteria:

1. Company size:
   - More than 10 employees is a positive signal.

2. Role:
   - CTO
   - Founder
   - Engineering Lead
   - VP Product

3. Company:
   - Must appear to be a commercial organization.
   - Personal email domains should not receive a Hot classification.

4. Missing information:
   - Do not invent missing company information.
   - If important information cannot be verified, reduce confidence.

Return JSON only:

{
  "score": "Hot | Warm | Unqualified",
  "reasoning": "One sentence explaining the classification.",
  "recommended_action": "Instant Demo | Add to Nurture | Drop"
}

The important part here is not the word "deterministic."

LLMs are probabilistic.

What we're actually doing is constraining the model's behavior with explicit rules and a structured output contract.

That makes the result much easier for an automation pipeline to consume.

3. Connecting the Workflow in n8n

The basic n8n workflow looks like this:

Webhook
   │
   ▼
Extract Email Domain
   │
   ▼
Company Enrichment API
   │
   ▼
Merge Lead + Company Data
   │
   ▼
AI ICP Evaluator
   │
   ▼
Parse Structured Output
   │
   ├── Hot ───────► Sales Alert
   │
   ├── Warm ──────► Nurture / CRM
   │
   └── Unqualified ► Archive

One improvement I'd recommend over a single AI node is adding an explicit structured-output/parser step after the model.

That gives you a clear boundary between:

LLM output
     ↓
Validation
     ↓
Automation

If the model produces malformed JSON, the workflow can stop or retry instead of sending unexpected data into your CRM.

4. Example n8n Workflow Structure

A simplified workflow can look like this:

{
  "name": "B2B Lead ICP Scoring",
  "nodes": [
    {
      "name": "Lead Inbound Webhook",
      "type": "n8n-nodes-base.webhook",
      "parameters": {
        "path": "lead-submit",
        "httpMethod": "POST"
      }
    },
    {
      "name": "Company Enrichment",
      "type": "n8n-nodes-base.httpRequest",
      "parameters": {
        "url": "https://api.example.com/company"
      }
    },
    {
      "name": "ICP AI Evaluator",
      "type": "@n8n/n8n-nodes-langchain.agent",
      "parameters": {
        "prompt": "Evaluate the lead against the defined ICP rules and return structured JSON."
      }
    },
    {
      "name": "Route Lead",
      "type": "n8n-nodes-base.switch",
      "parameters": {
        "mode": "rules"
      }
    }
  ]
}

This is intentionally simplified because the exact n8n JSON depends on the versions of the nodes you're using and the credentials configured in your instance.

For a real deployment, you'll also need to configure:

AI model credentials
Enrichment API credentials
Telegram/Slack credentials
Output parsing
Error handling
CRM integration

5. Don't Let the AI Become a Single Point of Failure

One mistake I see in AI automation workflows is putting too much trust in the model.

For lead scoring, the AI should be one component inside a controlled pipeline.

For example:

Raw Lead
   │
   ▼
Schema Validation
   │
   ▼
Company Enrichment
   │
   ▼
Rule-Based Checks
   │
   ▼
AI Evaluation
   │
   ▼
Output Validation
   │
   ▼
Business Routing

This gives you multiple opportunities to reject bad input before it reaches your CRM.

You can also keep hard business rules outside the model.

For example:

IF email domain is gmail.com
    → do not classify as Hot

IF employee_count < 10
    → reduce qualification priority

IF role = CTO
    → add positive signal

The LLM can handle the less structured reasoning, while explicit rules handle things that should never be ambiguous.

6. Production Considerations

Once the workflow starts receiving real traffic, there are a few additional concerns.

Queue-based execution

For higher webhook volume, n8n can be deployed using queue-based execution with Redis and worker processes.

This separates incoming webhook handling from workflow execution and can help handle bursts more reliably.

Secrets

Don't hardcode API keys inside workflow definitions.

Store credentials using n8n's credential system or your deployment's secret-management approach.

Rate limiting

Your enrichment and LLM providers will have their own limits.

Add rate limiting and retry strategies so a burst of inbound leads doesn't unexpectedly consume your entire API quota.

Error handling

External APIs fail.

LLM calls can time out.

Enrichment data can be incomplete.

A production workflow should define what happens when each of these situations occurs.

For example:

Enrichment API fails
        │
        ▼
      Retry
        │
   ┌────┴────┐
   │         │
Success    Failure
   │         │
   ▼         ▼
Continue   Queue / Review

7. Where This Gets Interesting

Once the basic lead-scoring workflow works, you can extend it considerably.

For example:

Lead enrichment

Email
 ↓
Company
 ↓
Employees
 ↓
Industry
 ↓
Funding
 ↓
Technology Stack

AI qualification

Firmographics
+
Role
+
Company Description
+
Inbound Message
        ↓
    ICP Score

Automated routing

Hot
 ├── Slack Alert
 ├── CRM Priority = High
 └── Sales Notification

Warm
 └── Nurture Sequence

Unqualified
 └── Archive

At that point, n8n becomes less of a simple workflow builder and more of an orchestration layer around your AI services and business logic.

8. Final Architecture

The complete architecture can be summarized as:

                 ┌─────────────────────┐
                 │   Lead Submission   │
                 └──────────┬──────────┘
                            │
                            ▼
                 ┌─────────────────────┐
                 │ Schema Validation   │
                 └──────────┬──────────┘
                            │
                            ▼
                 ┌─────────────────────┐
                 │ Company Enrichment  │
                 └──────────┬──────────┘
                            │
                            ▼
                 ┌─────────────────────┐
                 │ Rule-Based Checks   │
                 └──────────┬──────────┘
                            │
                            ▼
                 ┌─────────────────────┐
                 │   AI ICP Scoring    │
                 └──────────┬──────────┘
                            │
                            ▼
                 ┌─────────────────────┐
                 │ Output Validation   │
                 └──────────┬──────────┘
                            │
                 ┌──────────┼──────────┐
                 ▼          ▼          ▼
               Hot        Warm      Unqualified
                 │          │          │
                 ▼          ▼          ▼
              Sales      Nurture     Archive

The main lesson is that you don't need to make the LLM responsible for the entire process.

Use code for strict rules, APIs for enrichment, LLMs for flexible evaluation, and n8n for orchestration.

That separation makes the system easier to debug, test, and modify as your ICP changes.

Want the Full Automation Vault?

If you want to build beyond lead qualification, I packaged a collection of reusable n8n + AI workflows covering areas such as:

Lead qualification
Document RAG
GitHub issue triaging
Competitor monitoring
Customer churn workflows
AI-powered business automation

Enterprise n8n & AI Agent Automation Vault

https://nexusbuilds.gumroad.com/l/n8n-ai-automation-vault/EARLYBIRD

For the prompt-engineering rules used to structure AI coding and agent workflows, you can also check out the open-source repository:

Developer Prompt Vault

https://github.com/AymaneWebDEV/developer-prompt-vault

If you're building something similar, I'd be interested to know how you're handling AI scoring vs. rule-based qualification in your own automation stack.

How to Build Sub-100ms Streaming AI APIs with Next.js 15 and Supabase SSR

AymaneWebDEV — Wed, 16 Sep 2026 11:51:57 +0000

Building a Secure Streaming AI Endpoint with Next.js App Router

If you're building an AI SaaS or LLM wrapper in 2026, time-to-first-token (TTFT) has a huge impact on how the application feels.

Waiting several seconds for the entire completion before showing anything makes the UI feel slow, even when the model itself is responding normally.

Streaming fixes that by sending tokens to the client as they're generated.

But there's another side to it: implementing streaming carelessly can introduce problems around authentication, API-key exposure, rate limiting, and resource consumption.

Here's a simple architecture for building a streaming AI endpoint with Next.js App Router, Supabase authentication, and server-side rate limiting.

1. The Streaming Route Handler

Let's start with /api/ai/stream.

The native Web Streams API works well for this use case because we can send chunks to the client as they become available instead of buffering the entire response.

import { NextRequest, NextResponse } from "next/server";
import { createClient } from "@/lib/supabase/server";

export const runtime = "edge";

export async function POST(req: NextRequest) {
  try {
    // 1. Authenticate using Supabase SSR cookies
    const supabase = await createClient();

    const {
      data: { user },
    } = await supabase.auth.getUser();

    if (!user) {
      return NextResponse.json(
        { error: "Unauthorized" },
        { status: 401 }
      );
    }

    const { prompt } = await req.json();

    // 2. Create the response stream
    const encoder = new TextEncoder();

    const stream = new ReadableStream({
      async start(controller) {
        const chunks = [
          "Analyzing architecture... ",
          "Generating edge pipeline... ",
          "Done.",
        ];

        for (const chunk of chunks) {
          controller.enqueue(
            encoder.encode(
              `data: ${JSON.stringify({ text: chunk })}\n\n`
            )
          );

          await new Promise((resolve) => setTimeout(resolve, 60));
        }

        controller.enqueue(
          encoder.encode("data: [DONE]\n\n")
        );

        controller.close();
      },
    });

    return new Response(stream, {
      headers: {
        "Content-Type": "text/event-stream; charset=utf-8",
        "Cache-Control": "no-cache, no-transform",
        Connection: "keep-alive",
      },
    });
  } catch (error) {
    console.error("Stream error:", error);

    return NextResponse.json(
      { error: "Stream error" },
      { status: 500 }
    );
  }
}

The example above uses simulated chunks, but the same stream can be connected to an actual LLM provider.

The important part is that the server starts sending data immediately rather than waiting for the complete response.

2. Keep Your API Keys on the Server

One mistake I see frequently in AI wrappers is putting provider credentials in client-side code.

Don't do this.

Your browser should communicate with your application:

Browser
   ↓
/api/ai/stream
   ↓
Authentication
   ↓
Rate limiting
   ↓
LLM provider

The OpenAI, Anthropic, or other provider API key should remain on the server.

The client only needs to receive the streamed output.

3. Authenticate Before Starting the LLM Request

Streaming makes authentication even more important because an unauthorized user can potentially keep connections open and consume resources.

The sequence should be:

Request
  ↓
Validate session
  ↓
Check rate limit
  ↓
Validate input
  ↓
Call LLM
  ↓
Stream response

Don't start the expensive provider request and then perform authorization afterward.

Reject invalid requests as early as possible.

4. Add Rate Limiting

Authentication alone doesn't stop an authenticated user from making thousands of requests.

For an AI SaaS, this can become an expensive problem very quickly.

A rate limiter should generally be applied before the LLM request is created.

Depending on your architecture, you might use Redis or another shared store so limits work across multiple application instances.

For example:

user_123
   │
   ├── request 1 ✓
   ├── request 2 ✓
   ├── request 3 ✓
   └── request 4 → rate limited

For production systems, consider limiting based on both request frequency and the amount of work being requested.

5. Validate the Input

Don't blindly pass arbitrary request bodies to your LLM provider.

At minimum, validate:

Prompt type
Maximum prompt length
Required fields
Allowed parameters
Model selection
Token limits

This prevents malformed requests from reaching the expensive part of your stack.

6. The Architecture

Putting everything together:

                 ┌──────────────────┐
                 │     Browser      │
                 └────────┬─────────┘
                          │
                          ▼
                 ┌──────────────────┐
                 │ /api/ai/stream   │
                 └────────┬─────────┘
                          │
                    Authentication
                          │
                          ▼
                    Rate Limiting
                          │
                          ▼
                    Input Validation
                          │
                          ▼
                 ┌──────────────────┐
                 │   LLM Provider   │
                 └────────┬─────────┘
                          │
                     Token stream
                          │
                          ▼
                 ┌──────────────────┐
                 │   ReadableStream │
                 └────────┬─────────┘
                          │
                          ▼
                       Browser

The key idea isn't simply "use streaming."

It's to make streaming part of a properly controlled request pipeline.

Authenticate → rate-limit → validate → call the provider → stream the result.

That gives you a much better foundation for turning an LLM API into an actual SaaS feature rather than exposing a raw model endpoint.

One More Thing

Don't assume that runtime = "edge" automatically means your endpoint will have sub-100ms TTFT.

The runtime can reduce some latency, but actual TTFT still depends on your authentication path, region, network, provider, model, prompt size, and infrastructure.

Measure it. Don't market the number before you've measured it.

How to Stop Cursor from Hallucinating: 5 Production Rules Every AI Engineer Needs

AymaneWebDEV — Sun, 13 Sep 2026 13:41:37 +0000

How to Stop Cursor from Hallucinating: 5 Production Rules Every AI Engineer Needs

If you use Cursor, Claude Code, or GitHub Copilot on a non-trivial codebase, you've probably encountered the AI coding drift problem.

The model:

Invents methods that don't exist in your framework version.
Couples database queries or third-party APIs directly inside HTTP route handlers.
Generates loose types like any or object to bypass TypeScript or Pydantic errors.
Writes brittle unit tests that mock everything without testing actual boundary failures.

When building production systems, manually fixing AI-generated drift can quickly erase the productivity gains from AI-assisted development.

The solution isn't simply "better conversational prompting."

It's explicit engineering rules that constrain the coding agent before it writes the code.

Here are five rules you can add to your .cursor/rules/ directory.

1. Bounded Context & Layer Isolation

Prevent the AI from mixing database access, business logic, and HTTP concerns:

- Route handlers MUST only perform request validation and delegate to application services.
- Domain logic MUST remain independent of database ORMs and external APIs.
- External API clients and third-party SDKs MUST be encapsulated behind dedicated adapters.
- Database queries MUST NOT be placed directly inside HTTP route handlers.

This gives the agent explicit boundaries between the presentation, application, domain, and infrastructure layers.

Without these constraints, an AI agent will often choose the shortest path to a working implementation—even when that implementation creates unnecessary coupling.

2. Hermetic Unit Testing

AI-generated tests can look comprehensive while providing very little protection.

A common pattern is to mock almost every dependency and then assert that the mocked functions were called.

The test passes, but the actual boundary failure was never tested.

Give the agent explicit testing constraints:

- Unit tests MUST be hermetic: no real network calls and no unintended external filesystem dependencies.
- Tests MUST cover valid inputs, invalid inputs, and important boundary conditions.
- Avoid mocking internal domain logic.
- Mock external boundary adapters where appropriate.
- Tests MUST verify observable behavior rather than implementation details.
- Every bug fix SHOULD include a regression test when practical.

For example, don't only test that an API call succeeds.

Also test what happens when the external service:

Times out
Returns malformed data
Returns an unexpected status code
Returns an empty response

The goal isn't maximum mock coverage.

It's meaningful behavioral coverage.

3. Fail-Fast Input Boundaries

AI-generated applications often assume that incoming data is trustworthy.

That's particularly dangerous at API boundaries.

Tell the agent exactly how input should be handled:

- All incoming payloads MUST be validated using strict schemas such as Pydantic or Zod.
- Avoid implicit type coercion when strict validation is required.
- Invalid input MUST be rejected at the application boundary.
- Domain-specific failures MUST use typed exceptions rather than generic errors.
- Do not pass unvalidated request dictionaries through application layers.

This creates a clear boundary:

External input → Validation → Application logic → Domain logic

Instead of allowing malformed data to travel through the entire application before something eventually fails.

4. Hallucination & Assumption Defense

One of the most frustrating problems with AI coding assistants is confident guessing.

A model may generate an import, method, parameter, or dependency that looks perfectly reasonable but doesn't actually exist in your installed version.

Add rules that explicitly prohibit this behavior:

- NEVER assume an API, method, parameter, or configuration option exists without verification.
- Prefer APIs already used by the existing codebase when implementing new functionality.
- Do not invent dependencies or speculative import paths.
- Do not use deprecated APIs when a supported alternative exists.
- If an implementation depends on an unverified assumption, explicitly identify the assumption before proceeding.
- If the requested approach introduces architectural or security risks, explain the trade-off and propose a safer alternative.

The important principle is:

The project's installed dependencies and existing code are the source of truth—not the model's memory.

This is particularly useful when working with rapidly changing frameworks and libraries.

5. Idempotent State Mutations

AI-generated APIs can also overlook what happens when clients retry requests.

Consider an endpoint that creates an order or processes a payment.

If the client sends the request, experiences a timeout, and retries it, you don't want the server to process the operation twice.

For state-changing operations, give the agent explicit constraints:

- State-changing endpoints SHOULD support idempotency when duplicate requests could cause unintended side effects.
- Financial, order, and payment operations MUST define an idempotency strategy.
- Idempotency keys MUST be persisted and associated with the resulting operation.
- Concurrent state transitions MUST use appropriate transactional or locking mechanisms.
- Do not rely on application-level checks alone when atomic database guarantees are required.

The exact implementation will depend on your database and architecture, but the important thing is that the agent is forced to consider retry and concurrency behavior instead of generating only the happy path.

Why These Rules Matter

AI coding assistants are extremely good at generating code.

But they don't automatically know:

Your architecture
Your dependency versions
Your domain boundaries
Your testing philosophy
Your security requirements
Your tolerance for technical debt

Without explicit constraints, the model tends to optimize for producing code that looks plausible and solves the immediate request.

That's where coding drift begins.

Compare:

"Implement authentication."

with:

Use the existing authentication service.
Do not access the database from route handlers.
Validate all external input with the existing schema system.
Do not introduce new dependencies.
Add tests for expired tokens and invalid credentials.

The second instruction gives the agent a much smaller—and more useful—solution space.

Start With Constraints, Then Generate Code

You don't need an enormous system prompt containing every possible engineering rule.

Start with the constraints that matter most to your project:

Architecture boundaries
Dependency verification
Strict input and type validation
Boundary-focused testing
State and concurrency safety

Then adapt them to your framework and codebase.

The goal isn't to make your AI coding assistant less autonomous.

It's to make its autonomy bounded by engineering constraints.

Open-Source Developer Prompt Vault

I've collected these types of rules, along with additional prompts for architecture, refactoring, testing, security, and development workflows, in an open-source repository:

Developer Prompt Vault:
https://github.com/AymaneWebDEV/developer-prompt-vault

The repository contains reusable Markdown rules and templates that you can adapt to your own AI-assisted development workflow.

If you're building AI-powered applications with FastAPI, I've also put together a separate starter architecture covering authentication, streaming APIs, rate limiting, Docker, and automated testing:

FastAPI AI Agent Starter Kit:
https://nexusbuilds.gumroad.com/l/fastapi-ai-starter-kit

What Rules Have Helped You?

What constraints have had the biggest impact on your Cursor, Claude Code, or Copilot workflows?

I'd especially be interested in rules around architecture, testing, dependency verification, and preventing AI-generated technical debt.