Open Source, AI, and Building Things That Don't Exist Yet: How American Sound Approaches R&D

Pete's Pizzeria

We have a name for the place inside American Sound where research and development happens. We call it Pete's Pizzeria. The name is intentionally ridiculous, because the work that comes out of it is serious, and we've found that giving a skunkworks lab a corporate-sounding name tends to make people treat it like a department with a budget line and a Gantt chart, which is the fastest way to kill exploratory work that produces results. Pete's Pizzeria is where we prototype integrations, test ideas that might be terrible, build tools we think should exist, and generally figure out what the next version of our service delivery looks like before anyone asks us to build it.

Some of the things that have come out of Pete's Pizzeria have turned into cool products and client-facing capabilities. Some of them have been spectacular failures that taught us something useful. The ratio matters a lot less than the fact that the work keeps happening, because the AV and IT industry is moving fast enough now that standing still is the same thing as falling behind, and I'd rather have a team that's building and occasionally breaking things than a team that's waiting for a vendor to release a feature and then learning how to configure it six months after everyone else.

What Open Source Means to Us (and What It Doesn't)

When we decided to release the Utelogy MCP server as open source, it wasn't because we think everything should be free, and it wasn't a marketing exercise (though I'm obviously writing a blog post about it, so make of that what you will). It was because the tool we built solves a problem that's bigger than American Sound, and restricting access to it would have been a weird, small move that ran counter to how we actually think about our role in this industry.

The problem is straightforward: if you manage a Utelogy deployment and you want to use AI tooling to query your environment for real-time data on rooms, devices, alerts, and assets, there was no way to do that. The Utelogy REST API exists and it's capable, but nobody had built the connective tissue between that API and the Model Context Protocol, which is the open standard (originally developed by Anthropic and now under the Linux Foundation) that lets AI agents interact with external systems through a standardized interface. So, we built it. Thirteen tools covering alerts, assets, rooms, and the Global Device Library, running locally on Deno, communicating over stdio, connecting directly to the Utelogy portal API over HTTPS with your own credentials. Nothing hosted, nothing proxied, nothing routed through us.

To understand why we think open source is the right model here, it helps to understand what's been wrong with the alternative for a very long time.

The AV industry has historically operated in a relatively closed ecosystem where proprietary hardware and proprietary software have been co-dependent in ways that really benefit no one. Closed control protocols, vendor-locked device management platforms, firmware that only talks to one company's ecosystem: this model has persisted for decades, and the cost of it has been paid in stifled interoperability, underinvestment in security (because security scrutiny requires openness, and openness was never a priority), sluggish innovation cycles, and a chronic inability to standardize technology stacks across an enterprise the way IT departments standardized their compute and networking infrastructure years ago. We're still paying down that tech debt as an industry, and every time someone builds another closed silo, they're adding to the balance.

AI is accelerating the case for open tooling in a way that I think is going to be difficult for the closed-model holdouts to ignore. The entire AI ecosystem is being built on open protocols and open standards: MCP itself is open source under the Linux Foundation, the SDKs are open, the reference implementations are open. AI agents need to be able to discover and interact with tools dynamically, and that only works when the interfaces are documented, standardized, and available. Open tools with official support and active development behind them get adopted faster, get tested more thoroughly, get integrated more broadly, and produce better outcomes than proprietary alternatives that lock you into one vendor's idea of what your workflow should look like. The trajectory here is clear, and it favors openness.

Now, I want to be clear about something: open source isn't for everyone, and you're not a bad company if your software is proprietary. That's the entire business model for the majority of our vendor partners, and that's how it should be. Companies like Utelogy, Crestron, Q-SYS, and Pexip build and sell software platforms as their primary business, and licensing that software is how they fund R&D, support infrastructure, driver libraries, and everything else that makes their products worth buying and deploying. Proprietary software built by companies whose core mission is building that software makes complete sense, and we're happy to sell it, deploy it, and support it for our clients.

But that calculus changes when you're talking about tools built by an integrator. We're not a software company. We're a service company that happens to write software when the tools we need don't exist yet. It makes a lot less sense for us to license and sell our own proprietary code than it does for the companies who do that for their primary living, because our business model isn't "buy our software." Our business model is smart people doing things as a service (SMPDTaaS?): engineering, integrating, developing, supporting, and solving problems that require deep knowledge of both the technology and the client's environment. The value is in our participation, not intrinsically in the software itself.

That's the Red Hat Enterprise Linux model, and it maps directly to how we think about the things we build at American Sound. Linux has plenty of free distributions, and Red Hat built a massive enterprise business on top of that same open kernel because the value was never in the code. The value is in the support, the development, the security hardening, the testing, the integration expertise, and the accountability that comes from having full-time engineers standing behind the product. People don't buy Red Hat because they can't get Linux for free. They buy Red Hat because they want someone who knows what they're doing to make sure it works, keeps working, and evolves with their needs. Our advantage isn't the code in that repository. It's the fact that we knew to build it, we had the engineering capability to build it well, and we have a team that understands both the Utelogy platform and the AI ecosystem deeply enough to know what the next three things after this one should be. The server is the artifact. The capability that produced it is the asset.

We want other Utelogy customers to use this tool. We want other integrators to look at it, learn from it, extend it. If somebody at a competing firm uses our MCP server to do a better job managing their client's AV environment, that's a good outcome, because it means the standard of care in this industry went up, and we think that's a tide-lifts-all-boats situation where American Sound benefits from being the company that contributed to raising it.

Co-Development and Why Your Integrator Should Be Building With Their Partners, Not Just Buying From Them

The Utelogy MCP server was developed with Utelogy's knowledge and permission, and that sentence is doing more work than it looks like on the surface. We talked to their team before we wrote a line of code. We have a relationship with Utelogy that's rooted in genuine technical collaboration, where we understand their platform architecture, their roadmap, their constraints, and they understand our capabilities, our client requirements, and what we're trying to accomplish with the tools we build on top of their platform.

This is what co-development looks like at American Sound, and it's not unique to Utelogy. We do similar work with Cisco, with Pexip, with Crestron, with Q-SYS, and with other technology partners where we've invested the time to understand their platforms deeply enough that we can build things on top of them that neither party would have built alone. The key word there is "invested," because this kind of relationship doesn't come from attending a partner summit once a year and getting a certification. It means being in the weeds with their engineering teams, pushing their APIs to see where the edges are, filing bug reports and feature requests that come from production deployments. You build that credibility by actually building things and putting them in front of clients.

When we build something like the Utelogy MCP server, we're also showing our technology partners that their platform is extensible in ways they might not have explored yet. They get a reference implementation that validates the investment they've made in their API surface. That kind of partnership produces outcomes that move the industry forward.

AI, MCP, and Why This Matters Right Now

I want to be honest about something: the phrase "AI-powered" has been so thoroughly abused by marketing teams across every industry that using it in a blog post feels like it should require some kind of disclosure. So, here's mine: when I talk about AI in the context of what we're building at American Sound, I'm not talking about chatbots that summarize your meeting notes, I'm talking about agentic workflows where AI systems can actually interact with your infrastructure, query data, and help you make decisions based on what's happening in your environment right now.

The Model Context Protocol is what makes that possible in a standardized way. Before MCP, if you wanted an AI assistant to pull data from your AV monitoring platform, you had to build a bespoke integration for every combination of AI tool and data source. MCP solves the "N times M" problem by giving both sides a common interface: the AI assistant speaks MCP, the server speaks MCP, and they can work together without either one needing to know the implementation details of the other.

Our Utelogy MCP server means that an IT service professional can sit down with Claude, or with Codex, or with whatever MCP-compatible AI tool they prefer, and ask questions like "what rooms have active alerts right now" or "show me all the assets from this manufacturer" or "what drivers are available for this device model" and get real answers from their actual production environment. Not from a training dataset, not from a knowledge base article, from their live Utelogy deployment. That matters for anyone doing AV operations at scale, because it turns AI from a novelty into a legitimately useful operational tool.

Our time investment in building this, as well as our other tools and macros published in our GitHub repo, is hopefully a testament to our dedication to utilizing AI as yet another tool in our arsenal to revolutionize ITIL-based service delivery for audiovisual systems, and bringing enterprise AV service closer to how IT departments have been striving to work for decades.

What Comes Next

I'm not going to pretend I have a five-year roadmap for AI in the AV industry, because anyone who tells you they do is probably a little crazy. What I can tell you is that the work we're doing in Pete's Pizzeria right now is focused on expanding this pattern: identifying the operational data sources that AV and IT professionals rely on, building standardized interfaces to them, and making those interfaces available in ways that let people bring their own AI tools and workflows. We think the future of AV operations is one where your AI agent knows your environment the way a veteran technician does, because it has access to the same data and the same context, and we want to be the company that builds the bridges between those worlds.

The Utelogy MCP server is available now at github.com/American-Sound/utelogy-mcp-server. It's MIT-licensed, it's free, and you don't need to be an American Sound client to use it. If you have a Utelogy portal account with API credentials, you can have it running in about five minutes. If you have questions, want to talk about what we're building, or just want to tell me the name Pete's Pizzeria is dumb, I'm easy to find on LinkedIn.

Doug Schaefer is Chief Technology Officer at American Sound, where he leads the company's R&D efforts, open-source initiatives, software development practice, and AI integration strategy. Connect with Doug on LinkedIn or explore American Sound's open-source work on GitHub.