Agentic AI and LangGraph for B2B Workflows
An agent that can call tools is not automatically a product. In B2B, agentic AI means durable workflows: read context, decide, call APIs, wait for humans, retry failures, leave an audit trail. Frameworks like LangGraph help model that as an explicit graph with state, branches, and interrupts instead of a fragile prompt loop. This guide is for founders and engineering leads shipping agents inside SaaS or internal tools. It covers when agents beat chatbots, graph design, permissions, human-in-the-loop, observability, and failure modes. Pair with production RAG when knowledge retrieval is a tool node, and with ERP integration and observability when agents touch money-moving systems.
Agents vs chatbots vs plain automation
Use a chatbot when the job is Q&A with optional citations. Use deterministic automation (rules, BPM, scripts) when the path is known and should never invent steps. Use an agent when the path needs judgment over tools: classify intent, gather missing fields, choose which API, stop for approval, resume. LangGraph-style designs shine when you need checkpoints, branching, cycles (retry / clarify), and human interrupts without losing state. Do not wrap every cron job in an LLM. Agents add cost, latency, and new failure modes; they pay off when ambiguity is real and tools are well constrained.
- Chat: grounded answers, no side effects
- Automation: fixed path, strong SLAs
- Agent: tool use with branching and approval gates
- Hybrid: agent drafts, automation executes after sign-off
Designing the graph: state, nodes, edges
Model the workflow as nodes with a typed state object: user goal, tenant, collected fields, tool results, decision history, approval status. Prefer small nodes with one responsibility over a mega-prompt that does everything. Edges encode real business rules: 'if amount > threshold → approval node', 'if ERP soft-fail → retry with backoff', 'if RAG empty → ask clarifying question'. Keep irreversible side effects in dedicated nodes with idempotency keys. Persist state at checkpoints so a crash mid-flight can resume. Ephemeral chat memory is not enough for multi-hour B2B processes.
- Separate plan / retrieve / act / verify nodes
- Store correlation IDs across every tool call
- Make side-effect nodes idempotent and replay-safe
- Version graph definitions like API contracts
Tools, permissions, and least privilege
Every tool is an API with blast radius. Expose narrow tools ('get_order_status', 'create_draft_ticket') not 'run_arbitrary_sql'. Bind tools to the authenticated principal and tenant, never to a god-mode service role for convenience. Align permissions with SSO and identity. The agent inherits what the user may do; support impersonation must be audited. Schema-validate tool arguments. Reject out-of-range amounts, unknown plant IDs, and write operations outside allowed resource sets before the HTTP call leaves your boundary.
Human-in-the-loop as a first-class node
Enterprise buyers expect approval for irreversible actions: price changes, mass emails, ERP posts, access grants. Design interrupt nodes with clear payload: what will happen, why, evidence, and approve / reject / edit. Timeout behavior must be explicit: escalate, cancel, or park. Silent hangs destroy trust. After approval, continue from checkpoint without re-asking the model to reinvent the plan. Humans edit state; the graph resumes.
- Define which actions always require a human
- Show citations or tool evidence on the approval card
- Audit who approved and what changed
- Allow partial approve (edit fields, then continue)
RAG as a tool inside the graph
Treat retrieval as a node with filters and confidence, not as ambient prompt stuffing. The agent should decide when to search, then ground later steps on returned sources. Follow production RAG practices for tenancy and evaluation. An agent that retrieves the wrong tenant's policy is a security incident, not a cute hallucination.
Failure modes unique to agentic systems
Loops: the model retries forever. Cap iterations and force escalate. Partial writes: tool A succeeded, tool B failed. Compensate or saga. Tool hallucination: invented endpoints or IDs. Strict schemas and allowlists. Prompt injection via retrieved docs or ticket text: treat untrusted text as data, not instructions. Budget exhaustion: token or tool-call caps per run. Poisoned state: bad intermediate fields polluting later nodes. Validate state transitions like any workflow engine. These are delivery risks to price into project estimates and go-live readiness.
Observability and evaluation for agents
Trace each run: node sequence, tool latency, token use, approvals, final outcome. Correlate with tenant and business journey IDs so support can replay 'why did this order draft fail'. Evaluate offline with scripted scenarios: happy path, missing fields, tool outage, injection attempts, approval reject. Online, sample runs for policy violations and useless loops. Connect metrics to SLA expectations: agents that miss deadlines need escalation paths like any other automation.
- Persist full run traces with retention policy
- Alert on iteration cap hits and tool error spikes
- Regression suite on graph version bumps
- Red-team prompt injection via tickets and docs
MVP delivery with contractors
Scope one vertical journey end-to-end: e.g. 'intake support email → classify → draft ticket → human approve → create in system'. Non-goals: multi-agent swarms, open-ended browsing, unsupervised ERP writes. Acceptance criteria include allowlisted tools, ACL tests, approval UX, replay from checkpoint, and runbooks. Tie to contractor hiring and MVP scoping. Prefer explicit graphs over 'the model will figure it out' for anything that touches production systems of record.
Next steps
Draw the workflow on a whiteboard with side effects marked in red. If you cannot name the approval and rollback for each red node, you are not ready for an unsupervised agent. See RAG in production, other resources, case studies, book a call, or contact to review an agentic design before it touches ERP or customer data.
FAQ
Do we need LangGraph specifically?
You need an explicit state machine or graph with checkpoints, interrupts, and typed tool boundaries. LangGraph is a strong option in the Python/JS ecosystem; the product requirement is durable, auditable workflows, not a particular brand.
Can one agent call many tools safely?
Yes if tools are narrow, permission-checked, schema-validated, rate-limited, and side effects are idempotent with human gates on irreversible actions. Broad 'do anything' tools are how incidents happen.
How is this different from a traditional BPM engine?
BPM encodes known paths; agents handle ambiguity and language at the edges. Many B2B systems combine both: LLM nodes for classification and drafting, deterministic nodes for posts and billing.
What should we measure before expanding the pilot?
Task success rate, human override rate, average tool calls per success, incident count from wrong writes, and time-to-resolution vs the previous manual process. Vanity chat ratings are not enough.