AI Adoption Is an Org Problem: What Founders Learned

The hardest problems founders raised about AI adoption at this roundtable had little to do with which model or tool to use. They were about people and organization: how to redesign a company around agents, who loses a job and who moves into a better one, how a CEO introduces AI without scaring the team, what a ban on AI actually does, and which work, like the first phone screen, should stay with humans. The tools came up too, mostly as a lesson in letting a model drive plain, predictable software, and that part comes at the end.

The takeaway: One founder argued that adoption isn't the bottleneck; organizing the company around agents is, and they expect to let go more people than they convert. Another founder sees AI moving people into better jobs. Introduce AI through projects that help specific people rather than through a big announcement. Expect a ban on AI to push its use out of sight, not stop it. And keep humans on the work that teaches you something, like phone screens.

What follows are notes from this week's Executive AI Roundtable discussion, shared under the Chatham House Rule.

Organize the Company Around the Agents

"Adoption is not the issue. The issue is organizing the company around the technology," one founder said. Management has long rested on people, processes and technology. Their view is that AI doesn't fit in the technology bucket, and the model needs a fourth pillar: "people, processes, agents, and technology." Agents use technology, people use agents, and processes can be carried out by people, by agents, or built into the technology.

They expect that to cost jobs: "I think there are more people who need to be let go than people who need to be converted." They put it down to context rather than ability: "Change without changing context is a very heavy lift that most people will never do in their lives." Most people look for mastery, autonomy and purpose, and "Mastery presumes a lack of change because I have mastered my domain." In their experience, a new context is often the only thing that gets people to change. They said every attempt to explain why feels like casting aspersions, because they are describing people with a different psychology from theirs.

My addition: experts have their own reason to resist. If you're an expert in an area, it is easy to imagine all the reasons AI won't work in your field, because you know your field far better than you know AI. Another attendee reminded us how unusual this group is. They put us among the 1% or 5% of companies adopting AI fast, and pointed out that you can still find a comfortable job without touching AI: "we live in this little sliver of what we see." Free models add to the gap. People try Copilot or a free model, get poor answers, and decide AI is dumb. More on why people resist in the AI people problem.

Map Each Step by Who Decides

One CEO is starting with a map. They are mapping the current and ideal customer flow, covering podcasts, PR and marketing, and sorting each step into automation through code, automation through AI, or people. Their test for each step is who makes the decision on it, whatever does the work. A code tool might call an AI or notify a person; the question is which of the three makes the decision at that step. AI solutions almost always involve a little software, so where the decision sits tells you more than whether AI is involved.

They are betting their own product on this. In their view customers won't log into a dashboard, so the product is meant to be the engine behind a chat: normalized customer data underneath, and the customer asking questions and launching work in plain language. As they put it, "my AI is just the interface to get what I want done done."

Move People Up, Not Only Out

Another founder sees a different outcome. In their company, a non-technical employee now does work that used to need technical skill, and the team spends less time on technical steps and more on talking to customers and understanding what they need. AI helps "to move all the people up the ladder to a position where they are much smarter and can do stuff that they couldn't do before." Some jobs are gone: nobody sits in meetings writing notes anymore, and in the founder's view "that was not a good job before." They also said the change is "difficult, and it's scary for a lot of people."

Capacity can surprise you. One company parted ways with someone who produced content. While they looked for a replacement, a colleague who had picked up the work found they were getting more done without one, because the colleague used the AI tools more efficiently.

Introduce AI Through Projects, Not an Announcement

In one attendee's view, the CEO has to be the first to take AI seriously, and that creates its own problem. Staff may assume the CEO's new project will take their jobs, and many of them are already running their own AI experiments that someone has to pull together. Their version of the wrong way to start: "I've just been away for two weeks, I've worked 48 hours a day on this mad ting, and now I'm a superhuman."

What worked better for them was having the CEO build a picture of the business and then propose projects where AI helps particular people in the organization. Many founders new to AI, they found, wanted to move their whole organization onto an AI system at once, when the real first step was often smaller: buying a paid subscription and learning what the tools can do.

My view is close to that: the team does the AI work, the CEO or CTO stays involved so people believe it is a priority, and the training happens in a group, hands-on.

Banning AI Can Hide It Instead

One founder said "30 to 40% of the new leads that we get basically say we're not allowed to use AI in the company." The reasons are data protection law, lawyers who say no, and employee representatives whose agreement is needed for new software. The founder's answer is to let them use the older parts of the software and switch the AI features off. Some prospects even ask whether the product's text recognition uses AI or is ordinary OCR.

In the founder's experience, the ban does not stop the use. "They have, like, a free ChatGPT account, and they copy and paste the stuff. And nobody has to know." Some customers turn the AI features on anyway and ask the vendor not to tell their boss. In those cases the company has banned the governed tool, and employees copy data into an ungoverned free account instead. More on finding that usage in shadow AI.

The useful question is how much risk a given task carries. AI will make mistakes, one attendee said, but "we were making mistakes before." Their test: "if you can't tell the difference, you can't tell whether it was a human or an AI that created the mistake." An attendee raised an old medical-device software bug that gave a patient a lethal dose of radiation. AI running an X-ray machine needs different guardrails than AI writing social media posts for you. The EU AI Act draws one of those lines around hiring: it puts AI used for recruitment, including placing targeted job advertisements, in its high-risk category.

Keep Humans on the Phone Screen

Hiring is where one attendee sees AI wasting the most effort: CV-writing tools on one side and CV-sorting tools on the other, pushing against each other with "no discernible benefit." AI interview agents look worse to me. They remove the part of screening that teaches the hiring manager something.

A CEO's company skips the CVs. "We let most of the people into really quick phone interview," with the same questions for every candidate in a role, followed by a real interview and then a day in the office having lunch with the team and doing a little work. "And I would say half of them are rejected by the team." They have done hundreds of the phone screens. After about a hundred, they said, you can tell who will fit.

That matches what I tell people I mentor. A phone screen evaluates the candidate, and it also calibrates the hiring manager. Keep a roughly consistent script and keep going until one or two candidates are clearly beyond everyone else. If you have 30 people who all seem about the same, you haven't talked to enough people. You also learn what the role needs along the way. Hand the screen to a robot and you learn nothing, and the candidate meets the same AI interviewer they met in 15 other job interviews, which tells them nothing about your company. The CEO added that candidates who have already seen the CEO on video and on a phone call arrive feeling a personal connection, and they speak more openly about their concerns with the role.

Hire the Producer, Not the Editing Tool

One founder restarted a video channel and found that "the key to good YouTube content, I'm finding, is what you say." Deciding what is worth talking about, and talking about it well, is their job. Everything between the recording and publication is production work, and they handed that to an agent.

They tried the editing applications first and gave up on them: "I didn't want a video editing tool, because I didn't want to be video editing. I wanted to hire a video editor." So the editor became a stack of open-source command-line tools that an agent runs. "My video editor is FFmpeg. I allow the AI to do it." The agent downloaded and set up OBS for recording and runs the audio and video check. WhisperX produces the transcript, computer vision confirms what is in each frame, Blender handles 3D animation, and HyperFrames assembles the video. The founder runs it through Codex on a subscription they dedicate to the pipeline.

The founder gives it the kind of problem, the tools in the solution space and an idea of what good looks like, and then "it'll, like, go churn away for, like, 5 hours. It's more like hiring a producer." One video took about 30 hours of elapsed time: "I didn't care. It wasn't my time." It cuts a long riff into shape, splits it into chapters and finds places where a visual explanation would help. Because the pipeline needs no user interface, "now my… my only fee is tokens."

The output is now "something on the order of like 20 videos a week" of long-form video, not counting clips and shorts. Video "previously was the most expensive thing you could do on a per-unit basis," and the founder is trying to turn those economics around the way AI did for code. They are unconvinced that the animation changes a video's reach. What matters, in their view, is whether the topic interests people and whether the packaging says so. Their bet is volume over hits: about ten times as many pieces, each one aimed at a narrower problem, because viewers now look for the video about their own issue.

Another attendee was less sure the volume bet will hold. Splitting an idea into many narrow videos is tempting, but YouTube is filling with very short pieces, and they asked "how are the algorithms gonna kind of change to deal with that over time?"

My own version runs through Borumi, a desktop video editor with an MCP server that Claude can drive. "I had Claude build skills that… Find, like, noises, errant noises in the recording, and fixes that. Gives me feedback on my pacing, and intonation, and… like, whether or not my hair is messed up when I recorded a take," and it suggests a second take when the idea could be simpler. I wondered aloud whether an editor driven through MCP would use fewer tokens than stitching command-line tools together. The founder's answer was "potentially."

One attendee hit the counterexample with a hosted editor. They record in it and expected to edit through its MCP server with their own tokens. The server sent the edits through the vendor's own AI instead, and partway through an edit it reported that they were out of tokens.

Put the Personal Note on a Machine

One founder likes to send customers personal notes by mail, and an assistant used to write them by hand. That worked well but did not scale. As the founder put it, "how many can you write in a week?"

So they bought specialized hardware that produces the mailing and built a small AI system around it. After a sales call, the AI reads the transcript and writes a short note about something specific to that customer, and the machine produces it for the post. "The combination is great because you have AI to write this stuff." Nobody has to think about what to say, and the machine does the same job every time.

They have only just started, so there is no response data yet. One attendee warned that mail meant to look personal often looks "too perfect," and recipients can tell.

Build the Tool Nobody Would Have Paid For

One attendee reads a lot of industry RSS feeds and disliked how their reader prioritized them, so they built their own. "It finds all of them, it summarizes all my articles that I want to read," sorts them, and learns from "which ones I'm reading, how I am reading them, like, how long I'm reading them." It's still in progress. The goal is reading less, and more of what they want.

One founder, who dislikes writing JavaScript, vibe-coded a Chrome sidebar plugin for onboarding new customers. Setup means collecting the customer's Google Font and some images from their website. An API runs into anti-bot defenses, but the page opens normally in Chrome, so the sidebar shows what is needed and produces a JSON blob that pastes into their software and configures everything. Setup dropped from 20 minutes to two, and the person doing it no longer needs to know how the system works. The cost: "I haven't looked at the code at all. I don't know what's in there."

One company recorded a two-and-a-half-hour discussion between accounting and a developer about changing a process and the software behind it. "Then we went to lunch, and when we came back, we had the spec ready, we had a… presentation ready," and the group walked through it to ask whether it was the right thing. The spec used to arrive a week later, after everyone had forgotten the edge cases.

My executive assistant runs on Claude Code with access to my email and a two-way connection to iCloud Reminders: it adds to-dos there, and I give it tasks the same way. It caught that my Global Entry was expiring, from an email Gmail had filed somewhere I never looked. It runs as a scheduled task on my Mac, and remote control lets me tell it to improve a skill from the Claude app. Paying a person to manage my to-do list that closely would have cost a fortune.

These tools also show you things about your own business. I recently helped a client build a RAG system over their documentation, and the CEO asked the prototype whether they document how one process works and was surprised by the answer. One attendee is going further: "I've been building agents that look for bugs in my business. They're pretty busy, actually." They draw on how the business wants to present itself, down to the words, phrases and claims on the website and in the newsletter. That attendee had always known when a piece of writing was off without being able to write the rule down, and AI turned that knowledge into a formal voice. They think business is now roughly where coding was two years ago.

Let the Model Drive Predictable Tools

Most of the tool lessons came back to one idea: the model decides what to do, and a deterministic tool does it the same way every time.

One CEO described the pattern from their own video editing. When the model has to work out a task from scratch it burns tokens, and when a tool has the task as one button, "it just calls the one-click." With an engine custom-built for the task, "I notice my token use drops dramatically." Their example was color correction: a request through MCP to make a clip look like Star Wars, or to match a reference image. An editor like DaVinci Resolve has that as a single function, so the model only has to call it.

A second attendee reached the same place with templates for cutting excerpts from finished videos: a button that activates "a process that isn't necessarily AI is becoming increasingly useful for us." Left to do it all itself, they said, the model will eat tokens all day.

"What really worked for us was combining deterministic stuff with large language models," another CEO said about their code. They work in PHP, a weakly typed language, and run PHPStan and Psalm at strict settings, including taint analysis, where "everything that comes from untrusted sources is tainted" and the checker flags where tainted input reaches a place it can cause cross-site scripting or SQL injection. A model has trouble seeing that kind of bug, because the input arrives in one part of the code and does damage in another: "even, like, Fable can't really understand the whole code at once." They tell Claude to raise the strictness levels, and "whenever Claude does something, he automatically uses those tools to check his own work, so he catches his own bugs much faster." In their view this is overlooked because most people rely on the model alone.

I set up linting on every AI project, which is light static analysis. Tests do the same job. Someone online had argued that tests waste tokens; one attendee's answer was that tests are "the only way that AI knows if it's correct or not," and that linting and smoke tests exist "so that AI can know, oh, I just didn't break everything and went down a path for 20 minutes." The same attendee went further: "I think AI has made TDD more valuable than less." With three developers, full test-driven development was always too much work; now the first step is to write the spec and the test that should pass, and then let the model go.

I was never a big TDD person, and my recollection is that the research on human TDD found no productivity gain at the same level of quality. With AI it seems to matter. I tell the model to write tests that fail first, to verify that the tests do something, because "a lot of times it's been writing useless unit tests." A test that has never failed may not be checking anything.

Have a Second Model Check the First

One attendee asked whether plan mode and then pull-request review are both fading, with agents reviewing the PRs and a person stepping in only when something breaks: "unless it's a hot path type issue, you know, what are we here for? Besides taste." They use Copilot on GitHub and Codex to double-check it, "because it finds different things."

I use Impasse, an open-source skill I wrote that has a second model review the first model's work. "I usually use Claude as the primary, and then Codex as the checker, and Codex almost always finds something." My guess is that the context of the development work creates a kind of blindness: the model has been led down one path, and a reviewer that starts without that history may consider another. The attendee said even Claude reviewing Claude finds things, "as long as you do blind or adversarial." More on the method in AI code review by a rival model.

Not everyone has let go of the PR. "I still review PRs," a CEO said. "I have AI review the PRs, but then I also at least give it some sort of cursory glance. Like, I just… I'm too scared to launch anything."

Planning hasn't gone away either; it moved into a framework. The same CEO stopped using the built-in plan mode for the Superpowers plugin, which writes the spec and plan and checks steps off as it goes. An earlier tool they used kept the plan as a checklist, "so even if the AI lost context or restarted or did that, it still had the entire plan and what it had done up to there," and Superpowers does the same. For long runs, one attendee passed on an idea they saw on X: "you can just tell it to spawn a sub-agent to create an HTML dashboard for its progress," and watch it update.

Switching Harnesses Costs More Than the Credits

AWS offered one attendee's team "a thousand or three thousand bucks a month, something crazy," to have a couple of developers use Kiro, its coding agent, instead of Claude Code. Kiro runs the models on AWS's Bedrock. The attendee's first question was which models it would call and what the data-retention policy was. The answer was any model, but by default Kiro picks the routing.

They tried it and didn't like it. Onboarding "should have been 5 min, and it took hours." Kiro comes as three different products, including a CLI and a Teams version, and it was unclear which one to use. Everything the team had built in its .claude setup had to be converted, and "you'd be surprised at how much of a difference the harness makes when you're switching." One engineer wanted to approve actions automatically, and the harness kept asking for approval at every step. One developer is still trying it.

Another attendee recalled that Kiro arrived a few months after Claude Code with a strong opinion about spec-driven development: write the spec first, then build. "SDD had a real moment in, like, the third quarter of 2025, and then seemed to really fade away." The team that tried it found Kiro no longer forces that approach. The credits cover the tokens. They don't cover the skills, settings and habits a team has built around one harness. More on why the harness matters in the AI harness beats the model.

Where to Start

• Redesign roles around agents before you measure adoption.
• Map one process by who decides. Mark each step as code, AI or people, according to what makes the decision at that step.
• Look for the people AI can move up, not only the roles it can remove.
• Introduce AI through projects that help specific people. Let the team do the AI work, and keep the CEO involved so people believe it is a priority.
• Find out where your AI ban is being worked around, and match guardrails to the stakes of each task.
• Keep doing your own phone screens until the outliers show up.
• Hand production work to an agent and keep the judgment. What to say, and whether it's good, stays with you.
• Build the small internal tool you never would have funded, and decide who reads its code.
• Give the model tools instead of tasks, and put strict static analysis and tests where it can run them.
• Have a second model review the first, blind or adversarial, and keep a human glance on anything that ships.
• Count the setup cost before you switch harnesses. Free credits don't move your skills and settings.

Resources From the Roundtable

• Shell Game — a podcast recommended at the end of the session; its second season followed a startup staffed by AI agents.
• FFmpeg — the "video editor" in one founder's agent pipeline, run entirely by the model.
• OBS Studio — free recording software the agent downloaded and set up itself.
• WhisperX — transcription with word timings, used to find the cuts.
• Blender — 3D animation in the same pipeline.
• HyperFrames — HeyGen's open-source HTML-to-video renderer, used to assemble the final video.
• Borumi — a desktop video editor with an MCP server; Claude drives it and checks my recordings for noise, pacing and retakes.
• DaVinci Resolve — an editor with one-click functions, such as color correction, that a model can call through MCP instead of working them out.
• PHPStan and Psalm — static analysis and taint analysis for PHP, run by Claude on its own work.
• Superpowers — a Claude Code plugin that carries the spec and plan through long sessions.
• Kiro — AWS's coding agent, which runs models on Bedrock; one team tried it on AWS credits and didn't like it.
• Impasse — an open-source skill that has a second model review the first model's work.
• Claude Code — the harness behind my executive assistant and most of the code workflows here.