Skip to content

Instantly share code, notes, and snippets.

Multi-Model AI Development Pipeline

Opus 5.5 Planner → Sonnet 5.5 Builder → v6 Daybreak Reviewer

Concept Document
A specialized multi-agent system that routes work across complementary models: Anthropic Claude for planning and building, and an OpenAI v6 Daybreak-class model for rigorous review.


1. Overview

Multi-Model AI Development Pipeline

Opus 5.5 Planner → Sonnet 5.5 Builder → Fable 5 Reviewer

Concept Document
A specialized multi-agent system that routes work across Anthropic Claude models according to their complementary strengths.


1. Overview

SOP: Observing Grafana + Prometheus Metrics in Datadog

Overview

Datadog can scrape any Prometheus / OpenMetrics endpoint using the Agent’s OpenMetrics check (recommended) or the older Prometheus check. This lets you:

  • Ingest the custom LangChain metrics you already expose via prometheus_client (langchain_llm_*, etc.).
  • Ingest Prometheus’s own operational metrics.
  • Ingest Grafana’s metrics (if enabled).
  • Correlate everything with Datadog APM, LLM Observability, and infrastructure metrics.

SOP: Integrating Grafana + Prometheus with LangChain / Langfuse for Observability and Metrics

Overview

Langfuse provides excellent LLM-specific tracing, evaluations, and prompt management. It does not natively export Prometheus metrics. This SOP covers practical ways to add operational metrics (latency, request rate, errors, tokens, cost) and visualize them in Grafana, while keeping Langfuse as the source of truth for detailed traces.

Three complementary approaches are supported:

  1. Custom prometheus_client instrumentation via LangChain callbacks (recommended primary path).
  2. OpenTelemetry traces → span_metrics connector in an OpenTelemetry Collector → Prometheus.
  3. Direct SQL queries against Langfuse’s backing databases (Postgres / ClickHouse) from Grafana.

OmniRAG — Multi-Tenant RAG Chatbot: Detailed Specification

Oct 6, 2026 · @Tom T

1. Purpose and scope

OmniRAG is a self-hostable, multi-tenant chatbot that answers questions from each tenant's own documents, using any LLM provider. This spec expands the preliminary OmniRAG specification into buildable requirements: every requirement has an ID, a priority and a testable acceptance criterion.

In scope for v1: ingestion of PDF, Markdown and HTML files, single web pages and Wikipedia articles; chunking, embedding and per-tenant vector storage; retrieval-augmented chat with source citations; six LLM providers (Ollama, Groq, OpenRouter, OpenAI, Anthropic, xAI); session-scoped chat memory; a FastAPI backend and a Streamlit UI.

£10 to Cash: Resale Business SOP

Capital rule: £10 once. No further money in. Growth comes only from retained profit.
Goal: A repeatable weekly cash loop, then a service offer that does not depend on finding underpriced stock.

This SOP is the operating manual. Follow it in order. Do not skip the buy rules.


1. Purpose and constraints

GitHub Afternoon / Weekend Port Shortlist

Use this list when you want a real, finite modernization exercise: pick a source repo, choose a clear “from → to” stack, and treat the old app as the spec + golden oracle. Afternoon picks fit a focused 2–4 hour AI-assisted strip; weekend picks need incremental slices (UI shell → core domain → edge cases) across ~8–16 hours. Prefer fork-and-port (new repo, preserve attribution) over drive-by PRs unless maintainers invite rewrites. Star counts and activity below were verified from public GitHub pages / raw files on 2026-10-01 (BST / Europe/London) and will drift.


Selection criteria

Band Time Typical size Fit

Database Tables Breakdown

OpenEMR tables for the Clinical Co-Pilot: medications, allergies, encounters, lab results, and changes since the last visit

Codebase Gauntlet-HQ/openemr-base-clean (OpenEMR 8.2.0, database version 541)
Database MariaDB (mariadb:11.8 in docker/development-easy), schema openemr
Verified Every SQL query, the Python module, and the JavaScript module in this document were run against a database built from this repo's sql/database.sql and seeded with the synthetic test patient in Appendix A

Software Factories — FAQ

Frequently asked questions about building an agentic software factory, answered against a real one: ashtilawat/minimum-viable-factory. Every answer cites file and line numbers so you can read the thing being described instead of taking my word for it.

The one sentence the rest of this document defends:

Right now you are the orchestrator. A factory is what happens when you write that role down as code.

The Dining Philosophers Problem Set

Introduction

Conceived by Edsger Dijkstra in 1965, the Dining Philosophers Problem is a classic thought experiment in computer science. It was designed to illustrate the complex challenges of synchronizing multiple processes (or threads) that must share limited resources without communicating directly.

The Setup

Imagine a circular dining table. Seated around this table are five philosophers.

  • The philosophers spend their lives alternating between two distinct activities: thinking and eating.
  • In the center of the table is a large bowl of infinite spaghetti.
  • There are exactly five forks placed on the table, one between each philosopher.