Ju Lin's AI Weblog

Where MCP Is Headed Next

2026-08-27T00:00:00+12:00

The MCP maintainers published an updated roadmap.

Since March, MCP went stateless (no more session handshakes), turned Tasks into an official extension for long-running work, and shipped enterprise auth pieces like issuer validation and Client ID Metadata Documents.

Next up: one HTTP-native transport instead of separate stdio and HTTP paths, real agent identity (workload federation, token exchange), and progressive tool discovery for large catalogs. No firm dates yet.

MCP is leaving its single-session, request/response origins behind for something built for long-running, multi-agent systems.

What Is an Agent Harness?

2026-08-26T00:00:00+12:00

An oversimplified equation: agent harness = ai agent − model.

Overview

An agent harness is everything in an AI agent besides the model — everything outside the LLM inference call. It’s a piece of software that provides an environment for the LLM to observe and take actions.

The agent harness has a system prompt that defines the LLM’s basic behavior and controls how it puts out tokens.
The agent harness includes a set of tools that the LLM can call.
The agent harness interacts with the LLM to get tokens back.
The agent harness interleaves LLM outputs and tool calls, typically called the agent loop.

The system prompt

Before the user’s message arrives, the harness sends the model a fixed set of instructions: the system prompt. It sets the model’s baseline behavior and constrains how it generates tokens.

Tools

The harness also defines a set of tools the model can invoke: named actions, each with a description of what it does and how to call it. The model doesn’t execute these actions itself — it only requests them.

The model call

The harness communicates with the model through a single interface: it sends a prompt and gets tokens back. That call is the only boundary between the harness and the model.

The agent loop

The harness inspects the returned tokens for a tool call. If one is present, it executes the tool, appends the result to the context, and calls the model again. If not, it returns the output as the final answer. This send-inspect-act cycle is the agent loop.

Agents Should Be Durable, Not Long-Lived

2026-08-26T00:00:00+12:00

A common way to build an AI agent is to treat it as a long-running process. A worker receives a request, enters an agent loop, calls models and tools, waits for results, and eventually returns an answer.

This works well until agents start doing real work.

An agent may spend twenty minutes researching a problem, wait ten minutes for a build, ask a user for approval, or come back hours later when an external job finishes. Keeping a worker alive for the whole run wastes resources and makes failures expensive. A deployment, crash, or machine restart can also destroy work that has already happened.

A better model is to separate the agent run from the process executing it.

The agent run is durable. Its state, messages, tool results, budget, and current position are stored outside the worker. The worker is temporary. It leases a runnable agent, performs useful work for a short period, checkpoints the new state, and disappears.

Conceptually:

Another worker can later continue from the checkpoint.

This does not mean every model or tool call needs its own process. That would create unnecessary scheduling and state-reconstruction overhead. A worker might instead receive a 30- or 60-second lease and execute several agent steps while progress is being made.

The important boundary is waiting.

If an agent needs to wait five minutes for CI, it should not sleep for five minutes. It records that it is waiting and exits. When CI finishes—or a timer fires—the run becomes runnable again.

The same pattern works for rate limits, human approval, scheduled actions, external callbacks, and communication between agents.

This changes how we think about an agent.

Instead of:

one agent = one process

we get:

one agent = durable state
 + a sequence of short compute leases

That model has an interesting scaling property. A system might contain one million active agent runs without needing one million running processes. Most agents will usually be waiting. Only the agents with something useful to do need compute.

There are costs. State must be cheap to reconstruct. Side effects must survive retries without being executed twice. Browsers, shells, and sandboxes may need their own longer-lived services. Streaming also needs to be independent from whichever worker currently owns the run.

But these are infrastructure problems we already know how to solve.

Large web systems stopped assigning a permanent server process to every user long ago. Agent systems may eventually make the same transition.

The useful abstraction is therefore not a short-lived agent.

It is a durable agent with a leased executor.

Training Qwen to Paint Watercolors with Pure RL

2026-08-24T00:00:00+12:00

Surya trained Qwen 3.5 to have taste in watercolor painting. The results are stunning.

It’s purely RL:

The system is a four-step loop, run thousands of times during training.

The model receives a prompt, something like draw a peach hibiscus in watercolour, and writes a complete p5.brush JavaScript sketch. The sketch is rendered in a sandboxed Puppeteer environment, which produces a PNG. The PNG is judged against two random reference paintings sampled from a hand-rated pool, with a separate judge model picking the better watercolour. The judgment is converted into a reward signal, GRPO updates the model, and the loop runs again.

The non-obvious choices live in what is being judged, how the judgment is made, what is in the reference pool, and how the system prompt is written.

I ran into the same problem with pixel art generation. I built a harness around it, and the results still weren’t good enough. A harness can’t save you if the model itself puts out slop. This article shows a good way to fix that for art specifically.

The reference pool isn’t big: 581 AI-generated paintings, narrowed down from 1,664 candidates. The author hand-rated them into “love-tier,” “okay,” and a supplementary batch. The candidates themselves came from Opus 4.6, GPT-5.4, and Gemini 3.1 Pro, iterating against reference photographs under a VLM judge. It’s a niche enough domain that there wasn’t enough human-made reference art to draw from, so the training data had to be manufactured this way.

A few other takeaways:

Don’t do rubric judge, just do pairwise comparisons. The author tried a 1-10 rubric first and the scores compressed near zero. Switching to “which of these two is the better watercolour” opened up the dynamic range.
Just handpick a golden set and compare outputs to a random one from there, instead of a reward model. The 117 love-tier paintings became the comparison pool, and every rollout got judged against those. Training an actual reward model was the next step they never got to.
Simple prompts are better, don’t add too much detailed specs. A long reference doc in the system prompt made the model hallucinate APIs. A short, opinionated allowlist worked better than the full spec, and the generated code compressed from 13,500 tokens to under 2,000.
To do RL on subjective work, you have to author the reward by hand, and then design it carefully enough that it generalises.

Marin 535B-A23B Starts Training, in the Open

2026-08-24T00:00:00+12:00

🚢 Marin 535B-A23B started training this week! As usual, the whole process is open.

Voyage plan: pretraining (80%) + midtraining (20%) on 18.75T tokens on 11 x GB200 NVL72 for ~3 months (2.7e24 FLOPs). Post-training will follow.

Before kicking off the run, we trained a 4-rung scaling ladder from 1.6B-A61M (48B tokens) to 27.7B-A1.2B (926B tokens) to debug issues, and to make a forecast of our hero run. This is by far our biggest run, so definitely expecting the unexpected.

Percy Liang, announcing the run on X.

The Marin project is a great example of being open to AI. The whole process is public: the scaling ladder they ran to debug the pipeline before committing GPU-months to the real thing, the exact token counts, the exact FLOPs, even the admission that they’re “expecting the unexpected” on their biggest run yet.

Most labs treat a run like this as a trade secret until the model ships. It’s great we see another public model build. The last public run at this scale was BLOOM, BigScience’s 176B model. Marin’s 535B total parameters (23B active) puts it well past that, the biggest public pretraining run that I’m aware of.

Four Ways to Teach an AI to Draw a Cat

2026-08-24T00:00:00+12:00

A visual explainer comparing SFT, DPO, RL, and on-policy distillation through the analogy of teaching someone to draw a cat.

What Is Agentic UI?

2026-08-23T00:00:00+12:00

You already know ChatGPT’s style, but it moved away from the old chat interface some time ago. A chat interface works like ping-pong: one message bubble, then another. Agentic UI does not work that way, because it often runs a long process behind the scenes. Between your prompt and the agent’s reply, many details happen. The interface must show you these details.

Here is what I believe agentic UI must give you:

Progress. Show you where the agent stands in the task, not just that it is working.
Tool use. Show you which tools ran and what input each one used.
Direction. Show you if the reasoning is still on track.
Control. If it is not on track, let you stop, redirect, or undo the action.

UI styles

Here lists a few agentic UI styles.

Chat interface. Chat bubbles, streaming responses, expandable tool-call sections, and “thinking” indicators. Example: ChatGPT.
Copilot interface. A sidebar you can show or hide, instead of a full conversational app — a good fit as you evolve an app from non-agentic to agentic. Example: VS Code Copilot.
Canvas interface. Chat on one side, a canvas or file explorer on the other. Must persist artifacts, support versioning, and let you edit them. Examples: ChatGPT Canvas, Claude Artifacts.
Dashboard interface. Built for observability — real-time status, resource usage, queue status, warnings — so you can monitor and steer long-running agents. You can start by building a Grafana dashboard.
Collaborative interface. A chat variant that treats humans and agents as peers, with collaborator badges and multiple roles in one thread. Example: Cumora.
Workflow interface. Node-based graphs, common in creative tools. Example: ComfyUI.
Terminal interface (TUI). Runs fully in the terminal, common for coding agents. Examples: Claude Code, Cursor, Codex, Aider.

UI components

Regardless of style, most agentic UIs draw from the same set of primitive components:

Agent status indicator. Shows the agent’s current state, such as Thinking, Searching, Coding, or Waiting.
Streaming response. Exposes output incrementally as it’s generated.
Reasoning display. A dedicated area for the model’s reasoning, like <think>...</think> output.
Tool use visualization. Shows which tool ran and what input it used.
Approval gate. Pauses for human approval before a risky action runs — human-in-the-loop control.
Scheduled-task card. Asks whether to create a background task that tracks an event.
Compaction. Shown when the conversation nears the context window’s limit.
Completion. Reports what got done, such as “Done: 13 sites checked, 4 options found.”
Error. Handles failures gracefully: tool errors, hallucinations, an aborted plan, or a max-turn limit reached.
Questionnaire. Pops up a short question list when the agent is uncertain, so you can fill in the gaps.
Generative UI. The agent picks a native component, such as a stock quote, weather card, or data chart.
Input. More than a textarea: file select, thinking-level control, model switch, dictation, and send/steer/pause buttons.
Sources drawer. Collects the evidence the agent consulted.
MCP/tool list. Lists the tools and MCP servers available to the agent.

This list will keep growing as people discover fun, engaging agentic UX. I’ll update it every now and then. :P

UI frameworks

A few frameworks stand out for building agentic UI today:

Vercel ai-sdk. The most widely used framework for production web-based agent UIs. It gives you good low-level control, and I use it in my own work. Its generative UI feature is neat.
CopilotKit. Getting popular too. It is built around a protocol called ag-ui.
assistant-ui. It supports multiple backends, such as ai-sdk, ag-ui, and LangChain.
Gradio. Popular for building AI and ML prototypes quickly. You will see lots of Gradio apps on Hugging Face Spaces.
Streamlit. Popular for building data dashboards. It has a simple mental model, but it is hard to extend and cannot expose an API.
Chainlit. It has native LangChain support, an out-of-the-box experience, and little boilerplate.

Neural Network, Explained in Plain Language

2026-08-23T00:00:00+12:00

A six-part visual explainer of how a neural network learns, with animated diagrams for every step.

Linus Torvalds on Debugging the Kernel with AI

2026-08-23T00:00:00+12:00

And this was a debug session from hell, enormously helped by an AI doing much of the grunt-work.

I’d like to call it my tireless helper, but the AI several times stated flat out that this was impossible and unsolvable and that we should just write a report about it.

I suspect those things have been trained by people who may not be quite as stubborn as I am.

But while the AI was ready to give up several times, it did keep adding debug code and analyzing it faithfully when I pushed. So credit where credit is due and I let the AI write the commit message above.

This is basically a one-liner fixing a bogus round_up() to a round_down(), but there were 24 patches adding more and more debug information to this, and 18 kernel boot to finally narrow it down to this. — Linus

Linus Torvalds, in the commit message for a kernel fix.

I troubleshoot every now and then myself, and it’s way harder than programming, tbh. AI can’t always find the root cause. But it’s still a tireless companion to have on-call — it surfaces details I’d have missed on my own, and some of them are the ones that end up pointing the way.

Evals, Explained in Plain Language

2026-08-23T00:00:00+12:00

A visual explainer of how you actually know an AI system got better — not by feel, but by testing and scoring it.

Next Token Prediction, Explained in Plain Language

2026-08-22T00:00:00+12:00

A visual explainer of how a language model writes text one small piece at a time.

ELI5

2026-08-22T00:00:00+12:00

Thariq at Anthropic posted that it’s a skill people there have been using a lot recently: /eli5 <what you want to explain>.

I tried it on neural networks. Here’s what it made.

The first pass had bad colors, low contrast, hard to read. One follow-up prompt asking for a color fix and it was done.

No formulas, no sigmoid, no softmax, none of the math that actually makes a neural network work. It’s missing for good. What’s left is the dataflow — inputs go in, get combined, come out the other end as a decision — drawn simply enough to follow at a glance.

That’s the trade the skill makes, and it’s the right one for someone who isn’t about to read a textbook. eli5 is good exactly because it throws out the complexity most explanations lead with. I imagine this isn’t just for self-learning — it’s a genuinely useful tool for collaboration, communication, meetings. Conveying an idea isn’t easy. ;P

Updated at 2026-08-23. The neural network example is ported to julin.ai now.

AI Engineering SKill Map

2026-08-22T00:00:00+12:00

Andrew Ng’s wrote an AI Engineering Skills Map, which lists six things to learn: LLM foundations, grounding models with data, building agentic systems, evaluation-driven development, operating in production, and machine learning foundations.

As he broke it down, I think the most important skill is learning how to build reliable systems from LLM’s uncertain behavior.

You don’t know in advance what an LLM will output

This is the only only truth you need to take away in this post, if you can’t remember all.

You can’t design AI software the way you design normal software — plan it, build it, ship it — because you can’t plan around an output you haven’t seen yet.

The AI engineering stack is packed with jargons now: MCP, CLI tools, sandboxes, memory and context management, harness, loop, RAG, prompt, multi-agent, (sorry, I cannot name them all, too much). But the core of AI engineering is surprisingly simple:

Build something, observe what it does, evaluate whether that’s good enough, change the weakest part, and repeat.

Pretraining a Mini Kimi K3 for $252

2026-08-21T00:00:00+12:00

Vizuara AI Labs trained a miniature Kimi K3 from scratch: 1.02B parameters, 145M active, 5B tokens, one H200, $252.35.

Not simplifying the architecture like Karpathy’s microgpt, they kept Kimi K3’s MoE and attention design intact.

That’s a surprisingly cheap way to learn pretraining (in real-world). They worked through expert collapse, data-mixing bugs, distributed-training bugs, kernels, and GPU utilization on a modern MoE architecture.

A few things worth noting:

5B tokens is probably too little for a 1B model. The authors agree the run was budget constrained. So the cheap cost might due to the training stopped early.
Beating GPT-2 isn’t particularly meaningful when Mini K3 has roughly 10× the parameters.
MoE at this scale is debatable. A smaller dense model trained on more tokens would likely be better if the goal was capability.

Ju Lin's AI Weblog

Where MCP Is Headed Next

What Is an Agent Harness?

Overview

The system prompt

Tools

The model call

The agent loop

Further reading

Agents Should Be Durable, Not Long-Lived

Training Qwen to Paint Watercolors with Pure RL

Marin 535B-A23B Starts Training, in the Open

Four Ways to Teach an AI to Draw a Cat

What Is Agentic UI?

UI styles

UI components

UI frameworks

Neural Network, Explained in Plain Language

Linus Torvalds on Debugging the Kernel with AI

Evals, Explained in Plain Language

Next Token Prediction, Explained in Plain Language

ELI5

AI Engineering SKill Map

Pretraining a Mini Kimi K3 for $252