n8n, LangGraph or custom code: choose an AI workflow foundation

They can be combined. The useful decision is where each responsibility should live: receiving events, interpreting information, keeping state, asking for approval, calling business systems and helping an operator recover when something fails.

Consider an illustrative service business receiving a customer request with an attachment. The process must identify the customer, extract the requested work, compare it with the available service catalogue, prepare a draft response and wait for approval before sending it.

Now add an ambiguous attachment, a customer record that cannot be found and an approval that arrives after the request was changed. A prototype that handles the normal route is not enough. The foundation should make these exceptions understandable to the people who will maintain the product.

Write down the statuses before selecting the tool: received, awaiting information, prepared, awaiting approval, sent and failed. Define which transitions require a person and which system confirms that sending actually happened. That small state model makes comparisons more concrete than counting available integrations.

n8n's AI documentation describes combining model providers, tools, memory and workflow steps. It is a practical option to investigate when the work mostly connects existing systems and the team benefits from seeing those connections in one place.

For the service-request example, a workflow can receive the event, call an extraction step, look up the customer and route the draft for review. The important question is whether the maintained integrations support the exact operations and authentication your systems require, including the less convenient failure responses.

Visual editing does not remove software responsibilities. A complex expression, an undocumented custom node or a workflow with many hidden branches can be difficult to change safely. Establish a test environment, sample inputs, release ownership and a way to compare changes before relying on the flow for customer communication.

Hosting also matters. n8n's queue mode documentation describes a main instance, workers, Redis and database-backed execution information. That is an operational design to understand if you host this configuration yourself; selecting a visual platform does not make those components disappear.

LangGraph is worth investigating when the product needs custom branching, persistent state and model-driven work inside a codebase the team can maintain. Its persistence documentation distinguishes checkpoints for a thread's state from stores for information that spans interactions. An in-memory example is not the same as storage that survives a restart.

In the service-request workflow, explicit state can capture the current request version, evidence found, unresolved questions and approval reference. A branch can request clarification rather than continuing with an incomplete attachment. After a pause, the system can check whether the underlying request changed before applying an earlier approval.

The framework still needs application design. You must decide what is persisted, who can access it, how versions change and what a tool result means. Saving a checkpoint does not make an external email or booking atomic with that save. The product needs a deliberate rule for reconciling actions whose outcome is uncertain.

A small, well-bounded integration may be simplest as application code using your existing job system and database. If the workflow is a short sequence with clear rules, adopting a new orchestration framework may add more concepts than it removes.

Custom development also becomes relevant when the customer-facing interface, tenant separation or business data model is central to the product. These responsibilities exist even when n8n or LangGraph runs a part of the process behind the scenes. The choice is not “platform or product”; a product can contain either platform-managed or custom execution.

Be explicit about what “build it ourselves” includes. Someone must own deployment, credentials, scheduling, retries, cancellation, monitoring, data migrations and incident recovery. Reusing mature components for these jobs can be sensible. Reimplementing everything is not a requirement for a tailored business application.

Run the same deliberately awkward request through the candidates. Change its attachment while it is awaiting approval. Interrupt a downstream call. Deliver the input twice. Ask a person who did not build the prototype to locate the problem and resume the work. These exercises expose the operating model more clearly than a polished happy-path demonstration.

Record the work required to diagnose and correct each failure. A tool that makes the first workflow quick can still be a good choice, but its ongoing maintenance must fit the team's skills. Conversely, more code is not automatically more dependable if nobody owns the tests and operations.

One reasonable arrangement is a visual workflow for events and notifications, a focused service for complex model reasoning and an application database for authoritative business state. A code framework can sit inside that service if the stateful reasoning benefits from it.

Define the boundary with a job ID, input version, expected result, status endpoint and timeout behavior. Choose one component to decide whether the business job is complete. If both the visual workflow and the model service independently retry the same external action, they can duplicate it while each believes it is being helpful.

Start with the smallest arrangement that passes the workflow's acceptance cases. Add another layer when a measured limitation calls for it. For broader scope, read buying versus building business software and planning a business technology roadmap.

Talvyn Labs can test your workflow across the relevant options and build the product around a maintainable foundation. Bring the systems involved, a normal request and a request that usually gets stuck. We can define the state, connect the tools and deliver the interface and recovery process your team needs to operate it.