In today’s newsletter:
Building a durable multi-agent system with LangGraph and LangSmith.
Jev for Agent Memory, clearly explained.
The AI engineering master stack for 2026!
Building a durable multi-agent system with LangGraph and LangSmith
Parts 5 and 6 of our hands-on Agent Engineering course are now available.
Part 5 turns the verified agent loop into a team of parallel specialists. Part 6 adds the controls needed to keep that team running across restarts, approvals, graph changes, and releases.
Together, they cover:
Parallel specialist workers with scoped, read-only tools
Reducer-backed shared state, deterministic merging, and independent review
Postgres checkpoints, expiring approvals, and a queryable audit trail
Graph versioning, LangSmith evaluation gates, and an authenticated streaming API
Why care?
Building an agent that can call tools is one engineering task. Operating several agents as one reliable system requires a broader set of skills.
Once workers run in parallel, shared state becomes a concurrency problem. Each worker needs private loop state, concurrent writes need reducers, and the final merge must remain deterministic. A failed worker must become an explicit partial result instead of blocking the entire investigation.
Durability introduces a different class of problems. A run may pause for approval, lose its process, and resume elsewhere hours later.
That requires synchronous checkpoints, persistent interrupts, expiring approvals, and an atomic decision so approval, rejection, and expiry cannot resume the same thread twice.
Deployment adds change-management and security concerns. A paused thread created on yesterday’s graph must remain compatible with today’s code.
Prompt changes need behavioral evaluations because deterministic unit tests cannot detect every regression. Identity must come from authentication rather than the request body, and tenant boundaries must hold across every endpoint.
These are the same system-design concerns found in backend, platform, and agent-infrastructure roles: concurrency semantics, durable workflows, authorization, observability, compatibility, and release safety.
For a developer who already understands tool calling and basic LangGraph workflows, Parts 5 and 6 clarify the difference between framework familiarity and production system design.
Being able to explain why a state key needs a reducer, how a paused run survives a deployment, or why an evaluation gate catches failures that unit tests miss is a stronger signal than another agent demo.
👉 Over to you: Which production guarantee is still missing from the agent systems being built today?
Jev for Agent Memory, clearly explained:
An agent-memory system often passes conversations, tool results, and task outcomes through an extractor.
The extractor identifies possible memories such as user preferences, facts, and procedures.
Consider a travel assistant booking a flight.
The user says:
I usually prefer an aisle seat.
For this flight, book a window seat.
The flight is delayed by 25 minutes.
An extractor may identify all three as facts. Saving all three to long-term memory would be a mistake.
The aisle-seat preference could help with future bookings.
The window-seat request applies only to this flight. Saving it as the user’s latest seat preference could make the next booking wrong.
And the delay is useful during the trip. It has no value once the flight is over.
The extractor can identify what the user said, but it does not necessarily know how long the fact should live or where it should apply.
Jev can run here before the application writes anything to memory.
For each candidate, the application gives Jev the proposed fact, its source evidence, and the current user, trip, and session state.
The application can ask Jev typed questions such as:
Does the evidence support this fact?
Does it apply outside the current trip?
Should it be stored for the user, the trip, or only the current session?
How likely is incorrect reuse to cause a bad booking?
Jev returns choices, scores, and probabilities.
Application code then applies explicit rules. For example:
↳ Save the aisle-seat preference for the user.
↳ Attach the window-seat request only to this trip.
↳ Keep the delay in the current session and remove it when the trip ends.
Only the approved candidate memories are sent to Graphiti as episodes.
Graphiti keeps the original episode, extracts entities and relationships, resolves new facts against the existing graph, and records when facts become valid or invalid.
GitHub repo: https://github.com/getzep/graphiti
(don’t forget to star it ⭐ )
In code, Jev runs before the call that adds an episode to Graphiti.
If a candidate passes the threshold, the app writes it to Graphiti with the appropriate scope and source. If it fails, the application can keep it in the current session or discard it.
Graphiti still handles ingestion, entity resolution, temporal updates, and retrieval. Jev only evaluates the proposed memory before that ingestion begins.
This way, fewer temporary instructions and expired updates enter the set of facts that later agent runs can retrieve.
The diagram shows the write flow:
Agent activity produces candidate memories.
Jev evaluates each candidate using its evidence and scope.
Application rules decide whether and where to store it.
Graphiti maintains the accepted memory.
That said, Jev becomes more useful when the same typed decisions sit inside a complete agent loop. Parts 3 and 4 of our Agent Engineering course implement that system end to end:
Part 3: Build routing, guardrails, and approval controls with LangGraph and Jev →
Part 4: Add planning, verification, replanning, and stopping logic →
The AI engineering master stack for 2026!
We prepared this AI engineering master stack that covers ten layers from the model itself to running it safely in production:
Here’s what each layer comprises:
1) Foundations set how the model represents input through tokens, embeddings, transformer, attention, context window, positional encoding, and mixture of experts.
2) Model behavior covers how a trained model responds through pretraining, post-training, sampling, temperature, reasoning models, multimodality, and test-time compute.
3) Prompt engineering shapes the output through the prompt alone using system prompts, few-shot, chain-of-thought, structured outputs, prompt caching, self-consistency, and meta-prompting.
4) Retrieval feeds the model data it was never trained on through chunking, vector databases, hybrid search, reranking, retrieval eval, query rewriting, and GraphRAG.
5) Agents let the model take actions instead of only answering through function calling, ReAct, planning, reflection, multi-agent, computer use, and human-in-the-loop.
6) Context engineering controls what fills the context window across steps through context management, compaction, memory, MCP, agent harness, just-in-time retrieval, and structured note-taking.
7) Fine-tuning changes the weights when prompting and context fall short through SFT, LoRA, RLHF, DPO, distillation, GRPO, and RLVR.
8) Inference optimization makes the model cheap and fast to serve through quantization, KV cache, batching, speculative decoding, vLLM serving, FlashAttention, and PagedAttention.
9) Deployment turns models into services through serving engines, model routing, semantic caching, streaming, load balancing, autoscaling, fallbacks, and on-device inference.
10) Evaluation measures whether the system is actually correct through benchmarks, LLM-as-judge, golden datasets, hallucination detection, regression tests, trajectory evaluation, and red teaming.
11-12) LLMOps and safety keep the system reliable and safe in production through observability, cost tracking, guardrails, PII redaction, feedback loops, prompt injection defense, and model routing.
13) Frontier patterns include decision models, harness engineering, loop engineering, recursive and contrastive LMs, verifier engineering, WebMCP, and forkable agent runs.
This grid above is the overview, but each layer is deep enough to be its own field with dedicated tooling.
We have covered every bit of it in the LLMOps course, starting from fundamentals to production:
Read Part 2 on understanding the core building blocks of LLMs →
Read Part 3 on the key components of LLMs, focusing on the attention mechanism, architectures like transformers and mixture-of-experts, and the fundamentals of pretraining and fine-tuning →
Read Part 4 on decoding strategies, generation parameters, best practices, and the broader lifecycle of LLM-based applications →
Read Part 5 on context + prompt engineering from a system perspective, in-context learning, types of prompts, and different prompting techniques →
Read Part 6 on prompt versioning, defensive prompting, and techniques like verbalized sampling, role prompting, and more →
Read Part 7 on context engineering, covering context types, context construction principles, and retrieval-centric techniques for building high-signal inputs →
Read Part 8 on memory, dynamic, and temporal context in LLM systems, covering short and long-term memory, dynamic context injection, and common failure modes in agentic applications →
Read Part 9 on evaluation methods and approaches for LLM-based applications, primarily focusing on building a strong understanding of the fundamental concepts →
Read Part 10 on evaluation benchmarks in LLM applications, with task-specific methodologies, and the core tooling for evaluation of LLM apps →
Read Part 11 on evaluation of multi-turn systems, tool use evaluations, tracing, and red teaming →
Read Part 12 on LLM fine-tuning, parameter-efficient methods like LoRA and QLoRA, and alignment techniques such as RLHF, DPO, and GRPO →
Read Part 13 on LLM inference optimization, KV caching, PagedAttention, FlashAttention, speculative decoding, and model parallelism →
Read Part 14 on the fundamentals of LLM serving, including API-based access, inference with vLLM, and practical decisions.
👉 Over to you: What else would you add to the master tree?
Good day!