April 2025 Summaries

The text discusses the need for a common language in AI systems to enable reliable and scalable multi-agent interaction. As AI clients move from data consumers to active intermediaries, they require structured communication beyond secure APIs or natural language. Natural language is too ambiguous for agent interaction, and it's not sufficient to ensure coordination and shared structure among models. Instead, infrastructure that is auditable, structured, and designed for machine coordination is necessary. The authors propose using defined schemas, roles, and formats to improve model-to-model communication and suggest the development of protocols like Anthropic's Model Context Protocol (MCP) as a solution. These protocols aim to provide a standardized interface between AI agents and APIs, enabling machines to communicate effectively and safely. The text also highlights the importance of structure in making intelligence scalable, and it emphasizes that models need frameworks to manage complexity and ensure predictability.

Rate limits were designed for predictable clients with humans behind the screen. But AI agents act differently. They make decisions, call APIs, and post content without understanding context. Harm limiting is an emerging approach that focuses on how data is used after it leaves the API. It adds structure and guidance to help models act more responsibly and gives developers a clearer way to manage risk as AI systems become more autonomous. The traditional safeguards of rate limits and basic authentication are no longer enough in an ecosystem shaped by autonomous agents. Harm limiting builds on traditional API infrastructure by introducing a way to guide how data is used, not just whether or how often it's accessed.

The Model Context Protocol (MCP) is a new protocol that enables developers to extend Language Models like LLMs with custom tools, similar to how the Language Server Protocol (LSP) enables text editors with custom language features. MCP is designed to be model and tool agnostic, allowing it to enhance the experience of various tools such as Cursor, Windsurf, ChatGPT, VSCode, and more. By using MCP, developers can one-shot tasks like exploring an API schema, writing GraphQL queries, or configuring a router, without requiring deep domain knowledge. The protocol is inspired by LSP and provides a generic way to extend LLMs with custom tools. It's designed to enable business users to generate dashboards and reports, and can be used with various LLMs and tools. However, running MCP servers locally comes with risks, and the alternative of running them over SSE also has its own risk profile. Overall, MCP redefines how developers build software by enabling workflows that would otherwise take hours or days to complete.

Cosmo MCP has been integrated with Agent Mode in Cursor, Windsurf, and VSCode, allowing developers to navigate their schema, propose changes, validate queries, configure the router, and more within their IDE. The Cosmo MCP Server is a small extension that communicates with the IDE using STDIO, operating in the same context as the CLI. To set up Cosmo MCP, an API key must be obtained in Cosmo Studio and added to the IDE configuration. With Cosmo MCP, developers can explore their Supergraph schema, propose changes, automate tasks such as verifying queries against remote schemas, and configure routers with tools like "cosmo_router_config_reference" and "verify_router_config". The tool also enhances workflows like the dream query workflow by automating the process of going from an idea to a concrete proposal. Overall, Cosmo MCP aims to make developers more productive by automating tasks and allowing them to focus on high-level thinking while the model handles low-level details.

The Cosmo Router serves billions of requests daily and aims to avoid introducing breaking changes that could result in failed queries. A tool was built to export customer schemas and GraphQL operations into a private GitHub repo, run the router in "headless query planning mode" against exported queries, and check for plan changes or errors. The tool has three main parts: a router subcommand that generates query plans, a daily workflow that exports customer data, and a GitHub workflow that runs on every pull request and checks for plan changes. Query planning is complex due to the lack of a specification and the introduction of new features in GraphQL Federation, which can lead to complex query plans. The tool provides visibility into query plan changes and helps ensure that changes are intentional and do not introduce regressions. It also integrates with GitHub Actions to run automated checks on every pull request.

sync.Pool` is not a silver bullet for performance optimization in Go. While it can reduce memory allocations and garbage collection pressure by reusing objects, its use comes with complexity trade-offs, including managing object lifecycle, ensuring proper cleanup, and handling edge cases such as buffer size variations. It's valuable in scenarios with predictable object sizes, high-frequency allocations, short-lived objects, or GC pressure, but not ideal for situations with variable object sizes, low allocation frequency, long-lived objects, or prioritizing code simplicity over performance. Alternative approaches like direct allocation, fixed-size buffers, multiple pools, and memory arenas might be more suitable in certain cases, and careful consideration of the trade-offs is necessary before using `sync.Pool`.