Why Interlock

MSFT Word -> Google Docs doesn't work for AI. Not a good parallel; if all 5 AI agents needing to work on the same file was a problem, they can just use git worktrees.

One of the key functions of moving software to a multiplayer capacity is to 'multiply' human cognition. It brings multiple minds to the table, ones that think differently, contribute as they see fit, and produce an outcome that is greater than all its fragmented minds could make after being built apart and pieced together. Instead it has to be built together.

GitHub is the fileshare where AI can share their work. That was msft word + email, or Dropbox. There is no need for this with AI, since GitHub is already the Dropbox for AI.

Google docs for AI would look like all AI models coming together to work on the same branch, working from the same specification document towards a shared goal, without colliding too much and producing higher quality output than any single AI model could produce on their own. This can happen, and in some ways it already does.

As all humans carry their own personalities and experiences, so too do AI agents on each employee's machines. They have been formed to different shapes even if they all are shaped towards the same goal. A snowflake is still a snowflake even though no snowflake looks identical.

So this begs the question; what does 'Multiplayer AI' truly look like? Well, it has to be 'multiplayer' in a capacity that enhances the contributions of the individual running the AI agent, rather than simply enhancing the AI agent's output itself. It should be easier to bring individual contributions to the table without context overloading the human, only bringing up the most essential high quality questions and injections.

In the same way that microsoft word documents were shared over email before DropBox existed, so too is the way that humans will need to interact with shared autonomous AI systems.

There was an individual writing the microsoft word document, perhaps going around the office asking people questions along the way. You wouldn't ask two people the same question at the same time, because if each response is different, you personally would need to determine whose answer you ignore. Logically, you would instead ask the most high quality important question to the person most suited to answer. You would not ask 20 questions to every person. Likewise, you wouldn't ask an intern what our policy is for our 401k contributions; you would instead ask a senior HR representative.

A series of open questions remain visible following this logic:
Who or 'what' will be writing the 'word document' equivalent?
How will automated systems send emails to individuals when necessary?
How can we design such a system that is as passive as individuals on the team responding to an email when necessary?

I believe I agree with Y Combinator on this specific message: "Anyone on a team should be able to drop into the same live agent session to watch it work, redirect it, and hand it off, the way they'd work with any other human team member. This turns the work a team does with agents into a shared, living thing instead of a thousand private threads."

However; it has to fit in with existing AI infrastructure and tooling.

I believe this "drop into the same live agent session to watch it work" thing directly parallels our bus orchestrator. This is the bus. The agent that humans and teammates can interact with, and do all the actions Y Combinator suggested, is the orchestrator agent. Not the agents that join the bus; those are the worker bees. They execute and they better execute well (those can be configured based on the codebase's available context and guardrails to AI agents). The shared interface can certainly be a plan, since we have no mechanism of live-injecting into an Agent's prompt window with shared teammates; this can be the closest thing if we can make it "like-live" e.g. it is so instantaneous it feels like we are live injecting it with what we say. Those plan changes can also have a message queue to avoid collisions, in the same style that google docs handles edits or how github handles merge conflicts.