{"slug": "don-t-build-your-organization-around-a-model-provider", "title": "Don't build your organization around a model provider", "summary": "Organizations should not build their operations around a single AI model provider, warns a developer building the open-source aweb platform, as providers like Microsoft, OpenAI, and Anthropic increasingly embed agent communication and coordination into their products, risking lock-in. The author argues that agent identity, tasks, and accumulated knowledge must remain portable and under organizational control, advocating for open protocols like A2A to decouple intelligence from infrastructure.", "body_md": "As we increase our reliance on AI, decoupling intelligence from organization will become vitally important. The model providers are starting to build the systems through which agents communicate and coordinate; we could end up depending on them much more than we depend on the models.\n\nIn May 2025, Microsoft announced [task delegation between agents\nin Copilot\nStudio](https://www.microsoft.com/en-us/microsoft-copilot/blog/copilot-studio/multi-agent-orchestration-maker-controls-and-more-microsoft-copilot-studio-announcements-at-microsoft-build-2025/)\nand an [Entra directory of agent\nidentities](https://techcommunity.microsoft.com/blog/microsoft-entra-blog/announcing-microsoft-entra-agent-id-secure-and-manage-your-ai-agents/3827392). In\nJuly 2026, OpenAI announced a [multi-agent beta in the Responses\nAPI](https://openai.com/index/gpt-5-6/), with [hosted actions for\nspawning agents, sending messages, and waiting for\nreplies](https://developers.openai.com/api/docs/guides/responses-multi-agent).\nIn August, Anthropic added [messaging between independent Claude\nCode\nsessions](https://github.com/anthropics/claude-code/releases/tag/v2.1.224).\n\nThese announcements point in the same direction. Agents that can communicate can divide work, question one another’s conclusions, and take on more responsibility without bringing every problem back to a human. It makes sense that the model providers want to build this into their products.\n\nConsider what an organization invests in such a team. It defines roles, establishes who can authorize work, develops procedures, and accumulates knowledge. Agents learn where to find an answer and whom to ask when the documentation is insufficient. Tasks and conversations connect all of this. Teams learn, evolve and adapt.\n\nThese arrangements become the operating framework of the organization.\n\nIf they are coupled with the model provider’s infrastructure, changing model providers can mean rebuilding how the organization works. A better model elsewhere may not be enough to justify the move; a price increase, a withdrawn model, or a change in access conditions can impact the organization’s ability to operate.\n\nAgent identity is central here. A reviewer agent should remain the organization’s reviewer when we change the model or software running it, and retain its accumulated knowledge. Other agents should still know how to reach it, recognize its messages, and check what it is authorized to approve. Replacing the machinery should preserve those relationships.\n\nThe same applies to tasks, communication, and accumulated knowledge. They need to remain accessible, and under the organization’s control, across providers and harnesses. This should hold whether agents run through Gas Town, Gas City, or terminals we start ourselves.\n\n**Intelligence should become a commodity, and it should be\ndecoupled from the infrastructure needed to make the most\nof it.**\n\nThis is one reason I am building\n[aweb](https://github.com/awebai/aweb). It provides identity and\ncommunication independently of the agents’ runtimes, along with a\nshared task system. It supports other arrangements, like keeping\ntasks in [beads](https://github.com/gastownhall/beads) and using\n[aweb for its mail](https://aweb.ai/docs/beads-mail/). Aweb also\nhas [experimental support for\nA2A](https://github.com/awebai/aweb/blob/main/docs/a2a.md), an\nopen protocol for exchanging tasks between agents built with\ndifferent frameworks.\n\nOpen source lets an organization inspect, operate, and change the software it depends on. Open protocols let independently built components communicate. Neither removes the work of integration, but both give us ways to retain control as our needs change.\n\nCan we replace a model, a harness, or a service and keep the team working? We should build toward that while the agentic organizations are still taking shape.\n\nps. Microsoft’s [support for\nA2A](https://devblogs.microsoft.com/foundry/from-building-agents-to-working-with-them-enterprise-agent-distribution-in-microsoft-foundry/)\nis a welcome step in the right direction.", "url": "https://wpnews.pro/news/don-t-build-your-organization-around-a-model-provider", "canonical_source": "https://juanreyero.com/article/ai/model-provider-independence", "published_at": "2026-09-07 01:03:20+00:00", "updated_at": "2026-09-07 02:14:25.255806+00:00", "lang": "en", "topics": ["ai-agents", "ai-policy", "ai-infrastructure"], "entities": ["Microsoft", "OpenAI", "Anthropic", "aweb", "A2A", "Copilot Studio", "Claude Code"], "alternates": {"html": "https://wpnews.pro/news/don-t-build-your-organization-around-a-model-provider", "markdown": "https://wpnews.pro/news/don-t-build-your-organization-around-a-model-provider.md", "text": "https://wpnews.pro/news/don-t-build-your-organization-around-a-model-provider.txt", "jsonld": "https://wpnews.pro/news/don-t-build-your-organization-around-a-model-provider.jsonld"}}