A year of AI coding / 06
Open standards and coding agent portability
MCP and shared repository instructions can reduce integration friction, but interoperability still needs permissions, testing, and operational ownership.
By Grafty team · · 3 min read
Written in .
A tool connection that works with one coding agent can become a small integration project when you move to another. The tool may expose the same operation, but its discovery, input format, and authentication path can differ. Repeat that across an internal platform and switching costs accumulate.
On December 9, 2025, the Linux Foundation announced the Agentic AI Foundation with MCP, goose, and AGENTS.md as founding projects. MCP addresses connections between AI systems and tools or data. AGENTS.md provides a place for repository instructions. These projects already existed; the announcement established a shared governance home rather than introducing them for the first time. The foundation's announcement explains the contributions.
We see this as useful infrastructure work. A common connection mechanism and discoverable project instructions reduce plumbing. They also make it easier to ask what remains specific to the agent.
Open full-size diagram A common interface does not define authority
Consider an internal service catalog exposed through an MCP server. A coding agent could use it to find a service owner, inspect an API description, or request a new deployment.
Those operations should not have the same permission requirements. Looking up an owner is different from creating infrastructure. A shared protocol can carry a request, but the organization still has to decide which identity makes it and which actions that identity can perform.
We would separate read operations from state-changing operations and enforce authorization at the service boundary. The tool description should accurately explain the effect of a call, but it should not be the only thing preventing a destructive operation. A model misunderstanding a description must not become equivalent to an administrator approving a change.
The same applies to repository instructions. An AGENTS.md file can say how to run tests and which directories are generated. It cannot prove that a worker has no access to another repository. File access, credentials, and network policy need actual enforcement.
This distinction is easy to lose when every layer is called a standard. Standards can improve how systems communicate without settling how an organization grants trust.
Open full-size diagram Test portability with a real task
The practical test is whether a second agent can perform a representative job using the same underlying tools and project guidance.
Choose a task with observable behavior, such as adding a read-only endpoint to an established service. Check whether both agents locate the relevant instructions, use the approved tool, and produce a result that passes the same tests. Pay attention to failure handling. One agent may recover from a missing tool field while another repeatedly retries the same call.
When the workflows diverge, keep the fix in the right layer. An incomplete tool schema should be corrected at the tool. A repository convention belongs in project guidance. A provider-specific workaround may need an adapter. Putting every difference into a larger system prompt makes the integration harder to reason about.
For an enterprise team, portability also includes operating the tool itself. Someone needs to own its availability, credential rotation, version changes, and audit trail. An open protocol does not remove those jobs.
We would adopt shared standards where they simplify the system, then keep a small compatibility test suite around the workflows that matter. That gives the organization a credible option to change agents without assuming that a common interface guarantees identical behavior.