Open Reader

Which AI startups actually land enterprise contracts? — Brian Lewis, Millennium

completed 18:44 Aug 29, 2026 Watch on YouTube

Current Status

completed

Video ID

7A65O-0lvKE

RAG / Chat

Enabled
Which AI startups actually land enterprise contracts? — Brian Lewis, Millennium
Description

For a given internal pain point, Brian Lewis might find 10 to 15 startups worth a look, book two or three demos, run zero or one pilot, and sign roughly one contract for every four pilots. That works out to about 5% of demo calls ending in a signature, which turns out to match published benchmarks. He is on the buying side at a hedge fund, speaking personally rather than for his employer, and the talk is a catalogue of exactly where the other 95% dies. The examples are specific enough to sting. A vendor asked them to self report their own gateway telemetry so it could charge margin on traffic that never touched vendor infrastructure. Integrations that only function if granted read and write access to everything. Features held permanently in beta because the beta terms permit data retention. A team claiming zero data retention that revealed it had their data by mentioning something it could not otherwise have seen. Asked what happens in a breach, one vendor answered that they had not had one yet. His larger argument is that none of this is really an AI problem: a new frontier model lands every 11 days while the architecture underneath is a decade old, and he puts perhaps 60% of becoming AI native on entitlements, integration and change management. Agents inherit whatever foundations you already had. Speaker info: - https://www.linkedin.com/in/brianthomaslewis/ Timestamps: 0:00 - Sellers and buyers in the same room 2:52 - The funnel, and the 5% that signs 4:16 - Efficacy: solving the problem, and pricing it 5:36 - Pilot windows collapsing from months to weeks 6:57 - Security requirements from the buyer's side 8:19 - What goes wrong in security, repeatedly 9:42 - Reliability, control planes and audit logs 11:04 - An outage during a trading day 12:23 - Legal, retention clauses and fourth party risk 13:44 - A model every 11 days, architecture a decade old 15:07 - The unglamorous 60% 16:28 - Entitlements, and why agents multiply the problem 17:54 - The recipe for each

Summary

Generated by gpt-5.6-terra

At-a-Glance

  • Verdict: Watch fully
  • Core thesis: AI startups win demanding enterprise contracts not by having the flashiest model wrapper, but by proving measurable value while meeting enterprise requirements for deployment control, security, reliability, legal protections, and operational integration.
  • Why it matters: The talk is a buyer-side account from a highly regulated, security-sensitive enterprise of why roughly 95% of demos do not become contracts—and what agent and AI-platform builders must operationalize to clear that bar.
  • Best use: Use it as an enterprise-readiness checklist for evaluating AI vendors or hardening Ken's own agent/control-plane offerings before selling into regulated or large organizations.

Executive Summary

Brian Lewis, who evaluates products at Millennium, argues that current AI capability is not the primary constraint on enterprise value. In his experience, a typical pain point produces 10–15 candidate startups, 2–3 demos, zero or one pilot, and only about one contract for every four pilots. The resulting roughly 5% demo-to-contract conversion rate fails mostly on efficacy and commercial fit, then security, reliability, and legal readiness—not because enterprises lack interest in AI.

The enterprise-ready vendor must solve a defined problem, price against real delivered value, demonstrate integrations immediately, and allow the buyer to set success criteria. Lewis is especially critical of vaporware, margins added on customer-owned model traffic, open-ended promises after demos, and sales teams that keep pitching features the buyer has rejected. Pilot windows are also shrinking rapidly—from about six months to three months and, increasingly, as little as two weeks—so vendors need a deployable product rather than a roadmap.

For a regulated buyer, security and operations are product capabilities. Lewis expects zero data retention where possible, customer-managed keys that do not degrade functionality, bring-your-own gateway and infrastructure options, SCIM-connected RBAC, API-configurable controls, auditability, reliable versioned releases, real SLAs, and reachable support engineers. He describes common disqualifiers: broad read/write scopes, unannounced default-on beta features, undocumented architecture, data sent to vendor systems against instructions, and retention loopholes hidden in beta terms or subprocessor disclosures.

His broader conclusion is that becoming AI-native is roughly 40% models and products and 60% "boring" foundations: data hygiene, architecture, integrations, enablement, change management, identity, governance, and centralized knowledge. AI is a flashlight rather than a Band-Aid: it accelerates good systems but exposes and amplifies broken ones. This is particularly acute for agents, which inherit existing entitlement failures and can magnify rogue permissions or processes by orders of magnitude.

Key Takeaways

  • Claim: Only a small minority of AI startups that reach an enterprise demo will ultimately receive a signed contract, because enterprise buying is an operational qualification process rather than a model-capability contest. | Evidence: For a single pain point, Lewis may identify 10–15 startups, take 2–3 demos, run zero or one pilot, and convert only about one in four pilots; he estimates that about 5% of demos result in a contract and says this tracks industry benchmarks. | Implication: A startup should optimize for clearing procurement, security, deployment, and support gates before scaling top-of-funnel enterprise sales; a buyer should use these gates early to avoid expensive pilots. | Caveat: These figures are Lewis's experience and characterization of industry benchmarks, not a disclosed universal dataset.
  • Claim: Efficacy means buyer-defined, immediately demonstrable business value—not a plausible roadmap or a generic AI wrapper. | Evidence: Millennium expects the product to solve the stated problem, integrations to be demonstrated on day one, pricing tied to real value, and success criteria written by the buyer. Lewis cites vendors pitching functionality Millennium could rebuild in roughly six weeks, promising features without ETAs, and asking to mark up LLM traffic that already passes through Millennium's own gateway. | Implication: For AI products, articulate the durable advantage beyond model access or a thin wrapper, show the target deployment path live, and structure commercial terms around value and actual cost ownership. | Caveat: Being easy for an enterprise to rebuild is not automatically disqualifying; Lewis notes buying can still make sense when the vendor provides sufficient value beyond implementation.
  • Claim: Data control, identity controls, and least privilege are baseline product requirements for security-sensitive enterprises. | Evidence: Lewis calls for zero data retention where possible; customer-managed encryption keys that do not break the product; buyer-controlled model gateways and infrastructure; SCIM-tied RBAC; API-configurable entitlements; and at least one genuine security hire at smaller vendors. He reports pilots where vendors sent data to their own cloud despite instructions and integrations requiring read/write access to everything. | Implication: Agent systems need granular, externally managed authorization and customer-controlled data paths by design. Avoid all-access OAuth defaults and architecture that requires unrestricted vendor-side access. | Caveat: Zero data retention may not be feasible for every product design, but the alternative must preserve enterprise control and be explicitly understood rather than obscured.
  • Claim: Reliability and administrative control are core enterprise features, especially when AI products enter production workflows. | Evidence: Millennium expects every admin setting available through APIs, audit logs for configuration changes, controlled rollouts, versioned documentation, real SLAs, status pages, and access to a support engineer. Lewis cites vendors shipping multiple daily client updates across 3,000 users, leaving the enterprise unable to know which versions were deployed or diagnose breakage; he also cites a core API outage lasting multiple hours during a busy trading day. | Implication: Build a proper control plane: policy APIs, immutable or queryable audit trails, release rings, version pinning, incident communications, and human escalation paths should be part of the product, not post-sale promises. | Caveat: The required uptime and change-control standard will vary by workflow criticality, but regulated and revenue-critical deployments cannot treat production releases as consumer-app updates.
  • Claim: Legal claims around privacy, training, and third-party risk must exactly match product behavior; hidden exceptions can destroy trust even if the core product is useful. | Evidence: Lewis requires no training on Millennium data, transparent subprocessors and fourth-party risk, and IP indemnification with reasonable liability caps. He describes vendors claiming zero data retention but later revealing they had inspected retained data, as well as products placing permissive retention rights in beta-feature clauses and disclosing fourth-party risk only on an unreferenced website page. | Implication: Product, security, legal, and sales claims need a single source of truth. Treat beta features, telemetry, support access, and every subprocessor as components of the enterprise data-governance design. | Caveat: The specific indemnity and liability terms are negotiable and buyer-dependent, but undisclosed data handling is presented as an immediate trust and risk failure.
  • Claim: AI-native transformation depends more on foundational enterprise modernization than on selecting better models. | Evidence: Lewis estimates, explicitly as an unscientific hypothesis, that 40% of the work is models and products while 60% is data hygiene, clean architecture, integrations, enablement, and change management. He contrasts frontier models arriving about every 11 days with enterprise architectures and ERP migrations that can be a decade old or years in progress. | Implication: Do not frame AI deployment as a standalone tooling purchase. Prioritize the organizational and technical foundations that determine whether agents can access trustworthy data and execute safely. | Caveat: The 40/60 split is directional rather than measured, and the balance will differ by organization.
  • Claim: Agents amplify existing entitlement and knowledge-management failures, making identity architecture and centralized knowledge urgent prerequisites. | Evidence: Lewis says agents inherit enterprise foundations and can "100x" problems when people, processes, or permissions go rogue. He identifies broken entitlement models, cross-platform integration, centralized and machine-consumable documentation, and potentially separate experimentation environments as lessons from internal AI evaluation. He references the idea of "thinner agents and a smarter substrate." | Implication: Before granting agents broad cross-system access, remediate over- and under-entitlement, centralize operational knowledge, establish governed connectors, and isolate experimentation from production where necessary. | Caveat: A separate experimentation ecosystem may be warranted only where the gap between legacy systems and the desired AI environment is too large to bridge safely in place.

Detailed Brief

Enterprise sales and pilot operating model

  • Claims: The buyer expects the vendor to listen closely to requested requirements rather than repeatedly re-selling declined features.; Fast AI product cycles have shortened the buyer's tolerance for long, exploratory pilots.; A credible startup should arrive with a concrete 90-day deployment plan into the customer's infrastructure and cloud environment.
  • Evidence: Lewis says vendors often make commitments during demos but cannot provide an ETA even after two months.; He observed pilot expectations move from roughly six months to three months and then, increasingly, two weeks.; His closing checklist names a working security architecture, responsive support, an admin API from the start, a 90-day deployment plan, and buyer-authored success criteria as characteristics of the best vendors.
  • Caveats: A compressed pilot does not eliminate diligence; it increases the premium on pre-pilot architecture validation and a narrowly scoped success metric.
  • Implications: Qualify enterprise opportunities with a mutual technical acceptance plan before the demo, including deployment model, required controls, named integrations, evaluation data boundaries, and decision criteria.; Treat unresolved architecture diagrams, missing security ownership, and absent timelines as stop signals rather than issues to defer until after a pilot begins.

What the buyer means by an AI-native enterprise

  • Claims: Cross-platform integration has become more important because AI usefulness is constrained by what systems and knowledge it can safely reach.; Centralized documentation, support material, and operating knowledge should become an accessible substrate for agents and humans.; AI may help keep that knowledge current through a feedback loop, but it cannot compensate for fragmented or unreliable source systems.
  • Evidence: Lewis characterizes AI as a flashlight: it reveals and accelerates what already works, while breaking down quickly on existing technology-estate problems.; He suggests organizations may need a separate environment to experiment where legacy constraints make direct modernization impractical.
  • Caveats: Centralization should not mean indiscriminate access; the same entitlement and governance requirements apply to the knowledge substrate.
  • Implications: Architecture strategy should distinguish between the agent layer and the underlying knowledge, permissions, integration, and policy substrate.; Enterprise AI roadmaps should include modernization sequencing, not merely a list of model or copilot deployments.

Notable Concepts & Terms

  • Zero Data Retention (ZDR): A buyer requirement that vendor systems do not retain enterprise data; Lewis treats claimed ZDR that is contradicted by actual data inspection or logging as a serious trust failure.
  • Customer-Managed Encryption Keys (CMEK): Customer-controlled encryption keys used when full zero retention is not possible; the implementation must preserve product functionality rather than exist only as a sales checkbox.
  • Bring Your Own Gateway (BYO gateway): The enterprise routes model traffic through its own LLM gateway, preserving visibility, control, and cost governance rather than handing traffic to a vendor-controlled intermediary.
  • SCIM-tied RBAC: Role-based access control connected to enterprise identity and directory groups through SCIM, allowing granular, centrally managed permissions rather than universal feature access.
  • Control plane: The administrative layer for configuration, policy, rollout, and auditing; Lewis considers API-accessible controls and configuration audit logs fundamental to production readiness.
  • Fourth-party risk: Risk introduced by a vendor's subprocessors or their dependencies; enterprises need it disclosed transparently in contractual risk management rather than hidden on a web page.
  • Thinner agents and a smarter substrate: A model in which agents remain relatively lightweight while centralized knowledge, integration, permissions, and governance form the durable enterprise intelligence layer.
  • AI as a flashlight, not a Band-Aid: Lewis's framing that AI exposes and magnifies existing data, architecture, process, and entitlement quality; it does not repair those weaknesses automatically.

Operator Notes / Why Ken Should Care

  • Create an enterprise-readiness gate for any agent or AI platform: deployment topology, data-retention behavior, key management, gateway routing, SCIM/RBAC, admin APIs, audit logs, release controls, SLA/status page, incident response, and subprocessor disclosure.
  • Require least-privilege scopes and explicit feature flags for every connector; reject product designs that need blanket read/write permissions to prove value.
  • Define pilots around buyer-owned success metrics and a short, testable implementation plan; do not enter a pilot with unresolved security architecture, integration feasibility, or ownership of model-traffic costs.
  • Audit agent permissions against existing human entitlements before expanding cross-system autonomy, with particular attention to over-entitled groups and inherited service-account access.
  • Separate experimental agent environments from production where legacy architecture cannot yet support required governance, observability, and change control.

Source/Metadata

  • Title: Which AI startups actually land enterprise contracts? — Brian Lewis, Millennium
  • Transcript words: 3826
  • Duration seconds: 1124
  • Timestamp note: No timestamps or chapter markers were present in the supplied transcript.

Transcript

3514 words en Processed in 124.9s

Welcome everybody. Sorry for everybody who is already here and missed the Coinbase guy. I have no idea where he went or why he didn't come. I was actually pretty excited to hear about his comments. But today I'm going to talk about which AI startups actually win enterprise contracts. To begin, I thought this was going to be a different audience. I didn't realize this was going to be mostly people on the leadership track. I thought I was going to be speaking to more AI engineers. So maybe just by a show of hands, how many of you represent the engineering or startup or seller side? And then how many of you represent maybe the buyer side? You're in the enterprise, you're trying to get these tools in. Okay, so we got a good mix. I'm going to try to balance that out today. I work on product stuff at Millennium, which is a hedge fund. We build a lot of stuff. I can't talk about any of it. So I'm going to talk about stuff that we look at and evaluate. It's going to be pretty generic. I tried to make it as interesting as possible while still getting my compliance department to be okay with me doing this. But I also need to say legally that I'm speaking as an individual. I am not representing my company, and all opinions are my own. So with that, we can dive in. So I ran through this with my parents last week. I grew up not that far from here. And my mom said, why are you spending your time teaching vendors how to sell to you? Aren't you busy enough already? And the real answer to that question is I really like how stuff works. I like seeing stuff come together. My bachelor's degree was in economics. And I really love seeing things work well. So AI has been really interesting because it's a whole new paradigm of how businesses are doing work. That's the whole point of this track, this AI native enterprise track. And so even though I don't need more people DMing me on LinkedIn, I am actually really excited to talk about this. So my hypothesis, in short, is that at current model intelligence, most of the value available is already being left on the table. This is not a hot take for most people, I think, who work in enterprise. You've probably seen this problem. This little stat at the bottom is pretty heavily repeated for a lot of people who work inside of business circles. And they all laugh and they're like, yeah, yeah, all these AI tools. How much are they actually doing? And I want to talk about why. So there's two sides to this becoming Gen AI native. You have models and products, which are one side. That's the seller side. And then you also have systems and all of what's inside of the enterprise. That's the buyer side. So that's the side that I deal with a lot. So we're going to talk first about the seller side, and then we're going to talk about the buyer side. So per pain point, a lot of my job is to go around the company and figure out what are the pain points. What are we trying to solve for? Can we buy it? Can we build it? So let's say for a game, a given pain point, maybe I identify 10 to 15 startups that look really interesting. Maybe these guys can solve a problem for us. We don't have to build it. Of those, after doing a little bit of due diligence on my own, I might schedule two to three demo calls. Of those, we probably will land zero or one pilots. And of those, probably one in four of those, longer term, will actually end up with a contract. So what does this mean? This means about 5% of all of our demo calls actually end up in a signed contract. And this tracks with the industry. I had no idea that this was actually a benchmark. But it turns out that there's quite a bit out there that indicates that this is really similar across the board. So I want to talk about what enterprise ready actually means from the inside. Because we have a lot of startups that tell me what enterprise ready means. And then we go through all of our requirements. And then we have a very different idea of what enterprise ready actually means. So we're going to talk about what breaks down and why. So 40% of this is efficacy. So just value, commercial issues. Then a lot dies in security. Other things die in reliability. And then some stuff dies in legal. So we're going to start with the requirements that we put forward. And then some of the things that we've seen go wrong across various AI companies that we worked with. So our requirements for efficacy. Maybe unsurprisingly, the product actually needs to solve the problem. That seems pretty clear, but that's not always super clear. The next one is pricing models that need to reflect real value. Clear demonstration of integrations on day one. Not a hypothetical. And we define the success criteria, not the vendor. So things we've seen go wrong. Vaporware, in short. We've had a lot of startups who come in and pitch us an idea. And it's something that our platform team can rebuild in about six weeks. So this is not a knock. This is actually just what's going on in the industry everywhere, on all sides of the equation. Sometimes it's actually better for us to build, and sometimes it is still better for us to buy, even if we could rebuild. Upside down pricing. So this one's crazy. We had a startup just recently tell us, hey, we know that all of the LLM traffic that we're using for our wrapper is passing through your LLM gateway. But we want you to report your gateway telemetry to us so that we can then price a huge margin on top of that, even though none of it's running through our infrastructure. That did not work. Another one is promises in demo calls, but no ETAs after two months. This is pretty common. Not a lot to say here. And then re-pitching features we've already declined. So if you're a salesperson, my best advice to you is listen to your customers. It's not novel, but it still seems to be a struggle for some. It's really just better to address the things that we've asked for. So the other thing I want to point out at the very bottom of this slide is the pilot window collapsing. So I've been at Millennium for a little over two years. And when I started, a lot of these pilot timelines that people were used to were like, oh, maybe we'll run a pilot for six months. And then not that long after that, it was like, oh, maybe we only need it for three months. And now it's like, maybe we can do this pilot for two weeks because it's just accelerated so rapidly. So then moving on to security. This is a huge one. I'm not a security expert, but I do run frontline defense on talking to a lot of startups about security. And so these are a lot of the things that come up over and over. ZDR. So this is a really hot topic. Obviously, a lot going on with Fable, mandatory data retention requirements, and then a whole other battleground around customer-managed encryption keys. So ZDR is always best, of course. If that's not possible, customer-managed encryption keys, and with a big parenthesis, that don't break the product. There are a lot of things that people are like, oh, yeah, it's fine. It'll work with customer-managed encryption keys, and then it breaks the product. So that's a big product issue that we have to work through with people. Other requirements, bring your own gateway. We prefer to route all of our own traffic through our own gateway, and BYO infrastructure. We would prefer to host it in our own cloud infrastructure and have something that's deployable in our systems. This is another really big one. SCIM-tied RBAC. So for all of you who get that jargon, it's really important that we can tie our AD groups or other permission and entitlement groups to role-based access control. We want to make sure that we don't just turn on features for everybody across the board. A lot of people don't think about this when they're designing their systems. They're like, oh, this is a great feature. We should just turn it on for everybody. When you work at a massive enterprise, that's not something that people want to do. There are usually different groups who should have different access at different times, and most of all, we want it to be configurable via API. For smaller companies, we want to see at least one real security hire. So this is something that's really important. We know that security is not the first thing that people hire for, but in the age of AI, this is a very real problem, and we need to make sure that the startups we're working with actually have somebody who can understand what's going on from the security standpoint. So some of the things we've seen go wrong: outright people just sending data to their vendors' cloud servers, and not for the cloud. Following any of what we've asked for. This has been a problem in pilots. Thankfully, all of our pilots run on production data. Another one, like we talked about, read, write all default scopes. So there's a lot of really cool tools out there, integrations features. There are usually different groups who should have different access at different times, and most of all, we want it to be configurable via API. For smaller companies, we want to see at least one real security hire. So this is something that's really important. We know that security is not the first thing that people hire for, but in the age of AI, this is a very real problem, and we need to make sure that the startups we're working with actually have somebody who can understand what's going on from the security standpoint. So some of the things we've seen go wrong: outright people just sending data to their vendors' cloud servers, and not following any of what we've asked for. This has been a problem in pilots. Thankfully, all of our pilots run on production data. Another one, as we talked about: read, write all default scopes. So there's a lot of really cool tools out there, integrations, features. They're really flashy. You can click a button, and it'll integrate with everything, and then you get a little bit deeper and find out the only way that it'll work is if you literally give it a read, write all to everything, which is a huge problem. Another one, along the same lines: all new beta features on by default with each release. So if you're an enterprise, you don't want everything just turned on with each release. So being able to control that. And then the line that we hear a lot, which is we'll get you the security architecture diagram next week. We do weekly check-in calls during a pilot, and then we hear this over and over. It's not usually a great sign. The question that we often have our CISO end up asking, which is what are you going to do if there's a breach? And we get this response: well, we haven't had a breach yet. With the subtext that we don't know what we would do if we did. Okay, reliability, this is another one. So, control plane that actually works. We want to see every admin setting available via API. We want to see audit logs on config changes. So if there are five different people who are given admin access and somebody accidentally changes something, or does it because maybe it was really late at night and maybe they had too many drinks, we actually want to see what happened. We want to be able to control the rollout on these changes. We want to see real SLAs and a reachable support engineer. That goes a very, very long way. So things we've seen go wrong. A lot of apps that are rapidly prototyping. They're shipping so quickly that they are maybe shipping updates multiple times a day. And there's a really attractive little button that says relaunch to update. And it happens across 3,000 people. We have no way of tracking what's going wrong. Maybe then SSL certificates break in one of the new releases. And then we have no way of tracking because everybody's on a different version. And we have no way of being able to deploy at scale. That's really challenging. No documentation versioning. So support articles with new terms or risks that are not actually in the legal contract, but show up on the website somewhere in a random support page. And then we have no way of tracking what they were before versus after. And it just says updated yesterday. All of these are real examples, by the way. I am not naming and shaming. I'm just shaming. So maybe if any of you are familiar, you can put it together. Core API is down for multiple hours during a busy trading day. That is a really big problem for us because we run production systems. We are trading billions of dollars. This is a really big issue for us. And then lastly, no SLA roadmap or status page. The status page is a big one. Okay, last, legal issues. So we don't want anybody training on our data, regardless of what type of feature or product it is. We also want to see a lot of transparency in the subprocessors. Any fourth-party risk becomes our risk. We want to see IP indemnification with reasonable liability caps. We do not control the models. So if there's output that is IP infringing, we don't want to be held liable for it. So we have seen in pilots that people claim they have ZDR. They have it legally. But then they find out, or we find out later, that they actually retain some of our data because they say, hey, we were looking at something and we noticed this thing. And we're like, how did you notice that? You weren't supposed to have this data. And they're like, oh, yeah, you're right. So that's not great. If you say ZDR, do ZDR. Next, every feature that is conveniently beta with permissive data retention clauses. So we've seen some vendors who will stop releasing new features in general availability. They will only make them beta. And then the beta comes with a secret little clause that says that they're allowed to retain our data, which is a very sneaky way of trying to get our data. We don't like that. Not great. Another one, similar, is fourth-party risk that's tucked away on a random website page that's not listed in the contract. This is a really big problem for us managing risk. So it was the best of times. It was the worst of times. As a recap, the best startups have security architecture that actually works. Support engineers who respond. An admin API from the beginning. A 90-day plan that deploys into our infrastructure and cloud. And success criteria that we write. The worst AI startups don't have any security architecture diagrams. No path to a support engineer. No deployment control or audit logs. No ETAs. And salesmanship over solid product billing. This is really just a recap of what I have been through over the last two years. I actually don't think that any of this is novel. But it is codifying a lot of what I feel is good and best practice. So a new frontier model comes out every 11 days. But your architecture might be a decade or more old. So you have a bunch of cool new models. There are some amazing capabilities out there. And then you have profitability on the other side of it. And what's in the middle? Maybe it's your legacy architecture. Probably a lot of security and privacy issues. And a lot of change management. ChatGPT has only been out for 43 months. There are a lot of companies who are still doing an ERP migration that might have been from five years ago. So the timelines are very asymmetric. And I think that sometimes we forget about that. Okay. So my thesis again: half or more of getting AI-native is unsexy and has absolutely nothing to do with AI. AI models and products today can't fix your legacy architecture. Although if any of you are startup people, that's a great one to go for. And it also can't run your change management. These are unscientific numbers that I'm putting up here. But I hypothesize that 40% of getting to AI-native is AI models and products. The other 60% is all the other stuff that no one really likes talking about anymore, which is data hygiene, clean architecture, having good integration, strong enablement, and change management. I really look at AI as a flashlight, not a Band-Aid. I really think that AI shines a light on a lot of what's already working or not working. It can accelerate what's working really well, and it breaks down very quickly when things don't work well. I don't think that it's a Band-Aid. And I think that for everybody who's in tech leadership, it's really important to remember that if you have issues in your technology estate, those need to be addressed before trying to plug in AI and just having everything rip. It's not going to work. So, again, maybe an unpopular message, but I really believe that we all need to start with the boring 60%. I think that's where we all need to start to get to the other side of the road. So, what did we learn as we shine the flashlight internally? Again, not revealing anything super proprietary, but I do think these are big-picture lessons. Number one, entitlements. Entitlements need a new paradigm. There are a lot of people in a lot of large enterprises who are over-entitled, under-entitled. The entitlements model and how it works and how it's managed, all of that breaks down when you think about agents and how quickly you want agents to work and what you want them to work on and their ability to exercise judgment. The entire paradigm just shifts. Another one is cross-platform integration moved up the stack. So AI is only as good as what it reaches, and we want it everywhere. So having things that can integrate across platforms is really important, even more than it already was. Another one is centralized knowledge. So this is something that Emil brought up this morning in his keynote, which is that basically we need thinner agents and a smarter substrate. Centralized knowledge is really key to that. So all of your documentation, all your support articles, everything that's going on inside of your company that's making it work, all of that needs to be centralized and easily consumable. Even better, if AI can help write that in real time in a feedback loop. That's something we've been talking about with some of our vendors. Another one is a separate ecosystem for experimentation. The entire paradigm just shifts. Another one is cross-platform integration, moved up the stack. So, AI is only as good as what it reaches, and we want it everywhere. So, having things that can integrate across platforms is really important, even more than it already was. Another one is centralized knowledge. So, this is something that Emil brought up this morning in his keynote, which is that we need thinner agents and a smarter substrate. Centralized knowledge is really key to that. So, all of your documentation, all your support articles, everything that's going on inside of your company that's making it work, all of that needs to be centralized and easily consumable. Even better if AI can help write that in real time in a feedback loop. That's something we've been talking about with some of our vendors. Another one is a separate ecosystem for experimentation. Some companies may need to get here. That gap between your legacy architecture and where you want to go might be so vast that you actually just decide, hey, maybe we need a separate ecosystem to do a lot of this work, figure out what does work and what doesn't, and then go from there. And that's something that we thought about as well. So, to just put a finer point on the agents and the entitlement thing, agents inherit your foundations. So, I strongly recommend that everybody fix their entitlements if they're not working really well now. Because this is something that, if you think about the problems that you run into when things go rogue, processes go rogue, people go rogue, agents are going to 100x that problem. So, this is really something that's worth figuring out now. So, to recap as I wrap up here: The recipe, if you are one of the people in the first half who were raising your hand on, what do I need to do if I'm a start-up and I want to work with a really difficult large customer? Millennium's got 8,000 people. We have very, very tight security, compliance, and regulatory requirements. This is the stuff that we care about. And we want to see more start-ups doing work that allows us to work with them. I really view this as one of the highest bars. We're probably not the highest, although we're probably pretty close. And I think if you can architect your start-up to work with companies like this, with this kind of architecture, you're probably going to be able to satisfy everybody else. On the other side, for anybody who's buying, these are the things that I think, again, that boring 60% that really deserves a lot of work: auth entitlements, governance, audit logging, et cetera. These are the things that I think we need to have in terms of systems to get it working on the other side of the equation. So, that's it. My only motivation here is getting stuff working better and having better enterprise-grade AI.