The AI Meeting Nobody Needed

Conceptual illustration of the learned handoff and the executive we still need to develop.

Two frozen specialists, a learned connection, and an executive with more to do than forward messages.

Imagine an executive who requires a written memo every time one specialist needs a fact from another. Even a simple handoff becomes a small administrative exercise: compose the message, send it, read it, recover the fact.

We built that arrangement between two AI models.

One model knew a color. Another knew which city that color pointed to. The person waiting at the end wanted the city. Somewhere along the way, we required the models to exchange an English message.

It was a convenient interface. It was also a choice worth questioning. If no person needed to read that intermediate message, could the models pass the information another way?

We tried a learned vector connection between Qwen and Falcon, kept both models frozen, and got the handoff working in both directions. The results changed how I think about the executive sitting between specialists.

Two specialists, one missing fact

The task was deliberately small. Give one specialist a private record containing a color. Give the other a private table mapping four colors to four cities. If the record says blue and the table maps blue to Rome, the answer is Rome.

Neither specialist has everything it needs. The controller coordinating them sees neither the private table nor the target city, so it can't quietly solve the lookup itself. It has to get the specialists to cooperate.

Our models were Qwen2.5-0.5B, from Alibaba, and Falcon-H1-0.5B-Base, from the Technology Innovation Institute. Different developers, different internal representations. We ran them locally so we could access those representations.

The English route asked the first specialist for its color and supplied a short text handoff to the second. The vector route read the first model's internal state and transformed it into input vectors the second could use. A vector here is an array of numbers; the learned connection had to make those numbers useful to the receiving model.

We trained that connection. Neither specialist's weights changed.

The illustration shows a fixed route and an example answer. We tested both model directions; choosing the route was a separate problem.

The models didn't arrive with a shared internal language. The connection had to learn how to carry the task information between their different representations. Once it did, the receiver could produce the final city without the sender first spelling out the color.

English was still present in the records and instructions. A person still received a readable answer. We had removed one internal text exchange.

English won the first round

On the original reserved test, English got about 91% of the answers right. The vector route got about 88%.

That result mattered. Skipping the memo hadn't automatically improved the collaboration.

We had trained the vector connection to imitate particular model representations. Then we changed its training so the final city answer helped teach the connection. If the receiver chose the wrong city, that error could guide the bridge between the specialists, even while both specialists stayed frozen.

After 50 additional updates, we froze the connection and tested it on new city tables, using city labels held out from this controller's training.

The improved vector route answered all 384 attempts correctly. The original vector connection got 292 right. The unchanged English system got 282.

The surprising detail was where English failed. It passed the correct color every time. The receiving specialist still picked the wrong city on 102 attempts. A correct message hadn't guaranteed a correct collaboration.

One fit, 48 tables, two city palettes, and both model directions. The improved vector system received extra training that English did not.

I take this as a reason to train the interface around the task's outcome. The result doesn't establish that vectors are inherently better than English: the training budgets and controller sizes differed. And four possible colors carry only two bits of information. The wording stayed fixed; these city labels were held out from this training lineage, not necessarily unfamiliar to the pretrained models.

Still, we had a working connection between two frozen models from different developers. It succeeded on every tested table in both directions.

It also made the person at the end wait less. The vector route averaged about 87 milliseconds; English took about 264 milliseconds in our serial, uncached implementation.

These timings use an RTX 5090 and FP32. The chart separates elapsed time from logical arithmetic; the speed ratio depends on this implementation.

The timing gap was much larger than the arithmetic saving, which was about 2% per attempt. Generating and handling intermediate text affected the clock. Getting more answers right also meant less arithmetic spent per successful answer. We haven't accounted for the full training cost.

That gives us a practical result to build on. The more ambitious possibility still needs a different experiment.

A richer vector message might carry uncertainty or interacting constraints that a short English reply leaves out. Our color task couldn't show that. English preserved the color perfectly, and a learned vector projection can lose information too. I'd want a task that actually needs those distinctions before claiming we avoided information loss.

Give the executive a harder job

The executive is the part I most want to develop.

In the successful handoff, the route was fixed. The controller learned to ask for and carry useful information, but it wasn't deciding which specialist to consult next. It wasn't weighing whether another call would help.

A more capable executive would have to make those decisions. Suppose the specialists disagree: should it ask for clarification, consult a third source, or stop with an uncertain answer? If the task is already solved, can it recognize that and avoid another call?

Those choices are where coordination earns its cost. They require a view of the goal and the work so far.

We tried a decision-making executive in separate experiments. It learned the procedures we wrote for it, then struggled when goals arrived in unfamiliar wording. The perfect lookup result doesn't fix that failure. It gives us a useful communication component for a decision-maker we still need to train.

My bet is that the executive should learn from whether the whole collaboration succeeds. The specialists can remain frozen while the layer connecting them learns how to use their abilities.

There are good reasons to keep English when people need to inspect a handoff. But I no longer think a generated English message should be compulsory between every pair of models. Human readability is a design requirement at particular points in the system; the internal connection can be chosen for the work it has to do.

I want a person to state the goal, let the executive coordinate its specialists, and receive an answer they can understand. The next experiment is whether that executive can earn our trust to decide what happens in between.

The full results and limitations include the failed runs and comparison details. Related work on continuous model communication includes Interlat and Cache-to-Cache.