Four_Platforms,_No_Coordination

In the span of about four months this year, four platforms shipped the same underlying move without any visible co-ordination between them. Microsoft folded AutoGen and Semantic Kernel into a single production SDK on 3 April 2026 - Agent Framework 1.0, combining Semantic Kernel's session-based state management, type safety and telemetry with AutoGen's multi-agent conversation patterns (group chats, handoffs, reflection loops), with both prior projects placed in maintenance mode. Amazon made Bedrock AgentCore's declarative harness generally available on 18 June 2026, then shipped Loom on top of it three weeks later (InfoQ corroborates independently). Alibaba Cloud introduced Agent Native Cloud, including a product called AgentTeams, at WAIC in Shanghai on 18 July 2026. And the Model Context Protocol itself published a stateless, extensions-first specification as a release candidate on 28 July 2026 - not yet a ratified final spec - adding Tasks and MCP Apps as first-class primitives to the core protocol rather than bolt-ons.

One date needs correcting before any of this means anything. Bedrock AgentCore is not new. The platform went generally available in October 2025 - nine months before the harness update above, and coverage that treats AgentCore itself as a July announcement is describing the wrong layer. What's actually new in the June and July window is the declarative harness sitting on top of the existing platform, and Loom, the open-source reference platform AWS built to govern identity and approvals for whatever runs through it. Amazon's own account of the adoption curve is specific on this point: agent task volume on AgentCore grew fifteen-fold in six months, reported at AWS Summit New York in June 2026 alongside customer references including Nasdaq, Visa and Experian. That's a real number attached to a real platform, not a launch-week vanity metric - which is exactly why the harness and Loom, arriving on top of nine months of production load, are worth taking seriously rather than filed as more vendor noise.

LangGraph belongs in the same account, even though it arrived earlier. It reached 1.0 in October 2025, and durable execution state plus a first-class API for pausing a run for human review shipped as baseline features at that release - a restart or a long interruption picks the run back up rather than losing it. The officially maintained langchain-mcp-adapters package, built and maintained by langchain-ai's own organisation, converts MCP tool schemas into graph-native tools, so a Slack or filesystem MCP server becomes just another node in the graph rather than a custom integration written by hand.

None of this is a story about whether to adopt these platforms. It's a story about which parts of running a multi-agent operation the platform can now do for you, in generic form, and which parts it was never going to do no matter how good the harness gets. The distinction matters because a harness that handles the mechanics well is easy to mistake for a harness that has made the operating decisions too. It hasn't, and the four launches above are unusually clear about where the line sits, if you read past the demo.

What_the_harness_actually_absorbs

Session state and memory, as declared configuration rather than hand-written plumbing. The AgentCore harness treats memory as something you point to, not something you build: you declare a memory strategy and the runtime manages session state, conversation history and multi-user concurrency underneath it. LangGraph's durable state does the equivalent job from a different angle - execution state persists automatically, so a server restart or a long interruption doesn't lose the run. This absorbs a category of work that currently has to be built by hand: state preservation and fallback routing designed in before a task fails, not scrambled together after, because a fleet running several agents in parallel needs that as a baseline property rather than a recovery script written under pressure. A harness that provides session persistence and durable execution state as a declared setting is a genuine reduction in what an operator has to write from scratch. It doesn't remove the requirement - a fleet still needs its agents to survive interruption without losing their place - but it moves the mechanism from bespoke code to configuration.

Identity propagation between an agent and the tools it calls. Loom implements RFC 8693 token exchange to propagate identity from an agent through to downstream tools, plus three built-in methods for pausing on a sensitive action pending human approval. That's plumbing every operator running MCP servers currently handles by hand at a smaller scale: every server added deliberately, confirmed before it goes in, scoped to global or project level on purpose, because nothing upstream does that scoping automatically. A platform that generalises token exchange and approval wiring as a managed layer is solving a real, tedious, error-prone problem that has so far been solved one integration at a time.

Human-in-the-loop as a generic primitive, not a bespoke checkpoint written into each pipeline. Loom ships three approval methods out of the box; LangGraph's pause-for-review API shipped at 1.0 GA. The mechanism itself - stop, wait for a human, resume with the human's input folded back in - is now something you configure rather than construct. That is a real absorption of engineering effort. It is also, on inspection, the exact point where the harness's contribution runs out.

What_still_requires_an_operator

Decomposition judgment. None of the four launches above ask a builder whether the task in front of them should be one agent or several. A harness will run a single declared agent or wire up a dozen of them with equal indifference to whether the decomposition is justified. That question has to be answered before orchestration starts, not folded into it: a sub-task only earns its own agent if it can fail, be evaluated and escalate independently of the others; otherwise the honest move is to collapse back to one agent and put the effort into an evaluation harness instead, a distinction laid out at length in The Case Against Multi-Agent, From Someone Who Runs Twelve. A declarative harness makes it easier to run whatever decomposition it's handed. It has no opinion on whether the decomposition was the right one, and the reported 70-90% failure rate for enterprise agentic pilots was never an orchestration-mechanics problem in the first place.

Trust-tier calibration. Handing a harness an approval mechanism doesn't tell it which actions actually need approval. That's a calibration problem, and it's one better written down as a formula than left to instinct: trust as a function of track record, reversibility and blast radius. My research agents run autonomously because a wrong finding just produces a weaker input somewhere downstream, caught and corrected by whatever reads it next. My copy and social drafts wait for a synchronous approval before anything publishes, because a bad public post is a live, photographed, irreversible signal the moment it's out. My backend agents are autonomous for routine work and always-review the moment they touch anything security-adjacent. None of that assignment comes from a platform. It comes from someone deciding, agent by agent and task by task, what the actual cost of being wrong is - a judgment a configuration schema for models, tools and instructions has no field for.

Gate placement. A harness that ships human-in-the-loop as a checkbox still needs someone to decide which step in the pipeline gets the checkbox. My merge gate blocks on unanswered comprehension questions at merge, not at commit, because that's the last cheap moment to catch a swallowed error before it ships. My publish gate sits at the status flip to Published, not at Draft or Scheduled, because that's the one action with no rollback - including for this piece, which clears that exact gate before anyone reads it. My delegation-enforcement check fires at the point a tool is actually called, not at the point a task is assigned, because that's where a boundary is actually tested rather than merely stated. None of these placements live in a harness's configuration surface. They are decisions about where a human's judgment is worth more than the throughput cost of stopping for it, and that is a different question from whether the platform is capable of pausing.

Where_the_judgment_moves

What changes with this convergence isn't whether an operator's judgment is still required. It's where that judgment gets spent. Building a multi-agent system used to mean writing the state management, the retry logic, the identity propagation and the approval flow before ever reaching the point of deciding whether the decomposition was right, what a given agent should be trusted to do alone, or where to put a human in the loop. That ordering was backwards, and it's a plausible part of why the reported failure rates for these pilots run as high as they do - teams spending their scarce judgment on plumbing instead of on the three questions that actually determine whether a multi-agent system survives contact with production. A generic harness that absorbs the plumbing doesn't remove those three questions. It just makes it obvious, for the first time, that they were always the whole job.

I'm reading these four launches from inside a fleet of a dozen-plus agents, not from a research desk, and that's the vantage point this piece is written from. What convinces me the harness layer is real is that it removes work I used to have to write myself - the state persistence, the retry logic, the identity scoping - and hands that time back for the three decisions above. What convinces me it isn't the whole story is that none of my hardest calls this year showed up in a platform release note. Deciding that my copy and social drafts need a synchronous gate a research agent doesn't, or that a delegation-enforcement check has to fire at the tool call and not at task assignment, was mine to make before any of these four platforms existed. It's still mine to make now that they do.