The long-running agent stack in 2026.

01The shape

The category is no longer "AI agents." The category is the harness — the supervision, verification, and durability layer that turns a model into a worker that can be left running.

Three things settled between Anthropic's December 2025 MCP donation to the Linux Foundation and Microsoft's April 2026 unification of AutoGen and Semantic Kernel. First, the model is commodity — Claude Opus 4.7, GPT-5.5, and Gemini 3.1 Pro all perform within a few percentage points of one another on the long-horizon coding benchmarks. Second, the protocol layer went open — MCP for tool access, A2A for agent coordination, both under foundation stewardship, both with thousands of public servers. Third, the operational concerns that used to live inside each agent framework — durable execution, sandboxes, observability, HITL pauses — have separated into their own layer underneath.

What's left is the harness layer — the system prompts, the tool palettes, the verification logic, the decomposition strategies, the trust tiers, the budget enforcement. As Taskade put it bluntly in March: "2025 was the year of agents. 2026 is the year of harnesses." The frontier moved one level up.

02The four lanes

Thirty-three platforms, grouped by the concern they solve. Filter by lane to narrow the choice, or search for a specific name. Each card carries an honest "watch for" line.

03Protocols deep dive

Two protocols, both under foundation stewardship, both wired into nearly every entry in the four lanes. They are the reason the stack works at all. Architecture, wire format, and a live message simulation for each.

// Client → Server: invoke a tool by name
{
  "jsonrpc": "2.0",
  "id": 7,
  "method": "tools/call",
  "params": {
    "name": "github.create_issue",
    "arguments": {
      "repo": "your-org/your-repo",
      "title": "Agent-test: hello-world article",
      "body": "Drafted by an automated coding agent."
    }
  }
}

// Server → Client: structured result
{
  "jsonrpc": "2.0",
  "id": 7,
  "result": {
    "content": [{
      "type": "text",
      "text": "Issue #142 created"
    }],
    "structuredContent": { "issue_number": 142, "url": "https://..." }
  }
}

{
  "name": "code-agent",
  "description": "Coding agent that opens PRs for assigned tasks.",
  "url": "https://code-agent.example.com/a2a",
  "version": "1.0.0",
  "capabilities": {
    "streaming": true,
    "pushNotifications": true,
    "stateTransitionHistory": true
  },
  "skills": [
    {
      "id": "write_article",
      "name": "Write article and open PR",
      "inputModes": ["text"],
      "outputModes": ["application/json"]
    }
  ],
  "authentication": { "schemes": ["bearer"] }
}

04Concepts deep dive

Twelve concepts every engineer building long-running agents should be able to draw on a whiteboard. Each one carries a definition, a claim about why it matters, a working simulation, and a real code example.

def compact_if_needed(messages, limit=8000):
    tokens = count_tokens(messages)
    if tokens < limit * 0.8: return messages
    # Keep last 4 turns verbatim; summarize the rest.
    head, tail = messages[:-8], messages[-8:]
    summary = claude.summarize(head, style="key decisions + state")
    return [{"role":"system", "content": summary}] + tail

tools = [{
    "name": "get_weather",
    "description": "Get current weather for a city",
    "input_schema": {
        "type": "object",
        "properties": {"city": {"type": "string"}},
        "required": ["city"]
    }
}]
response = client.messages.create(model="claude-opus-4-7",
                                  tools=tools, messages=[...])
# response.stop_reason == "tool_use" → run the tool, return tool_result

with client.messages.stream(model="claude-opus-4-7",
                            messages=[...]) as stream:
    for event in stream:
        if event.type == "content_block_delta":
            print(event.delta.text, end="", flush=True)
        elif event.type == "message_stop":
            break

def run_agent(task, max_iters=50, max_cost_usd=5):
    messages = [{"role":"user", "content": task}]
    for i in range(max_iters):
        resp = think(messages)                  # model call
        if resp.stop_reason == "end_turn":
            return resp.content              # done
        if resp.cost > max_cost_usd:
            escalate("budget exceeded")        # control
        for call in resp.tool_calls:
            result = act(call)                  # run tool
            messages.append({"role":"tool", "content": result})  # observe

def verify(worker_output, done_condition):
    judge = claude.create(
        model="claude-sonnet-4-6",           # cheaper, lower-temp
        system="You judge whether output meets criteria. Return JSON.",
        messages=[{"role":"user", "content": f"""
            Output: {worker_output}
            Criteria: {done_condition}
            Return: {"passed": [], "failed": []}
        """}]
    )
    return json.loads(judge.content[0].text)

@workflow.defn
class ProcessTaskWorkflow:
    @workflow.run
    async def run(self, task_id):
        spec = await workflow.execute_activity(get_spec, task_id)
        plan = await workflow.execute_activity(make_plan, spec)
        result = await workflow.execute_activity(run_agent, plan)
        await workflow.execute_activity(apply_outcome, result)
        # Each activity is journaled. Crash → replay returns cached results
        # for completed activities; resumes at the first incomplete one.

stripe.charges.create(
    amount=5000,
    currency="usd",
    source="tok_visa",
    idempotency_key=f"task-{task_id}-charge",  # client-supplied, unique per intent
)
# Stripe stores the first response by key for 24h.
# Retries with the same key return the cached response — no double charge.

05Voice agents

Voice changes one constraint — latency — and that single change ripples through every architectural choice. The lanes from section 02 still apply. The protocols from section 03 still work. But each component now has to be picked against a 500-millisecond budget.

The shape is familiar: a model, tools, a session. The differences are in the I/O. Audio in becomes audio out. The user expects to interrupt, be interrupted, hold pauses naturally, and never wait more than a beat. A weeks-long agent is allowed to think for ten seconds. A voice agent gets half a second before the human notices and gives up.

Cascaded vs end-to-end.

Most voice agents are cascaded — a chain of specialized models. Voice activity detection finds when the user stops talking. Speech-to-text transcribes. The LLM thinks. Text-to-speech synthesizes. Audio plays back. OpenAI's Realtime API is the prominent exception — a single speech-to-speech model that processes audio tokens directly, no separate STT or TTS. Cascaded gives more control and easier debugging; speech-to-speech gives lower latency and more natural prosody. Sierra, ElevenLabs, Vapi, Retell, LiveKit, and Pipecat all cascade. OpenAI Realtime ships end-to-end. Google's Gemini Live and Anthropic's experimental voice mode sit between the two — partially fused stages.

The latency budget, traced.

The classical 2026 cascaded pipeline sits around 690ms time-to-first-audio on a good day. Swapping in semantic VAD and Cartesia Sonic cuts that roughly in half. Watch each stage's contribution.

Turn-taking and barge-in.

The hardest problem in voice is knowing when the user is done talking. Silence-based VAD is fast but wrong on ambiguous pauses ("I think… yeah, let's do that"). Semantic VAD reads the partial transcript and predicts end-of-utterance from meaning — much harder to fool, slightly slower. Barge-in is the inverse problem: the user starts speaking while the agent is mid-response. The agent must immediately stop playing TTS, cancel the in-flight model call, discard any pending audio, and reprocess from the new user input. Both behaviors are table stakes by 2026.

The voice stack today.

Ten platforms — speech-to-speech models, cascaded agent frameworks, telephony bridges, low-latency TTS layers, and emotion-aware variants. The choice is part latency, part control over each stage, part which surface you ship to (phone, browser, embedded device).

06Prompt, fine-tune, or reinforce

Eight ways to change how a model behaves. Most product companies should only reach for the first four. The other four are where vertical AI lives — Sierra, Harvey, Cursor — and where the foundation labs spend their compute budget.

The training pyramid.

Three layers, each doing different work. Foundation labs train the base model. Vertical AI companies fine-tune for their domain. Product companies compose with prompts and tools. Knowing which layer you're on tells you which paradigms are even available to you, and which ones would be a category error to reach for.

The pyramid is also a cost ladder. Composing with prompts and skills costs hundreds of dollars per month in model spend. Fine-tuning a small open model costs ten thousand for the training run plus serving. Training a frontier model costs hundreds of millions and a custom data center. The economics are why almost no one should train.

The spectrum, end to end.

Eight paradigms from "no weight changes" to "full reinforcement learning with an environment simulator." Click any marker to see what signal it needs, what changes underneath, and when to reach for it.

The RL feedback loop.

Reinforcement learning is the agent's natural training paradigm. An agent acts on the environment. The environment responds with a new state and a reward. The agent's policy — its weights — updates to maximize expected future reward. Repeat for millions of episodes. The structure is identical across game-playing AI, robotics, code-writing reasoning models, and Sierra's customer-retention agents. Only the environment and the reward function change.

Verifiable reward vs preference reward.

The most important distinction in 2026 RL is where the reward comes from. RLVR is having the better year because verifiable signals — tests passing, programs running, math being correct — give you objective gradients without a learned reward model in the loop. RLHF still rules for open-ended generation where "good" is subjective.

When training actually kicks in.

A practical flow for product companies. Most of the questions resolve to "no" — that's the entire point.

1. Can prompts + skills + RAG get you 90% of the way?

   If yes: ship. Iterate. Most product agents fit here. The rest of this list is a distraction for you.

   → stay in tier 3, the product layer

2. Is per-call inference cost or latency a bottleneck?

   If yes: distill. Train a small open model (Llama 4 8B, Qwen 3 7B) to mimic your prompt-engineered behavior. Don't train from scratch — distillation is cheap because the labels come from your large model's outputs.

   → distillation, sometimes SFT

3. Is behavior brittle across runs even with strong prompts?

   If yes: SFT on 500–1,000 carefully labeled examples. Dramatic consistency gains for a one-time engineering cost in the thousands, not the millions.

   → supervised fine-tuning

4. Is "good" subjective and only obvious post-hoc?

   If yes: DPO on preference pairs collected from your real traffic — chosen-vs-rejected. Cheaper and simpler than full RLHF, and the 2024-2025 papers showed it's competitive on quality.

   → direct preference optimization

5. Is the signal automatically verifiable?

   If yes: RLVR with a verifier function. This is how every reasoning model in 2026 was trained — let the model attempt, let the verifier judge, update the policy. Works for code, math, structured-output tasks, anything with a deterministic grader.

   → RL with verifiable rewards

6. Is it a multi-step task with sparse rewards in a real environment?

   If yes: deep RL with PPO or GRPO. Be warned: you probably don't have an environment simulator, and building one usually costs more than the training run. Reserved for game-playing, robotics, and a handful of specialized agentic benchmarks.

   → full deep RL (rare in product work)