article Building a Production LangGraph Agent on Databricks - NorthStar Brand Copilot in Technical Blog

Building a Production LangGraph Agent on Databricks - NorthStar Brand Copilot

SashankKotta — Mon, 10 Aug 2026 11:43:09 GMT

We built NorthStar Brand Copilot, an AI assistant for brand managers and field-sales reps at a fictional multi-category CPG company (Snacks, Beverages, Personal Care). It's a LangGraph custom agent that routes each question to the right Databricks-native capability:

Genie (NatualLanguage→SQL) for the numbers — sell-in/sell-out, trade-promotion ROI, inventory, market share
AI Search(RAG) for the documents — product specs, allergens, consumer reviews, brand guidelines, the promo playbook
Lakebase (long-term memory) for the decisions, For ex: "remember we cut BOGO (Buy One Get One) at Walgreens," recalled across sessions. This provides a persistent, semantic context layer, ensuring the agent doesn't process queries in isolation but evolves its understanding based on past decisions and specific user history.
LangGraph for agent orchestration. While simpler frameworks (like standard LangChain chains or monolithic agent patterns) are easier to start with, LangGraph was chosen for its superior ability to handle cyclical, complex workflows and granular state management. It allows the agent to reason, refine its tool-calling strategy iteratively, and maintain persistent state, which is essential for enterprise-grade reliability compared to more rigid, linear alternatives.

Note: The CPG organization and data used in this blog post are fictional and intended for demonstration purposes only.

Re: Building a Production LangGraph Agent on Databricks - NorthStar Brand Copilot

DoTA — Wed, 12 Aug 2026 14:38:43 GMT

Great end-to-end write-up — the MLflow tracing setup in particular is a pattern more teams should adopt from day one rather than bolting on later.

One thing worth extending that tracing to: per-node cost attribution. Since every ChatDatabricks call in the LangGraph graph is a separate model invocation, the context window grows with each tool result appended to the message list. In a session where the agent calls Genie + Vector Search + Lakebase in sequence, you're often paying 3–5× what a single-query baseline would suggest — because each tool output accumulates in the prompt for all subsequent steps.

MLflow spans already capture token counts per step. Adding a cost_usd attribute to each span (input_tokens * price_in + output_tokens * price_out) and grouping by session_id gives you a per-conversation cost view that's essential for tuning buffer sizes before you hit production scale.

Two optimizations that help: (1) Summarize each tool response before appending it to the graph state — passing a 50-token summary instead of a 500-token raw Genie result keeps context lean across subsequent nodes. (2) Not all nodes need Sonnet-class reasoning. The routing step (which tool to call?) is usually a simpler classification task than the final answer synthesis. Splitting that to a lighter model and reserving claude-sonnet-4-5 for the final generation step can cut per-session cost 30–50% with no visible quality regression on the routing decision itself.