Agent IDE Meeting Room

Inspiration

Most multi-agent systems begin by connecting model APIs. I began with a different observation:

The Agent IDE is the agent.

An AI coding agent’s real behavior is shaped not only by its underlying model, but also by the IDE built around it: vendor tuning, tools, context management, permissions, memory, interface, and continuous product updates. A role assigned by the user is only an outer layer; the Agent IDE remains its real identity.

Today, using Codex together with other Agent IDEs requires a human to repeatedly switch windows, copy messages, explain context, and coordinate decisions manually. I built Agent IDE Meeting Room (AMR) so these independently developed agents can work together without being reduced to interchangeable API bots.

What It Does

AMR provides a shared meeting facility where Codex and other vendor-built Agent IDEs participate as themselves.

A human Director can:

• Bring multiple Agent IDEs into one structured session
• Assign temporary roles without replacing their native identities
• Run meetings through Draft, Review, Decision, and Final phases
• Send private tasks through per-agent inboxes
• Track presence, decisions, approvals, and meeting history
• See who should act next and receive automatic state summaries
• Detect stalled discussions, duplicate votes, and approval timeouts
• Activate GUI-based Agent IDEs through a safety-controlled delivery layer

AMR does not recreate the agents. Each Agent IDE remains the environment where reasoning and execution happen. AMR supplies the shared protocol, memory, and coordination space between them.

How I Built It

I built AMR as a Python MCP server with a FastAPI Director dashboard and a deterministic secretary.

Meeting rules are defined in YAML. Shared state is stored using atomic JSON writes, while the transcript is maintained as an append-only JSONL log. File locking and stale-lock recovery allow several IDE processes to participate safely.

The deterministic secretary enforces meeting phases, role permissions, approval gates, next actions, summaries, and anomaly detection. A mailbox and delivery layer connect the shared room to each IDE, including GUI-only agents that do not provide a headless command-line interface.

Codex with GPT-5.6 was both my primary development partner and one of the real Agent IDEs used to test AMR. I used it to challenge the architecture, turn ideas into specifications, implement the system, design tests, debug failures, and verify live collaboration across multiple IDEs. I developed AMR milestone by milestone using specification-first development, TDD, and live verification. The current implementation is backed by 260 automated tests.

Challenges

The hardest challenge was that Agent IDEs do not share a universal interface. Some provide command-line automation, while others can only be reached through their GUI. A message arriving in an inbox also does not mean the agent has been activated to read it.

This led to a layered delivery design. The mailbox remains the source of truth, while adapters handle notification, window activation, and verified prompt delivery. For GUI-only Agent IDEs, AMR identifies the intended process and window, locates the chat composer through Windows UI Automation, waits while the agent is busy, verifies the pasted prompt exactly, and confirms submission. It does not rely on fixed screen coordinates or move the user's mouse, and it fails closed when the target cannot be verified.

Another challenge was balancing agent autonomy with deterministic coordination. Language models are probabilistic, but meeting rules, approvals, and shared state cannot be ambiguous. AMR therefore keeps reasoning inside each Agent IDE while making coordination rules deterministic and testable.

What I Learned

I learned that the central problem is not simply making several models talk to one another. It is allowing independently designed Agent IDEs to collaborate without erasing the differences that make each one valuable.

I also learned that:

• Delivery is not the same as activation
• Roles describe responsibility, not identity
• Deterministic protocols make agent collaboration more accountable
• Live multi-IDE testing exposes failures that isolated unit tests cannot reveal
• Human oversight should be part of the architecture, not added afterward

What’s Next

The next step is to make cross-IDE activation more robust, simplify onboarding, and package AMR so a Director can assemble a team of Agent IDEs with minimal setup.

The long-term vision is a world where people can choose Agent IDEs from different companies as specialized team members, then bring them together in one accountable workspace without sacrificing their individual capabilities.

The Agent IDE is the agent. AMR brings them together.

Built With

• agentic
• codex
• context
• css
• fastapi
• gpt-5.5
• gui
• html
• human-in-the-loop
• javascript
• jsonl
• model
• multi-agent
• openai
• pytest
• python
• pywinctl
• test-driven
• uvicorn
• win32
• yaml