Typed shared state
Saved after each step, so a run can pause, resume or be replayed.
LangGraph development
Agents as explicit graphs.
State you can inspect, steps you can test.
Agents built as a graph of steps: call a model, run a tool, ask a person, retry. For assistants that act in order, recover from errors and stop for approval.
Ultrabot, built by 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.
A free loop works in a demo. In production, the model picks what to say and which tool to call, but the graph decides what is allowed next. Fixed structure where the process is known, model judgement where it helps. More on what an Ultrabot agent does.
Tool calling with limits
Validated inputs, caps per turn, timeouts, and a defined reply when a tool fails.
Human-in-the-loop steps
Sending, booking or refunding waits for a person to approve, edit or reject.
Branches, retries & fallbacks
A failed search is retried; an unsure answer goes to a person, not the user.
Multi-agent only when it helps
Each extra agent adds delay and cost. We split only when tests show a gain.
Streaming to the interface
Users see progress as it happens, and a voice can start at the first sentence.
Quality you can measure
Evaluate the steps,
not only the final answer.
We score both the outcome and the path, on a set of real tasks.
Task success
Did it finish the task, within the allowed actions?
Tool-call correctness
Right tool, valid arguments, no extra calls.
Grounding
Every claim backed by a source, or an honest "I don't know".
Latency & cost per run
Tracked on every change to prompts or models.
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.
A voice-and-avatar assistant for a healthcare app, currently in development: Claude on Bedrock with about twenty tools, capped per turn, and no settings change without on-screen confirmation. Earlier, a self-serve website chatbot that answered in Hebrew or English and captured leads. The lesson from both: tight tools, and log what the agent did, not 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
Steps, systems, approvals, and what success means.
Build the evaluation set
Real requests and edge cases, before tuning prompts.
Graph & tools
Build, measure, fix the worst failures first.
Deploy & observe
Tracing, cost limits and alerts, re-tested on every change.
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.
Talk to a person
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.