I keep seeing people build an AI lead processing agent when they really need a 6-step rules engine

Many teams mistakenly build complex "AI agents" for tasks like lead processing when a simpler, more reliable rules engine would suffice. It recommends using AI only for extracting messy input data (e.g., from emails or PDFs), then handling all deterministic business logic—such as duplicate checks, threshold-based routing, and bank assignment—with explicit code and database transactions to ensure consistency and prevent race conditions.

I knew this was worth writing when I saw a Reddit thread describing an “AI lead processing agent” for underwriting. The job sounded fancy until you translated it into actual steps: - Watch an inbox - Extract business name + monthly deposits - Check Salesforce, HubSpot, or a custom CRM/CMR - See whether the lead already exists - Route to new banks if needed - Assign a rep only if deposits are over $30,000 That is not an agent problem. That is workflow logic with one messy-input step. And a commenter in r/openclaw said the quiet part out loud: Don't use AI for deterministic processing. You can write a simple script for this and it will be much more reliable and cheaper. I think that’s exactly right. The mistake: using an LLM as a decision engine A lot of teams are building “AI lead gen automation” that should really be split into two pieces: - fuzzy extraction - deterministic state transitions Those are not the same thing. If the input is ugly — forwarded email chains, scanned PDFs, weird broker notes, inconsistent merchant statements — then yes, use Claude, GPT-5, or Qwen to extract fields. But once you have the fields, stop asking the model to make business decisions that can be expressed as code. Bad pattern: - “Figure out whether this is a duplicate” - “Decide whether to assign a rep” - “Determine which bank should receive this” Better pattern: - model extracts business name , monthly deposits , contact email - code checks CRM state - code applies explicit rules - code writes the result atomically That split matters a lot in production. The architecture I’d actually ship If I were building underwriting intake or lead routing, I’d use this shape: - Trigger on inbound email/webhook - Parse sender/subject/attachments deterministically - Send only messy text to an LLM for strict extraction - Normalize extracted values - Check CRM using normalized identifiers - In one locked step, decide duplicate/new/assignment - Only after the write succeeds, trigger downstream actions That gives you a small LLM boundary and a deterministic core. Put the LLM in a tiny box The safest contract is something boring like this: { "business name": "Blue Lantern LLC", "monthly deposits": 35000, "contact email": "ops@bluelantern.com", "requested amount": 50000, "confidence": 0.91 } That’s a good use of GPT-5, Claude Sonnet, or Qwen. What I would not do is this: Read the email, decide if the lead is a duplicate, determine whether it qualifies for rep assignment, and choose which bank should receive it. That prompt looks convenient right up until you need consistency, auditability, and duplicate prevention. What actually breaks first in production Not the prompt. Concurrency. This is where agent demos usually lie to you. They work great with one email. Then two brokers forward the same merchant 20 seconds apart. Now both workers do this: - query CRM - see no assigned record yet - decide the lead is new - route it - create duplicate work That’s not an AI failure. That’s a race condition. And no amount of “reasoning” fixes a missing transaction boundary. The rule that matters more than your prompt If your flow includes duplicate checks, threshold-based assignment, or bank routing, the critical part is the write path. This logic should be explicit: python def process lead crm record exists, new banks available, monthly deposits : if crm record exists: if new banks available: return "route to new banks" return "mark duplicate internal" if monthly deposits = 30000: return "assign rep and send docs" return "mark low revenue" And the final decision should happen inside one transaction or locked operation. For example, in PostgreSQL: BEGIN; SELECT id FROM leads WHERE normalized business name = $1 FOR UPDATE; -- if exists, update state -- if not, insert new row with unique constraint protection COMMIT; Or with an upsert: INSERT INTO leads normalized business name, contact email, monthly deposits, status VALUES $1, $2, $3, $4 ON CONFLICT normalized business name DO UPDATE SET updated at = NOW RETURNING id, status; That is the part worth obsessing over. Not whether your agent sounds confident while making inconsistent choices. A practical hybrid design This is the version I’d recommend to most teams using n8n, Make, Zapier, OpenClaw, or custom Python/TypeScript workers. | Layer | What it should do | |---|---| | Trigger/orchestration | Watch inboxes, webhooks, retries, notifications | | LLM step | Extract fields from messy email/PDF text | | Normalization step | Clean business names, parse currency, standardize email/domain | | Rules engine | Apply deposit thresholds, duplicate policy, assignment logic | | Transaction-safe write | Insert/update CRM state atomically | | Downstream actions | Send docs, notify reps, route to banks | This is what “AI where it helps, code where it matters” actually looks like. Example: n8n + Python worker If I wanted to move fast, I’d use n8n for orchestration and a small Python service for the transaction-sensitive part. n8n flow - IMAP Email Trigger or webhook - extract attachments/text - LLM node for structured extraction - HTTP request to internal worker - Slack/email notification after successful write Python worker sketch python from fastapi import FastAPI from pydantic import BaseModel app = FastAPI class LeadPayload BaseModel : business name: str monthly deposits: float contact email: str requested amount: float | None = None @app.post "/process-lead" def process lead payload: LeadPayload : normalized name = payload.business name.strip .lower pseudo-code for transaction-safe logic begin transaction lock matching lead row or rely on unique constraint check duplicate/new bank state apply 30k threshold write final status commit transaction if payload.monthly deposits = 30000: return {"status": "assign rep and send docs"} return {"status": "mark low revenue"} That gives you a workflow people can reason about. It also makes debugging possible when something goes wrong at 9:12 a.m. on a Monday. Where AI does help I’m not arguing against LLMs here. I’m arguing against giving them the wrong job. Good uses in this flow: - extracting fields from ugly broker emails - parsing scanned PDFs or OCR output - summarizing long email threads for a rep - drafting a reply asking for missing docs - flagging low-confidence extractions for human review Bad uses in this flow: - duplicate detection when the criteria are known - rep assignment when the threshold is explicit - bank routing when policy is fixed - deciding whether CRM state “probably means” something The moment a rule can be written down, it should stop being an LLM decision. The cost problem gets ugly fast There’s another reason to avoid agent-first design: cost creep. I saw another Reddit comment from someone using OpenClaw who said summarizing the last 10 emails with Claude 4.6 Sonnet cost about $0.25. That sounds tiny. Until your “agent” is doing that kind of work all day across: - inbox triage - CRM re-checks - duplicate review - status summaries - follow-up drafts - lead routing decisions that should have been simple SQL or code That’s how teams end up saying their agent stack burns tokens faster than expected. The model is doing office work your rules engine should be doing for free. This is exactly why predictable pricing matters if you’re running automations 24/7. If your workflows call models constantly, per-token billing turns every design mistake into a monthly surprise. Standard Compute is interesting here because it gives you an OpenAI-compatible API with flat monthly pricing, so you can afford to use models for the messy extraction layer without constantly watching token spend. That doesn’t mean you should waste LLM calls on deterministic routing. It means you can use AI where it actually helps and keep the rest of the pipeline boring. Agent-first vs automation-first | Approach | What usually happens | |---|---| | Automation-first | Deterministic branching, explicit thresholds, atomic writes, easier debugging | | Agent-first | More token usage, inconsistent decisions, harder audits, race-condition blind spots | | Hybrid | LLM for extraction/summaries, code for rules and state transitions | If you remember one thing, make it this: Using an LLM for extraction is not the same as handing control to an agent. Those are completely different design choices. A concrete test Before you add an AI agent to a workflow, ask: What part of this flow is genuinely ambiguous? If the answer is: - “the email is messy” - “the PDF format is inconsistent” - “the broker note is hard to parse” Use Claude, GPT-5, Grok, or Qwen for extraction. If the answer is: - “check the CRM” - “apply the $30k rule” - “avoid duplicates” - “assign the right rep” - “route to the right bank” You do not need autonomy. You need explicit logic. My opinionated version Most underwriting intake automations are not agent problems. They are data integrity problems wearing an AI costume. The messy-input layer is where AI earns its keep. The state-transition layer is where software engineering still wins. So if you’re building this in n8n, Make, Zapier, OpenClaw, or custom code, keep the model on a short leash: - extract - classify uncertainty - draft summaries - stop there Then let your rules engine do the real work. That may be less exciting than saying you built an autonomous underwriting agent. It also sounds a lot more like something I’d trust with real leads.