Source: https://mayphus.org/ai-coordination-experiment/
Title: Coordinating AI tools: access, ideas and evidence
Metadata: {"kind":"page","language":"en","route":"/ai-coordination-experiment/","tags":["ai","workflow","experiments"],"type":"page"}

This experiment asks what becomes possible when AI tools contribute different access, capabilities and approaches to the same task. Adding more agents is not, by itself, evidence of value.

In this setup, dot coordinates goals, decisions and verification. Supporting tools can explore a bounded task, return evidence or suggest another approach. The coordinator’s job is to keep the result connected to the original purpose, including the limits of what was actually demonstrated.

## Coordination flow

1. **Owner goals and boundaries** — define the purpose and what an acceptable outcome would look like.
2. **dot: coordination and verification** — keep decisions, evidence and next steps connected to that purpose.
3. **Choose an access route**
   - **Demonstrated: Muse via Chrome.** The browser/chat route returned China-platform listings and concrete leads.
   - **Prospective: ordinary Grok web or Gemini.** These routes remain untested here.
4. **Evidence and results** — verify the returned material, record limits and decide what is useful. Access and new leads are demonstrated; the learning outcome remains open.

This is a coordination structure. The prospective branch is not a tested connection or a demonstrated native API integration.

## Route comparison

| Route | State in this experiment | Observed result and limit |
| --- | --- | --- |
| Muse via Chrome | **Demonstrated access** | Browser/chat interaction returned listings and new concrete leads. No native API integration was established. |
| Android Mi 8, ADB and GrokBot | **Stopped for friction** | Screenshots and taps worked. The UI hierarchy was unreadable, input was unreliable and no successful test message was demonstrated. |
| Ordinary Grok web or Gemini | **Prospective** | Possible comparison routes; not tested here. |

## Complementary access

One browser-based test used Chrome to chat with Muse. That route accessed China-platform listings that dot's direct browsing had struggled to retrieve, and returned new concrete leads for further checking.

The demonstrated connection used an existing browser and chat interface. No native API integration between the assistants was established.

The verified benefit is additional access and concrete leads. It does not establish better income, better decisions or measured token savings. Ordinary Grok web and Gemini interfaces remain possible routes for comparison; neither was tested here.

## A phone route that stopped

A separate Android Mi 8 experiment used ADB to open GrokBot. Screenshots and taps worked, but the UI hierarchy was unreadable and text input was unreliable. No test message was successfully sent.

I stopped that route because of the interaction friction. Opening an app and tapping its interface were intermediate results; a usable conversation was not demonstrated.

## Learning from another assistant

I also asked dot to learn from Muse. I see value in trying this exchange even if no useful new lesson emerges. Maybe it will learn something new; maybe not.

Here, learning means exchanging approaches, critiquing suggestions, testing an idea and adapting the working process. This experiment does not demonstrate model-weight retraining or automatic gains in intelligence.

The direction I have already asked for includes less micromanagement, ownership of outcomes, priorities that adapt to the task, and deeper work when it is useful. These are existing requests from me. There is no evidence here that Muse originated them or caused a gain.

The open question is what one assistant can learn from another, and how we would tell whether it helped. A useful account should identify the suggestion, the test, the change in approach and the observed result. An exchange can remain worthwhile to explore while its practical benefit is uncertain.

## Autonomy with an accountable coordinator

Task-level autonomy gives a tool room to carry a clearly defined task through to a reviewable result. It requires a shared purpose, known boundaries and a way to check completion. It does not require constant instruction for every small step.

The coordinator still needs to reconcile conflicting suggestions, verify consequential claims and decide whether to continue, change direction or stop. Another assistant can contribute a perspective without becoming a second centre of decision-making.

## Judge the outcome and the cost

Coordination adds work: carrying context between interfaces, reading responses, checking claims and resolving disagreement. An extra reply or a fluent conversation is not a demonstrated improvement.

For access, the useful question is whether a route returns information that can be checked. For learning, it is whether a tested suggestion changes the approach or result. For coordination, it is whether the outcome justifies the additional effort and verification.

The evidence so far supports complementary access, new leads and a clearly stopped phone experiment. The learning question remains open. Future claims should follow actual outcomes, including cases where an exchange produces nothing useful.