Skip to main content
AI & Technology

Before AI can work across vendors, what can we learn from the Internet, the Web and Linux?

Part 1 of a four-part series on interoperable AI. TCP/IP, the Web and Linux help explain protocols, standards and open source, and what to ask before changing an AI vendor.

Agentic AIOpen ProtocolsOpen SourceLinuxEnterprise AIAI
Editorial drawing of computers from different eras connected by copper cables on a worktable, with spare connectors in front
Original AI-generated conceptual illustration of systems connecting across different eras, not a historical reconstruction.

The internet runs on open protocols and open source. So will agentic AI.

That is the headline on the Agentic AI Foundation (AAIF) homepage, checked on 25 October 2026. It connects the Internet’s foundations with AAIF’s vision for agentic AI.

In this series, an agent means an AI application that selects steps and uses tools toward an assigned goal, within the permissions it has been given.

The second sentence remains a proposition to test. It does not establish that every AI product will be equally open, or that products will connect without adaptation. It does raise a useful question for anyone buying business software: if you change AI tools next year, how much of this year’s work can come with you?

Consider a hypothetical industrial equipment distributor. It wants AI to answer a customer’s question: is this order available to ship? The task sounds small. Behind it sit a purchase order, product codes, inventory reservations in the ERP and the sales team’s rules. Some of that is data, some is integration and some is company knowledge. An “open” label does not tell you which parts are portable.

This first article uses the Internet, the Web and Linux to separate those parts. Later instalments will follow the same business task into ERP connections and agent working instructions.

The Internet lets different systems agree on communication

On 1 January 1983, ARPANET switched to TCP/IP, an important milestone in the development of the Internet, as Internet Society records. The relevant lesson here is that different computers and networks can communicate through common agreements. They do not all have to belong to one product family.

A protocol sets rules for how communicating parties send, receive and interpret messages. Imagine two companies agreeing on purchase-order fields and how to report an error. Real protocols specify much more, but the distinction is useful.

An implementation is the software that puts those requirements into practice. Two developers can write different programs in different languages and sell different services around them. Following shared requirements gives their products a basis for communication. Testing still matters: a compatibility claim does not prove that both products support the same version or the same parts of it.

Openness also concerns how the rules are maintained. The IETF describes an open process with public documents and discussions, participation by interested individuals, and experience from working implementations informing agreement. Its standards are voluntary. It does not own or control the entire Internet.

For a business buyer, that suggests looking beyond the existence of API documentation. Who can change the requirements? How are changes announced? Can another company actually build a compatible product?

The Web added a way to access information over the network

The Internet and the Web are different things. The Web is one system that operates over the Internet. Tim Berners-Lee invented the World Wide Web at CERN in 1989. On 30 April 1993, CERN placed the Web software in the public domain and later made a release available under an open licence, according to CERN’s history.

There are two separate decisions here: rules that allow systems to communicate, and rights to use and develop software. They can reinforce each other, but they do different jobs.

HTTP provides an example. RFC 9110 defines semantics for requests, responses and status codes. It describes behaviour; it is not a ready-to-run web server. A company may therefore replace its web server while people continue using their existing browsers, provided the relevant agreements are still met.

HTTP does not know what “available to ship” means at the distributor. Is stock on hand enough? Must reservations be deducted? Does the customer’s credit position matter? A protocol helps carry the question and answer. Someone still has to define the business meaning.

That boundary matters when AI begins using real systems. Successful data transmission and correct interpretation need separate checks.

Linux illustrates the right to develop software further

Linux occupies another part of this story. It is a kernel, the core that manages a computer’s resources, rather than a network communication protocol. It should not be presented as the origin of the Internet. GNU’s documentation dates Linux’s start to 1991 and its change to free software to 1992, years after the TCP/IP milestone above. (GNU/Linux FAQ)

The project documents the Linux kernel’s licence as GNU GPL version 2, with stated exceptions. A complete operating system commonly called Linux also includes other programs, whose licences need their own consideration. (Linux kernel licensing rules)

“Open source” therefore concerns rights, not just visibility. Under the Open Source Initiative’s definition, access to code alone is insufficient. Distribution terms must meet criteria covering redistribution, modification and derived works, among other requirements.

For a buyer, those rights may provide a route to inspect code, modify it or engage another maintainer under the licence terms. They do not remove maintenance work. The company still needs people who understand the software, an update process and someone responsible when it fails. Open source also does not make the company’s customer or commercial data public; access to that data is a separate decision.

Openness has several dimensions. A product may support an open protocol without publishing all its code. Another may publish its code while making data export difficult. The relevant question is which dimensions matter for your work.

Separate the layers before reading an AI proposal

A standard provides shared requirements. A protocol specifically concerns communication, while a standard can also describe something else, such as a file format. Publishing a document and calling it a standard does not make every such document equally credible. Its maintainers, change process and evidence of interoperability also matter.

An API (application programming interface) is an interface through which a program lets other programs request data or capabilities. An API may use HTTP to carry messages while defining its own operations and fields. Having an API does not, by itself, establish interchangeability with another vendor’s tool.

Use this table to read a proposal. Individual systems may arrange these components differently.

What you are examining What it answers What it leaves unresolved
A protocol, such as HTTP or MCP How systems exchange messages and behave Whether a business result is correct
A published format, such as Agent Skills How instructions and supporting files are packaged Whether different AI products follow them equally well
Software and its licence How the program works and what rights you have to use, modify or redistribute it Who maintains it for your company and at what cost
Company data and working rules Which data to use, what it means and who may act How completely it will transfer without testing

For agents, the Model Context Protocol (MCP) specification dated 2026-07-28 defines a protocol for connecting AI applications with external data and tools. Agent Skills defines a format for instruction packages containing a SKILL.md file, potentially accompanied by scripts and reference material. They can work together, but answer different questions.

On 22 October 2026, Anthropic announced its donation of Agent Skills to AAIF. Whether your company’s instructions produce equivalent results after a move still needs testing with the actual tools and tasks. Our Agent Skills news article covers the announcement; here it illustrates a distinct layer of openness.

Back to “is this order available to ship?”

In our hypothetical distributor, the ERP might show 50 units on hand and 40 already reserved. A customer requests 20. AI reading only stock on hand might say there is enough, although just 10 units remain unreserved. These numbers illustrate the problem; they are not a customer result or a report from a working system.

The integration could transmit every field correctly and the answer could still be wrong if nobody told the AI to deduct reservations. “Supports an open protocol” cannot certify that answer. The company must define available stock, identify its authoritative data and specify what happens when demand exceeds availability. Permission to approve an exception needs a separate decision.

If the team changes AI vendors, it would want to retain the ERP data and field meanings, an inspectable integration, and sales instructions with an accountable owner. A chat history alone may not explain why a particular answer was approved.

A useful test is to give both tools the same request and simulated data. Ask each to show the data it retrieved, how it calculated availability and where it would escalate a shortage. Begin before granting permission to reserve stock or change live records. The exercise can reveal what already transfers, what needs adaptation and which rules the team has never written clearly.

This is an assessment method proposed by this article, not a claim that any standard guarantees a particular saving.

Questions to bring to a vendor meeting

Choose one task, such as checking available stock, and turn the broad question “is it open?” into requests for evidence.

  1. Which named specification, version and features do you support? Can you demonstrate a connection to another vendor’s tool?
  2. If the contract ends, in what formats can we export data, instructions, reference files and necessary configuration? What restrictions apply?
  3. Whose identity accesses the ERP? Who can change its permissions, and who handles changes to the specification or ERP version?
  4. Can we trial another AI tool using the same simulated data and acceptance criteria? Which parts must be rebuilt?
  5. If the vendor or standard’s maintainers change direction, what alternatives do we have, and who can maintain them?

The answers might justify a product with proprietary components because its service and accountability fit the task. They might justify open source because the team needs to modify it. Either can be a reasoned choice. Leave the meeting knowing whom you depend on, for what, and what evidence supports the promise of portability.

The lesson we can use today is to distinguish shared agreements from programs, and software rights from company knowledge. That makes questions about integration and migration more precise, without requiring us to accept the entire future described by the opening headline.

Next in the series: we will follow the stock-availability question into the ERP, examine the roles of APIs, tools and MCP, and identify where permissions and result checking still need an owner. Part 3 will cover Agent Skills and company working instructions. Part 4 will examine delegation between agents, controls and adoption decisions.

Sources and specifications checked on 25 October 2026.

"Empowering Innovation,
Transforming Futures."

Contact us to make your project a reality.