Mid-Market AI

The Great MCP vs. CLI Debate | Mid-Market AI | Episode 109

Paragon Season 2 Episode 109

Use Left/Right to seek, Home/End to jump to start or end. Hold shift to jump forward or backward.

0:00 | 32:22

There's a war happening inside every major technology company about how AI agents should connect to the tools they use. This week Stripe dropped 288 product announcements including MCP support for their financial infrastructure. OpenAI shipped four CLI versions in eight days. Google launched an Agents CLI. Shopify open-sourced MCP plugins. The Linux Foundation took over the protocol.

And a developer benchmark went viral claiming MCP is 10-32x more expensive than CLI and already obsolete. Your CTO has an opinion. Your channel rep has a pitch. All of it is based on a debate written by developers for developers. This episode translates it for everyone else.

WHAT WE COVER:

What MCP actually is, the USB-C for AI. What CLI actually is, and why it's not just a developer tool. The simplest framework: CLI for legacy systems, MCP for SaaS. Why the benchmark is real but the conclusion is wrong. The three layers every AI deployment needs: execution, connectivity, governance. What MIP and MIP-RA are and how the Optimization API makes the transport irrelevant. The governed vs. ungoverned distinction that actually matters. Real scenarios: manufacturing, home health, SaaS portco. What MSPs should be building and billing for right now. Three questions every PE operator should ask their CTO this week.

KEY STATS:

97M monthly MCP SDK downloads, up from 100K at launch 18 months ago. CLI is 10-32x cheaper on tokens than MCP for identical tasks. 88% of MCP servers have insecure credential handling. Gartner: 40% of enterprise apps will include AI agents by end of 2026.

SERIES:

Episode 107, What Is the AI Harness? Episode 108, Headless AI. Episode 109, The Great MCP vs. CLI Debate.

FOR: PE operating partners. Portco CEOs. MSPs building an AI managed service. TSDs and channel partners whose agents are getting asked about AI every week.

Mid-Market AI is hosted by Ariel Jalali, CEO of Paragon Technology Solutions. Paragon is a Managed Intelligence Provider, a CAIO and CDO-led team deployed inside PE-backed and mid-market companies, delivering AI as a managed service through the TSD and MSP channel. paragoncto.com

Paragon - Managed Intelligence Provider (MIP™)


Speaker

There's a war happening right now inside every major technology company about how AI agents should connect to the tools they use. On one side, a 50-year-old technology called the command line. On the other, a protocol that didn't exist 18 months ago and already has 97 million downloads a month. Developers are writing posts declaring each other wrong. Executives are picking sides, and somewhere in the middle, a PE operator just got a recommendation from their CTO about one of them and has no idea whether to say yes. Today I'm going to explain what both of them actually are, why the debate is the wrong frame for your business, and what the right question is instead. You're listening to Mid-Market AI? I'm Ariel Jalali, CEO of Paragon. We're a managed intelligence provider. We put CAIO-led data and AI teams inside PE-backed and mid-market companies to accelerate automation and transformation. A few times a month I get on here and cut through the noise for operators, investors, and channel partners who need field experience, not conference slides. Quick note on who this episode is for. If you're a Portco CEO, Portco being shorthand for portfolio company, a business owned by a private equity firm, and the alphabet soup of MCP and CLI makes your eyes glaze over, stay with me. I've got you. If you're a PE operating partner trying to evaluate what your CTOs are recommending, there's something in here for you. And if you're an MSP, a managed service provider, the technology companies that manage IT for business clients on a monthly basis, or a channel partner, don't go anywhere. This is your episode 2. One more thing before we start. If you haven't heard the two episodes before this one, go back and listen. Episode one was about the AI harness, what it is, why an AI agent without a harness is a liability, not an asset, and what the five functions every real AI deployment needs. Episode two was about headless AI, what it means when your software goes headless, why Salesforce restructured their entire platform so AI agents can run it without a human ever logging in, and why software portcos in particular need to pay attention. Today builds directly on both of those. You don't need to have heard them to follow along, but if you want the full picture, start there. Here's why this episode exists, and why you should care. In the last 30 days, every major technology platform company, Stripe, Google, Shopify, OpenAI, Adobe, Salesforce, shipped something called an MCP server. At the same time, OpenAI shipped four versions of a terminal tool called a CLI in eight days, and then a developer benchmark went viral, claiming the MCP approach is 10-32 times more expensive and less reliable than just using the CLI. Your CTO read that benchmark. Your MSP partner has an opinion on it, your channel rep has a pitch based on it, and the problem is that this entire debate was written by software developers for software developers, and it's being handed to PE operators, portco leaders, and channel partners as if it's a business decision framework when it's actually a developer workflow preference dressed up as enterprise strategy. The reason this matters to your business specifically is that both of these technologies, MCP and CLI, are going to be in the infrastructure stack that runs AI agents inside your portco or your client's business. Someone is going to make a decision about how to use them. If that decision is made based on a benchmark designed for one context and applied to a completely different one, you'll build something that works for a developer and fails for a business. We have seen this pattern, it's expensive to unwind. So this episode is about helping you understand what MCP and CLI actually are, when each one is the right tool, why most companies are skipping the layer that actually matters, and how Paragon's approach through MIP and the reference architecture gives you a way to use both without betting the company on the wrong one. Two terms you need to know before anything else makes sense. MCP stands for Model Context Protocol. A protocol is a standard that lets different systems talk to each other the same way. Before MCP existed, if you wanted an AI agent to access your Salesforce data, you needed a custom integration built specifically for that agent and that version of Salesforce. If you also wanted the same agent to access your ERP, your enterprise resource planning system, the software that runs your core business operations like finance, inventory, and production. Another custom integration. Your billing system, another one. Ten AI applications connecting to 100 business systems meant potentially a thousand different custom integrations, each one built from scratch, maintained by whoever built it and broken by the next software update. MCP replaces all of that with one standard. An AI agent connects to an MCP server, and that server handles the translation between the agent and whatever system sits behind it. One standard interface for every system. Think of it as USB-C for AI. One port, every device. CLI stands for command line interface. This is the terminal, the black screen with the blinking cursor that software developers have been using since the 1970s. When a developer types a command like git push or AWSDploy, that's CLI. For AI agents, CLI means the agent is generating and running those same kinds of commands directly, the way a developer would. No protocol layer, no schema to load. The agent types a command and gets text back. AI models are good at this because they've been trained on millions of examples of developers using exactly these tools. Both of these let an AI agent take action in the world. They're not competing philosophies, they are tools that belong at different layers of the same stack. The confusion comes from treating them as alternatives when they mostly aren't. Here's the simplest way to think about it. CLI for legacy, MCP for SaaS, your on-prem ERP, your older manufacturing systems, your cloud infrastructure like AWS and Azure. These have mature CLS with enterprise governance already built in, and the AI models know how to use them, Cold. Use CLI, your SaaS stack, Salesforce, HubSpot, Stripe, Google Workspace. These were built API first, and the vendors are now shipping MCP servers for them. Stripe shipped one this week, use MCP. The optimization API and your reference architecture should sit above both, and doesn't care which one it calls. Your business logic stays the same. The transport is just plumbing. MCP went from an anthropic internal project to the de facto standard for AI agent connectivity in about 13 months. OpenAI adopted it. Google, Microsoft, Salesforce, AWS, all of them. In December 2025, Anthropic donated MCP to the Linux Foundation, which is the organization that also stewards Kubernetes, the infrastructure layer that runs most of the world's cloud workloads today. When something moves to the Linux Foundation, no single company controls it anymore, everyone builds on it together, which is what makes it safe to standardize on. By March 2026, the MCP SDK Software Development Kit, the package developers download to build with the technology, was pulling 97 million downloads per month, up from 100,000 at launch. That's 970 times growth in 18 months. There are 17,000 active MCP servers indexed across registries. Gartner is projecting that 75% of API gateway vendors, an API, or application programming interface, is the standard way software systems expose their data and capabilities to other systems. An API gateway manages and secures that access, will include MCP support by end of this year, and 40% of enterprise applications will include task-specific AI agents by end of 2026, up from less than 5% today. That's the scale of what's being built on top of these protocols. And every one of those agents needs to connect to something. Every one of them needs to be governed. That's what this episode is about. The week that matters as context for all of this. Stripe held their annual conference this week, 288 product announcements in two days. Mark Zuckerberg, CEO of Meadow, was on stage with John Collison, the CEO of Stripe. Together they announced that AI agents can now move money, manage financial accounts, and retrieve real-time billing data directly through Stripe's infrastructure. Not through a dashboard, not through a report, through an agent that connects to Stripe's MCP server and just asks, if you run a SAS portco, your AI can now pull your monthly recurring revenue, your churn rate, meaning how many customers are canceling, and your billing anomalies instantly without a dashboard, without a data team building a query, without waiting. The agent asks Stripe directly. Same week, OpenAI shipped four versions of a CLI tool called Codex in eight days. Browser added, computer use on Mac OS added, GPT 5.5 is the default. OpenAI is the company that built ChatGPT. The product that taught 100 million people to talk to AI through a chat window. They are now building and shipping a terminal tool and calling it the primary workspace. That's a strategic signal worth sitting with. Google made two CLI moves at once. Gemini CLI is their open source terminal agent. Open source means the code is publicly available for anyone to use and build on. Apache 2.0 is a specific open source license that allows free commercial use, 1 million token context window, MCP support built-in. Google's own infrastructure engineers are using it in production to resolve outages. Google also shipped the agent CLI in their agent platform, built not for humans typing commands but for AI coding tools like Gemini CLI, Claude Code, and Cursor, giving them a direct connection to the full Google Cloud Stack. That's a machine readable interface from AI coding agent to cloud infrastructure, with no human in the middle. Shopify open sourced their AI toolkit two weeks ago. MCP plugins for the major AI coding tools. Adobe Marketo launched an MCP server in April with over 100 operations. Salesforce, Google Workspace, all shipping MCP servers as official products, not side projects. The governance piece that matters most. MCP moved to the Linux Foundation in December 2025, with OpenAI, Google, Microsoft, AWS, and Cloudflare all joining as founding members. Nobody controls it. The whole industry owns it together. That's a real infrastructure shift versus a technology trend. Let's break down the benchmark debate, translated for normal folks who don't spend time on developer forums. In late February, a software developer published a post arguing that MCP was already obsolete. A performance test showed CLI completing identical tasks at 10-32 times lower cost, with near-perfect reliability versus MCP's 72%. A technology executive at a prominent AI company announced they were moving away from MCP. The argument spread through technical circles quickly. Now let me say this loudly so everyone in the back can hear. The reports of anything being dead in AI are always greatly exaggerated. Transformers were declared dead. Rag, retrieval augmented generation, a technique for giving AI models access to current information, was declared dead. Agents were declared dead before most companies had shipped one. MCP is 18 months old, has 97 million monthly downloads, and every major enterprise software vendor just built a server for it. The argument that it's obsolete is a super wild developer workflow argument dressed as a technology verdict. But the performance problem that the benchmark identified is real and worth understanding. When an AI agent connects to an MCP server, that server loads the definition of every tool it offers, function names, what they do, what inputs they take, what they return, directly into the model's context window before the agent has done anything. A full GitHub MCP server loads definitions for around 93 tools. That is roughly 55,000 tokens. A token is roughly three-quarters of a word, and models have a fixed limit of how many tokens they can hold in memory at once, called the context window, consume before the first task. Large enterprise MCP servers can reach 100 to 150,000 units of overhead before any real work begins. You are paying in both cost and speed for the model to hold a catalog of capabilities it may never use in that session. CLI is leaner. The agent generates a command, maybe 3,000 units of context total, runs it, gets text back. The model already knows how to use Git and AWS and Stripe. Not from a schema, a schema is a structured definition of what a system can do and how to interact with it. That it just loaded, but from training on years of developer documentation. The commands are part of what the model knows. That efficiency advantage is meaningful, the benchmark isn't wrong. But the conclusion being drawn from it probably is. The benchmark was designed for a specific scenario, a single developer using an AI tool for their own work, on their own machine, with their own credentials. In that scenario, CLI wins clearly. The agent inherits the developer's permissions, acts with the developer's authority, touches only systems the developer already has access to, and the only person at risk from a bad command is the developer. That is a narrow and specific context. It isn't the context most of the people listening to this podcast are operating in. When you're running AI agents at a portco across a team, touching customer data, financial records, clinical data, or operational systems, the agent isn't acting as one developer. It is acting on behalf of the organization. And in that context, the properties that make CLI efficient become liabilities. An AI agent with unconstrained CLI access runs with the full permissions of whoever set it up. It can delete files, execute arbitrary commands, access every system the installer had access to. A security survey found that 88% of MCP servers use insecure credential handling, which is a real problem in the ecosystem and also a problem with the same root cause, people deploying powerful tools without governance infrastructure. OWASP, the organization that defines security standards for software, published a top 10 threat list specifically for MCP. An audit of 201 public MCP servers found the four most popular ones all scored D or below on security. These numbers aren't arguments against either protocol, they are arguments for the governance layer, which is the layer most companies are skipping. There is also a technical fix for the token overhead problem that most of the debate ignores. An MCP gateway, a governance layer that sits in front of MCP servers and controls what gets loaded and who can access what, that uses schema filtering, loading only the two or three tools relevant to the current task instead of the full server inventory, brings the overhead from 44,000 down to roughly 3,000. That approaches CLI efficiency. The performance problem the benchmark documented is an architecture problem and it has a solution. The security and accountability problem with running unconstrained CLI in an enterprise environment? Well, that doesn't have an equivalent fix. So, let's review the three layers. Not competing choices, but more of a complete stack: execution, connectivity, and governance. Execution is where developers work, writing and testing code, deploying infrastructure, managing cloud resources. CLI wins at this layer cleanly and completely. Your development team using clawed code or cursor with CLI tools is making the right call for that context. Do not second guess it. Connectivity is where AI agents reach business systems, the ERP, the CRM, the billing platform, the scheduling software, the data warehouse, Stripe, Salesforce, HubSpot, Google Workspace. This is the MCP layer. The MCP server sits between the agent and the system, standardizes the connection, handles authentication, and means you build that integration once, not once per agent, not once per software update, just once. Governance is where enterprise deployment actually lives. Authentication, verifying that the agent is who it claims to be. Audit trail, a log of every action the agent took, time stamped and attributable. Role-based access control, meaning different agents and different users can only do what they're specifically authorized to do. Policy enforcement. Cost tracking. This layer wraps both of the others. Without it, you've tools that work in isolation, and no ability to explain to your CISO, Chief Information Security Officer, the person responsible for security in your organization, your board, or your auditors what those tools did, who authorized them, or what they accessed. For port cooperators, this is what separates a scalable AI program from a shadow IT problem with a different acronym. For MSPs, this is the layer that justifies the managed service fee and creates the stickiness that makes the business defensible. The companies skipping the governance layer aren't moving faster. They are building debt they will pay back when someone asks the wrong question. Before we consider the scenarios, this is where our managed intelligence provider solution, MIP and MIPRA, our reference architecture, come in. And I want to explain this clearly because it's the practical answer to everything we've been discussing. MIP stands for Managed Intelligence Provider. Paragon created this category in 2024. A managed intelligence provider isn't a software vendor, it isn't a consulting firm. It's a managed service, a CAIO and CDO-led team that's chief AI officer and chief data officer that goes inside your organization in your own cloud environment and builds and runs the AI agents, the data infrastructure, and the automation that your business needs. We deliver AI as an ongoing managed service the way an MSP delivers network infrastructure. You don't buy a license, you don't hire a team. You get Paragon's team deployed inside your environment, running your AI programs, and accountable for outcomes. The reference architecture we deploy for our clients has an analysis engine that processes your raw data, cleaning it, normalizing it, making it something an AI can actually reason on rather than a direct feed from a messy legacy database. An AI model engine with swappable models so you're never locked into one vendor. A test bench automation suite that governs what runs, when, and with what context. And the optimization API. The optimization API is the layer that most companies don't have, and the layer that makes everything else portable. It packages and ships your intelligence wherever it's needed, your automations with business rules, your decision logic, your exception handling knowledge, your industry-specific thresholds once and deploys it wherever it needs to go. As an agent, bolt it onto a SaaS tool your team already uses, inject it into a legacy ERP or SaaS tool without replacing it. Through an MCP server, through a CLI call, through a direct API. The transport is a deployment decision. The intelligence travels. And here's the point that matters for this episode specifically. When you need a CLI built, Paragon or your AI team builds it. When you need an MCP server built, Paragon or your AI team builds it. When you need both, we deliver both. The MCP versus CLI debate is a delivery decision inside the engagement, not a strategic choice the client has to make. The client's strategic choice is what business problem they want to solve. We figure out what transport gets the intelligence there. This is why the debate, as it plays out on developer forums, isn't the right frame for this audience. The question isn't which protocol to pick. The question is whether you've an AI team or partner who understands both, can build either, and is accountable for the outcome regardless. Now let's get into some practical scenarios. A mid-market manufacturer with an ERP and a production scheduling system. Every morning, two hours of manual work, pulling yesterday's data, cross-referencing work orders, flagging what slipped. A developer can write scripts that query both systems and push a digest to a messaging tool. That works on their machine until the ERP updates and the schema changes. It works until that developer leaves. It works until your CISO asks what the automation was touching, with what credentials, and there's no log. Then the two hours of manual work come back. The right architecture starts with the analysis engine processing the raw data from both systems, cleaning it, normalizing it, resolving 15 years of accumulated inconsistencies before any AI reasoning happens. The optimization API packages the business logic once. What counts as a slippage, what severity level gets escalated versus handled automatically, what routing happens when two systems disagree? That logic fires every morning through whatever transport reaches each downstream system, the messaging tool gets the digest, the ERP gets the exception record, the schedule The moduling system gets the reroute suggestion. The governance layer logs every action. Your CISO can pull the audit record. Your board sees documented AI return in the quarterly review. Same outcome, different durability. A home health operator with 400 field staff, losing 45 minutes per patient visit to documentation requirements. The AI can generate the draft from visit notes, but it needs the patient record from the EMR, the electronic medical record system where patient clinical data lives, and the billing codes from the RCM system, Revenue Cycle Management, the platform that handles medical billing and claims and write access back into the clinical workflow. There is no CLI for an EMR. There is no terminal command for an RCM platform. These systems don't have command line interfaces. The connectivity layer, MCP servers configured for each clinical platform, is the only viable path. And in healthcare, the governance layer isn't optional. Every access to a patient record must be logged, timestamped, and attributable to an authorized action. That isn't architecture preference, that's HIPAA. The optimization API deploys the documentation intelligence across all 400 staff inside the existing EMR workflow. Clinicians open the same screen they've always opened. The output is already there. A SaaS Portco, software as a service, meaning the company sells software subscriptions rather than physical products, running Salesforce, HubSpot, and Stripe, wanting daily churn signals without a data team to build them. With Stripe's MCP support announced this week, the Salesforce MCP server and HubSpot's connector, the connectivity layer already exists, built by the vendors. The optimization API packages the churn logic once, billing patterns from Stripe, activity signals from Salesforce, engagement patterns from HubSpot, weighted by whatever the customer success team knows about their specific customer base, runs every morning, digests to the CS team, task auto-created in Salesforce for at-risk accounts, Block, the parent company of Square and Cash App, which co-developed MCP with Anthropic, reported 50 to 75% time savings for employees running this kind of governed multi-system stack, 30 to 60 day deployment through MIP, not a six-month internal project. Now the headless AI connection and why it matters for Software Portco specifically. If you heard the Headless AI episode, you know that the major enterprise software platforms, Salesforce, Microsoft, and others, have restructured themselves so that AI agents can run their entire platforms without a human ever logging in. The CRM, the workflow engine, the data layer, all of it accessible through APIs, MCP tools, and CLI commands. Headless means the software runs without the graphical interface driven entirely by agents. For most portcos, that's a capability to use. For portcos that are software companies, companies that sell software products to customers, headless AI is a modernization imperative. If your product still requires a human to log into a screen to do everything, and the company selling against you has gone headless, your product is slower, less automatable, and more expensive to operate than theirs. The path forward for software Portcos is to expose their platform through APIs and MCP servers so that AI agents can drive the product. That is the modernization conversation we have with software company Portcos, not rip and replace, add the connectivity and governance layers on top of what exists, and the product becomes agent compatible. Paragon builds that as part of MIP delivery. For channel partners, TSDs and the MSP networks they represent, I want to be direct about something. Most channel partners know AI in two ways. They know the AI features built into the CX platforms they already sell, CX meaning customer experience, things like contact center software, chat, and support tools, the sentiment analysis, the smart routing, the AI-assisted agent tools built inside vertical software. And they know AI productivity tools, chat, GPT, and Microsoft Copilot from their own use. That is the frame most channel SES, sales engineers, are working from when a client asks about AI. That frame isn't wrong, it's just one layer of the stack. What we're covering today, MCP CLI, governance infrastructure, MIPBARB, is the layer underneath the applications that powers the third type of AI we at Paragon call efficiency AI and drives cross-system automations. It's the layer that determines whether the AI your client buys actually connects to their business systems, runs safely, and can be audited. The AI application layer is what the client sees. The infrastructure layer is what makes it work. MCP is the connectivity standard for AI agents, the way SIP was the connectivity standard for unified communications. Before SIP, every phone system required a custom integration with every other phone system. After SIP, one standard, universal compatibility, and the entire UCAS category became possible. MCP is doing that for AI agent connectivity across the enterprise software stack. Every business system your clients run will have an MCP server. The major vendors are already shipping them. One standard interface instead of one-off integrations. CLI isn't just a developer productivity tool, it's a legitimate enterprise transport. AWS, Azure, and Google Cloud CLI all have enterprise grade auth, logging, and access controls built in. A well-governed CLI is more secure than a poorly configured MCP server. And 88% of MCP servers currently have insecure credential handling. CLI also fills gaps MCP can't. Plenty of mid-market ERP and legacy platforms don't have MCP servers yet, and won't for a while. The real distinction isn't CLI versus MCP, it's governed versus ungoverned. Whichever transport reaches your systems, CLI, MCP, or direct API, the question is whether there's a governance layer on top. That's the managed service, that's MIP, and that's the conversation that belongs on the invoice. Paragon is in the TSD and MSP channel specifically to be the managed intelligence provider that channel partners can deploy at their clients. When a client needs a CLI built, we build it. When they need an MCP server, we build it. When they need both, we deliver both with the governance layer on top. The channel partner earns the margin, the client gets a managed service, Paragon delivers and runs the AI program. That is the MIP motion through the channel. For MSPs, the business model case for owning the AI governance layer is the same case that made network infrastructure sticky. When their Salesforce vendor changes an API, you update the MCP server. When they add a new system, you add the server. When their compliance team needs an audit trail for what the AI accessed, you pull the log. You are the integration layer and the accountability layer. Every workflow a client runs through your governed MIP stack deepens the relationship with your practice rather than with any software vendor. That compounds. Gartner predicts 40% of enterprise applications will include AI agents by end of 2026. Every one of those agents needs connectivity and governance. The channel partners who can deliver that through a managed service are going to be positioned the way network layer MSPs were positioned in 2012. What to do this week by audience. PE operators and portco leaders. Three questions for your CTO. One, where are your AI agents running and what systems can they actually touch? If the answer is individual laptops, shared credentials nobody owns, or I don't know, the governance conversation needs to happen before the next AI subscription gets purchased. Knowing what your agents can access is the baseline for operating them responsibly. 2. Do you have audit logs for what your AI tools did last week? Not for the quarterly slide, for operational visibility. If an agent moved data or touched a customer record and you can't explain what happened to your C so you're one question away from a pause on everything. 3. Stripe, Google, Shopify, Salesforce, and Adobe all shipped MCP connectivity in the last 30 days. Which of those are systems your portco runs? The integration work is done. The MCP servers exist. The question is whether your infrastructure is in place to use them safely, and whether you have a partner who can build and govern that stack for you. For MSPs, build one reference deployment before you pitch the next client. One client, three of their most used systems, MCP servers configured for each, governance gateway on top, AI tools connected through MIP, then document every step, that is your productized offering. Every deployment after that is the same playbook. For channel partners, strongly consider partnering with a managed AI provider who can actually deliver governed AI infrastructure. Not a chatbot vendor, not a copilot reseller, a managed intelligence provider who builds and runs the full stack, CLI when needed, MCP when needed, governance always, deployed in the client's environment, accountable for outcomes, billed monthly through your channel. Stripe dropped 288 announcements this week. OpenAI shipped four CLI versions in eight days. Google connected their entire cloud stack to AI coding agents. The Linux Foundation owns the protocol. Every major software vendor is shipping MCP servers now. The companies that come out ahead aren't the ones who picked the right side of a developer debate. They are the ones who got the three layers right: execution, connectivity, governance, and built their intelligence on data they own through a managed service accountable for delivering real outcomes. That is what MIP is. That is what we're doing at Paragon. Everything referenced today is in the show notes. Go back and listen to the Harness episode and the headless episode if you haven't. This one is the third part of that story. If this was useful, send it to one operator or one channel partner who needs to hear it. So, that's a wrap for today. I hope that you're outside on a walk right now. I guarantee that the AI space will have changed by the time you get back. Ha! Cheers!