Decision models give AI agents a way to evaluate defined outcomes without generating an answer as text. The basic interface is straightforward. An application supplies a state, a question, and the possible answers. The model assigns probabilities to those answers, which the application can then use for classification, tool selection, routing, severity assessment, or other decisions. That sounds simple, but the mathematics has consequences across the entire agent system. A binary decision produces a probability that can be compared against a threshold. A categorical decision distributes probability mass across the supplied alternatives. An ordinal decision produces a distribution over ordered levels, from which an expected score can be calculated. These are different output contracts, and each requires different handling by the application. There are also important limitations. Softmax normalization does not guarantee that probabilities are calibrated. A high probability does not establish that a prediction is correct. Changing the available options changes the decision problem, and omitting the correct answer can force probability mass onto incorrect alternatives. Even when the prediction is reasonable, the appropriate action depends on error costs, thresholds, permissions, and escalation policies. I put together a technical handbook on Decision Models for AI Agents, using Drex 2.0 and Drex Max to work through the mathematics and engineering in detail. Drex 2.0 provides a useful implementation reference through its released model weights and runtime. The handbook examines how candidate answers are represented, how hidden-state readouts are used in pointer-head scoring, how logits become probabilities, and how question execution can reuse shared state. Drex Max extends the typed decision interface to images. That introduces another set of problems around image preprocessing, context limits, visual ambiguity, and incomplete evidence. The handbook keeps its documented behavior separate from internal architectural details that have not been publicly established. The material works through everything from first principles => binary, categorical, and ordinal decisions, probability distributions, expected risk, cost-sensitive thresholds, abstention, pointer-head mathematics, temperature scaling, shared-state inference, multimodal inputs, calibration, evaluation, and production failure modes. The explanations include worked mathematical examples, with Drex-specific implementation details grounded in Nace AI's official code and documentation. Sharing the handbook here 👇

You can literally play with fluid dynamics in your browser. Pavel Dobryakov built a real-time fluid simulation that runs on the GPU with WebGL. Click and drag and you can push dye through the velocity field, create vortices, mix colors and watch the flow evolve in real time. The implementation is based on GPU fluid-simulation techniques for the Navier-Stokes equations. No install. Works on mobile too. paveldogreat.github.io/WebGL…

You are lucky if you work with a senior engineer who never makes you regret asking a basic question. You ask something you think everyone else already knows. They explain it without showing off. Then somehow you leave understanding more than what you originally asked. Those people are rare. And you remember them for years.

LLM quantization reduces the precision used to represent model weights, activations and KV-cache tensors. The goal is to reduce memory requirements and data movement while keeping numerical error within acceptable limits. But bit width alone doesn't determine accuracy, memory consumption or inference speed. There are several important engineering decisions. 1./ Quantization formats INT4, INT8, NF4, FP4 and FP8 use different numerical representations. Uniform integer quantization maps values through scales and, optionally, zero-points. Floating-point formats have exponent and fraction fields, while NF4 uses a nonuniform codebook. The same bit width can produce different quantization errors. 2./ Scaling and granularity Quantization can operate per tensor, per channel or per group. Smaller groups can reduce reconstruction error, but require additional scaling metadata and compatible kernels. Rounding and clipping introduce error. Outliers make this particularly important. 3./ Quantization algorithms GPTQ: Uses approximate second-order information to reduce errors introduced by weight quantization. AWQ: Uses activation statistics to identify salient weight channels and protect them during quantization. SmoothQuant: Redistributes quantization difficulty between activations and weights to enable W8A8 quantization. These methods address different aspects of the quantization problem. 4./ Training approaches PTQ: Quantizes an already-trained model, often using calibration data. QAT: Accounts for quantization effects during training, commonly using fake-quantization operations. QLoRA: Keeps a quantized pretrained base model frozen while training low-rank adapters. 5./ Memory accounting For a model with exactly 8 billion weights: FP16 weights = 16 GB Packed INT4 weights = 4 GB One FP16 scale per 128 weights = 0.125 GB Total = 4.125 GB for weights and scales, assuming no additional quantization metadata. KV cache, activations and temporary buffers are separate memory costs. 6./ Storage versus computation A W4A16 model uses 4-bit weights and 16-bit activations. That doesnt necessarily mean the matrix multiplication itself runs in 4-bit arithmetic. Some kernels unpack and dequantize weight tiles before performing FP16/BF16 operations. Accumulation precision is another choice. The actual speedup depends on kernel support, dequantization overhead, memory bandwidth, batch size and workload characteristics. 7./ Evaluation Quantization needs to be evaluated for both model quality and serving performance. Measure held-out task accuracy, numerical stability, time to first token, time per output token, throughput and peak memory under comparable conditions. A 4-bit model isn't automatically four times faster than its 16-bit counterpart. Quantization determines how values are represented. The hardware, kernels and workload determine how efficiently those values are processed.

4 free CUDA resources to learn GPU programming from scratch. 1./ NVIDIA - Modern CUDA C++ Learn GPU programming directly from NVIDIA. Video lectures, slides, and coding notebooks covering parallel algorithms, CUDA streams, and writing your own kernels. github.com/NVIDIA/accelerate… 2./ freeCodeCamp - CUDA Programming 12 hours with Elliot Arledge. Starts with setup and a C/C++ review, then moves into kernels, memory management, matrix multiplication, and custom PyTorch operations. freecodecamp.org/news/learn-… 3./ University of Illinois - Applied Parallel Programming Understand CUDA’s execution and memory models, then work through tiling, reductions, scans, and convolution. lumetta.web.engr.illinois.ed… 4./ University of Oxford - CUDA Programming on NVIDIA GPUs Free lecture slides and practical exercises from Mike Giles and Wes Armour. Covers memory, synchronization, libraries, and programming across multiple GPUs. people.maths.ox.ac.uk/~giles…

Learn Harness Engineering 🚀 Found this excellent open-source course by Walking Labs, covering 14 lectures and 8 hands-on projects on building more reliable AI coding agents. What's inside: → Agent instructions (AGENTS.md / CLAUDE.md) → Context management and persistent memory → Multi-session continuity and state tracking → Task boundaries and scope control → Testing, verification, and observability → Automated agent loops and workflows → Multi-agent orchestration and graph engineering The practical projects walk you through building a complete agent harness, comparing prompt-only execution with structured workflows. Also includes ready-to-use templates, verification scripts, and a harness-creator skill. Perfect for developers working with Claude Code, Codex, and other AI coding agents who want to understand the engineering behind reliable agent execution. Completely free. Here's the GitHub Repo: github.com/walkinglabs/learn…

Somebody just built the Truman Show for a fly.

A geophysicist got laid off, built his own AI job-search system using Claude Code, and landed a job as an AI engineer. 69 tailored applications. 20 first-round interviews. One signed contract. The developer, Mads Lorentzen, has now open-sourced the workflow, and the GitHub repository has already crossed 50,000 stars. Its called AI Job Search, and it handles much more than rewriting resumes. The system uses Claude Code to manage different stages of the job search: → /setup builds a structured profile from your CV, work history, skills, and career preferences. → /scrape searches supported job boards, removes duplicates, and ranks openings by fit. → /apply evaluates a job description and generates a tailored CV and cover letter. → /interview prepares you using the actual job posting and documents you submitted. The application workflow is particularly well designed. A second Claude agent reviews the CV and cover letter in a fresh context, checks them against the job requirements, and suggests revisions. The documents are generated using LaTeX, compiled into PDFs, and checked for layout problems and readable text extraction to improve compatibility with applicant tracking systems. Theres also application tracking, skill-gap analysis, and support for adding custom job portals. The framework doesnt blindly submit applications. You choose which opportunities to pursue, and the current job-board integrations are strongest in Denmark, with options for other markets. One important detail => the repository recommends keeping your personalized setup private, since it contains your employment history and contact information. Fully open source. Here's the GitHub Repo: github.com/MadsLorentzen/ai-…

Richard Feynman called Euler's formula "the most remarkable formula in mathematics." And there's a fascinating engineering reason why this equation is so important. e^(iθ) = cos(θ) + i·sin(θ) It connects exponential functions, imaginary numbers, trigonometry, and rotation through a single mathematical relationship. But its usefulness goes much further. Consider a sinusoidal signal: x(t) = A cos(ωt + φ) Using Euler's formula, we can represent it as the real part of a complex exponential: A e^(i(ωt + φ)) Why would engineers use this representation? Because differentiating e^(iωt) simply multiplies it by iω. Phase shifts can be represented through complex multiplication. For linear, time-invariant electrical circuits in sinusoidal steady state, this allows differential equations to be reduced to algebraic equations. Engineers use this mathematics in phasor analysis, AC circuit calculations, impedance, and frequency-response analysis. The same complex-exponential representation is fundamental to Fourier analysis, signal processing, communication systems, and the study of mechanical vibrations. Feynman also described the complex-plane representation of numbers as the unification of algebra and geometry. And that's what makes Euler's formula so remarkable. An equation connecting imaginary numbers and circular motion provides a practical way to analyze real electrical signals, oscillations, and physical systems.

Someone built an open-source CapCut alternative that AI agents can actually control. 🤯 Its called Concat, and the engineering behind it is pretty impressive. A full video editor built around a native Rust engine, with GPU-accelerated rendering and an API for automated editing. Here's what it supports: → Multi-track editing with keyframes and transitions → Automatic captions using local Whisper models → Text-to-speech and voice cloning → AI background removal → Voice cleanup and audio effects → 4K video export at up to 60 FPS And here's the interesting part. Concat exposes a JSON-RPC API, so scripts and AI agents can create projects, import footage, arrange clips, add titles, and export videos programmatically. The AI models run locally after downloading. Your footage doesnt need to be uploaded to a cloud service. Use it for free, with no subscriptions, watermarks, or account required. Available for macOS, Windows, Linux, and Android. Still in beta, but completely open source under AGPL-3.0. Here's the GitHub Repo: github.com/jub0t/Concat