How to Integrate AI Agents with CRM, ERP and Existing Business Software

Every AI agent demo looks clean. A language model processes a query, calls an API, returns an answer. Then you try to connect it to your live Salesforce org, your ERPNext instance running three years of customisations, and a legacy supplier portal that only supports API keys — and the complexity triples.

Integration is where most AI agent projects stall. Not because the AI reasoning fails, but because the plumbing is harder than anticipated. This guide covers the exact technical patterns Techseria uses to integrate LangGraph.js agents with CRM, ERP, and business software — including authentication architectures, data consistency approaches, error handling, and realistic timelines so you can plan a project that actually ships.

Why Integration Is the Hard Part

A standalone LLM call takes milliseconds. An integrated AI agent that reads a CRM record, validates it against ERP inventory data, and posts an update to a supplier portal involves:

• Authentication tokens that expire mid-workflow
• API rate limits from three separate systems
• Data schema mismatches (a "customer" in Salesforce is an "Account"; in ERPNext it's a "Customer" with a different ID structure)
• Partial failure states where two of three API calls succeed before the third errors
• Audit requirements demanding you log every external write

None of these are unsolvable. All of them require deliberate design.

The LangGraph.js Tool Node Architecture

In LangGraph.js, external system calls are implemented as tool nodes — discrete functions the agent invokes as part of its reasoning loop. The graph-based architecture is what makes this tractable at scale: each integration point is an isolated node with its own error handling, retry logic, and state management.

A minimal tool node for an ERPNext integration looks like this in TypeScript:

import { tool } from "@langchain/core/tools"; import { z } from "zod"; const getERPNextSalesOrder = tool(

The agent's reasoning loop decides when to invoke this tool based on context — it does not fire on every message, only when the agent determines it needs that data to proceed.

Authentication Patterns by System Type

Authentication is the most common source of production failures. The pattern you choose depends on the system.

OAuth 2.0 (Salesforce, HubSpot, Microsoft 365)

Salesforce and HubSpot use OAuth 2.0 with short-lived access tokens (typically 2-hour expiry). For long-running agent workflows, you need a token refresh layer that runs transparently:

class OAuthTokenManager { private tokenCache: Map<string, { token: string; expiry: number }> = new Map(); async getToken(integration: string): Promise<string> {

Without this, agents that run for more than two hours — common in overnight batch processing or multi-step approvals — will fail mid-workflow with a 401 that cascades into data corruption if writes have partially completed.

API Key Authentication (ERPNext, Legacy Systems)

ERPNext uses a key:secret pair passed as an Authorization header. This is simpler but requires secure storage in environment variables or a secrets manager (Azure Key Vault for Azure-hosted deployments). Never hardcode API credentials in agent code.

Webhook Callbacks for Asynchronous Triggers

Some integrations need the external system to notify the agent rather than the agent polling. When an invoice is posted in ERPNext, it should trigger an AP agent — not wait for the agent to check every 5 minutes.

LangGraph.js supports this via interrupt points combined with an external webhook receiver:

// In your Express/Fastify webhook handler app.post("/webhooks/erpnext/invoice", async (req, res) => { const { doc_type, doc_name, event } = req.body;

This is faster than polling and far cheaper on API rate limits. The trade-off: webhooks require a publicly accessible endpoint with proper HMAC signature validation — both ERPNext and Salesforce send a signature header you must verify before processing.

Webhook vs Polling: When to Use Each

Scenario Recommendation

Event-driven triggers (invoice submitted, deal closed) Webhooks — lower latency, no rate limit cost

Bulk data sync (nightly reconciliation) Polling with cursor-based pagination

Systems that don't support webhooks (legacy ERP, spreadsheet APIs) Polling with exponential backoff

High-volume events (>1,000/day per system) Webhooks with queue buffer (Azure Service Bus)

Audit-critical workflows requiring guaranteed delivery Webhooks + message queue with dead-letter channel

For ERPNext specifically, the Document Event hook system supports webhooks on any doctype event. For Salesforce, Platform Events or Outbound Messages handle this. For HubSpot, the Webhooks API covers contact, deal, and company events.

Data Consistency: The Problem Most Projects Ignore

When an agent writes to three systems — updating a Salesforce opportunity, creating an ERPNext sales order, and sending a HubSpot follow-up task — you have a distributed write problem. If the ERPNext call succeeds but Salesforce fails, you now have inconsistent data across systems.

The patterns that address this:

Saga pattern (recommended for most integrations): Each step in the agent's workflow has a corresponding compensating action. If step 3 fails, the agent executes compensating actions for steps 1 and 2 (delete the ERPNext draft order, mark the HubSpot task as cancelled). LangGraph.js state persistence makes this tractable — the graph state at each checkpoint tells you exactly what has and hasn't completed.

Idempotency keys: All write operations should include an idempotency key (a UUID generated at the start of the agent run). If the agent retries a failed write, the same key prevents duplicate records. ERPNext's REST API supports this via the `name` field on document creation.

State checkpointing: LangGraph.js persists graph state after every node execution. If the process crashes mid-workflow, the run can resume from the last checkpoint rather than starting over and duplicating completed writes.

Error Handling and Retry Logic

Production integrations need three layers of error handling:

1. Transient errors (rate limits, timeouts): Retry with exponential backoff. For Salesforce, the API governor limits are per-org per-24-hours; for HubSpot, it's per-10-second windows. A backoff of 2^attempt seconds with jitter handles most transient failures.

2. Business logic errors (record not found, validation failure): These should surface to the human-in-the-loop interrupt rather than auto-retry. If an ERPNext customer record doesn't exist, the agent should escalate — not blindly create a duplicate.

3. Authentication errors (401, 403): Trigger token refresh (for OAuth) or alert on credential rotation (for API keys). Never surface raw credential errors to end users.

async function callWithRetry<T>( fn: () => Promise<T>, maxAttempts = 3

Integration-Specific Patterns

ERPNext Integration

ERPNext exposes a complete REST API at `/api/resource/{doctype}`. Key patterns:

• Use frappe client libraries or raw fetch — avoid ORMs that add schema assumptions
• Filter using `filters` query parameter as JSON: `?filters=[["status","=","Submitted"]]`
• For bulk operations, use the `bulk_update` endpoint to avoid N+1 API calls
• ERPNext webhooks require SSL — dev environments need a tunnel

Salesforce Integration

• Use the Salesforce REST API v58+ — avoid SOAP for new integrations
• Composite API allows up to 25 operations in a single HTTP request — critical for staying within governor limits
• SOQL queries in tool nodes should be parameterised to prevent injection
• Bulk API 2.0 for operations exceeding 2,000 records

HubSpot Integration

• HubSpot's Private App tokens are the correct auth pattern for agent integrations (not OAuth, which requires user interaction)
• Properties API is required to read custom properties — don't assume standard fields cover your data model
• Associations API needed to link contacts to deals and companies in a single read

Realistic Build Timelines

Based on Techseria's delivery history across 20+ enterprise integrations:

Integration Scope Timeline

Single system, read-only (agent reads CRM data to answer queries) 2–4 weeks

Single system, read-write (agent updates CRM records) 4–6 weeks

Two-system integration (ERPNext + Salesforce bidirectional sync via agent) 6–10 weeks

Three-system orchestration (CRM + ERP + email/comms) 8–14 weeks

Legacy system with no REST API (file-based integration) Add 3–6 weeks

The majority of timeline variance comes from two sources: data quality issues discovered during mapping (20–30% of integrations reveal inconsistencies requiring remediation before the agent can function reliably), and IT security review cycles for production API credential provisioning.

Common Pitfalls and Solutions

Pitfall 1: Mapping data schemas too late. Most teams start building before they've fully mapped the data schemas of both systems. Discovering that a Salesforce "Account" doesn't map cleanly to an ERPNext "Customer" two weeks into build is expensive. Solution: mandate a data mapping document before a line of integration code is written.

Pitfall 2: Testing against production systems. Rate limits get exhausted, test records pollute live data, webhooks fire into production workflows. Solution: ERPNext has bench sandboxing; Salesforce has full sandbox orgs; HubSpot has developer test accounts. Enforce sandbox-only testing during build.

Pitfall 3: Ignoring pagination. A Salesforce query returning 2,000 records will silently truncate at 200 if you don't handle `nextRecordsUrl`. Solution: wrap all list/query calls in a pagination loop.

Pitfall 4: No observability. Integration failures in production are invisible without logging every tool node invocation. LangGraph.js's LangSmith tracing integration provides this out of the box for cloud deployments.

Pitfall 5: Hardcoded field mappings. Business fields change — Salesforce admins add custom fields, ERPNext gets customised, HubSpot properties are renamed. Hardcoded mappings break silently. Solution: externalise field mappings to configuration files that non-developers can update.

What to Do Before You Build

The single highest-value activity before any integration project is a data architecture audit. Before writing a tool node, you need to know:

1. Which system is the single source of truth for each entity (customer, product, order, invoice)?
2. What is the data quality in each system (duplicate records, missing required fields, inconsistent formats)?
3. Which APIs have been enabled and what are their rate limits?
4. Who owns credential provisioning in IT security and what is their review timeline?

At Techseria, we run a structured Discovery Workshop as the first engagement on every integration project. This 3–5 day process produces a data map, integration architecture diagram, and a realistic timeline — before any build commitment.

The Cost of Getting This Wrong

Poor integration architecture doesn't fail loudly. It fails quietly: duplicate records accumulate, sync gaps widen, and by the time the problem surfaces, remediation takes longer than the original build. One manufacturing client came to Techseria with a six-month-old "AI agent" that had created 847 duplicate customer records in ERPNext because idempotency logic was missing. Cleanup took 3 weeks.

Done correctly, integrated AI agents eliminate 60–80% of the manual data entry and cross-system reconciliation that finance, operations, and sales teams perform daily. The integration architecture is what makes that possible.

[Book a Strategy Session with Techseria](/contact) — we'll map your integration architecture, identify data consistency risks, and deliver a fixed-scope build plan within 5 business days.