AI Delegation: What Founders Hand Off and What They Keep

I hosted two roundtables at MicroConf Europe 2026, at Harpa on the Reykjavik waterfront, with about twenty founders at each table. The subject was AI inside the business rather than AI in the product.

The takeaway: Work handed over whole came back unusable; work broken into checkable steps, fed with written context, and gated on a human review came back usable, and far cheaper than the humans were doing it. Two jobs still had no takers — making the sales call, and thinking about what an attacker can feed your agents.

What follows is shared under the Chatham House Rule.

Break One Big Handoff Into Steps You Can Inspect

One founder took a business idea, had AI write every specification into Linear tickets, and let AI build the product for three or four weeks with no human in the loop.

Their verdict was flat: it's not there yet. Usability and interface were bad, and the cleanup phase gave away that the code underneath was bad too — "every pass it went through to fix some, it found, like, twice as many."

Somebody put a rough conversion on it out loud: three or four weeks of continuous agent work is a developer building for years with no direction from you, and of course it was a mess. The founder's own consolation was the right one: "I wasn't doing anything, so I can feel okay scrapping it" — then doing it again with a human in the loop.

The other founders had three suggestions for getting a better result out of a run like that. First, articulate what "better" means and feed that definition into the system, rather than assuming the model shares your standard. Second, "make it checkable every step of the way," because a single instruction that runs from start to finish is "a magic box" — you cannot inspect it until it has finished being wrong. Third, add an architecture step, where the AI works as the architect and confirms the shape of the whole before anything gets built.

The success stories where real work changed hands all had the same shape: one large handoff replaced by a chain of small ones you can inspect.

Ask the Model to Write the Code, Not to Do the Job

An operator building content pipelines put the replace-one-handoff-with-many idea in one line: "instead of asking the model to do the job, ask the model to write the code to do the job."

Their worked example was turning rough notes into a marketing page. The naive version hands the model everything at once — here are my notes, here is the website, make a new page that looks like that. Instead they modeled what a human would do, broke it into smaller chunks, and wired the output of each chunk into the input of the next. They get a pipeline, and the finished page falls out the end of it. They built the tooling itself with Claude Code, in React and Next.js, so they could watch token costs per step.

What they end up with is a program, not a prompt. Each step is its own call to the model with its own narrow job, and the code between the steps is code they wrote.

The payoff is repeatability. The same notes run through the same steps produce the same page tomorrow, and a single long prompt will not do that — hand a model the whole job and "if you give it the problem, it invents the solution," a different one each time. Two smaller gains come with it. You can check the output of each step, so a wrong turn surfaces at step three instead of at the end. And each step starts with a clean context, so nothing said in the first minute is still shaping an answer forty steps later, when the window is full and the results have gone strange.

Write Context Files Like You're Onboarding an Employee

What moved AI from mildly useful to indispensable was written context. One founder built a structured set of context files — a general structure, then one per project and one per role, a CFO file, a CMO file — holding the company knowledge that had been living in their head. They wrote every one by hand, and described the job as onboarding a new employee: this is our logo, this is the color we use, this is how we write, this is our tone.

Another builds theirs by walking design thinking end to end. What is the problem we think we're solving, who is the customer, and then — the part most people skip — what words does that customer use? A third gets those words by interview, asking customers to describe the product back to them and then recycling that language into outbound. If the customer calls it a cup of water and you call it a cup of coffee, the customer is right.

Two founders warned against overfeeding it. Don't hand one agent the whole company. As one of them put it, "you don't give one agent your whole company knowledge, because that's too much." The filter to apply is a human one: "What information do you need in order to reason correctly or well on top of it?" And don't accumulate files forever — if you want summaries of every inbound email to be searchable, that's a database, not a hundred thousand markdown files.

One operator has the agent maintain its own files, rewriting its skills and context as it learns what works. That is what keeps AI knowledge capture from going stale.

Whatever Holds Your Knowledge, You Need to See What Changed

Once the context files carry real company knowledge they become a knowledge base, and the room split three ways on where it should live.

One team keeps theirs in markdown under version control, with a defined structure and hygiene rules that are themselves markdown files. Information is typed — ideal customer profile, customer jobs, positioning, operational, current state — so new material lands in a known place and anyone can tell Claude Code where it belongs. Their own emphasis fell on a rule that isn't technical at all: "One person owns it and is responsible for it being structured." That owner doesn't hand-check every entry; they refactor when the structure sags. Why they think it earns the overhead: the knowledge base is "the underlying layer for every pipeline or agent" that runs on the data. Their non-technical staff commit directly, using Claude Cowork against the file system or Claude Code in the editor.

A second founder runs everything in Notion and reports needing none of that. They edit in place, direct Claude at the workspace, and it finds what it needs. A third keeps notes in Git and in Notion, syncs by hand, had tried and abandoned Obsidian, and calls the collaborative version hopeless.

So take the ownership rule as one team's answer that suits a team already comfortable with version control, not as the shape every company needs. The founder having the worst time named the one thing that did generalize across all three: "Sometimes I [say], okay, record this meeting for me. Okay, thanks. And then it just overwrites an old meeting. Sometimes I catch it, sometimes I don't." With Git you see the diff. In Notion the history exists but getting back to it is work. An agent with write access to your knowledge will eventually overwrite the wrong thing, and the question that separates the three setups is how cheaply you find out.

The one pointer offered for multiplayer was Buzz, the open-source workspace Block released in July 2026, where AI agents are ordinary members of a channel, with the same access as anyone else in it. What it offers is multiple people directing the same agents, where everyone can see what was asked and what changed.

Get Yourself Out of the Internal Answer Queue

One founder described being the bottleneck in everything, and staying the bottleneck as the team grew. You can only be one person.

They connected Claude to the company's internal knowledge base — a couple of hundred articles — and to the recordings of every sales call and support call, captured with Read AI. It was not a complex build. Now the team asks the tool before they ask a founder, and it answers roughly three-quarters of what used to come upstairs. The heaviest users are customer support and customer success. Sales barely touches it; engineering already had its own tools.

A second team got the same result with a permission change and no new software. Their proposal writer answers technical questions in government tender applications and is not technical, so every application used to queue behind the CTO. They gave that colleague read-only access to the code repositories and let them ask Claude Code. The CTO still proofreads and corrects a few things, and their accounting of the change is "it's like 10 times less work for me." The same setup carried them through SOC 2 and ISO 27001, which used to take, in their words, so much time.

The marketing hire on that team now writes landing pages in Claude Code and submits them as pull requests. In both cases the work was easy and the only person who could do it was busy.

Ask What You Can Step Back From

A year and a half ago, stepping back meant letting Cursor write three lines of code and then going back to fix the middle one. Now a whole feature can go over at once — build, test, and deploy. That frontier has mostly moved inside code, though. Who has pushed it somewhere else?

The founders who answered had pushed it into commercial work, not code. Customer-facing presentations. Quoting, including a pricing calculator. A weekly financial report — burn rate, retention, new accounts, lost accounts, stalled accounts — assembled from an accounting system and a CRM linked over MCP, with nobody in between.

And an exit plan. One founder handed over their financials and their operating data and asked what a sale at retirement would require. What came back was a sequenced plan: what to do in year one, how many clean years of financials a buyer will want, the growth rate to hold, the churn drivers to attack, and dashboards to watch it against. "That was a weekend's work." A plan of that shape used to be an engagement.

A non-programmer in the room went further and stepped back from prototyping altogether. They run OpenClaw on a hosted server, wired to Telegram. They send a brief from their phone, and it builds and deploys the tool. The output isn't production software and isn't meant to be — the prototype goes to the team, collects feedback, and then becomes the specification the developers build from. The MVP is the brief.

AI Can't Edit While It Writes — So Make Editing a Second Pass

One founder explained why prompt instructions fail on writing quality.

"It will not write well. It will write better, but it will not write well."

A human writer hits a word they dislike, stops, and thinks for a minute. A model generating token by token has one job — keep writing — and "it cannot stop, and it will write that stupid word." Rules in the prompt reduce the rate of the thing you hate. They do not remove it. Earlier models were especially bad at negative instructions and noticeably better at positive ones. The gap seems to have narrowed without closing.

So separate writing from editing. Let it write badly on the first pass. Then, in a second pass, tell it to go back and read what it wrote, and hand it the rules there — remove this, simplify that, stop reaching for its favorite crutch word. Now it can edit, because judging existing text is a different task from producing new text. The second pass works in the same session; a fresh context works better; a different model works better still.

This is reviewable work, so make it a named review. One operator keeps a pedantic review skill that impersonates their most exacting developer, runs it three times over a change, and has it fix everything unambiguous and ask about the rest. Sometimes it fixes fifteen bugs, the way they would have fixed them. Alongside it sit an architectural review and a migrations review. For prose, the same shape: one skill for narrative structure, a separate one for the tics models fall into.

Run this on marketing copy too. As another put it, it had hit them that they were applying iterate-and-code-review discipline to software and to nothing else. Review marketing copy the way you review code. More on the mechanics in AI skills that replace entire workflows.

Build a Linter for Your Prose

One founder took the second pass and made it deterministic. They wrote a tool holding roughly 110 rules about language, and put it in a loop: the model writes, the tool rejects what breaks the rules and says why, the model rewrites, repeat. Their description — "a linter for context, not for code" — and what it produces is closer to "writing the test against text, not code."

Those rules came from industries where an ambiguous sentence is a safety incident. Aerospace, defense, and pharmaceutical documentation all constrain how English may be used: restricted vocabulary, one meaning per word, short sentences, no ambiguity. The specification named at the table was ASD-STE100 Simplified Technical English, first published in the 1980s so that aircraft maintenance manuals could be read reliably by people whose English was basic. Boeing maintains its own Simplified English Checker against the same idea, and patient-facing medical writing targets a sixth-grade reading level for the same reason. Collect those rule sets, then keep only the rules that match your voice.

They warned that Simplified Technical English is dry, and prose written directly in it reads like a maintenance manual. So they use it in two steps: write the specification in the constrained language, where ambiguity is the enemy, then have the model write the marketing copy from that specification. The clarity moves downstream; the dryness does not.

Publish What Nobody Else Will Write

"I put 12,000 pages on my website and I didn't edit them."

The business helps organizations find funding. Before anyone applies, they Google the funding body — and across the long tail of smaller ones, those searches are not competitive, because nobody has written anything worth reading.

A script fires up when their Claude subscription has tokens going unused, pulls ten rows from a spreadsheet, researches each funding body with Claude Code, and emits markdown and JSON that the site build turns into pages. They iterated on the prompt; the pages were output. The result over roughly a year: from no clicks a day, to the first exciting day at one click, to about a thousand clicks a day now.

The specialists who use those pages are opinionated and will tell you when you're wrong, so the pages are openly labeled as AI-generated. "They're very keen to prove the AI wrong" — and these days they rarely find anything. A hostile expert audience with an easy way to complain is a better review process than an internal editor who has read too many of these already.

It works because "that's not trying to write wordy blog posts with a story." It's structured research that someone needs and nobody wants to write by hand. As another founder pointed out, the reader wants the details the way they want the recipe — not the story that comes before it.

Another operator enforces that boundary with machinery. Their content system generates articles from research sources, but every assertion is tied to a source in a claim database, so a draft can be checked claim by claim rather than trusted whole. They've started routing validation through a fast inference provider to make the checking cheap. Their read matches the first operator's: the system is poor at story-driven writing and good at factual writing you can constrain. Once the article is verified, the derivative work — social posts, reels, animated charts — falls out of the same pipeline, because the claims are already anchored.

Onboarding Time Fell 70%, and the Hiring Plan With It

An operations team reported the largest efficiency gain in either room. They cut customer onboarding time by 70%, and the consequence lands on the hiring plan: "we thought we would have to double our staff this next year, and now we don't."

They built one Claude skill per step of a twelve-step onboarding process, and an agent that has learned the whole sequence drives it. The work is data migration — pulling a new customer's records out of whatever system they were using, cleaning them, mapping them into the new schema, and loading them. Over many migrations the agent has learned the competitors' database structures, so an incoming customer from a known system needs almost no mapping work. "It's learned all the competitors."

One customer arrived with a large stack of paper. The old answer was that data entry wasn't on offer. The new answer is: photograph it, and the pictures come back as correctly formatted records.

Asked whether anyone could beat 70%, one founder answered in a different unit: their lead developer runs about twenty Claude Code sessions at once.

Another operator drew out the business-model consequence. Migration is a service you charge for, priced against the hours it used to take. The hours are gone; the price isn't. That's a better margin and fewer hires for the same revenue — the kind of change that shows up in the accounts before it shows up in any AI strategy document. It also stays invisible to everyone outside the company, which is the point of the real AI advantage sitting in operations.

Work That Used to Need a Specialist

Remotion is a library that describes a video as React code, so the animation is a program rather than a timeline in an editor. That is why a model can write one. Two years ago a product launch video meant hiring a motion-graphics specialist for $5,000 or more. One founder now has Claude Code produce the video and iterates from there, and says even the first version is usable.

Framer is a website builder with a content management system behind it: you define what fields a product has, and a single template page renders every product in the catalogue from those fields. A designer quoted one founder about €15,000 to build that template a year ago. Three weeks before the conference they built it themselves in two hours — and the model didn't just lay out the page. It changed the field structure in the CMS underneath, which is the schema rather than the styling, and the part that used to need the designer.

Both of those are services these founders used to buy and have stopped buying. What you pay a specialist for has collapsed; what you can charge has not yet followed.

It also makes work worth doing that never was. One founder pointed at industries still keeping their records on paper, where nobody ever digitized anything because the data entry cost more than the result was worth. AI has changed the economics of white-glove service.

Give It Read-Only Access to Production

One operator got the biggest capability jump anyone reported by changing a permission, not a model: "a big step change in how useful AI became for operations is once we gave it read access to production." With it, an issue report becomes an instruction — "go find clues and then implement a solution, open up a PR, and I'll review it" — and the agent works while you do something else.

Asked who lets AI touch production data, most hands went up for read access and almost none for write. The safe structures people had built:

• A read-only cloud role scoped to production, the only credential the agent is given. It can read logs and database dumps and anything else, and change nothing.
• Write access to the analytics database only, so the agent can query production and still have a scratch table to write reports into.
• A staging clone of production, scrubbed of personal data, where write access is safe because the clone can be rebuilt from production in a day.

What people then run on top of that access follows the graveyard shift pattern. One operator's agent wakes on a server each morning and checks the error tracker, the hosting platform, and the database for problems. Then it works through open bug reports, decides which to advance, flags anything waiting on a human, opens pull requests, and files a report. Their estimate of what it replaces at a startup they advise: two or three engineers of triage work.

A second team pulls a week of support chats and emails on a schedule, has AI summarize the pain points, and opens pull requests against the documentation site. A human reviews and merges. A third routes error-tracker issues into Slack, has AI check every fifteen minutes, and creates triage tickets automatically.

One team runs a lower-tech version. They assemble a running list of customer signals from every onboarding call, trial, and conversation. Not automated tickets, just a table. Its value is that the founder is absent from most of those calls, so the table converts a vague sense that people want a feature into a count of how many asked.

Call Your First Customers Yourself

A founder selling software to repair businesses had two customers and wanted twenty. They built a scoring agent: give it a town, ask for fifty repair businesses, and score each one against four signals. A website at all, which says the owner is switched on. A company registration number in the footer, which the law requires in their market and sloppy operators leave off. A team page listing more than one person. And, read off the photographs on the site, the physical characteristics of the premises — how big the operation actually is, which the owner has usually photographed without meaning to disclose it. Run over a couple of towns, that produced a hundred qualified prospects.

Then the real problem: "I've got my list, the next problem is, what do I say when I reach out?"

Nobody had solved that, and the one attempt in the room had failed. Lemlist is a cold-email tool: you load a list of contacts, write a sequence of messages, and it sends and follows up on a schedule. Another founder had Claude configure the whole thing — the part they didn't know how to do themselves — and ran it at 200 CEOs. Nothing broke; the setup worked. What went out was the problem: "that would definitely qualify me as the AI slop user."

Two founders answered, and neither answer involved a tool. With two customers and a target of twenty, "I would call them myself" — because you don't yet know what these people want, and until you do, automating outreach just scales a message that doesn't work. Find where they already gather, which for that market means Facebook groups and old forums. Participate and give; most groups will remove you for selling. AI's job there is monitoring the conversation for moments worth entering, and dropping a qualified lead into the CRM when someone asks for what you sell.

Enrichment was the one place tools clearly won. Clay came up as the known option with usage-based pricing, and another founder countered: assemble it yourself from cheaper APIs — Exa for search, RocketReach for the LinkedIn side — for a fraction of the cost. The pattern that reportedly closed large deals was blunt: scrape everything public about the person, find one true point of connection, and open with it. You rarely need the personal detail, though. You already know what kind of business they run, and how big it is.

One caution on automated qualification, from a team running an agent over every inbound lead. Where public information is thin — one operator's customers include a lot of churches — the scores are unreliable. Worse, the humans read them: "they see, ooh, the [AI] said this business wouldn't be a good customer. And then they don't make as good of a job because it's predetermined to fail." A score you show a salesperson becomes a forecast that fulfills itself, so keep the score on the routing side and off the rep's screen.

Adopt Through a Win the Team Can Feel

One adoption story started with a flat refusal. A sales team pushed back on AI entirely — they aren't technical, and they got into sales because they like talking to people.

Dictation got in first. Salespeople who typed with two fingers got Wispr Flow and gained speed immediately. Because they talk now, notes get recorded at all, and the CRM filled up with real detail instead of fragments. The follow-up emails got specific, and the team reported conversion up "at least 10, 12%." Only then did the objection dissolve: "after that, they accepted AI much better."

The same team learned to shape the output for the reader. Salespeople don't read long documents, so the coaching they receive is a few lines — you missed a buying signal here — while the back end collects as much data as it can, out of sight.

Training came next. Facing their first conference as a sales team, one operator had Claude read a year of recorded customer calls and generate a role-playing prompt from them, then told the team to go practice against it. Hard buyers, easy buyers, buyers who were never going to be a fit. One constraint made it work: "I told them you have to use the voice function," because "if you have time to think [and] type, then it's not the same pressure." The same approach builds a practice partner for new support and onboarding staff out of transcripts you already have.

Gemini Enterprise can listen to a support call and surface the answer on screen while the rep is talking. A logistics operation feeds pick instructions into a warehouse worker's earpiece, routing them by shelf and by what that person can safely lift. One team looked at the sales version and passed, reckoning that reading, listening, and speaking at once is a lot to ask of a rep mid-call. The counter-argument was that it's a skill, and skills can be practiced. Nobody had evidence either way.

Plan for the Physical Cost of Working This Way

One founder had started losing the use of a hand — "a little bit trouble in my hand… because of all the typing and the multiple Claude sessions." Running several agents at once means writing several briefs at once, and the volume lands on the same wrists it always did.

Everyone who answered named a piece of hardware. A foot pedal wired for dictation, so the hands never leave the keyboard. A three-button controller — one for carriage return, one to start and stop the dictation. Two microphones.

Dictation is also not equally available. One founder, for whom English is a second language, gets poor transcription in English and worse in their own: asked whether they could simply speak their first language instead, the answer was that the result is unusable. Every adoption story that runs through voice — the sales team that dictates, the founder capturing ideas while driving, the role-play practice that only works spoken — assumes a native-accented English speaker. For part of your team that assumption is wrong, and the workaround is still typing.

List Every External Feed That Reaches an Agent

Error logs into Slack into a triage agent. Customer interview recordings into Notion into an extraction agent. Support tickets into documentation pull requests. Accounting and CRM data into a weekly financial report. A dozen systems, every one of them taking outside data into an agent with no human in between.

Which raises the security question. Your error logs carry raw strings that anyone on the internet can influence. If an attacker sends you crafted input, what happens when your agent reads it?

Nobody was concerned about that.

The reasoning that followed is the reasoning most companies are using. The first defense offered was isolation: the process that handles error reports has access to nothing, and production can't be reached from it. The second was human review: the agent "can open a PR, but I will review that PR." Both are real controls. Neither addresses the failure that matters, and someone named it immediately: an agent with repository access "can exfiltrate your whole code base out to wherever it wants on the internet." No pull request review will show you that. Exfiltration doesn't need a pull request.

One founder answered that with a joke, drawing on everything the session had just established about how cheaply code now gets written: "we just learned that code has no value in their mind." Someone added the correction straight away: your code may be worth little to you at current writing costs, and still be worth taking.

Then one attendee raised a vector nobody had a defense for. Customer interviews get recorded and transcribed, and at least one team in the room has that feed landing automatically in their knowledge base for an agent to process. An instruction can therefore be spoken aloud during the interview — subtle enough to pass a listening human, clear enough for the microphone — and arrive as text inside the pipeline.

That makes the input channel a company trusts most the one where a stranger talks to it for an hour, and it argues for the transcript agent holding read credentials and nothing else.

Nobody in either room had seen this happen, and the customer-interview version is a stretch. The error-log version is not: anyone on the internet can put a string into your logs, and that string reaches an agent holding repository credentials. Likelihood is the wrong test here anyway — the downside is your code base leaving, and the mitigation is a credential scope you can set this afternoon. Every one of those pipelines was built in the last year by a careful, technical operator, and the security question went unasked until it was asked out loud at the table. If you have wired an external feed into an agent, the question to answer this week is which credentials that agent holds and what it could send outward, not whether you would notice a bad pull request. More on the exposure that accumulates unnoticed in AI tools and trade secrets.

Run Your Own Model When a Client Forbids the Cloud

One founder runs local models, and was clear about why: their clients — including a scientific funding agency — forbid sending anything to a third-party service. Absent that constraint, they wouldn't bother.

It also shows where an LLM slots into machinery that predates it. Clustering algorithms have grouped documents for twenty years. What they did badly was name a cluster — awkward before, easy now, by handing the grouped items to a model and asking what they have in common. From there the team splits a long proposal into sections and matches reviewers to each section separately, rather than treating the whole document as one undifferentiated blob.

Small models are, in their words, much more stupid. Five simultaneous requests can take ten minutes, because the hardware is modest on purpose: "I don't want to pay 10 grand a month for something that is used for 2 hours per week." They rent dedicated servers and GPU servers from Hetzner in the same data center, and fine-tune Gemma for the job.

Watch Where AI Pulls You

AI pulls founders toward building when they should be selling. That failure mode is a common one in CEOs.

One founder gave the unflattering and correct reason. "It reinforces kind of your own personality." If you're a builder, an enthusiastic collaborator who never gets tired and never says this is a bad idea will keep you building. You get advice, it sounds great, and some weeks later you've built something impressive that nobody wants. Another called the residue AI clutter: more output, more of it to maintain, more work than before.

Products get the same disease. Features accumulate because each one is now cheap, and the more-is-better logic goes unchallenged. Look at any remote control if you doubt that we've been doing this since long before AI. Every button is there because someone thought it must be needed.

The fixes people reached for were all pre-AI ones. Talk to customers about where they actually get value. Delete features ruthlessly. And accept that the scarce skill is now simplification: "So now, the role is gonna be, how do you make it simple?"

One founder had a different answer. They've paused building internal tooling, because the capability they'd build keeps arriving inside the systems they already pay for — the site builder, the issue tracker's own assistant, the CRM. Waiting is a real strategy when your vendors ship faster than you can, and it costs nothing but the option value of building early.

Nobody automated the habit that matters most here. "Does anybody just ramble for their prompts and just hit go?" Nearly every hand. Almost nobody edits a prompt before sending it — with the telling exception of Slack messages, where people slow down because a human is reading. The habit worth building is one founder's pause: notice that the model is leading, stop, and say no, not that direction.

Off the Topic, and Worth Keeping

Both rooms drifted. Four things came out of the drift.

Some customers do not want AI in your product, and will tell you so. One founder surveyed their customers about adding AI features and got an answer they weren't expecting: "I am so upset that you even sent out a survey. It means you're thinking about putting AI in. If you put AI in, I'm gonna walk." Running AI inside your business and putting AI into your product are separate decisions, and your customers may feel very differently about the second one than you do.

Find the person who pays. One founder, describing a habit learned at a large software company, said they had spent too much of their early career talking to technical people — people like them, who agreed with them — when the person worth finding is whoever can actually say yes and sign.

Make onboarding compulsory. The team that cut onboarding by 70% does not let anyone sign up without going through it. Given how much of their pipeline is automated now, they could open a self-serve door and don't — the forced onboarding is where the customer's data gets correct, and correct data is what makes the product work at all.

Make it a requirement instead of an integration. One founder sells to repair businesses whose technicians are supposed to clock on and off each job and never reliably do. The suggestion from the room was to read it off the security cameras those businesses already run: have a model watch the footage and log when someone starts and stops work on a vehicle. The obstacle is that every customer has a different camera system, so supporting them all means writing an adapter per vendor and maintaining it forever. Two ways around that came back. State the requirement up front — your camera system has to do this — and let the customer spend the couple of thousand to upgrade, which is cheaper for them than permanent integration work is for you. And skip the live feed: these systems already store recordings, so the customer can send yesterday's footage in a batch, which is all the feature needs.

And one more: if the work you are avoiding is picking up the phone, tell Claude to tell you to make the calls.

Where to Start

• Break your next handoff into checkable steps. A job you can't inspect partway through is a magic box: you can't correct it, only scrap it.
• Write the code that does the job, or have the model write it. A pipeline you can verify beats a prompt that invents its own solution, and it runs the same way tomorrow.
• Write your context files the way you'd onboard a hire, then give each agent only the slice a human in that seat would need.
• Check how you would notice an agent overwriting the wrong thing in whatever holds your knowledge, before you widen its write access.
• Split writing from editing. Let the first pass be bad, then run a named review skill — fresh context, ideally a different model — over what it produced.
• Take one document standard from aviation or pharma, keep the rules that match your voice, and enforce them with a linter in a loop instead of a prompt.
• Look for research nobody wants to write by hand before you look for essays, and publish it where the audience will tell you when you're wrong.
• Audit your operations before your product. Onboarding, migration, and compliance were the biggest measured gains in either room.
• Grant read-only production access deliberately, as a scoped credential, and keep write access to a clone you can rebuild.
• Adopt through a win your team can feel. Dictation for people who hate typing beat every mandate in the room.
• List every external feed that reaches an agent, then check what credentials that agent holds and what it could send outward.
• Reconsider the direction AI is pulling you at least once a week, and say no out loud when it's building instead of selling.

Resources From the Roundtable

• Claude Code and Claude Cowork — the default tools behind nearly every system described, including the pipelines, the onboarding skills, and the non-technical staff committing to Git.
• Cursor — the editor named as the earlier benchmark for how much code you could step back from.
• Linear — held the specifications for the multi-week autonomous build.
• Buzz — Block's open-source team workspace where AI agents are ordinary members of a channel; raised as the answer to multiplayer agent control.
• Notion and Obsidian — the knowledge bases people are wiring agents into, and the source of the overwritten-meeting-note problem.
• Intercom — support tickets routed into Notion for automatic categorization.
• Sentry — error tracking, feeding both the overnight triage agent and the security discussion.
• Wispr Flow — dictation; the tool that turned a resistant sales team into AI users.
• Plaud — a credit-card-sized recorder with four microphones, used to capture car-journey ideas and whiteboard sessions and pull the transcripts into Claude over MCP.
• OpenClaw — self-hosted AI assistant; one non-programmer runs it on a Hostinger VPS and briefs it over Telegram to build and deploy tool prototypes.
• Remotion — video as React code; used for product launch videos that previously cost thousands from a specialist.
• Framer — the CMS where a €15,000 template quote became a two-hour build.
• Clay, Exa, and RocketReach — lead enrichment; Clay as the known option, the other two as the cheaper assembly.
• Lemlist — cold email sequencing, and the setting for the AI slop experiment.
• Hetzner and Gemma — rented GPU servers and the open model fine-tuned on them for privacy-constrained work.
• Groq and Cerebras — fast inference, raised in the context of local dictation and cheap claim validation.
• ASD-STE100 Simplified Technical English — the aerospace documentation standard behind the prose linter.
• Read AI — call recording feeding a knowledge-base agent that fields roughly three-quarters of a team's internal questions.
• Rovo — Atlassian's AI in Jira, named in September 2026 as much improved.