donbr

The LangChain Provider Switching Pattern

How to Switch Between LLM Providers in 20 Lines of Code

---

🎯 The Core Pattern

The essential truth about switching LLM providers in LangChain:

donbr

2025 agentic papers

1. Agentic Retrieval-Augmented Generation: A Survey — arXiv, Jan 2025 Why it matters: formalizes “agentic RAG” patterns (reflection, planning, tool use, multi-agent) and maps implementation choices you already teach. Great for framing why orchestration beats “just a better model.” ([summarizepaper.com][1])

2. Reasoning↔RAG Synergy (Survey): Toward Deeper RAG-Reasoning Systems — arXiv, Jul 2025 Why it matters: unifies “reasoning-enhanced RAG” and “RAG-enhanced reasoning,” then spotlights agentic interleaving (search ↔ think loops). Solid taxonomy + dataset links you can fold into eval curricula. ([summarizepaper.com][2])

3. LLM-based Agents in Medicine (Survey) — ACL Findings 2025 Why it matters: a rigorous vertical survey (healthcare) with evaluation tables, safety constraints, and workflow patterns (routing, oversight, audit). Use it as a model for domain-specific agent governance sections in your posts. ([ACL Anthology][3])

donbr

donbr

How to discover A2A agents (code)

1) Direct discovery via “well-known” AgentCard

Most A2A servers expose a public card at a well-known path. (Spec recommends a well-known URL and describes card contents/capabilities.) ([a2a-protocol.org][1])

import httpx, asyncio

WELL_KNOWN = "/.well-known/agent-card.json"  # (spec names vary slightly by version)

donbr

Open Deep Research Observability prompt

Role: You are a senior AI systems observability engineer specializing in multi-agent pipelines and trace analytics. Your task is to help us define what visibility truly means in our LangGraph “Open Deep Research” project, and what we must monitor to make it reliable and explainable at scale.

---

Context:

• We run long-form, multi-agent research graphs composed of supervisor, researcher, compression, and tool nodes.

donbr

donbr

The Authoritative Playbook for uv in Production Teams

This guide is the complete, canonical workflow for managing Python project dependencies using uv. It provides a clear, two-mode approach, production-ready best practices, and drop-in templates to ensure reproducibility, security, and developer efficiency across teams.

Core Concept: The Two Modes of uv

uv operates in two distinct modes. Your team should choose one and use it consistently.

1. Project Mode (Recommended): This is the modern, preferred approach. It's managed by commands like uv add, uv lock, and uv sync, using the cross-platform uv.lock file as the single source of truth for reproducibility.
2. Requirements Mode (Compatibility): This mode mirrors the classic pip-tools workflow and is useful when you need a requirements.txt file for legacy tools or specific deployment platforms.

donbr

uv Project Template Scaffold

This scaffold provides a production-ready starting point for any new Python project, with best practices for dependency management, CI, and collaboration baked in.

Project Structure

my-python-project/
├── .github/
│ └── workflows/

donbr

The Authoritative uv Project Scaffold & Playbook

This repository contains a production-ready Python project starter with uv dependency management, linting, formatting, testing, CI, and contribution guidelines all baked in. It represents a gold-standard foundation for building robust Python applications, designed to eliminate setup friction and enforce quality from the very first commit.

🚀 Rollout Strategy: How to Use This Template

There are three recommended ways to use this scaffold, depending on your team's needs.

1. GitHub Template Repository (Recommended) – For org-wide standards. Create a repository from this scaffold and enable the “Template repository” setting. Team members can then click Use this template to generate new, fully compliant projects instantly.
2. Cookiecutter (CLI-driven Templating) – For parameterized, automated scaffolding. Users can generate a new project by running

donbr

Research Prompt (paste into Claude)

Role & Goal You are an expert DevEx engineer researching best-practice change-management and task-management workflows using Claude Code (CLI & SDK) in real engineering teams as of Sept 22, 2025. Produce actionable guidance I can adopt in a repo that already uses a YAML task plan and a Prefect 3 flow to orchestrate phases/tasks 1:1 (think .claude/tasks.yaml → flows/golden_testset_flow.py).

What to cover (prioritize authoritative sources):

1. MCP configuration & scopes — current, documented best practice for using project-scoped .mcp.json in VCS vs user-scoped/global config; precedence with .claude/settings.json and managed policy files; environment-variable expansion and approval prompts for project MCP. Cite docs.
2. Claude Code settings for governance — permission model (allow/ask/deny), enabling/approving .mcp.json servers, “includeCoAuthoredBy” in commits, relevant env vars (MCP_TIMEOUT, MAX_MCP_OUTPUT_TOKENS)