Every enterprise AI rollout has a moment when the vendor’s engineers arrive and start asking for things nobody wrote down. Access to a system, an export of last year’s data, an owner for a field mapping, a security review that was never scheduled. Ged Ossman thinks most of what goes wrong with enterprise AI happens in that moment, and on this episode he described the company he is building in one line.
“So at Interf today, we are teaching agents to self-onboard in enterprise environments. Today, they are like deployed blindly, and we kind of have this inefficient AI implementations today between vendors and enterprises.”
Ged Ossman, at 1:41
Ged is the founder and chief executive of Interf, which his LinkedIn dates to February 2024 and which lists its headquarters in Salesforce Tower in San Francisco (LinkedIn). Before Interf he spent six years as the first technical member of the founding team at Copper, the institutional digital asset custody and settlement company in London, where his LinkedIn says he built the backend of the custody and settlement products and then the data and BI systems for the stretch when the company grew from 100 to 300 employees in two years. Before that he was an engineer at Dolfin in Amsterdam and London, and before that he co-founded Sunrise Group, a platform for remote IT support (LinkedIn). His profile also lists operating systems research with Microsoft’s Singularity project and Google’s Android, an Intel ISEF Grand Award in computer science, and a minor planet named after him by MIT Lincoln Laboratory. On this episode Ged tells me why AI rollouts stall mid-flight, why he keeps reaching for operating systems to explain the fix, what a pre-flight check is, and why the protocol he was writing belongs to a foundation rather than to his company.
Where we sit, so you can weigh what follows: YSecurity helps startups pass the security and compliance reviews enterprise buyers run, from the first questionnaire to SOC 2 and ISO 42001. In Ged’s terms that puts us on both sides of the readiness gap, with the vendors who have to say what their agents need and with the buyers who have to say whether they can supply it. I hosted this one on my own. We recorded in January 2026, per the episode notes, when an open-source agent then called Clawdbot was the thing everyone in tech was talking about, and the episode aired on July 14, 2026.
Agents that onboard themselves
Ged’s first answer is a picture of the end state, and it is worth holding in your head for the rest of the conversation. Today a company buys an AI product, the vendor’s people show up, and humans on both sides spend weeks working out what the agent can touch. In Ged’s version the agents do that work, and do it better.
“And our idea was that we see this future where vendors’ agents will communicate with enterprise agents, and they will figure out better than humans how best to integrate all systems and make it compliant, secure.”
Ged Ossman, at 1:56
The key word there is the last one, compliant. Ged isn’t describing an agent that grabs whatever access it can find. He is describing two parties, the vendor’s agent and the enterprise’s agent, negotiating what the integration is allowed to be, with the rules written down where both sides can read them. “So instead of like humans figure it out with each other, I see a way where all these things will be automated and driven by agents.”
I told him I love things that just work when you open the box, and agents are in that category. Most of the episode is about why they don’t yet, and the boring infrastructure that has to exist first. Ged’s own summary of the episode, posted the day after it aired, puts it in one phrase: a deterministic contract for agent context and permissions.
Thanks for having me, Jon! Really enjoyed discussing why AI onboarding should start with a deterministic contract for agent context and permissions.
Ged Ossman (@gedossman) · July 15, 2026
If you want the long version of that idea from our side, we wrote up why agent governance starts at onboarding, not runtime, and how to run a readiness assessment before you deploy one. This page is the conversation those posts came from, with the record beside it.
A frustration-led founder
I asked Ged what got him into this, and he went back to the start. He started his first company when he turned eighteen, left university to do it, and built “IT maintenance, like platform to help IT people solve the problems remotely.” His LinkedIn lists that company as Sunrise Group, from 2013 to 2015, with Ged as co-founder and chief technology officer. Interf came from somewhere else, and he named it plainly: “I would define myself as a frustration-led founder.”
“I experienced hyper-growth scale, where in my previous venture we scaled from 100 employees to 300 in just two years. And I saw how departments scale, how department leaders figured out the ways how to scale their functions and support the business. And I was like, oh my God, this is so inefficient today.”
Ged Ossman, at 3:10
The previous venture was Copper. Ged’s LinkedIn describes the job in two halves. From zero to the Series A he built the backend of the core products, custody and settlements. From the Series A to the Series C he built the data and business intelligence systems that supported the hyper-growth stage, which his profile puts at 100 to 300 employees in two years. That second half is where the frustration came from. When the data person is the one building dashboards for every department, you see exactly how much of the company runs on spreadsheets, side channels and people’s memory.
The question he took away was a specific one: “What value can AI unlock in enterprise, specifically in business operations?” He announced the move himself at the end of 2024, after six and a half years at Copper.
I stepped down in April to found Interf, rethinking how organizations measure and scale operations in the AI era.
Ged Ossman · December 31, 2024
One to ten is a different job
I asked how short a time it took. “For us, it was like two years,” Ged said, and then he made a distinction every founder who has lived through it will recognize. He had been on Copper’s founding team, so he had seen zero to one and one to ten, and he had expected the first to be the hard part.
“My expectation was like zero to one is the hardest part, but actually seeing how many like, what it takes to scale from one to ten and make it efficient, there is a lot of like skills and expertise needed. Not just like on the individual contributor role, but building processes, like functions, establishing and making it work.”
Ged Ossman, at 4:20
“Different job,” he added. It is the same transition we see in security programs. At ten people, security is whatever the most careful engineer does on a Tuesday. At three hundred, it is a set of processes with owners, and the first enterprise customer will ask to see them. The skills that got a company to its first product are not the ones that get it through its first SOC 2, which is why a vCISO is so often the bridge between the two.
Ged’s hope for AI is aimed at exactly that gap. “And I’m excited about how AI can transform it and make it like efficient finally. We’ve all been dreaming about that, you know?”
The iceberg
I asked him to help us see the vision, and Ged answered from a chief information officer’s chair. He had spent the last decade working with asset managers, and he borrowed their model of how money should work.
“I’ve been working like last decade with asset managers, and I always see like this idea where you have assets under management and you deploy capital and you get ROI. So it’s very straightforward.”
Ged Ossman, at 5:34
Companies don’t run that way inside, he argued, because most of the value is invisible to the people who decide where to spend. After scaling a company himself, “I saw how much value still gets locked, and it’s not even surfaced. Like, leaders just don’t know how to uncover that value and how to unlock that value.”
His picture for it was an iceberg. “We always see the problems, the initiatives on top, but everything below the surface is hidden.” The structure of planning keeps it that way: goals start at the board, an executive committee plans the year, and leaders hand those goals down to their teams. “It’s always coming from top.”
Five big initiatives
The part of the iceberg Ged cares about is the person at the bottom who sees a fix. Someone close to the work spots an inefficiency and wants to use AI to capture it. What happens next, in his telling, is a gauntlet.
“There is no real way how this initiative will be executed in enterprise, because you need to build this business case, you need to create this presentation, show to your manager. And usually if this initiative touch security and compliance and requires developers’ time, you need to build this business case, pitch it, align stakeholders, other departments.”
Ged Ossman, at 6:51
Notice where security sits in that list. Any idea that touches data, compliance or engineering time has to clear the same gates as a major project, so small ideas rarely try. Ged called the result “mostly like a zero-sum game, you know, where you have like maximum like five big initiatives, and everything else is more like, it’s not our priority.” And he was fair to the people saying no: “We cannot say yes to them because we already committed to execute the first five, which is fair.”
That is a useful way to read a security review, too. It isn’t the reason good ideas die. It is one of several fixed costs that make every idea expensive to try, and anything that makes the review cheaper, like a clear list of what the tool needs, makes more of the iceberg reachable.
Agentic business operations
Ged’s answer to the iceberg is what he calls agentic business operations: engines that run every day, find the inefficiencies, and bring them to an executive as a decision instead of a project.
“But I see the world, I call like agentic business operations, where AI will be driven like with this self-improving engines that, let’s say, daily runs diagnostics, identify inefficiencies, bottlenecks, ways to improve, ways to create value in this specific domain, bring it, make it visible for executives.”
Ged Ossman, at 8:06
In that world executives become more like asset managers. “Executives just review the pre-built business case, click approve. So there’s like a lot of governance element in this place. I believe still humans are in charge.” He compared it to robo-advisors, where software proposes the portfolio and a person approves it. Then he said the line that turned the conversation toward security: “And AI just installs other AI.”
Under it sits a digital twin of the company. Today the data lives across departments in different systems of record, he said, and once you connect that context into a single picture, “I call like digital twin of like business operations, AI can like see the whole business.” No single person can do that. “We are the bottleneck.”
That was Interf’s first product. In January 2025 Ged launched it on LinkedIn as an operations intelligence platform, with AI diagnostics he described as health trackers placed across a business, starting with revenue operations.
One critical insight about AI in business operations has become clear: even the best-crafted AI solutions fail without a proper organizational context.
Ged Ossman · January 30, 2025
His Forbes Technology Council profile from that period describes Interf the same way, as an applied AI lab building an operating system for operations run by virtual analysts (Forbes Councils). His two contributions to the council’s 2024 expert panels were about the same foundations he talks about on the tape: data quality and traceability as the condition for AI that works (June 2024), and secure, compliant AI integration with outcomes you can trace (July 2024).
The go button
This is where I put on the security hat, because the vision contains two moments that make a security team sit up. The first is the data. The engine that sees the whole business has to read the whole business.
“And when you’re responsible for the security of an organization, that data is very precious.”
Jon McLachlan, at 11:03
Companies build entire security programs around protecting that data, so when an agent gets its hands on it, it’s a big deal. The second moment is the install. In Ged’s picture, an executive clicks approve and the system “pulls in an outside agent, installs it into our infrastructure.” From a security mind, I said, that sounds a little scary at first glance. It is also the whole point of the company’s name. “It’s the interface of what’s acceptable to pull in, and then what’s also acceptable of how to use that data.”
Those are the two questions every review of an AI vendor comes down to: what can it read, and what are we letting in. Most companies answer the first with a data classification exercise and the second with a vendor questionnaire, and neither one is written for software that decides what to do next on its own. If you want to know what your own agents can already reach, that’s what an AI access control audit maps.
Blue screens and shared memory
Ged agreed, and then he did something I liked: he declined to claim the idea was new. “And honestly, I’m not like here trying to bring new concepts.” Engineering has solved this class of problem before, he said, in the place most of us met it first.
“I do think that everyone knows this blue screens of death in Windows operating systems, right? When you install the drivers and suddenly your operating system is like not loading.”
Ged Ossman, at 12:20
“You’re looking at a blue screen, it has like hex on it,” I said. The blue screen of death is Windows’ stop error, the screen it shows when the system can no longer run safely, and faulty device drivers are one of its classic causes (Wikipedia also notes it turned black in Windows 11 version 24H2). The biggest one on record arrived as a security update. On July 19, 2024, a faulty update to CrowdStrike’s Falcon sensor crashed about 8.5 million Windows systems, in what has been called the largest outage in the history of information technology (Wikipedia). Privileged code that the rest of the system simply trusted is the common thread.
Ged’s point was about what operating system designers did next. Programs that talk to each other in undeclared ways are dangerous, so the systems started making them say up front what they would touch.
“So this idea that if we have one application and another application, they do not communicate with each other in kind of non-deterministic way. People started to realize, well, there can be like bad intent software that is dangerous.”
Ged Ossman, at 12:47
Ged’s LinkedIn names the research behind the analogy: Microsoft’s Singularity and Google’s Android. Singularity, a Microsoft Research operating system developed from 2003 to 2015, took the idea about as far as it goes. Its software-isolated processes could not point into each other’s memory at all, they talked only over channels managed by the operating system, and the rules were checked when an application was installed, by the operating system itself.
Declare it before it runs
The fix Ged took from operating systems has two halves, and the order matters. First the developer declares everything the program will need. Then, when it runs, it already has permission for exactly that.
“you define all external dependencies that you may request in advance and you get permission to. And then when your application actually runs in a runtime, it already pre-authorized to execute this, to get access to this like shared context, to get access to these permissions.”
Ged Ossman, at 13:34
Ged said “in Android, like certificates,” and the Android version is the one most developers know. An Android app has to list the permissions it might use in its manifest before it ships (Android Developers), the low-risk ones are granted at install, and the ones that reach into private data or affect other apps are runtime permissions that the person has to approve (Android Developers). Google’s best practices for those permissions could be a checklist for an agent: request a minimal number of permissions, be transparent, and make system accesses explicit.
Ged’s name for the agent version was the agent onboarding protocol. “This is a protocol we call it agent onboarding protocol, that defines the sides, enterprise side, agent side, but also define rules how the sides will communicate with each other in a compliant, like governed way.” He wasn’t claiming the protocol solves everything. He called the deterministic layer “a stage one where we should come to make security and governance questions even managed in a controlled way.” The questions stay. The protocol gives them somewhere to live.
A bill of materials for the runtime
I reached for the security world’s nearest equivalent. “It’s almost like a bill of materials, but for your runtime.” A software bill of materials lists what a piece of software is made of, and CISA describes it as a nested inventory of the components inside an application (CISA). The agent onboarding protocol, as I understood it, “would enumerate all of the capabilities and the data that it would be using with those capabilities.”
The two documents answer different questions, and it helps to keep them apart. A bill of materials says what the software contains, so you can find the vulnerable library when the next advisory lands. A declaration of needs says what the software will take from you: which systems, which data, which approvals, which people. The second one is the document a security review actually wants, and almost no vendor sends it. We sketched what one could hold in the agent permission manifest, and the data-side cousin of the idea in the AI data bill of materials.
AI is not a magic box
Ged’s answer to the bill of materials was the clearest statement of the whole idea on the tape.
“If like vendor agents need something from enterprise, it should be specified in a machine-readable form, in a way where compliance security teams can quickly assess the risk, can quickly understand their current state of systems.”
Ged Ossman, at 15:06
The surprising part was what he said comes next. You would expect the declaration to be mostly about security. In his experience the first thing it exposes is that the data isn’t there. “Usually, we have this problem with like data quality, where the security is not even a concern. It’s just like the data is not there to make this specific agent deployment work and bring ROI for this organization.”
The reason the industry skips this step, he argued, is a belief about the product. “So I’m a huge believer that in kind of like straightforward deterministic way to define prerequisites, define requirements. And I think this is what currently the industry is lacking, because everyone thinks AI is a magic box.”
“But I think it should be like, this agent can perform certain capabilities. To do that, it needs like A, B, C from enterprise.”
Ged Ossman, at 16:13
RAND reached the same place from the other direction. Its 2024 study of why AI projects fail lists five root causes, and two of them are exactly Ged’s prerequisites: the organization lacks the data the model needs, and it lacks the infrastructure to manage that data and deploy the result. Another is a focus on the latest technology over the problem the users actually have. RAND’s own phrase is that AI is not a magic wand (RAND).
“It’s agentic change management, right?” I said. “It’s a machine and it has outputs and it will enhance the business, right?” Ged’s version of the same sentence put the obligation on the right side of the table: the enterprise works out how to supply A, B and C in a compliant way, instead of the vendor saying, “of course, it’s compliant.”
Never a technology problem
Ged’s bet, as he put it, is that this was never really about technology. Operating systems solved how processes interact with the kernel and with each other, I offered shared memory and network files, and as Ged put it, “Engineers figured it out.” Frameworks and new programming languages then added abstraction and handled security concerns that had never been addressed. What he thinks AI adds is something else.
“But still I believe the core value that AI can bring is this idea for better translating things between teams. And this is very important, I think, in general for organizations, because like they have like security teams, they have engineering teams, and they may not speak the same language.”
Ged Ossman, at 17:44
That reframes the slow adoption every vendor complains about. “I think enterprises are behind by a few years what vendors are currently exploring and building,” Ged said, but slow adoption is the symptom. “It was always about communicating, aligning stakeholders internally, of how we can adopt this solution in a way that does not introduce new risk.”
He was also careful about the word security. He doesn’t think of the review as security governance. He thinks of it as risk: any new solution introduced to the organization is a risk, and the company has to work out how it will address it. “And that process, this is like, I think, the hardest part.” AI’s advantage there, in his view, is that it “can easily translate same objective to different users,” the security team’s version, the engineering team’s version and the business owner’s version, and push the dependencies to resolution.
Decision traces
Then Ged made a vocabulary point that turned out to be timely. The thing an agent needs from all those stakeholders isn’t a database. It is the record of how decisions get made.
“And collecting this, I would say, decision traces, now the popular word context graphs, but I personally don’t like context graph. For me, it’s just like decision traces, like governance model.”
Ged Ossman, at 19:24
The popular word had a very specific source. On December 22, 2025, a few weeks before we recorded, Foundation Capital’s Jaya Gupta and Ashu Garg published an essay calling context graphs AI’s trillion-dollar opportunity, and its central idea is the decision trace, the record of why a company made the calls it made, which today sits in chat threads, escalation calls and people’s memories rather than in any system of record (Foundation Capital). Ged’s preference for the older-sounding name is a small tell about how he thinks. A graph is a data structure. A decision trace is a governance record, something a security or compliance team can read.
“But the thing is, once we collect this decision traces, we can give it to agents, and they can like suddenly get all this context from different stakeholders in enterprise.” Done that way, he said, AI could finally solve the adoption problem, “not just because there is a new technology, like that suddenly AI is magic, but just because we can translate things internally in a much scalable way that was never possible before.”
The same risk as before, or less
Ged called himself “more like an enthusiast of like structural solutions versus like there is a cool technology,” which is an unusual sentence from a founder who also says he is super bullish about technology. His test for any new system is conservative on purpose.
“My take is always like, let’s be like realistic and like still assess risk first, but yes, let’s also keep like optimism in place, just to figure out how we build better systems that all like existing functions in enterprise operate with the same risk exposure as before and not introduce new level of risk.”
Ged Ossman, at 20:19
“Or make it less risky,” I said. We make it less risky as we move forward, and more efficient. Ged went further than I expected. Instead of AI adding new levels of credentials exposure, “I think in the five years’ horizon, we actually make the whole infrastructure together with security, compliance champions,” infrastructure that mitigates risk and drives value creation at the same time.
He drew a line between inside and outside, though. Internally he is super optimistic. “But I can also agree that there is going to be external threats where, like, AI agents attack your systems.” I agreed that this is already happening. “Engineers use AI, so do red teams, and so do adversaries. It’s just a tool. You pick it up, you start using it.” We wrote about the outside half in autonomous AI cyberattacks and AI agents on both sides of the breach.
For the inside half, Ged’s prescription was almost anticlimactic, which is why I trust it. “We don’t need to invent them. Someone should just build proper infrastructure for proper stakeholders with aligned incentives. And just doing that is going to be very impactful for the whole industry.”
Innovation needs an interface
That was my cue for a soapbox I climb on a lot. Something that can’t be adopted doesn’t get to be called innovation, however clever it is.
“And actually, like one of the things that I oftentimes remind people of is the innovation that’s not easy to adopt is not actually innovation.”
Jon McLachlan, at 22:24
As I put it, “it might be a fun hobby, it might be a cool new technology, but it’s not innovation.” For me the bar is the potential to change the world, and a product that is too hard to integrate, or doesn’t make sense to the buyer, or doesn’t meet “the very rigorous high bar of the security and privacy expectations that large enterprises are going to bring to the table,” isn’t going to change those companies, and so it won’t change the world. “It has to have a way to get in there. It needs a path forward. It needs an interface.”
That is most of what YSecurity does for a living. A SOC 2 report, an answered questionnaire, a Type 2 audit or an ISO 42001 certificate is an interface in exactly that sense: the format a large company already knows how to read, so a small company’s product can get in the door.
Not another crypto decade
Ged picked up the thread from his own background in financial infrastructure, and the comparison he drew is a hopeful one for anyone building AI infrastructure.
“With AI, I think we finally have this proper adoption, where if you’re building infrastructure, you can actually make impact within like a short-term horizon if you know the ways how to communicate with security teams, how to communicate with compliance teams, how just to build the proper industry solutions.”
Ged Ossman, at 23:28
Crypto, in his telling, had many ambitious companies building new infrastructure while the market to adopt it never quite arrived. “people just don’t understand what a smart contract is,” he said, and if you ask someone today whether they use a smart contract, they’ll tell you they’re not sure they need one. Enterprise AI is “the different game,” because the buyer already wants it. “And I’m more like bullish on it.”
The condition in that sentence is the useful part. The impact is available “if you know the ways how to communicate with security teams, how to communicate with compliance teams.” For an AI startup that is a go-to-market plan, and an honest one: the security review is part of the product.
Risk first, technology second
Which led Ged to the principle he said he applies to engineering any solution. Understand the risk first, then the business, and only then the technology.
“So it’s always about like understanding risk first, understanding the risk that customers, like the market, face today, and figure out what’s the most effective way to solve that risk. And technology here is honestly, is always like second. It never should be like the first thing.”
Ged Ossman, at 25:04
He was generous to vendors about why they oversell. They are trying to get attention, he said, so they lead with what’s possible today with AI. His ask was for the opposite posture: say what your solution makes possible, then say plainly what risk it introduces. “So please, please share it with the industry, make this risk visible for everyone who plan to adopt this vendor solution.” Then let the security and compliance teams work out internally how they prefer to address it.
“It’s always about risk. Maybe I’m biased,” he added. Maybe, but it is the same order RAND’s root causes argue for, and the same one a good security review follows. A buyer who has to guess at your risks will assume the worst ones. A buyer you’ve told can decide.
The Clawdbot week
Then Ged told a story from the week we recorded, and it is the best argument on the tape for why the risk has to be visible before anyone installs anything.
“And with AI, I think like we have this friction in AI implementations because it’s just not visible for the industry what risk is.”
Ged Ossman, at 26:37
“You hear about like, I’m installing this Clawdbot. Everyone like talk about Twitter now. And then you see another report. Guess what? Now, again, we see another wave of exposed credentials.” Clawdbot was the name, until January 27, 2026, of the open-source personal agent now called OpenClaw. It runs on your own machine, connects to a large language model, takes instructions over messaging apps, and can reach your email, calendar and accounts. It was renamed twice in a week, first to Moltbot and three days later to OpenClaw, and by March 2, 2026 the project had 247,000 stars on GitHub. Wikipedia’s summary of the security record is the one Ged was reacting to in real time: the broad permissions it needs to be useful, misconfigured or exposed instances, prompt injection, and a third-party skill that Cisco’s AI security team found quietly exfiltrating data.
The part of Ged’s story that stayed with me was personal. “Yesterday, I got four emails from my network with hacks, with malware, basically.” I guessed phishing, and he went on. “They were developers who tried Clawdbot. I cannot say this for sure, but I see this like kinda things related.”
He didn’t conclude that engineers should stop trying things. He understands the pull, he said, as an engineer himself. He concluded that companies should give the experiments somewhere safe to happen.
“As an engineer, I understand this, but I also understand like I want to create maybe this like engineering sandbox environment that makes experimentation friendly. So organizations incentivize people to experiment with AI, but in a secure environment.”
Ged Ossman, at 27:33
“Not like you install something in your CLI, give it root access, and then like you hack next day.” That sentence aged well. When OpenClaw 2.0 shipped on August 30, 2026, The Register’s review, as Wikipedia summarizes it, faulted it for stored secrets that weren’t encrypted at rest and a sandbox for untrusted code that wasn’t on by default. “We still lack this tooling for engineers, for enterprises to make this adoption,” Ged said in January, “to address key risk that’s still there and still not resolved.” We wrote up what a real sandbox needs in your sandbox is adorable, and where the credentials end up in the .env file as a first security program.
Ask the industry
I asked what I always ask near the end: if I’m listening and I want to step on the gas pedal of all of my AI initiatives, what are my next steps? Do I reach out on LinkedIn for a demo? Ged’s answer was not a demo.
“Well, currently we prefer to get more hands into real market challenges and understanding what’s the risk today the industry is facing. So it’s not about me thinking about like just how to solve certain problems.”
Ged Ossman, at 28:45
Things are moving too fast for a fixed product, he said. “AI is evolving so fast, and enterprises had to adjust so fast, that just by keeping the same product over and over again and try to sell it, it’s not the most efficient way to build this industry infrastructure today.” So the plan was open source infrastructure and an open protocol, built with a few design partners “on enterprise side, but as well on vendor side.”
“So in other words, like you’re also looking for vendors,” I said. He corrected the framing in a way I appreciated. “Yeah, I ask the industry. So I never like try to sell things. I try to ask, what is your challenge today?”
The pre-flight check
For enterprises, Ged said, the challenge is understanding their own readiness, and his advice to a chief information officer or chief data officer with a big agent deployment coming was the line the episode is named for.
“my advice would be first is to understand, are you ready for this specific agent implementation? And to do this, there is like an activity, I hate to say, but in the consulting world, called readiness assessment.”
Ged Ossman, at 30:17
The “I hate to say” is fair. Readiness assessment usually means a slide deck that scores a whole company on strategy and culture. Ged means something narrower: before deploying capital into one specific agent, work out “what it takes for this initiative to succeed, what it takes from us to connect, to provide to vendor for this AI initiative to succeed.” Then connect with the vendor and implement. Interf’s offer at the time was to be the partner for that pre-flight check, to identify the risks and even the runtime dependencies in advance.
“So my point is, I would just say to enterprises, to leaders, be more like, do this pre-flight checks first, before just blindly going to basically figure out gaps mid-flight.” The cost of skipping it, in his estimate, is most AI projects.
“It’s just, we see, you know, like that, like more than 60% AI implementations just don’t get any meaningful ROI.”
Ged Ossman, at 31:39
The 60% is Ged’s estimate, and he didn’t cite a source for it on the tape. The published record is in the same range or worse. RAND’s August 2024 report says that by some estimates more than 80% of AI projects fail, twice the rate of IT projects without AI, and it cites a survey in which only 14% of organizations said they were fully ready to integrate AI (RAND). Gartner predicted in July 2024 that at least 30% of generative AI projects would be abandoned after proof of concept by the end of 2025, citing poor data quality, inadequate risk controls, escalating costs or unclear business value (Gartner). In June 2025 it predicted that over 40% of agentic AI projects will be canceled by the end of 2027, for escalating costs, unclear business value or inadequate risk controls (Gartner). Data quality and risk controls appear in both lists. Those are pre-flight items.
We turned this into a working method in AI readiness assessment: the pre-flight check before you deploy an agent, and the scorecard further down this page runs a short version of it on your own company.
Nobody says we weren’t ready
The reason the 60% doesn’t shrink, Ged argued, is that nobody can agree on what went wrong, and the incentives point both sides at each other.
“Enterprises will never like say, like, it failed because we were like not ready. And they would just say, this is like vendors, they over-promised us, because in the contract, they said like they bring meaningful ROI within like six months, but there is no ROI.”
Ged Ossman, at 31:54
He knows the other side too, from the forward-deployed engineers he talks to, the vendor staff who go on site to make the product work. Their version, in his telling, starts with “hey man, we just came to this,” and I finished it for him.
“We showed up, they didn’t have any of the data. We need all this context. No one knew where it was. Like, nothing was there. Like, of course the agent didn’t do what it’s supposed to do.”
Jon McLachlan, at 32:19
“Yeah, yeah,” Ged said. “We go, we raise tickets, we start like exploring, we start like basically the job of assessing the risk with their compliance and security teams.” The engineers end up doing the readiness assessment after the contract, one ticket at a time, and educating the buyer’s security team “that this is actually an industry standard and this risk is okay for you to take.”
His structural fix doesn’t blame either side. It moves the work earlier: “for enterprises not hoping vendors will solve all their problems, but first, like, doing these pre-flight checks, answering, are they ready?” And he was honest about where the market was. Interf was answering those questions as a service, because selling the fully automated version, agents that onboard themselves, would be selling promises. “We’re not there yet.”
The call for vendors
“So the call for vendors is like, vendors, like, here, you need to give to our enterprise friends on the other side of these deals, like, the tools that they need in order to be ready for all of this innovation,” I said. Ged agreed, and described the piece he was building for exactly that.
“And I would say, like, what like I’m working on now is just making vendors’ requirements more visible to everyone. So we’re building this open registry of vendors’ dependencies.”
Ged Ossman, at 33:46
The security version is the same idea one level down: “we make AI risk for specific solutions in a machine-readable form before this implementations even start,” so enterprises can assess it “in a more organized way, not hoping that like forward-deployed engineers will come and help figure it out, because it’s just not effective.”
I added the timing that makes it matter. Today the dependencies come out after “the contract is signed and everything is all done and there’s expectations on the table that this ding-dong is going to do all this magical stuff.” Every one of those discoveries happens after the leverage is gone. “Very prudent approach,” I said. “I bet CIOs just love you.”
If you are the vendor, this is the cheapest advantage in an enterprise deal. A written list of what your agent needs, sent with your security questionnaire answers, turns the review from an interrogation into a checklist. Our list of the questions buyers ask about AI agents is a good place to start writing it, and our sales support team writes those answers for a living.
Trust is transparency divided by self-interest
Ged’s answer to my CIO comment was about whose side Interf is on, and he was clear. “I believe our customers should always be enterprises and not vendors.” Vendor intelligence platforms, he said, can end up with incentives that aren’t directly aligned with the enterprises that read them, and then he put the principle in a formula.
“I believe like in this formula where trust is transparency divided by self-interest.”
Ged Ossman, at 35:09
If you have conflicted incentives, he said, the whole adoption of your solution looks wrong. “And maybe self-interest could be aligned with the customer’s interest,” I offered. “Exactly,” Ged said. “That’s why like, yeah, for us, I take CIOs’ ideal incentives, what they are incentives, and I just serve them.”
The formula has a famous ancestor. The trust equation that Trusted Advisor Associates teaches puts credibility, reliability and intimacy over self-orientation, so the more an advisor is focused on themselves, the less they are trusted (Trusted Advisor). Ged’s version keeps the denominator and replaces the top with one word. For an agent vendor the numerator is concrete: publish what your product needs and what risk it brings, before anyone asks.
The ten hidden answers
So what is missing from today’s paperwork? Ged gave the forms their due. Everyone already does security questionnaires, and “It’s like, I would say, stage one.” The gap is a kind of requirement the questionnaires never ask about.
“But there is still a lot of requirements that are hidden, specifically around context dependencies, meaning that like I have the AI agent that like, for example, do scenario modeling for workplace strategy. For my AI agent to work, I need like this 10 answers, like 10 context entities we need to connect.”
Ged Ossman, at 36:16
Ten answers is a good number to remember, because it is small enough to write down and large enough to sink a six-month timeline if each one is discovered on site. Today “the enterprises start to figure out how to find that answers only when vendors’ forward-deployed engineers tell it, like during the onboarding process.” Ged called that “a major bottleneck today,” and his fix was the one he had been describing all along: “And just bringing that visibility in a like machine-readable way is the first step how we can solve this industry problem.”
He wanted to hear from both sides before writing the protocol down: from forward-deployed engineers about what they wish they could tell enterprises in advance, and from enterprise leaders about where their AI implementations stall. “So I would say today we are not like selling. We are actively working together to create.”
Give the protocol away
I asked him to plug the GitHub repository. There wasn’t one yet. “I’m working right now on releasing the protocol,” he said, and then he explained who he wanted it to belong to.
“I noticed that the trend, that it’s published not by Anthropic from their repository, but it’s actually like an independent organization, that being donated to Linux Foundation today.”
Ged Ossman, at 38:36
The protocol he meant was the Model Context Protocol, the open standard for connecting AI systems to tools and data, which its creator introduced in November 2024 and donated in December 2025 to the Agentic AI Foundation, a fund under the Linux Foundation (Linux Foundation). That was the reference Ged was taking for his own work. “I already have in mind that it’s not like a proprietary protocol, you know, like that we will just figure out how to commercialize.” The plan was to donate it, “and our job is to make the adoption the fastest way possible,” then build an enterprise platform that implements it with the features design partners ask for.
He gave a date and an invitation. “But yeah, working on a protocol, releasing mid-February. Please, happy to share with the community and get security feedback.” He wanted security leaders to tell him which sections were missing, “so vendors can identify security risk in the specific sections, so security leaders can quickly identify. So, yeah, it’s designed to be open source and driven by the community.”
We closed on optimism, his and mine. “I actually believe that developers should be excited about building solutions for enterprise. There is so much value.” I said the CIOs I talk to feel the adoption coming whether or not they know what’s under the hood, so they might as well adopt a standard and understand the risks while their organizations push them forward. “I know, like, directives and board initiatives are not the sort of thing that we can dodge as leaders. We have to execute.”
What happened after the tape
The protocol shipped, five months after the date on the tape and under a new name. On July 21, 2026, a week after this episode aired, Ged published the Agent Readiness Protocol on GitHub under the MIT license, described as an open standard for defining and verifying what AI agents need from enterprise environments before rollout. Its README opens with the argument from this episode in two sentences: agent deployments rarely stall because of the model, and they stall on hidden dependencies.
The format is small on purpose. A vendor writes a readiness.yaml contract, and every dependency is a plain-English pair: what the agent needs from the enterprise, and a ready condition that proves it is available. The README’s example asks for read and write access to CRM contacts and opportunities, and the matching ready condition is that the agent creates a test contact and reads a test opportunity in staging. Items under requirements block the rollout and items under optional don’t, the contract carries a version because rollout dependencies change, and an optional canonical identifier puts each item in one of six categories (specification).
The rules in the specification read like a security reviewer wrote them. Write the ready condition as “a specific observable outcome,” not access granted or setup complete. Keep contracts free of credentials, private data and confidential endpoints. Never infer access, approval or compliance from public information alone. The workflow is four steps: the vendor drafts the contract, delivers it to the enterprise, both teams resolve the requirements in dependency order, and each item closes only when its ready condition is demonstrably true. The repository says it was packaged and published during OpenAI Build Week, as three installable skills for a coding agent: one drafts the contract from an agent’s codebase, one previews a rollout at a named enterprise, and one carries the specification. Its project notes list what’s next: a JSON Schema, a lightweight validator, reusable industry profiles and a GitHub Action that checks contracts when an agent’s requirements change (project story).
Two pieces from the tape aren’t there yet. The README says the repository has “no runtime, hosted-service, registry, or proprietary platform dependency,” so the open registry of vendors’ dependencies is still an idea, and as of November 3, 2026 the repository lives under Ged’s own account with a single commit, not at a foundation. The lesson the project notes draw is the episode’s in one line: successful agent deployment is a coordination problem as much as a technical one.
Interf moved with the idea. Its site now reads “Prepare context for agent tasks,” and says it builds task-specific knowledge graphs from files, shows that every source was covered, and lets you reuse the context with any agent (interf.com). Ged’s LinkedIn headline is “Making agents work on 10MB+ data,” and his experience entry for Interf is “Reusable context preparation for agents.” The trust center still carries the readiness framing in its tagline, Readiness Interface for Enterprise Rollouts (trust.interf.com). In early August Ged presented Interf at a WorkOS demo night, where WorkOS’s recap described it as building a custom knowledge graph for every task instead of one generic knowledge base for agents.
wow, 20+ @WorkOS events since my move to sf -- what @grinich is doing for the sf dev scene is unmatched! had the pleasure of presenting @interf today -- thanks for having me!
Ged Ossman (@gedossman) · August 6, 2026
In September he announced a launch party for Interf during SF Tech Week, for founders, builders and investors “in context infra & next operating systems.”
Hosting Interf Launch Party during SF TECH WEEK by a16z 🌉 The event is for friends: founders, builders, and investors in context infra & next operating systems.
Ged Ossman · September 10, 2026
Read together, the arc is consistent. In January 2025 Ged said the best AI solutions fail without organizational context. In January 2026 he said agents should declare the context and permissions they need before they arrive. In July he published the format for that declaration, and by the fall his company was building the context itself. For a startup selling an agent the useful part fits in one file: write down what your agent needs, with a way to prove each item is ready, and send it before the contract.
Did you catch it? A six-question quiz
Interactive · six questions
Did you catch it?
Six questions on what Ged and I actually said, with the timestamp for each answer. The answers are under each question for anyone reading without JavaScript.
-
What does Ged say Interf is teaching agents to do?
- Write their own integrations
- Self-onboard in enterprise environments
- Replace forward-deployed engineers
b. "So at Interf today, we are teaching agents to self-onboard in enterprise environments." Transcript, 1:41.
-
How long did Ged's previous company take to grow from 100 to 300 employees?
- Two years
- Six months
- Five years
a. "I experienced hyper-growth scale, where in my previous venture we scaled from 100 employees to 300 in just two years." Transcript, 3:10.
-
Which everyday failure does Ged use to explain why software needs deterministic rules?
- A dropped video call
- A spam filter that misses a phishing email
- The blue screen of death after installing drivers
c. "I do think that everyone knows this blue screens of death in Windows operating systems, right?" Transcript, 12:20.
-
What does Ged say the industry is lacking, because everyone thinks AI is a magic box?
- A straightforward deterministic way to define prerequisites and requirements
- Bigger models
- More forward-deployed engineers
a. "So I'm a huge believer that in kind of like straightforward deterministic way to define prerequisites, define requirements. And I think this is what currently the industry is lacking, because everyone thinks AI is a magic box." Transcript, 15:51.
-
What is Ged's formula for trust?
- Credibility times reliability
- Transparency divided by self-interest
- Results minus promises
b. "I believe like in this formula where trust is transparency divided by self-interest." Transcript, 35:09.
-
When did Ged say the protocol would be released?
- Mid-February
- At the end of the year
- After a Linux Foundation vote
a. "But yeah, working on a protocol, releasing mid-February." It shipped on GitHub on July 21, 2026, as the Agent Readiness Protocol. Transcript, 39:29.
Is your company ready for this agent?
Ged’s pre-flight check asks one question about one agent: can you supply what it needs? This scorecard asks eight questions about the next agent you plan to deploy, using the categories in Ged’s protocol. It takes about two minutes.
Scorecard · eight questions
Is your company ready for this agent?
Pick the next AI agent you plan to deploy, from a vendor or built in-house, and answer for that one. If two answers fit, pick the lower one.
-
Before the contract, do you have a written list of everything the agent needs from you?
- No, we'll find out during onboarding
- We have the vendor's questionnaire answers, not a list of dependencies
- A versioned list, with an observable ready condition for each item
"If like vendor agents need something from enterprise, it should be specified in a machine-readable form." See AI is not a magic box.
-
Is the data the agent needs actually there, reachable and clean enough to use?
- We assume so
- We know where it lives, but nobody has checked it for this use
- We pulled a sample, checked it against the agent's needs and named an owner
"Usually, we have this problem with like data quality, where the security is not even a concern." See AI is not a magic box.
-
What identity will the agent run under?
- An employee's account or a shared API key
- A service account with broad access
- Its own identity, scoped to the declared systems, with an owner and an expiry
Declared in advance, pre-authorized at runtime, the way an app's permissions are. See Declare it before it runs.
-
Do you know every system the agent will read from or write to, and who owns each one?
- Not yet
- We know the systems, not the owners
- Each system is listed with read or write access and a named owner
"It's the interface of what's acceptable to pull in, and then what's also acceptable of how to use that data." See The go button.
-
Has someone named the people who hold the answers the agent needs, like field mappings, policies and approvals?
- No
- We'll ask around when the vendor's engineers arrive
- Every human answer has a named owner and a date
"For my AI agent to work, I need like this 10 answers, like 10 context entities we need to connect." See The ten hidden answers.
-
Is there a test environment where the agent can prove each item before production?
- It goes straight to production
- A shared test environment, with real credentials in it
- A sandbox with test data and its own credentials, where each ready condition is checked
"I want to create maybe this like engineering sandbox environment that makes experimentation friendly." See The Clawdbot week.
-
Is the security, privacy and legal review scheduled before kickoff, with a date for go, fix first or not yet?
- It happens after kickoff, if it happens
- It's scheduled, but nobody owns the decision
- It's on the calendar before the contract, with a named decision owner
"do this pre-flight checks first, before just blindly going to basically figure out gaps mid-flight." See The pre-flight check.
-
After go-live, can you compare what the agent does with what it declared?
- We'd have no record
- We keep logs, but nobody compares them with anything
- Its actions are logged and checked against the declared list, and anything outside it is flagged
The goal is the same risk exposure as before, or less. See The same risk as before, or less.
Most of what this agent needs will be discovered after the contract, by the vendor's engineers, one ticket at a time. Before you sign, ask the vendor for a written list of everything the agent needs, put a ready condition next to each item, and give each one an owner on your side.
You know the systems and you have the questionnaire. Now close the gaps the questionnaire doesn't ask about: check the data, give the agent its own scoped identity, name the people who hold the answers, and set a date for the go or not-yet decision.
This agent has a declared list, owners and a place to prove each item. Run the check, keep the list versioned as the vendor's requirements change, and compare what the agent does in production with what it declared.
What does finding it mid-flight cost?
Ged’s example agent needed ten context entities, and his example contract promised meaningful ROI within six months. This calculator compares discovering those dependencies one at a time after kickoff with declaring them up front, so several teams can work on them at once.
Calculator
What does finding it mid-flight cost?
The number of dependencies the agent needs from you, the days it takes to close one, the teams that can work on them at once when the list is known, the months the contract gives to reach meaningful ROI, and the monthly contract value.
Found one at a time after kickoff, 10 dependencies at 5 days each take 50 days, 28% of a 6-month window, and about $41,667 of contract value. Declared before the contract and worked in parallel, the same list takes 15 days.
The ten dependencies and the six months are from the tape. The days per dependency, the number of parallel teams and the contract value are placeholders to replace with your own. The model is deliberately simple: it assumes every dependency takes the same time, that mid-flight discovery finds them one after another, which is the pattern Ged and the forward-deployed engineers describe, and that a declared list can be split evenly across teams. It is an illustration, not a measurement.
From remote IT support to a readiness contract
Everything on this page sits on one timeline, from Ged’s first company to the protocol on GitHub. Filter it by thread.
Timeline · 2003 to 2026
From remote IT support to a readiness contract
Filter by thread. Dates are from the public record except where marked as part of this show.
- Singularity
Microsoft Research starts the experimental operating system, which runs until 2015 and checks its isolation rules at install (Wikipedia).
- Sunrise Group
Ged co-founds a platform for remote IT support and serves as its chief technology officer (LinkedIn).
- Dolfin
Full stack engineer in Amsterdam, then a senior engineer in London on an order management and MiFID II platform (LinkedIn).
- Copper
The first technical member of the founding team, building the custody and settlement backend, then the data and BI systems through the Series C (LinkedIn).
- Interf
Ged's LinkedIn dates the company, and his Forbes Technology Council membership, to this month (LinkedIn).
- Data quality
Ged's contribution to a Forbes Technology Council panel: traceable reports and a data-first culture as the condition for AI (Forbes).
- A driver-level outage
A faulty update to CrowdStrike's Falcon sensor crashes about 8.5 million Windows systems (Wikipedia).
- 30% abandoned
Gartner predicts at least 30% of generative AI projects will be abandoned after proof of concept by the end of 2025 (Gartner).
- RAND on AI failure
More than 80% of AI projects fail by some estimates, and data and infrastructure are among the five root causes (RAND).
- Model Context Protocol
An open standard for connecting AI systems to tools and data is introduced (Wikipedia).
- Leaving Copper
After six and a half years, Ged says he stepped down in April to found Interf (LinkedIn).
- Operations intelligence
Interf launches publicly, with AI diagnostics for business operations, starting with revenue operations (LinkedIn).
- 40% canceled
Gartner predicts over 40% of agentic AI projects will be canceled by the end of 2027 (Gartner).
- A foundation for agent standards
The Model Context Protocol is donated to the Agentic AI Foundation under the Linux Foundation (Linux Foundation).
- Context graphs
Foundation Capital calls context graphs AI's trillion-dollar opportunity, built on decision traces (Foundation Capital).
- We record episode 99
"Now, again, we see another wave of exposed credentials."
- Clawdbot renamed
The viral open-source agent becomes Moltbot, and three days later OpenClaw (Wikipedia).
- A verified page
Interf's LinkedIn page is verified, with its headquarters in Salesforce Tower (LinkedIn).
- The planned release
The date Ged gave on the tape for the agent onboarding protocol.
- Episode 93
Jacob Andra and Stephen Karafiath of Talbot West on mapping the dependencies under an AI project (episode 93).
- Episode 99 airs
This conversation, on Podbean and YouTube (YouTube).
- A deterministic contract
Ged's summary of the episode: AI onboarding should start with a deterministic contract for agent context and permissions (X).
- Agent Readiness Protocol
Published on GitHub under the MIT license, as a readiness.yaml contract of what and ready pairs (GitHub).
- WorkOS demo night
Ged presents Interf, one of 21 live demos at WorkOS in San Francisco (X).
- Episode 102
Chris Kirschke on 27 years in security operations and why he won't give an AI agent write access (episode 102).
- OpenClaw 2.0
The agent's second major release, criticized for a code sandbox that isn't on by default (Wikipedia).
- A launch party
Ged announces an Interf launch party during SF Tech Week, for builders in context infrastructure (LinkedIn).
- Episode 104
Yash Kosaraju, the CISO of a16z, on why he doesn't trust the approve button (episode 104).
- Context for agent tasks
Interf's site: task-specific knowledge graphs from files, with visible source coverage (interf.com).
What to do this week
Five things, in the order Ged’s argument suggests.
- Ask for the list before the contract. For every AI vendor on your roadmap, ask for a written list of what the agent needs from you: systems, data, identities, people and approvals. If they can’t produce one, that is the first finding of your readiness check.
- Put a ready condition next to every line. Access granted isn’t a condition. The agent reading a test record in staging is. Ged’s protocol makes this the atomic unit, and it is the difference between a checklist and a hope.
- Give the agent its own identity. Scope it to the declared list, give it an owner and an expiry, and never let it run on an employee’s account or a shared key. Our AI access control audit starts by mapping what your existing agents can already reach.
- Build the sandbox before the next viral agent. Your engineers will try the next Clawdbot whether or not you approve it. Give them a place with test data and its own credentials, so trying things doesn’t mean root on a laptop full of production keys.
- If you sell an agent, write your own contract. A readiness file in the format Ged published, or your own version of it, sent with your security questionnaire answers, will shorten your enterprise reviews more than any slide. If you want a second pair of eyes on it, book 15 minutes with us.