Typed shared state
Every step reads and writes a defined state object: the conversation, retrieved documents, tool results, flags and counters. State can be saved after each step, so a run can pause, resume or be replayed for debugging.
AI Agents · LangGraph
Agents as explicit graphs.
State you can inspect, steps you can test.
LangGraph models an agent as a graph of steps that share a typed state: call a model, run a tool, check a result, ask a person, try again. We use it when an assistant has to take several actions in order, recover from errors and stop for approval, and when the team needs to see exactly why it did what it did.
A specialist practice of MLAIA Data ScienceLed by Dr. Yochai Edlitz · Ph.D., Weizmann Institute
Why a graph, not a loop
A free-running loop is easy to demo.
A graph is easier to operate.
The simplest agent is a loop: the model picks a tool, reads the result and repeats until it decides it is done. That works in a demo and becomes hard to control in production, where some steps must always happen, some must never happen without a person, and every failure needs a defined next step.
In a LangGraph design, the routes between steps are code. The model still decides what to say and which tool to call, but the graph decides what is allowed next. This is the same principle we apply across the AI Agents practice: deterministic structure where the process is known, model judgement where it adds value.
Tool calling with limits
Tools are typed functions with validated inputs. We cap tool calls per turn, set timeouts and decide what the agent says when a tool fails, instead of letting it guess.
Human-in-the-loop steps
Consequential actions, such as sending, booking, refunding or changing a record, stop at an approval node. The person sees the proposed action and its inputs, then approves, edits or rejects it.
Branches, retries & fallbacks
Conditional edges route by intent, confidence or tool outcome. A failed retrieval can trigger a rephrased search; a low-confidence answer can route to a person rather than to the user.
Multi-agent only when it helps
A supervisor with specialised sub-agents can help when tasks really differ, but each extra agent adds latency, cost and failure modes. We start with one well-scoped graph and split only when evaluation shows a gain.
Streaming to the interface
Graph events stream to the client as they happen: partial text, tool starts and results, and approval requests. Users see progress, and voice front-ends can start speaking the first sentence early.
Quality you can measure
Evaluate the steps,
not only the final answer.
An agent can reach a correct answer by a wrong route, or a wrong answer through one bad tool call. We build an evaluation set from representative tasks and score both the outcome and the path.
Task success
Did the run finish the task the user asked for, within the permitted actions? Scored against expected outcomes for each test case.
Tool-call correctness
Right tool, valid arguments, no unnecessary calls. Most production regressions show up here before they show up in answers.
Grounding
For answers drawn from documents, whether each claim is supported by the retrieved sources, and whether the agent says it does not know when nothing relevant was found.
Latency & cost per run
Model calls, tokens and wall-clock time for each test case, tracked as prompts, models and graphs change.
Typical stackLangGraphLangChain toolsClaude, GPT & Gemini modelsAmazon BedrockLangSmith or OpenTelemetry tracingPostgres & pgvectorFastAPI services
What we have built
Agents that take actions,
with the safeguards around them.
Our recent work includes a voice-and-avatar assistant for a healthcare app, currently in development. It runs Claude on Amazon Bedrock with around twenty tools, caps tool calls and time per turn, streams the reply one sentence at a time, and never applies a settings change until the user confirms it on screen.
Earlier, we built and ran a self-serve website chatbot product: it crawled a customer's site, indexed it for retrieval, answered in Hebrew or English and captured leads through a separate tool-calling agent. The lessons from both carry into every agent we design: scope the tools tightly, keep exact values such as dates and amounts out of free-text generation where possible, and log what the agent did without logging what users said.
We describe client projects in general terms. Details are shared in conversation, subject to confidentiality.
A practical delivery path
From one workflow
to a production agent.
Map the workflow
List the steps, systems, decisions and the actions that need approval. Agree on what success looks like for each task.
Build the evaluation set
Collect representative requests, expected outcomes and known edge cases before tuning prompts.
Graph & tools
Implement the graph, tools and approval steps; measure against the evaluation set and fix the worst failures first.
Deploy & observe
Ship behind access controls with tracing, cost limits and alerts. Re-run the evaluation whenever a model or prompt changes.
Before we start
Good questions. Straight answers.
When is LangGraph the right choice over a simple chain?
When the assistant has to take several actions in order, recover from failures, pause for a person or resume later. For a single retrieval-and-answer step, a simple chain or a direct API call is easier to maintain.
Can a LangGraph agent run on our own cloud?
Yes. The graph is ordinary Python, so it runs in a container or serverless function on AWS, Azure or Google Cloud, or on your own servers, with any model your policies allow, including models through Amazon Bedrock.
Which model should the agent use?
We test candidate models on your evaluation set and compare success rate, latency and cost. Often a smaller, faster model handles routing and simple steps while a stronger model handles the hard ones.
How do you stop an agent from taking a harmful action?
Tools only do what their code allows, inputs are validated, and consequential actions stop at an approval step. The agent cannot reach systems it was not given a tool for.
Can it work in Hebrew?
Yes. We have built assistants that work in Hebrew and English, including retrieval over mixed-language content. Hebrew needs its own test cases, because tokenisation, search and model behaviour differ from English.
Keep exploring
Related reading & tools.
AI Agents & Voice Agents · LangGraph Agents
Tell us what
you’re working on.
Share the problem, the data you have and what success would look like. We’ll discuss a practical next step.
Please don’t include confidential datasets, credentials or patient information.