loading
loading
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: Multi-agent orchestration with LangGraph → - Part 6: Durable Agents with LangGraph and LangSmith → 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. - Learn to orchestrate parallel specialists safely in Part 5 → - Learn to make agent runs durable and deployable in Part 6 → 👉 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: 👉 Over to you: What else would you add to the master tree? Good day!
document fetched 2026-10-24 10:04