Ju Lin's AI Weblog: Agents

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.

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.