I jokingly asked if we needed gateways anymore on LinkedIn this week. Declaring that AI had breached the enterprise gates. I am only half joking. The breaching of the enterprise gates began well over a decade ago with our adoption and then expansion of SaaS. Over time more and more of enterprise operations was in the cloud and outside of the enterprise firewall. We have been moving our businesses onto the open web slowly and then all of a sudden throughout this century. We needed gateways to protect our backend services, databases, and file systems, but with MCP we’ve flattened everything into “tooling”, and have opted bypass over a decade of investment in API management, with gateways at the center.

The Web
Mark Nottingham talks about the Web’s Openness in terms of access to information, and how easy (or hard) it is to publish and obtain information without barriers there. Concluding that, “We have to create an Internet where people want to publish content openly – for some definition of “open.” Doing that may challenge the assumptions we’ve made about the Web as well as what we want “open” to be. What’s worked before may no longer create the incentive structure that leads to the greatest amount of content available to the greatest number of people for the greatest number of purposes.” I can’t agree more, and I the boundaries in which we define our enterprises are directly related to the state of the open web, and something that is changing because of artificial intelligence, for better or for worse. 

SaaS
Software as a Service, or SaaS has been transformative for businesses of all shapes and sizes. However, it also has slowly shifted the boundaries of our businesses in ways that aren’t always known and properly managed. There are many different types of SaaS platforms, but one of their hallmarks is that they operate in the cloud, which minimizes the overhead and cost of setting and motion—but it is something that diminishes over time, depending on the platform. SaaS has set in motion an unprecedented shift of our valuable data and other digital bits outside of the enterprise, with APIs being the counter balance, allowing businesses to assert more control through integrations. But mot all companies take advantage of APIs, let alone full coverage of APIs available across the SaaS services that they are already paying for.

Open-Source
The proliferation of open-source software has transformed how enterprises do business, from the operating system to the content management system. Open-source standards and tooling reflects a different balance than commercial SaaS offerings do, even with the open APIs—putting more control in the hands of business when it comes to where the software runs, and what data it has access to. However, this doesn’t mean that open-source is any less of a target of consolidation, threats, and other forces. Like the Web, and SaaS, open-source standards and tooling are under threat from artificial intelligence, providing an array of concerns that are shifting the economics of free or commercial open-source standards and tooling. Well vetted and managed open-source software is how you mitigate threats, but it is something that also needs alignment with the open web and SaaS.

Forward Proxy
Cross these three streams I am looking to get back to basics when I think about the boundaries that have historically existed between us and the open web, which I think are beginning to radically shift our worlds. To understand this shift I began to look at the forward proxy, which sits between clients and the internet, making requests on behalf of users, and is commonly used for privacy, content filtering, and caching, with the destination server sees the proxy's IP rather than the client's. A forward proxy represents the client, and sits on the client side of the network. The forward proxy is about protecting internal client considerations, from external threats that exist out there on the web, providing protection from a hostile Web.

Reverse Proxy
Changing the flow of our digital bits, the reverse proxy sits in front of servers, receiving requests from the internet and forwarding them to backend servers, introducing load balancing, SSL termination, caching, and protecting origin servers from direct exposure to the open web. A reverse proxy represents the server, and its in front of backend infrastructure, receiving inbound requests from the internet—clients never know the true backend architecture or server identities. A forward proxy is how we protect ourselves from the open web, and reverse proxies are how we let in some of the open web to our enterprises in a safe and secure manner that is aligned with business outcomes. 

Gateways
Now we get to the concept of the gateway, which for me is often indistinguishable from the reverse proxy. I am generalizing here, and I am coming at this from the perspective of boundaries, not networks—although they share a lot of characteristics. I am thinking about the business incentives for forward and reverse proxies, as well as the gateway. Honestly I am still trying to draw the feature and use case line between a reverse proxy and a gateway. Someone said to me on LinkedIn this week that the difference between a reverse proxy and a gateway was taking venture capital. Which explains the proxy to API management evolution of our API universe, and the current identity crisis between data, API, event, AI, and other incarnations of gateways that exist out there today—which are more investor responses to what is happening than they are anything else.

Service Mesh
A service mesh is a dedicated infrastructure layer that handles service-to-service communication within a microservices architecture. It typically works by deploying lightweight proxy sidecars alongside each service instance, which intercept and manage all network traffic between services. Now we are getting into the distribution of what I’d consider to be simply proxies. Who they are protecting shifts in nature when you are just talking about an internal mesh, in contrast to what an external or public mesh might look like, reflecting the intentions behind a forward and reverse proxy. I’m less interested in in the viability of mesh as a business model than I am just the business intent behind wanting to do it, and what a mesh looks like when the primary gateway for an enterprise has been breached via MCP or an agentic approach to integrations between the systems we use.

Event-Driven
An event gateway acts as a centralized hub that ingests, routes, and delivers events between producers and consumers in event-driven architectures, enabling real-time, asynchronous communication across distributed systems and services. Unlike request-response patterns, it manages fire-and-forget event streams. Uniquely supports pub/sub patterns, event replay, and buffering for offline consumers, and are optimized for temporal decoupling where producers and consumers  can operate independently. Personally, I think this pattern is more consequential when it comes to doing automation than agentic ever will be, and I think is a gateway that emerged as an organic response to real-world problems versus other patterns which are market and investor introduced to try and convince people that there is a problem in need of solution—I won’t name names.

Boundaries
This entire newsletter is written with a consideration for the reshuffling of boundaries that is going on because of artificial intelligence. I blame AI, but honestly this is just the end-game of something that has been evolving and expanding for some time. It just reach the rich environment of the current spend on AI approaches to EVERYTHING! APIs were redefining boundaries, but they did it at a manageable scale using proxies, gateways, meshes, and events to define, redefine, and shape our business boundaries—primarily on the open web. Artificial intelligence has substantially changed the oxygen levels on the open web and within the enterprise—leaving everyone gasping for air, and forcing many of us to open MCP windows, centralizing power and access via AI copilots, and now announcing we all need to be letting in swarms of agents to help usher our enterprises into the AI age.

Signals
I am looking for signals across many different types of businesses to understand where they stand within this shift in the boundaries of the web, markets, and our business operations. The rate of adoption and change, as well as the deployment and usage of all the patterns I outline above varies widely. Not all companies have jumped on the AI train, with many others going all in. I am looking for signals regarding how susceptible, resistant, and in control companies are when it comes to operating on the open web, leveraging SaaS solutions, investing in open source, and how adaptive they are because of how they use proxies, gateways, mesh, and event-driven approaches to operating their businesses. I am looking for how shuttered and siloed a company is or how much it is able to operate on the open web, which shows me who needs the help of Naftiko the most, but also those we can watch and learn from.

Context
There is a lot of talk about context and context engineering right now. I’m no expert, but I know that domains and boundaries play an important role in setting the context for integrations of any sort. I know that having a solid handle on the inventory of internal and 3rd-party APIs, as well as having proxies, gateways, mesh, and event-driven infrastructure in place to help manage the technical and business details of integrations will shape the context engineering discussion. If you are further along in your API journey, you will have more muscles and training when it comes to delivering the resources, skills, and capabilities required for the context in which they are needed. Context is much more manageable if you have done the domain-driven design work and have invested in teams being API-first and design-first. Ultimately context will need to be governed if you want to get anywhere close to the vision in leaderships minds.

Operations
As I gather the signals from across the the companies I am profiling, I am also developing a rich catalog of 3rd-party services in which companies are investing in and dependent upon. From this catalog I harvest the APIs and webhooks available across these services. From this I produce an even more granular and rich catalog of the operations available across these 3rd-party services. These operations posses tags, as well as summaries, descriptions, identifiers, and other technical details regarding how to execute an operation. These are the individuals operations that make up your enterprise operations. These are operations we’ve been bundling together and managing as resources for over a decade now, and increasily are the operations we are translating into tasks, and stitching together into skills, workflows, and other forms of repeatable business capabilities. These operations already exist across the enterprise in many different contexts, and are just waiting to be put to use in any application, even artificial intelligence copilots and agents.

Sandboxes
I am organizing these operations I’ve mined across the signals I’ve beet n gathering while building Naftiko, but also API Evangelist and APIs.io, into sandboxes. First as services defined boundaries like the Notion and GitHub API sandboxes. This is just to prime the pump of development of the Naftiko framework as it explores its proxy, gateway, mesh, and event-driven features. Once I have a stack of OpenAPI, Microcks, Bruno, and Backstage sandboxes deployed across the top services I’ve identified through market research and Nafitko Signals, the crafting of more capability centered sandboxes will be much easier. These sandboxes provide a rich forkable and open-source space to shape integrations of all types, including the integration of AI copilots and agents into the enterprise. I believe that API sandboxes providing REST, MCP, A2A, event-driven, and other approaches can help shape the current AI conversation in important ways, but also believe that they can literally shape the enterprise by defining what is capable of in a space that allows you to practice what you are capable of. 

Certification
Each operation in the sandboxes I am developing get certified. What that means right now is that it has at least one valid example for the request and the response. This is expressed as an OpenAPI example, which is augmented with Microcks OpenAPI extensions that help be bind requests with responses. Then I use Bruno to provide an open-source client for viewing the sandbox. Right now it is just making sure each operation has a response, but next I will make sure there is a test to certify. After that I will be certifying against the production version of each API, and then validate then compare with the sandbox edition. Ultimately I want each operation to be certified, ensuring that any company depending on the sandbox and any capability they become part of, can be confident that they are truly capability of doing whatever an operation delivers. I don’t want to stop with the single example in the sandbox and what the production instance provides, I want to deliver rich sets of synthetic examples for delivering different business scenarios and outcomes that push wha tis possible when it comes to integrations.

Capabilities
OK, what is the end-game here? Well, I am looking to use everything I am talking about here to shift the boundaries of how we define our products and business operations, or at least be able to keep up with defining how our products and business operations are shifting. I am looking for a way to keep up with things at scale. Gathering the signals from across the landscape and understanding the different patterns in use takes time right now, and producing the sandboxes, then certifying them takes time, but it is getting faster and scaling as fast as I imagined. I am looking for a way to quickly sweep up millions of lego bricks and be able to quickly show people how to assemble them into useful kits that reflect the most common enterprise patterns. I am not looking for the one way to do things. I am looking to understand and automate the creation and evolution of blueprints that deliver upon what is needed for AI, but also desktop, web, mobile, device, and network applications to get the digital resources they need—while not giving away the lion share of the value created to the other platforms we depend upon, or just preying upon us.

“We need to have a talk on the subject of what's yours and what's mine.” ― Stieg Larsson, The Girl With the Dragon Tattoo