Wrote my first RL environment this evening. A very simple on, mind, but 'verifiers' (by @PrimeIntellect and @willccbb) makes it very easy to slot in the pieces.

I'm now transitioning from the part of my agentic RL exploration where I learned the high-level concepts to seeing what people are doing in practice.

Whenever a frontier lab drops a new model you always see their employees posting things like "you’ll be surprised by how good we made our new model! throw your hardest problems at it".

Doing a bit of a self-study RL course at the moment and one of the really useful tweaks I always have my 'teacher' do is to revisit the early FastAI lessons from @howard.fm and to really live up to those invitations to make things interactive, to get a sense for how things work intuitively.

Published a new post on our Kitaru adapter for Claude Agent SDK. Claude owns the agent loop. Kitaru records the completed invocation as durable workflow state: result, artifacts, waits, and replay boundary. One completed invocation = one checkpoint.

OpenAI Agents SDK is a great harness. When you move your agent to production, you're probably going to need and want more. That's where Kitaru comes in... We build an adapter so you can keep your OpenAI Agents SDK code, but throw in some durability and other goodies on top.

Had fun chatting with Hamza for this CNCF webinar last week, all about Kitaru, durable agent harnesses + agent runtimes. The video is embedded in the link in the thread. If you have agents in production and are experiencing growing pains around the runtime layer of the stack, we'd love to talk!

Just made a bumper release this evening: 25 new format adapters covering the major cloud annotation platforms, autonomous-driving and aerial datasets, document layout, synthetic data, and the long tail of academic/community formats.

"Your Harness, Your Memory" by Harrison Chase argues that memory belongs inside your agent harness, not behind a third-party API. We've been building exactly that, and Kitaru 0.4.0 shipped it this morning. kitaru.ai/blog/kitaru...

We just shipped migration skills to allow you to migrate off 11 ML/data platforms to ZenML: Airflow, Argo, AzureML, Dagster, Databricks, Flyte, Kedro, Metaflow, Prefect, SageMaker, Vertex AI. Each has hand-curated concept maps baked in showing what maps 1:1 and what needs redesign.

I've been building panlabel — a fast Rust CLI that converts between dataset annotation formats — and I'm a few releases behind on sharing updates. v0.3.0: Hugging Face ImageFolder support v0.4.0: auto-detection UX overhaul + Docker

Last month I migrated our ZenML website from Webflow to Astro in a week during a Claude Code / Cerebras hackathon. 2,224 pages, 20 CMS collections, 2,397 images. The site you see now is the result. Didn't win the hackathon but got a production website out of it, so I'll take that trade.

panlabel 0.2 is out. It's a CLI tool (and Rust library) for converting between different dataset annotation formats. Now also available via Homebrew.

I've been trying to push myself to use Codex Spark more, mostly because the speed changes the workflow in ways I'm still wrapping my head around.

This, all weekend long. #antidote www.youtube.com/watch?v=5vK...

If your product doesn't have an MCP server or public API in 2026, you're legacy software. I've noticed a shift in how I filter tools now. I'm basically only reaching for products that are AI-native i.e. whether I can integrate them into my AI-assisted workflows.

There's a lot to be gained from dual-model workflows for agentic engineering. Claude Code to take a first pass, Codex to review. Or 5.2-Pro to make a detailed plan and then Sonnet to implement.

If you've copied or downloaded a ChatGPT Deep Research report as markdown, you'll have noticed that they include all sorts of gunk in the file that you don't want. Here's a skill and a script that strips all that stuff out. (Also OpenAI please just fix this 🙏) github.com/strickvl/sk...

New blog post: running Recursive Language Models in production with ZenML. www.zenml.io/blog/rlms-i...

A break from the usual programming (pun intended). Over the past few weeks I've been building something that has nothing to do with ML pipelines or developer tooling: a macOS menu bar app called Felt that sends gentle prompts throughout the day inviting you to notice what's happening in your body.

How do ML teams actually share GPU clusters when demand outstrips supply? Three dominant allocation models keep appearing:

What does a minimum viable "grown-up" GPU governance stack actually look like?

There's an assumption baked into GPU governance discussions: make utilisation visible and people stop hoarding.

I've been digging through infrastructure talks and case studies trying to answer a simple question: How are companies scheduling GPU resources for long-running AI agents?

Most GPU scheduling advice assumes you have "1 problem." You don't. You have 2 variables: Job shape: high-frequency small jobs vs low-frequency mega jobs Scarcity level: mild (queues annoying) vs severe (demand blocks roadmaps) If you're in the EU, you're probably starting in severe by default.

When the governance layer is missing from your ML compute stack, the platform lead becomes the human scheduler.

I've been writing about GPU scheduling all week. Governance, queuing models, preemption contracts, the human politics of who gets the big slot. But there's a variable I've mostly treated as fixed: the capacity itself.

We often run little experiments at ZenML and a recent one is that we built an ambient agent that connects to your ZenML server (read-only), quietly monitors what's going on, and surfaces what matters.

Hoarding is rational in an unfair system. That sounds like an excuse. It's actually a diagnosis. When ML teams "hoard" GPU allocations they don't fully use, they're not being greedy. They're responding to a system that punishes them for being efficient.

The organisations that get GPU scheduling right share a few practices. They're less about picking the right tool than about designing the right rules.

GPU scheduling looks like a technical problem. It's actually an org design problem wearing infrastructure clothes. The queue is just where the politics become visible. Here's what I mean:

European ML teams face a GPU problem that American teams can often avoid: even when the cloud has capacity, sovereignty and regional constraints mean you can't just move to another region. The result? Europe develops explicit governance systems earlier. The US can defer.

When your GPU cluster gets "busy," most teams blame contention. But the ugliest failures usually come from something else: your queue and your resource pool drift apart.

The same GPU queue looks completely different depending on your role. That's why "just add priority levels" rarely sticks. Queue prioritisation is a coordination problem between people who measure success differently. Here's how the queue problem feels across the org: FINANCE / FINOPS:

When GPU demand starts exceeding supply, organisations face a governance problem more than a scheduling one. And most teams end up walking through the same three phases, often without realising it.

I went down a rabbit hole this evening, starting with GPU scheduling and queue prioritisation—trying to understand how teams handle competing workloads when compute is scarce.

Worked on a little tool called Zenlings this weekend. The idea: you open a broken (ZenML) pipeline, fix it, and a CLI running in your terminal watches your changes and tells you if you got it right. Then you move on to the next exercise.

Been working through what "dynamic pipelines done right" looks like in practice. The key insight: separate what the *framework* should control from what the *agent* should control. In ZenML's dynamic pipelines, responsibilities split cleanly:

Built a Rust CLI + SDK for the Ravelry API this weekend. Ravelry is a social network for knitters and crocheters — 10M+ users sharing patterns, logging yarn stashes, tracking projects. My wife crochets and knits, and we wanted programmatic access for some tooling ideas.

This evening working on updates to tinbox (my automated translation tool for books with slightly more sophisticated algorithms for handling page transitions across PDFs etc and very long texts).

These two are at the top of my reading pile for the coming weeks. Happy to get them in the post today from Manning after a little wait!

Yesterday I was skeptical about dynamic pipelines. Today: where they actually make sense.

I've been thinking about dynamic pipelines lately, where the DAG structure emerges at runtime instead of being defined upfront.

As promised yesterday — here's the demo of the two ZenML MCP apps I built the day Anthropic launched MCP Apps. What you're looking at:

I spent part of today building two ZenML MCP apps on the day Anthropic launched MCP Apps — the first official MCP extension. Interactive UIs that render inside the conversation. Day-one notes on what it's actually like to build one:

ZenML just shipped our first Agent Skill: Quick Wins. I originally wrote our Quick Wins docs page as a collection of 15 things you can do in ~5 minutes to make your ZenML pipelines more robust. It's always been a sleeper hit.

Sunday. Sentimental Value. Fifth time’s a charm.

Apparently time for my yearly repost of this line from 'Halt and Catch Fire'. Perhaps more relevant in 2026 than last year.

YouTube used to allow you to search/filter the videos you received when searching by upload date. i.e. I want to see the most recent videos over 20 minutes on a particular topic or keyword. No way to do that any more. 😓

Two case studies (both now in the ZenML LLMOps Database) came out this month that caught my attention. AutoScout24 (Europe's largest car marketplace) and Thomson Reuters both published detailed write-ups on how they're building internal platforms for AI agents.