Motorola Solutions brought its Internal Developer Platform into the IDE because its existing platform had more than 4,000 monthly active users but only 22% adoption.
2
A flat mesh of agents became difficult to route and produced cascading hallucinations beyond eight agents, so the team introduced a Master Agent as a single entry point.
3
The team reduced context overhead with tool search and separated agent work into perception, decision, action, and memory loops, while keeping human approval in the flow.
Summary
Adnan Vahora describes how Motorola Solutions tried to increase adoption of an Internal Developer Platform used by more than 4,000 monthly active users. The platform had only 22% adoption, so the team moved its agent experience into the IDE through a Bring Your Own Agent approach. Early designs exposed problems with duplicated engineering work, flat agent meshes, routing, hallucinations, authentication, and context pollution. The team introduced a Master Agent, an agent registry, shared knowledge services, memory, authentication management, and human approval for sensitive actions. Vahora explains a request flow that crosses MCP and A2A, including BigQuery authorization. He also describes tool search, which reduced context use by 80% in one case, and a decomposition into perception, decision, action, and memory. The final direction is a declarative agent harness that lets teams package agents with YAML, Docker, and Helm while the platform handles common security and compliance work.
The team moved the agent experience into the IDE to address low platform adoption
Motorola Solutions had more than 4,000 monthly active users on its Internal Developer Platform, but adoption was only 22%. The platform team faced a cycle where developers wanted mature features before adopting the platform, while the team needed more users to justify building those features. Since developers already work in their IDE, the team decided to bring the platform there. Its Bring Your Own Agent approach asked teams such as infrastructure, observability, and FinOps to build agents that could be integrated into the shared platform.
A collection of domain agents created duplicated work and a poor user experience
The domain teams knew their own problems, but they were not necessarily experienced in building AI agents. Each team repeated research and implementation work around problems that other teams were also solving. For users, the result would have been a set of separate agents, each producing output that the developer had to combine. Vahora says this could make the AI experience more difficult than the original task, so the team changed its design.
Security requirements put human approval and A2A communication into the architecture
Because Motorola Solutions works in public safety, the team began with a security-first constitution. Its design included zero-trust execution and required every user, tool call, and agent action to pass through human approval. Agent-to-agent communication had to use A2A. These requirements shaped how the team designed delegation, authentication, and the boundary between the agent experience in the IDE and the platform services behind it.
A flat agent mesh became unreliable as the number of agents grew
In a canonical mesh, every agent can discover and communicate with every other agent. Vahora found that this made each agent responsible for routing as well as answering the user's question. When the mesh grew beyond eight agents in their case, hallucinations snowballed and the system became unstable. The overall system was also limited by its weakest agent. This led the team to use one Master Agent as the single entry point and orchestrator.
The Master Agent centralizes discovery, memory, knowledge, and authentication
The Master Agent can receive requests through MCP, A2A, a chat endpoint, or an IDE integration. To avoid redeploying it whenever a new agent appears, the team created a registry containing agents, MCP resources, and skills. They added short-term and long-term memory, a shared context domain for team documentation, and an authentication manager for tokens and security controls. These components let individual teams reuse platform services instead of rebuilding them.
Crossing the MCP and A2A boundary requires explicit event mappings
In the project-cost example, a user asks the Master Agent from VS Code, and the request is enriched with registry context before going to the FinOps agent over A2A. The Master Agent asks the user to approve the delegation through MCP elicitation. FinOps then needs access to a BigQuery MCP server using an authorization-code flow. The authentication consent URL travels back through A2A, and the Master Agent converts it into an MCP elicitation. After approval, the token is stored in a secure vault and FinOps can continue.
Tool search reduced context overhead, but the team still had to separate responsibilities
Agent tools, skills, MCP resources, and their descriptions consumed context before the user even asked a question. The team used a tool search tool that finds the required tools through semantic search from the input description. In one case, this reduced context use by 80%, although it added another network hop. The team then split the context into perception, decision, action, and memory loops so each node receives only what it needs.
A declarative harness lets teams focus on domain work instead of repeated platform setup
The Master Agent architecture did not remove duplicated developer effort by itself. The team responded by making the agent harness declarative. A team with a simple agent can provide a YAML file and release a Docker and Helm package into the platform. The shared harness handles security reviews, compliance concerns, and MCP version changes. Teams can then concentrate on solving their business problem or improving the developer experience. The composable agents can also be chained into a larger agentic system.
"Whenever you try to scale your agent mesh more than a certain number of agents, in our case it was eight, hallucinations really snowball and things go haywire."07:09
Who should watch
You run an Internal Developer Platform that has users but low adoption, and you are considering an IDE-based developer experience.
Your platform team is building multiple agents and needs practical guidance on orchestration, authentication, human approval, or context management.
You are deciding how MCP and A2A should interact in an agent system that calls internal tools and cloud data services.
