Skip to content

Concepts · Orchestration

Where the demo becomes a system.

We orchestrate with LangChain and LangGraph — and we'll tell you exactly what that buys, what it doesn't, and where the real production engineering happens. The framework is plumbing. The hardening is the product.

The plumbing

What LangGraph actually gives you.

Good primitives for stateful workflows — free, widely known, and heavily used in production. Which is exactly why it's plumbing, not differentiation.

  • Explicit graphs, not free-running agents

    Workflows are defined as graphs — nodes, edges, conditions — so the system's possible control paths are enumerable and reviewable. An auditor can read the graph; nobody can read an agent loop's mood.

  • State & checkpointing

    Long-running workflows persist their state, survive restarts, and can resume mid-process — table stakes for document pipelines that run for hours. Token streaming comes with it, so users see output as it generates.

  • Human-in-the-loop interrupts

    The graph can pause at defined points and wait for a person — which is how consequential actions (send, submit, pay, file) stay under human authority by construction.

  • Tool calling & integrations

    A mature interface for calling into your systems, with LangChain's integration ecosystem where it helps and hand-built tools where it doesn't.

The gap

What the framework deliberately doesn't ship.

This list is why "we use LangChain" tells you nothing about whether a vendor can put AI into a bank. It's also the part you're actually buying.

Access control & RBAC

Who may invoke which workflow, which tools a workflow may touch, and with whose permissions. The paid platform tier bolts some of this on — inside its own walls. We integrate with your identity provider and scope every tool to least privilege, in your infrastructure.

Audit trails

A decision-grade record: who asked what, which documents were retrieved, which model version answered, which tools fired with what arguments. Built into every system we ship, retained per your policy.

PII discipline

Redaction and minimisation at the boundaries — including logs, traces and checkpointed state: tracing captures full inputs and outputs once enabled, and every checkpoint persists the full conversation state. Inference logs are personal data; we treat them that way.

Evaluation & guardrails

The framework will execute whatever graph you give it, good or bad. Quality gates, adversarial guardrail tests and go/no-go thresholds come from our evaluation harness, not the orchestrator.

Trace & telemetry residency

The ecosystem's default observability is a hosted SaaS — traces full of your data, shipped out; self-hosting it is an enterprise-tier product. We deploy self-hosted tracing inside your boundary instead — Langfuse with its own usage telemetry switched off, or an OpenTelemetry backend.

Versioning discipline

Prompts, graph definitions, model builds and eval scores versioned together, so every production answer traces to the exact configuration that produced it.

The quality gates come from the evaluation harness, which has its own page: evaluation-first delivery.

The hardening

Bounded autonomy, validated boundaries.

The difference between an agent demo and an operable system is a list of boring engineering decisions. These are ours.

Bounded where it matters: we prefer explicit graph flows over open-ended agent loops, and every loop that does exist has a hard iteration budget. A system that can wander is a system nobody will certify.

Schemas at every boundary: model outputs are validated against typed schemas before they touch a downstream system; tool arguments are validated before execution. A malformed answer is a handled error, not a surprise in your core system.

Tools that fail well: timeouts, bounded retries with backoff, idempotent writes, and circuit breakers on every integration — because your core systems have maintenance windows even if the model doesn't.

Humans on the consequential path: actions with external effect — sending, filing, paying, deciding — sit behind interrupt points with named approvers. The model drafts; a person disposes.

Pinned and re-validated: framework versions are pinned, and every upgrade — routine or CVE-driven — is re-validated against your evaluation set before it reaches production, on the same change-management cadence as a model update.

The commitment

A choice we re-earn, not a marriage.

The same rule we apply to models applies to frameworks.

LangGraph is our current default: of the orchestrators built for stateful, tool-calling work, it has the most production miles, and its primitives fit regulated workflows best. The field is moving — and if a better orchestrator earns the spot, the switch is deliberately cheap: your graph design, your tools' business logic, your evaluation set and guardrails are the durable assets, and they port — the framework bindings are the only thing rewritten — and at handover the whole graph is plain code in your repository. The framework is the one layer of the stack we'd swap without ceremony.

FAQ

Orchestration questions.

Why LangGraph, and not CrewAI, Microsoft's Agent Framework (formerly AutoGen), or an SDK from a model vendor?
Because its primitives — explicit graphs, checkpointing, human-in-the-loop interrupts — map most directly onto how regulated workflows actually run, and it is among the most widely deployed orchestrators in production today. But it's a default we revisit per engagement, not a doctrine — nothing in how we build makes switching expensive. And while model-vendor SDKs will nominally run against any compatible endpoint, their centre of gravity — hosted tools, tracing, evals, roadmap — is the vendor's cloud, which is exactly the dependency we're hired to remove.
Is LangChain actually production-ready?
The framework is; production-readiness is a property of the system around it — the six gaps and the hardening practices above. That layer doesn't come from any framework; it's engineered per system, and it's most of the work.
Will our team need to learn LangChain to operate the system?
To operate it — no; runbooks cover deployment, monitoring and recovery without framework internals. To extend it — some familiarity helps, and the handover includes a walkthrough of the graph, the tools and the tests. The graph definitions are ordinary, readable code in your repository, not vendor configuration — which is also your exit route from us, by design.
How do tools connect to our systems — do you support MCP?
Both natively and via the Model Context Protocol, an open standard for connecting models to tools and data sources. Where an MCP server already exists for a system you run, we can use it behind the same schema-validation and least-privilege discipline as any hand-built tool; where none exists, we write the tool directly. The standard matters less than the wrapper — every tool call is validated, logged and permission-scoped regardless of transport.

Show us your integration map.

Core systems, identity provider, approval chains — one scoping call, and you'll see the graph sketched with the trust boundaries drawn in.