Is any of this usable now?

The connector standard is, widely, and cross-vendor driving exists in places. One coding tool in this corpus can be driven by compatible editors and reuses connector configurations written for other tools. That is narrower than the general promise and it is real rather than announced.

What is the hard part?

Permissions and accountability rather than the message format. When something acts through something else, whose authority applies and what it is scoped to are the questions that decide whether the arrangement is safe. Products taking this seriously answer them explicitly, which is a useful thing to look for.

Should a buyer wait for it to settle?

Waiting is reasonable for the general case and unnecessary for the specific one. Where a pairing you need already works, the standard behind it matters little. Where it does not, building bespoke plumbing now is a bet that will probably be rewritten, which is a cost worth naming before starting.

Glossary

Agent to agent (A2A)

Agent to agent (A2A) describes the emerging protocols that let software from different vendors delegate work to each other directly, rather than every pairing being wired up by hand.

In plain terms

Getting one vendor's software to hand work to another's without somebody writing the join. Today most of that plumbing is bespoke: every pairing is its own project. The protocols are an attempt to make it a standard instead, so anything speaking it can be driven by anything else.

Why it matters

Because the alternative is a permanent integration tax. Every useful pairing built by hand has to be maintained by hand, and the number of pairings grows far faster than the number of tools. A standard is the only thing that changes that arithmetic, which is why several are being pushed at once.

How it works

Two different problems are being solved and the vocabulary blurs them. One is giving software access to tools and data, which is what the widely adopted connector standard addresses. The other is one piece of software driving another piece of software, which is a different question about delegation and control. Products increasingly do both, under one heading.

Some of this already works, which is worth knowing before treating it as future. One coding tool in this corpus speaks a client protocol so that compatible editors can drive it, and reads connector configurations meant for other tools without modification. That is cross-vendor delegation in production rather than in a specification.

The connector standard is where adoption actually is. Knowledge platforms describe letting software retrieve and act in tools such as chat and ticketing systems; a compliance platform describes an early-access connector letting external assistants query live data under the asking person's own permissions. That last detail is the interesting one, because it is where the hard question lives.

Permissions are the unsolved part rather than the plumbing. When one piece of software acts through another, whose authority is being used and what is that authority scoped to. The products treating this seriously answer it explicitly, and a standard that moves work between vendors without answering it has moved the difficulty rather than removed it.

The two problems sharing one name

Separating these two makes the announcements far easier to read, because a great many of them describe the left column while sounding like the right. Giving software a standard way to reach a ticketing system is genuinely useful and genuinely widely adopted, and it is a plumbing achievement: the hard parts were description and discovery, and those have largely been settled. Delegation between vendors is a different shape of problem. The message format is the easy half; what has to travel with the message is an answer to whose authority is being exercised, over what scope, recorded where, and revocable how. Those are the same questions that make any delegation difficult, and crossing a vendor boundary makes them harder rather than easier, because the two sides have different notions of identity and different logs. The products worth paying attention to here are the ones that state their answer to that question rather than the ones that state which protocol they speak.

Seen in the wild

A coding tool that speaks a client protocol so compatible editors can drive it, and reads connector configurations meant for other tools without modification.
Kimi Code
A compliance platform with an early-access connector letting external assistants query live data under the asking person's own permissions.
Drata
A knowledge platform whose connector support lets software retrieve and act in tools such as chat, ticketing and customer systems.
Guru

Common misconceptions

People assume

It is all one standard.

In fact

Two distinct problems share the vocabulary: reaching tools and data, and one piece of software driving another. The first has broad adoption and the second is far earlier. Reading a product's claim carefully to see which it means is worth more than following which name is winning.

People assume

A standard removes the integration work.

In fact

It removes the bespoke plumbing and leaves the difficult part. Who is acting, under whose authority, scoped to what, and recorded where are questions a protocol can carry but not answer. Those are the same questions any delegation raises, and they do not become easier for crossing a vendor boundary.

Telling them apart

Agent to agent (A2A) vs MCP

Agent to agent (A2A)

One piece of software delegating work to another.

MCP

A standard way to reach tools and data.

Reaching a tool and driving another system are different problems. Most of today's adoption is the first.

Questions

Is any of this usable now?: The connector standard is, widely, and cross-vendor driving exists in places. One coding tool in this corpus can be driven by compatible editors and reuses connector configurations written for other tools. That is narrower than the general promise and it is real rather than announced.
What is the hard part?: Permissions and accountability rather than the message format. When something acts through something else, whose authority applies and what it is scoped to are the questions that decide whether the arrangement is safe. Products taking this seriously answer them explicitly, which is a useful thing to look for.
Should a buyer wait for it to settle?: Waiting is reasonable for the general case and unnecessary for the specific one. Where a pairing you need already works, the standard behind it matters little. Where it does not, building bespoke plumbing now is a bet that will probably be rewritten, which is a cost worth naming before starting.

Key takeaways

Two problems share the name: reaching tools and data, and driving another system.
Adoption today is mostly the first; cross-vendor driving exists but is narrower.
A protocol carries the questions of authority and scope; it does not answer them.
This is the fastest-moving part of the category, so specifics decay quickest here.

Tools that use this

Kimi Code
Speaks a client protocol and reuses connector configurations from other tools.
Drata
An early-access connector serving external assistants under the asker's permissions.
Guru
Connector support letting software retrieve and act in chat and ticketing tools.