Translational Intelligence

When Your Science Is Outsourced

Fri, 17 Jul 2026 00:00:00 GMT

Most writing about AI in biotech, some of mine included, pictures a company with its science in the building. Assay data on the servers, models trained on your own experiments, a discovery engine to make faster. If you run a clinical-stage company, that picture is not yours. Your bench is at the CROs. Your molecule is in trials you monitor rather than run. And your company, the part with employees and deadlines and risk, is something else entirely.

It is clinical operations, regulatory, medical writing, safety, and vendor oversight. That is where your people spend their days, and it is where AI actually touches your company. So the question is not how AI changes your lab. It is how AI changes a company that mostly writes, reviews, submits, and oversees, under rules written to protect patients. And that runs straight into the validated environment, which is exactly where most leaders assume AI cannot go.

[Diagram: Two lines decide where AI can help in a clinical-stage company]

Two lines decide where AI can help, and neither is the wall people imagine. The first is the data class you already know from your AI Use Policy: patient data and unfiled results are Tier 1 and live only in an approved, enterprise-secure environment. The second is subtler and matters more. It is whether AI is drafting something a qualified human owns and reviews, or becoming part of a system that creates or maintains a regulated record. The first is a question about your people and your programs. The second is a computer-system-validation and Part 11 question for your quality function. Most of the early value sits where neither line bites, and there is a great deal of it.

The validated gate is not there to keep AI out. It is there to protect patient safety and data integrity, and those do not get cheaper to ignore because intelligence got cheaper. So you do not relitigate the gate. You do the Permission work once, choose controls you can stand behind, and then ask the only interesting question left. Is the current shape of this gate still the best way to protect what it guards, or is it a manual step that survived because the old systems could not see each other. That question belongs to you and your quality function together, and it gets answered on purpose, not by waiting.

Artifact: Where AI Touches a Clinical-Stage Biotech

Here is Monday morning. Take one document your team writes by hand every week, a safety narrative, a monitoring summary, a submission section, and place it against the two lines. If it is a human-owned draft on data you already control, you can start this week. For everything past that line, bring your quality function in early and move it deliberately. The full map is the artifact above, and the destination it rests on is the AI-Native Biotech.

FAQ: Can I use AI in a validated workflow?

Fri, 17 Jul 2026 00:00:00 GMT

Regulatory Two different questions usually hide inside that one, and much of the time they have different answers. What follows is the shape of the constraint, with the controlling sources linked, not legal advice. Confirm the specifics with your own quality and regulatory function.

If AI is drafting a document a qualified human owns and reviews, a clinical study report, a safety narrative, a submission summary, you are mostly in People and Programs territory. The human is the author of record, your normal quality review still applies, and the main environment question is the data class from your AI Use Policy: patient data and unfiled results stay in your approved, enterprise-secure environment. That is closer to your existing accountability applied to a faster first draft than to a new regulatory frontier. It is not automatically free of validation questions, though: if that draft is generated or maintained inside a system that keeps a regulated record, the intended use, the inputs, and how the output is used can still pull it across the line.

If AI is becoming part of a system that creates or maintains a GxP record, that is a different matter. Now you are in computer-system-validation and 21 CFR Part 11 territory, records the agency has to be able to trust, with audit trails, access controls, and validation. It is your quality and regulatory function's call, not something to route around. Do not relitigate that gate out of principle. Do the Permission work once, choose controls you can stand behind, and bring quality in early. If the AI is being used to help establish safety, effectiveness, or quality, the FDA's 2025 draft guidance on AI to support regulatory decision-making sets out a risk-based credibility framework tied to the model's context of use.

Most of the early value sits in the first case, not the second. So start where a human owns the output and the data is already yours to use, prove it, and let your quality function help you move the harder line deliberately. The full picture is Where AI Touches a Clinical-Stage Biotech.

Sources

FDA, 21 CFR Part 11, Electronic Records; Electronic Signatures (eCFR, current)
FDA, Considerations for the Use of Artificial Intelligence to Support Regulatory Decision-Making for Drug and Biological Products (draft guidance, Federal Register, January 2025)
ICH, E6(R3) Good Clinical Practice (Step 4, 2025), on computerised systems and data integrity
EMA, Reflection paper on the use of AI in the medicinal product lifecycle (2024)

Artifact: Where AI Touches a Clinical-Stage Biotech

Fri, 17 Jul 2026 00:00:00 GMT

Read this if your bench is outsourced

Regulatory This map names where AI touches a clinical-ops company and where the validated-environment line sits, with the controlling regulations linked below. It is the shape of the constraint, not legal advice; confirm the specifics with your own quality and regulatory function.

Most AI-in-biotech advice pictures a discovery lab: assay data on your servers, models trained on your own experiments. If you run a clinical-stage company, that is not your company. Your science is largely at the CROs. The part with your employees and your deadlines is clinical operations, regulatory, medical writing, safety, and vendor oversight. This map is where AI touches that work, and where the validated-environment line sits.

Where AI helps today

Function	Where AI helps today
Medical writing and clinical study reports	First-draft narratives and summaries from structured data, consistency and style checks across a document set
Protocol and regulatory documents	Drafting and harmonizing protocols, consent forms, and submission summaries against templates and prior filings
Safety and pharmacovigilance narratives	Drafting case narratives from structured case data at volume, for human review before anything is filed
Regulatory submissions	Summarizing, drafting, and QC-ing content across submission modules, checking cross-references
CRO and vendor oversight	Synthesizing monitoring reports, surfacing signals across vendor deliverables, drafting oversight questions
Clinical operations	Drafting queries, summarizing site performance, preparing for monitoring visits
Medical information and literature	Searching, summarizing, and drafting responses from public and licensed sources

The two lines that decide the environment

Two questions govern every use above, and neither is about the model.

First, what class of data. Patient data and results you have not yet filed are Tier 1, and they belong only in a contracted, enterprise-secure environment approved for that class, exactly as your AI Use Policy says. Public and non-confidential inputs are Tier 2, where you should push people to explore.

Second, is AI touching a validated record. There is a real difference between AI drafting a document a qualified human owns and reviews, and AI becoming part of a system that creates or maintains a GxP record. The first is mostly a People and Programs question: the human is the author of record, and your normal quality review still applies. The second is a computer-system-validation and 21 CFR Part 11 question, and it is your quality and regulatory function's call, not something to route around.

Most of the early value sits on the near side of both lines: drafting and synthesis, on non-patient data or inside your approved environment, with a human who owns the output. There is more of it than you think.

Don't relitigate the gates. Reconsider their shape.

The validated processes and review gates in a clinical-stage company were rational answers to a world where information was expensive to move and slow to trust. AI does not delete the judgment those gates protect, which is patient safety and data integrity, and you should not try. Do the Permission work once, choose controls you can stand behind, and stop relitigating settled safety debates out of principle.

But do ask the AI-native question. Is the current shape of a gate still the best way to protect what it guards, or is it a manual step that survived only because the old systems could not see each other. That is a question for you and your quality function together, answered deliberately, not a reason to wait.

Start where neither line bites: a first-draft narrative, a summarized monitoring report, a submission section a qualified human will own and check. Win there, bring your quality and regulatory function in early, and move the harder lines on purpose.

Sources

FDA, 21 CFR Part 11, Electronic Records; Electronic Signatures (eCFR, current)
FDA, Considerations for the Use of AI to Support Regulatory Decision-Making for Drug and Biological Products (draft guidance, Federal Register, January 2025)
ICH, E6(R3) Good Clinical Practice (Step 4, 2025), on computerised systems and data integrity in trials
EMA, Reflection paper on the use of AI in the medicinal product lifecycle (2024)

You Already Employ Your AI Product Partner

Thu, 16 Jul 2026 00:00:00 GMT

Every small-company leader who reads about the AI Product Partner arrives at the same wall. It sounds essential, and it sounds like a hire they cannot make. Fifty people, clinical-stage, runway to protect, and no room on the org chart for a new senior role whose value they cannot yet prove to a board. So they file the idea under later, and later never comes.

The wall is built from a single wrong assumption: that the AI Product Partner is a headcount. It is not. It is a function, and a function does not need its own full-time body until it outgrows a fraction of one. At your size the whole role is about 20% of a person you already employ, and the move that matters is not posting a job. It is naming the person.

[Diagram: The right owner is already on your team]

The person has a shape, and the shape is not a title. They are trusted by their peers, curious about what the tools can now do, and broad enough to see across the whole company rather than down into one function. That is often a chief of staff or a head of operations, usually not your most technical person, because the job is translation and trust rather than engineering. And it is almost never an outside hire, because the hardest part of this work is changing how respected colleagues do their jobs, and that kind of trust does not transfer with an offer letter.

What the 20% does is not mysterious. They score the company, own the one-page policy, find the one workflow worth changing, route new requests instead of defaulting to a purchase, and recruit the peers everyone copies. What they do not do matters just as much. They do not stand up a committee, buy a platform before shipping a workflow, or wait for a strategy to arrive from somewhere else.

Hiring feels like commitment, and commitment feels like seriousness. But at fifty people, the serious move is the small one. Name the function, give it a fifth of the right person's week, and let it earn its way to a full-time job by outgrowing the fraction. Most companies at this size never need the hire. They need the owner.

Artifact: The Small-Team Operating Model

Skip the requisition. Write down the three people on your team with the right shape, and have the honest conversation with the first one this week. Give them a fifth of their time and the scorecard to start with. You are not adding a head. You are naming an owner who was in the building the whole time.

FAQ: Who on my team should own AI?

Thu, 16 Jul 2026 00:00:00 GMT

Look for a shape, not a title. The right owner is T-shaped: deep enough in one part of the work to be respected, broad enough to see across the whole company, and genuinely curious about what the tools can now do. They can spend about 20% of their week on this without dropping the job you already value them for. In practice that is often a chief of staff, a head of operations, or a respected program lead.

It helps to be clear about who it is not. It is not your most technical person by default, because the job is translation and trust, not engineering, and your best builder is often not your best persuader. It is not an outside hire, because the hardest part of the work is changing how respected colleagues do their jobs, and that trust does not transfer with a contract. And it is not simply your loudest AI enthusiast, because enthusiasm is not the same as the trust of the room, and this job runs entirely on that trust.

So the test is simple. Who already gets listened to, across functions, and would be curious enough to spend a fifth of their time here? That person is your owner. The full model for running it at your size is The Small-Team Operating Model, and the role it scales down from is the AI Product Partner.

Artifact: The Small-Team Operating Model

Thu, 16 Jul 2026 00:00:00 GMT

The one idea

At fifty people with runway to protect, you cannot open a requisition for an AI Product Partner, and you should not try. The role is a function before it is a job. Someone has to own permission, own adoption, and route the programs, but that someone is already on your team, at about 20% of their time. Operator heuristic The 20% is a starting figure, not a measurement; size it to your company, and watch for the trigger where the function outgrows the fraction. Naming them is the whole move.

Give it an owner, not a hire

The function has to exist. The full-time body does not, until the function outgrows a fraction of one. So do not post a job. Take one person who already has the trust of the room and a real curiosity about the tools, and give them a fifth of their week and a clear mandate. A named owner at 20% beats an unfilled requisition every quarter of the year, and it beats a committee every day of the week.

Which of your people is the right shape

The right owner is T-shaped. Deep enough in one part of the work to be respected, broad enough to see across the whole company, and genuinely curious about what the tools can now do. In practice that is often a chief of staff, a head of operations, or a sharp program lead.

It is usually not your most technical person, because the job is translation and trust, not engineering. And it is almost never an outside hire, because the hardest part of the work is changing how respected colleagues do their jobs, and that trust does not arrive with a contract. Look for the shape, not the title. You are looking for the person other people already listen to.

What the 20% does

Runs the Permission, People, Programs Scorecard and names the weakest pillar.
Owns the one-page AI Use Policy, so permission is settled and out of the way.
Finds the one workflow worth changing, and makes the win visible.
Trains people to self-serve, because most of the value lives there and needs no project.
Routes every new request through the five moves instead of defaulting to a purchase.
Recruits the ambassadors that everyone else copies.

What not to do at your size

Don't hire a Head of AI. Name the function first, and hire only once the 20% is visibly, provably full.
Don't buy a platform before you have shipped a workflow. You have not earned the signal that tells you which one.
Don't stand up a committee. A committee is how a small company simulates progress. One owner outruns it.
Don't build what you can buy, or buy what your people can already self-serve.
Don't wait for a strategy. Run a quarter, and let the strategy be the pattern you find.

The minimum viable institution

You do not need a transformation office. You need the smallest working version of all three pillars: one page of Permission, one visible win under People, one workflow routed on purpose under Programs. That is a complete operating model, and it fits on a company under a hundred people without adding a single full-time head.

Before you post the job, look around the room. The person who should own this is probably already in it, doing something you value, and one honest conversation away from spending a fifth of their time on the thing that will change the other four.

You Don't Need a Roadmap. You Need a Quarter.

Wed, 15 Jul 2026 00:00:00 GMT

The request that kills more AI transformations than any budget line is the one that sounds the most responsible. Bring me the roadmap. A two-year plan, phased, with milestones and a target operating model on slide fourteen. It feels like leadership, and it is mostly a way to not start, because the ground under a two-year AI plan moves faster than the plan does. By the time it clears the room, the capability it assumed is a year out of date.

You do not need a roadmap. You need a quarter. Ninety days is long enough to name an owner, score yourself honestly, ship one real workflow, spread it to a few people, and score again. It is short enough that the capability will not outrun you, and small enough that you can run it with the people and the runway you already have.

[Diagram: The first 90 days, as a repeating quarter]

The quarter has a shape, and the shape matters more than the ambition. The first two weeks are for honesty and an owner, not launches: name the person who will own the work at a fifth of their time, and score the company out loud. The next month is one workflow made real where people can see it. The month after that is turning that one win into a few, by letting the person you helped bring their bigger idea and by recruiting the peers everyone else copies. The last two weeks are for scoring again and choosing the next pillar. Then you do the whole thing over.

A roadmap promises you will know the entire path before you take a step. A quarter admits you will learn the path by walking it, which in a field moving this fast is the only honest promise on offer. The roadmap optimizes for the comfort of the room that approves it. The quarter optimizes for the one thing that compounds, which is adoption. Solve one person's real problem this quarter, and next quarter they arrive with a bigger one, and that is a company teaching itself to move.

Artifact: The First 90 Days

So do not commission the roadmap. Name the owner today, put the scorecard on this week's agenda, and let your target for the quarter be a single level on a single pillar. Ninety days from now you will have moved, which is more than most roadmaps deliver in two years. That habit, run over and over, is what keeps a company AI-native.

FAQ: What will the first 90 days cost?

Wed, 15 Jul 2026 00:00:00 GMT

Mostly attention, not budget. The real cost of the first quarter is one owner's 20% of a week and the honesty of a single scorecard meeting. Almost everything else you need, you already have, because the licenses are usually sitting in a drawer and the point of the first 90 days is to use them, not to buy more.

So resist the instinct to make it expensive. Writing a big check feels like commitment, and commitment feels like seriousness, but at a sub-100-person company the serious move is the cheap one. Do not buy a platform in the first quarter. You have not yet earned the signal that tells you which one you need, and once you have shipped a workflow or two, you may find you never needed it at all. Run each request through the five moves before any money moves.

The genuinely expensive version of this is the one you are trying to avoid: buy the platform first, adopt it never, and spend the next year explaining a line item that changed nothing. Spend attention this quarter, not budget. If you want the week-by-week version, it is The First 90 Days.

Artifact: The First 90 Days

Wed, 15 Jul 2026 00:00:00 GMT

Before you start

This is the quarter that follows the first move, not a replacement for it. If you have not yet picked one workflow, one owner, and two questions, start there and come back. This plan assumes you are ready to make that first move real and build a few more around it.

Two rules hold the whole thing together. Give the work one owner, not a committee. And aim to raise your weakest pillar one level, not to touch all three. Ninety days is enough for exactly that, and no more, and that is the point.

Days 1 to 15: Name the owner and score yourself

Do not launch anything yet. Spend the first two weeks getting honest and getting an owner.

Give it one owner. Not a new hire. One person who already has the trust of the room and is curious about the tools, at roughly 20% of their time. The role is a function before it is a job.
Score the company. Run the Permission, People, Programs Scorecard with your exec team, out loud. Your lowest pillar is your target for the quarter.
Write the one page. Put the AI Use Policy in place: two data tiers, a few duties. Permission should take an afternoon, not a task force.

Days 16 to 45: Ship one workflow

Now make the first move real, where people can see it.

Pick the workflow a respected person would change their Tuesday over. Not the biggest problem. The one where a win will be noticed and believed.
One owner, two questions. Is this the workflow that matters, and did it actually get better. Keep it that simple.
Open the safe door. Give everyone secure self-serve access for Tier 2 work, with education, not a project. A surprising amount of value arrives with no program at all.

Days 46 to 75: Turn one into a few

The first win earns the next. Spend this stretch on adoption, not on scope.

Let the person you helped bring their bigger idea. Solve small, and they bring you big. This is how momentum compounds.
Recruit two ambassadors. The respected peers in other functions who will do it in front of their teams. Behavior spreads by imitation, not by memo.
Route new requests on purpose. As they arrive, run each through the five moves. Resist the platform purchase. You have not earned it yet, and you may never need it.

Days 76 to 90: Score again and set the next quarter

Close the loop, then open the next one.

Re-run the scorecard. Did your weakest pillar move a level? If yes, the quarter worked. If no, you now know where the resistance really lives.
Pick the next pillar. Whichever is lowest now. Not the one you like to show off.
Put the next 90 days on the calendar. This is not a one-time sprint. It is the cadence, and the company that keeps running it is the one that stays AI-native.

Ninety days from now you will not be finished, and that is correct. You will be one level higher on the pillar that was holding you back, with an owner, a few wins, and a habit. Then you run it again.

You Can't Fix What You Won't Grade

Mon, 13 Jul 2026 00:00:00 GMT

Ask a leadership team how their AI transformation is going and you will hear a story. A pilot that went well. A team that loves the new tool. A policy that finally got signed. What you will almost never hear is a number, because most companies are running the whole thing on anecdote and vibes, and anecdote always flatters the teller.

You cannot fix what you will not grade. So grade it. Not the whole sprawling thing at once, but the three pillars that decide whether AI changes how you work: Permission, People, and Programs. Score each one from zero to three, in a room, with the people who own the work. It takes fifteen minutes, and it ends the storytelling.

[Diagram: You are only as native as your weakest pillar]

Here is the rule that makes the score honest. You do not average the three. Your true level is your lowest pillar, because the three grow together or none of them grows. A company with a signed policy and a shelf of licenses and no one changing how they work is not two-thirds transformed. It is stuck, with good governance on top. The tallest pillars do not carry the short one. The short one sets the ceiling.

And the scoring is where the honesty gets tested, because two mistakes are almost universal. Leaders over-score Permission, because writing a policy feels like progress and it threatens no one. And they under-score nothing so reliably as People, because behavior is the hardest and least visible thing in the building to change. If your Permission score comes in high and your People score comes in low, you are not behind. You are normal. You have just found where the work is, which is the entire point of grading.

The move after that is small on purpose. You do not launch a program against all three pillars. You take the lowest one and raise it a single level this quarter. Then you put a date on the calendar and grade again, and now you are running a transformation on evidence instead of on the best story someone told in the last meeting.

Artifact: The Permission, People, Programs Scorecard

Here is Monday morning. Put the three pillars on a whiteboard and have each of your leaders score the company privately, zero to three, before anyone speaks. Then compare. The spread between your highest scorer and your lowest is its own diagnosis, and the pillar you argue about most is usually the one you have been avoiding. Start there. The full model, and where to point the first move, is on Permission, People, Programs.

FAQ: What's a passing score?

Mon, 13 Jul 2026 00:00:00 GMT

There is no passing score, and chasing one is its own mistake. The scorecard is not a test you clear once. It is a floor you raise, and the only number that matters is your lowest pillar, because Permission, People, and Programs grow together or none of them grows.

That changes what "good" looks like. A company sitting at a steady Practiced on all three is in far better shape than one showing Native on Permission, Native on Programs, and Absent on People, even though the second one has two perfect scores. The first company has a high floor. The second has a wall with a hole in it. So do not celebrate your tallest pillar, and do not try to reach Native everywhere at once. Native on every pillar is not the target, and for most functions it is not even the right ambition this year.

The healthy pace is one level, on your lowest pillar, per quarter. Grade honestly, raise the floor, put a date on the calendar, and grade again. If you want the tool, it is the Permission, People, Programs Scorecard. If you are not sure which pillar to move first, that has its own answer.

Artifact: The Permission, People, Programs Scorecard

Mon, 13 Jul 2026 00:00:00 GMT

How to use this

One rule. Score your company from 0 to 3 on each of the three pillars, using the tables below. Do it with the people who own the work, not alone at your desk, and score the company you have, not the one on the strategy slide. Then read your result by your lowest pillar, not your average, because Permission, People, and Programs grow together or none of them grows.

Permission: the space to move

Score	What it looks like
0 · Absent	No usable policy, or a blanket ban people quietly route around. Nobody can say cleanly which data goes in which tool.
1 · Stated	A policy exists on paper, but it is a data policy in disguise, and your people cannot answer the Tier 1 versus Tier 2 question without checking.
2 · Practiced	Two data tiers are clear, approved environments exist for each, and accountability and decision rights are named. People know where they are allowed to move.
3 · Native	You revisit permission as the capability changes. Governance creates speed instead of braking it, and you review each gate for its shape rather than freezing it.

People: the capacity to move

Score	What it looks like
0 · Absent	Access without adoption. A handful of enthusiasts, and everyone else works exactly the way they did last year.
1 · Stated	Training happened, a rollout or a webinar or a license, but behavior has not moved and there is no peer anyone is copying.
2 · Practiced	Respected people use it in view of others, the examples look like real work, and adoption is spreading by imitation.
3 · Native	Changing how the work is done is normal. People bring their own AI ideas, and new capability turns into new habits without a program pushing it.

Programs: the capability itself

Score	What it looks like
0 · Absent	No programs, or scattered pilots that never change how the institution operates.
1 · Stated	Tools get shipped, but every request defaults to the same reflex, a pilot or a purchase or a custom build, whatever the room reaches for.
2 · Practiced	Requests get routed on purpose, and the smallest builds are winning the adoption that unlocks the bigger ones. The learning is kept.
3 · Native	You keep re-routing your builds and your buys as the line moves. The institution operates measurably differently than it did a year ago, on purpose.

Read your score

Pillar	Your score (0-3)
Permission
People
Programs

Your true level is your lowest pillar. Two things are almost always true when leaders score themselves honestly. Permission comes in high, because writing a policy feels like progress and it threatens no one. People comes in low, because behavior is the hardest and least visible thing to change. If Permission is your highest score and People is your lowest, you are not behind, you are normal, and you now know exactly where the work is.

The move

Take your lowest pillar and raise it one level this quarter. Operator heuristic One level per quarter is a healthy default pace, not a law; a higher-risk or earlier-stage company should set its own target. Not all three, and not the one you like to show off. One level, on the pillar you are worst at. The question of which pillar to fix first has its own answer, and the full model is on Permission, People, Programs.

Score it in the next exec meeting, out loud, before anyone has time to round themselves up. Then put a date on the calendar ninety days out, and score again.

There Are Only Five Moves

Sun, 12 Jul 2026 00:00:00 GMT

Every AI request that lands on your desk feels like its own special problem. It is not. Strip away the framing and there are only five things you can do with any of them.

Self-serve it. Buy it. Build it. Redesign around it. Or do nothing. That is the whole menu. Most of the discipline is not deciding whether to act. It is routing each request to the right one of the five, on purpose, instead of defaulting to whichever move your culture reaches for by reflex.

[Diagram: Route each request through five moves, in order]

The order matters, because the cheapest honest answer is usually near the top. Can people already do this with tools you have? Self-serve it, with training and guardrails, not a project. Is the real fix a different workflow rather than a tool? Redesign it, because speeding up a broken workflow just gets you to the wrong place sooner. Is there a strong vendor for a capability the whole market shares? Buy it, and do not rebuild a commodity out of pride. Is it genuinely yours, on your data and your workflow? Then build it. And if the value is thin or the problem is not real, do nothing, and protect your attention and your credibility.

Most requests never reach build. That is the point. Build is the last stop, not the first reflex, and routing on purpose is what keeps a company from pouring its scarce engineering into the wrong four moves out of five.

The failure is rarely choosing wrong. It is not choosing at all: letting every request default to a pilot, or a purchase, or a custom build, because that is what the room always does. Say the five out loud, for each request, in front of the people who own the work.

Artifact: The Build-vs-Buy Decision Framework

What is the loudest AI request in your queue right now? Route it out loud through the five, in order, in front of the person who owns it. Notice how far down the list the honest answer sits. It is rarely where you started. The full discipline is on Buy the Record. Build the Intelligence.

FAQ: How do I audit my own company against its own rules?

Sun, 12 Jul 2026 00:00:00 GMT

Write your rules down first. Most companies cannot, and that is the first and largest gap, because a rule you have not written is a rule you cannot be held to.

Once they exist, take the work you are proudest of, the AI strategy you would show the board, and check it against them line by line. Where did you break your own standard? A rule you write down only means something if the gaps get closed, not just noted.

Do it in the open, gaps included. A case study that shows only the wins is exactly the premature coherence worth distrusting. The value of holding yourself to a written standard is that the gaps come out small and findable, instead of large and hidden. A company that never audits itself against its own rules does not have fewer gaps. It just has not looked.

See it done, on this publication itself: Built by Its Own Rules.

Artifact: The Build-vs-Buy Decision Framework

Sun, 12 Jul 2026 00:00:00 GMT

The one rule, and how it moved

Buy the system of record. Build the system of intelligence. The system of record is the infrastructure everyone in your industry shares and no one wins on, so buy it. The system of intelligence is the layer that turns your data and your particular way of working into advantage, so build that.

But know that the line has moved, hard, toward build. AI has made building faster and cheaper than it has ever been, so the honest default now leans toward build more than the old procurement wisdom allowed. When you catch yourself reaching for a vendor out of habit, stop and ask whether a small, sharp build would be faster than the buying cycle.

The five routes

Every AI request comes down to one of five moves. Most of the discipline is routing each request to the right one, on purpose.

Self-serve. Give people secure access to general-purpose tools, with education and accountability. This is where the AI Product Partner earns their keep: train for self-service, because most of the work lives here Operator heuristic (call it roughly 70%; the point is the majority, not the decimal), and a surprising amount of value arrives with no project at all.
Buy. License a mature capability the market already builds well, the commodity infrastructure everyone shares. This is a system of record.
Build. Create the capability only you can, on your data and your workflows. This is a system of intelligence, and in this era you will build more of it than you used to.
Redesign. Change the workflow or decision structure itself. Automate a broken process and all you get is the same breakage, faster.
Do nothing. Decline the weak requests. Not every problem needs AI, and saying no protects your attention and your credibility.

Route the request

Ask these in order, and stop at the first yes.

Can people already do this with tools you have? Self-serve. Train them and set guardrails, not a project. Most requests end here.
Is the honest fix a different workflow, not a tool? Redesign first. Do not automate the old shape.
Is there a strong, ready vendor for a capability everyone shares? Buy it. It is a system of record.
Is it yours to build? Build it, and see below.
Is the value thin or the problem not real? Do nothing, for now.

Build what you can't or won't buy

You build for two reasons, and the bar for both has dropped.

You can't buy it. The capability is genuinely unavailable, or your proprietary data and your particular workflow are the whole point and no vendor has them. This is the system of intelligence.
You won't buy it. It is bespoke and tailored enough that a vendor implementation would take more work, cost, and compromise than building it yourself. With AI in hand, a focused build is often faster than the procurement it replaces.

The old caution was drift toward build, rebuilding commodity you should have licensed. That is still true for the system of record, so do not write your own cloud or your own lab notebook. Past that line, build more freely than you used to.

Solve small, and they will bring you big

Here is the part most frameworks miss. The temptation is to reserve "build" for the big strategic bets, to only swing for the fences. In an AI-native company that is exactly backwards, because adoption and change are the whole game.

Solve one person's real problem, however small, and they come back with bigger ideas than they had before. A small build that makes a scientist's Tuesday better is not a distraction from the strategic work. It is how you earn the trust and the momentum to do the strategic work at all. Solve for the individual, and you unlock the institutional.

Revisit the line

The line is not fixed. What is a differentiating build this year can become a commodity you should buy in two, once the vendors catch up, and what was too expensive to build last year is a weekend now. Put a date on the calendar to re-route your biggest builds and your oldest buys alike.

Run your three loudest AI requests through this once, out loud, with the people who own them. Then run your three smallest, the ones you have been ignoring. The small ones are where adoption is won.

Audit Yourself in Public

Sat, 11 Jul 2026 00:00:00 GMT

The strongest test of a system is not whether it sounds good in a deck. It is whether its author will use it, on their own work, in public, where the gaps show.

Most companies fail that test quietly, and for one reason: they never wrote their rules down. A rule you have not written is a rule you cannot be held to. It is a preference, and preferences bend under pressure.

[Diagram: Written rules make gaps small and findable]

This publication was built on its own written rules, so I did the honest thing and audited it against them before I recommended you do the same. I found real gaps. The founding piece had no signature diagram, though the standard says every Issue carries one. And for a publication about using AI well, there was no disclosure anywhere that the work is AI-assisted, though I preach disclosing exactly that where it is material.

Neither was a catastrophe. That is the point. When you hold yourself to a standard you wrote down, the gaps come out small and findable, instead of large and hidden. A company that never audits itself does not have fewer gaps. It just has not looked, and the gaps it is not looking at are the large ones.

What a real audit looks like

Take the work you are proudest of, the AI strategy you would put in front of your board, and check it against your rules, line by line. Where did you break your own standard? Then close the gap, because a rule only means something if the gaps get fixed, not just noted.

And do it in the open. A case study that shows only the wins is exactly the premature coherence worth distrusting. The willingness to publish the gaps is the whole signal that the system is real.

I wrote the full accounting up as the first case study, the system applied to the thing you are reading.

Here is Monday morning. Write your rules down, if they are not already. Then run your loudest AI work against them and fix the smallest gap you find this week. The full self-audit is Built by Its Own Rules.

FAQ: How do I get AI to write in my voice?

Sat, 11 Jul 2026 00:00:00 GMT

Stop describing it. Everyone tells the model to be clear, smart, and concise, and everyone gets back the same thing, because those words describe no one.

Your voice is a pattern of decisions, not a list of adjectives: what you notice first, where you put the tension, which comparisons you reach for, what you refuse to exaggerate, which sentences feel dishonest coming from you. You cannot recite that from memory. You derive it from evidence.

So feed the model several things you wrote yourself, from different rooms, and have it find the recurring patterns. Its first read will grab the surface, that you favor short sentences, say, while missing that your real signature is moving from a concrete detail to a first-principles claim. Correct it. Every correction, this is too polished, I would never say that, the argument is cleaner but less true, makes your taste explicit, and that accumulated judgment is worth more than any prompt.

The full guide is How to Write With AI Without Sounding Like It.

Case Study: Built by Its Own Rules

Sat, 11 Jul 2026 00:00:00 GMT

The strongest test of a system is whether its author will use it. Not describe it, not sell it, use it, on their own work, in public, where the gaps show.

So here is the most honest thing I can hand you: this publication, built with the exact system it teaches. Every claim in it, applied to itself.

What this is

Translational Intelligence is the capacity to turn new capability into durable advantage, again and again, as the technology moves. This site is that capacity made concrete. It has a system, a discipline, a role, and a destination. I did not only write about them. I built the thing you are reading by their rules, and this is the accounting.

Buy the record, build the intelligence

The stack is a live example of the discipline. I bought the commodity, the system of record, and I built the layer that is mine.

[Diagram: Bought the record, built the intelligence]

Astro and Keystatic hold the pages. Beehiiv sends the email. Cloudflare serves it, GitHub holds the source, and the frontier models do what frontier models do. None of that is where the advantage lives, and writing my own would have been vanity. What I built is the layer that is genuinely mine: the design language, a signature diagram in every piece, the Artifact Library, the voice, and the way every page links into one connected argument instead of a feed. No vendor could sell me that, because no vendor has my problem.

And it leans build more than the old wisdom would, on purpose. The ethos is that in this era the line has moved toward build, and that adoption is won by solving small. This site is a stack of small builds, each one shipped before the next was started.

There is no AI work product

Here is the part most publications about AI will not say out loud. This one is AI-assisted. I use AI to draft, to argue with, and to build the site itself.

And there is no AI work product, only AI-assisted human work product. I am the author of record. Every claim, every number, every diagram, I own completely, whether I, a colleague, or a model produced the first version. That is not a hedge or a disclaimer. It is the standard I ask you to hold, and I am holding this publication to it in the open. A standing note now sits on the About page, because I preach disclosing AI assistance where it is material, and for a publication about using AI well, it is material.

I do not automate the struggle

I do not use AI to skip the thinking. I use it to reach the hard part more often. The ideas start with me: an argument I have been circling, a contradiction I cannot yet resolve, a claim I suspect is true but cannot defend. Only then do I put the model to work, and I put it to work making the problem harder, not finishing it.

The Think-Harder Writing Workflow is not a theory I admire. It is the process that produced every piece here, this one included.

Where I was breaking my own rules

A case study that shows only the wins is exactly the premature coherence I warn about. So before I published this, I audited the site against its own written rules. Here is what I found.

Every Issue is supposed to carry its own signature diagram. When I ran this audit, the founding piece was the one exception. It has one now, added the same day I wrote this. A rule you write down only means something if the gaps get closed, not just noted.

I preach disclosing AI assistance where it is material, and until this study there was no disclosure anywhere on the site. That was a real gap in the thing I most insist on. It is why the About note now exists, and why this case study does.

The cadence labels, the Tuesday and Friday stamped on everything, had drifted from useful into decorative, so I cut them back to where they inform.

None of these are catastrophes, and that is the point. The value of holding yourself to a standard you wrote down is that the gaps come out small and findable, instead of large and hidden. A company that never audits itself against its own rules does not have fewer gaps. It just has not looked.

Monday morning

If you want to know whether a system is real, watch whether its author will apply it to themselves, in public, with the gaps left in.

Try the thing this piece just described. Take your own AI strategy, the version you would show your board, and audit it against the rules you have written down. If you have not written the rules down, that is the first gap, and it is the biggest one. Then fix the smallest thing you find this week. That is where it starts. It is where this started too.

Arguing About the Wrong Thing

Fri, 10 Jul 2026 00:00:00 GMT

You have sat in this meeting. The whole argument is about tools. Which foundation model. Which vendor. Build the copilot or buy it. Everyone leaves feeling like a decision was made.

The choices matter, a little. But they do not decide your future, and pretending they do has a cost. It lets a room full of capable people feel busy while the company stands still.

The scarce resource was never the technology. It is the person who can hold a new capability in one hand and a real piece of work in the other and see how one should reshape the other. That person needs a name and a job.

[Diagram: The person who bridges the gap]

I call the role the AI Product Partner, and it exists because of exactly that gap. The people who know what AI can now do usually do not understand the work that has to change. The people who understand the work usually do not know what just became possible. Nobody who could close the gap alone is standing in it.

Both words are chosen on purpose

Partner, because this is not a ticket taker. The relationship is not tell me which tool to build. It is help me understand the outcome and the real work, and we will decide together what should exist. The job is one part enablement: someone who lives in the tools, carries real empathy for how hard it is to change how a person works, and spends the day teaching people to change themselves.

Product, because a demonstration is a comfortable way to lie to yourself. A prototype proves something is possible. A product makes it a repeatable part of how the institution works. The other part of the job is translating what teaching cannot solve into clear build requirements, and handing them to a dynamic, innovative engineering team to make real.

Not a new tool, a new seat

So the first move is not a purchase. It is to put a person at that intersection, give them real standing across Permission, People, and Programs, and let them reframe the work instead of taking tickets. As capability gets cheaper and more abundant, deciding what to do with it is the scarce skill, and it will not commoditize.

Where do your best people spend their days on work beneath them? Name that one function, and put a person at the seam this quarter, with the standing to change the work and not just field requests for it. The full role is on The AI Product Partner.

FAQ: Doesn't thinking with AI make writing slower?

Fri, 10 Jul 2026 00:00:00 GMT

At first, yes, and that is the point. You are not buying speed. You are buying depth, and depth is the thing worth having.

The fast path, hand the model a prompt and take its clean draft, feels quicker right up until you notice the argument was never yours and cannot survive a hard question. Then you rewrite it, or worse, you ship it. That is not fast. That is expensive.

Used to make the problem harder before it makes the prose easier, AI gets you to a sharper claim than you would have reached alone, and it gets you there without hollowing out your own thinking. Over a handful of pieces it turns out faster, because you stop rewriting drafts that cohered before they earned it.

Slower on the first draft, quicker to something true. That is a trade worth making every time.

The method is on one page: The Think-Harder Writing Workflow.

The One-Lever Mistake

Wed, 08 Jul 2026 00:00:00 GMT

A company decides to get serious about AI, and it reaches for one lever. It buys the licenses. Or it writes the policy. Or it ships a tool. A year later, the lever moved and the company did not.

The mistake is not the lever. Each one is fine. The mistake is thinking any one of them is a strategy.

[Diagram: One lever versus three pillars]

The system that builds the capacity is Permission, People, and Programs. Permission is the space to move: knowing where you are allowed to act, with which data, under whose accountability. People is the capacity to move: whether anyone actually changes how they work. Programs is the capability itself: what you self-serve, buy, build, or redesign.

They are not phases

The three are easy to say in order, so people run them in order. Finish the policy, then train the people, then start the programs. That sequence fails, because these are not phases. They are dimensions of the same thing, and they mature together.

Better Permission lets your people move faster and with more confidence. More capable people find and adopt better Programs, because they can see the openings in their own work. Programs surface new risks that send you back to sharpen Permission. You never finish one. You grow all three, and you grade yourself on all three.

The pillar that decides it

If you have to start somewhere, start where you are weakest, not where you like to show off. And the weak one is almost always People, because behavior is the hardest and least visible part of the whole enterprise. A license is not adoption. Someone can have the tool, the training, and the policy in front of them and still work exactly the way they did last year.

That is why a clean policy on top of unchanged behavior has transformed nothing. The model is a catalyst. The organization is the transformation, and the organization is people.

Grade yourself this week, honestly. Score your company on Permission, People, and Programs, and start on the one you scored worst, not the one that would look best in a deck. The full operating system is on Permission, People, Programs.

FAQ: How do I run build-versus-buy in a real meeting?

Wed, 08 Jul 2026 00:00:00 GMT

Do it out loud, with the people who own the work, not on a spreadsheet by yourself.

Take your three loudest AI requests. Route each one, in front of the room, through the five options: self-serve, buy, build, redesign, do nothing. Say why out loud. If all three come back build, stop, because you are almost certainly about to rebuild a commodity you could license.

Then do the harder half. Take the three smallest problems your best people keep hitting, the ones too minor to make any roadmap, and pick one to build this week. That is where adoption is won, and adoption is the whole game.

Give the routing a permanent owner whose job is to know the difference, and put a date on the calendar to re-route your biggest builds, because the line moves as the market moves.

The one-page tool is The Build-vs-Buy Decision Framework.

Your Edge Was Never the Model

Tue, 07 Jul 2026 00:00:00 GMT

Every few months a new model takes the lead, and every few months a wave of companies rebuilds its AI strategy around it. Both moves are a mistake.

The model that is ahead today will not be ahead for long. If your advantage is the model, you rent your advantage, and the rent resets every quarter. Whoever is on top next quarter, you will be renting from them instead.

The thing worth owning is underneath. It is the capacity to take whatever new capability arrives and turn it into how your company actually works. That capacity has a name.

[Diagram: The model is rented; the capacity is owned]

The capacity is translational intelligence: the institutional ability to convert emerging capability into durable advantage, again and again. Read that word institutional twice. It is not a skill one brilliant person has, and it is not a team you stand up in a corner of the org chart. It is something your company can do, as a company, and keep doing as the ground shifts under everyone.

The advantage is not the model. It is the capacity to keep translating.

Why this reframes the whole conversation

A frontier model behind a login is not transformation. A thousand licenses are not transformation. Between what becomes newly possible and what your institution can actually do sits a gap, and that gap is where most transformation dies. Closing it, over and over, is the entire job. The model is a catalyst. The organization is what changes.

That is also why the buying question, which vendor, which model, matters less than the room thinks. You can buy every input on the market and be the same company next year, only with a larger software bill. What you cannot buy, and what compounds, is the capacity itself.

Where it breaks

The work runs along a chain, from raw capability to permission to behavior to workflow to decision to advantage. Each link is a place the translation can fail. And experience keeps teaching the same lesson: most companies break at behavior and workflow, not at capability. They have the tools. They do not have the habits or the redesigned work. So they pour money into the first link and wonder why nothing moves at the last.

Stop asking which model. Take the chain and walk your own organization along it until you find the link that breaks. It is almost never the one you are spending on. Fix the real link, not the visible one. The full argument, and the whole chain, is on Translational Intelligence.

FAQ: What if legal wants a longer, stricter AI policy?

Tue, 07 Jul 2026 00:00:00 GMT

Take the question seriously, then push back on the premise. A longer, stricter policy that no one reads or can follow does not protect you. It protects the person who wrote it. The one-page version is not lax. It is the only kind that gets followed, which is what protection means.

Give legal the two things that carry all the weight. First, data sensitivity decides the environment: confidential information goes only into contracted, enterprise-secure tools you have approved, and everything else is fair game. Second, accountability is total and human: there is no AI work product, only AI-assisted human work product, and the author of record owns all of it.

If legal wants more, add specifics for the few genuinely high-stakes cases, regulatory, clinical, legal, and stop there. Every clause past a page trades real adoption for the feeling of coverage.

Take the one-page version and adapt it: A Lightweight AI Use Policy.

Excellent and Generic

Mon, 06 Jul 2026 00:00:00 GMT

You can do everything right. Start with your own idea, think it through, pressure-test it, land an argument that is genuinely yours. And the writing can still come out sounding like a machine made it. Not wrong. Not clumsy. Just generic. Nobody's.

That is the failure most people do not see coming, because it does not look like failure. It looks like a clean, competent, publishable draft.

Thinking hard about what you mean is the first half of the job, and I have written about not automating that struggle. This is the second half. Even when the idea is unmistakably yours, the prose can still belong to no one.

Excellent and generic

Here is the uncomfortable pair. A piece can be excellent and still be generic. Those are not opposites. Polish measures one thing. Whether the writing could only have come from you measures another entirely.

[Diagram: Excellent and generic are two different axes]

The trap is the top-left corner: excellent and generic. Fluent, well-organized, and completely interchangeable with what any competent person would have produced from the same prompt. The goal is the opposite corner, and getting there is not about writing better. It is about writing like someone.

Why it all sounds the same

AI prose is recognizable, but not because it reaches for a secret set of forbidden words. The tell is structural. The sweeping opener about a fast-changing world. The tidy rule of three. The false binary, this is not merely X, it is Y. The heading that just restates the thesis. The uplifting abstraction where a concrete conclusion belonged. Every tension resolved a little too cleanly.

No one of those is a crime, and human writers use all of them. The problem is accumulation. AI prose feels synthetic because every sentence performs its job too visibly. The transitions transition. The emphasis emphasizes. The conclusion concludes. Real writing has more variance. It lingers in some places and moves abruptly through others, and it trusts you to fill a gap now and then.

Voice is a pattern of decisions

The usual fix makes it worse. People hand the model a list of adjectives, clear, smart, conversational, concise, and wonder why the output sounds like everyone else who wanted to sound clear, smart, conversational, and concise.

Voice is not an aspiration. It is a pattern of decisions. What you notice first. How you build an argument. Where you place the tension and how long you hold it. Which comparisons you reach for, and which you would never make. What you refuse to exaggerate. Which sentences feel dishonest coming from you.

You cannot describe that from memory and expect a model to reproduce it. You derive it from evidence. Feed it several things you wrote yourself, from different rooms, and have it find the patterns. Then correct what it finds, because it will grab the surface first. Every correction, "I would never say that," "cleaner, but less true," is you making your taste explicit. That accumulated judgment is worth more than any prompt.

The one test

There is a single question that catches all of it. Could any competent person with the same prompt have written this?

If the honest answer is yes, the piece is generic however polished, and the fix is not more editing. It is to reclaim the passages that carry your judgment, the opening, the central claim, the turns, the ending, and write those in your own hand. I put the rest of it, the negative rules, the tells, the way to derive a voice from evidence, on one page.

Artifact: How to Write With AI Without Sounding Like It

Run the one test on something you are proud of. Take a piece AI helped you write, read it, and ask whether anyone with your prompt would have produced the same thing. Where the answer is yes, that paragraph is not yours yet. Rewrite it until it could only have come from you. That is the whole difference between using the tool and being replaced by it, and it usually lives in about four paragraphs a piece.

FAQ: Are we AI-native, or just AI-enabled?

Mon, 06 Jul 2026 00:00:00 GMT

Ask one question. What has your company actually reconsidered, versus just made faster?

If your workflows, your approval chains, your job descriptions, and your measures of value are the same as before, only now with a copilot bolted on, you are AI-enabled. You are quicker at the same documents, the same meetings, the same decisions in the same order. That is efficiency, and it is the old company with better throughput.

AI-native means you treated those inherited assumptions as the actual work, and asked which of them should still exist now that the constraints that created them are gone. It is not a finish line or a particular tool. It is a capacity to keep reconsidering as the ground shifts.

Most companies choose efficiency and call it transformation, because efficiency threatens no one and redesign does. The tell is whether anyone has changed what they decide, not just how fast they decide it.

The full picture is on The AI-Native Biotech.

Artifact: How to Write With AI Without Sounding Like It

Mon, 06 Jul 2026 00:00:00 GMT

The principle

AI can make any draft sound finished. That is the danger, not the promise. A style guide is not decoration; it is how you make your taste explicit, so that you, an editor, and a model all know what "good" and "sounds like us" actually mean. Written down, judgment becomes something you can repeat, delegate, and defend.

Voice is a pattern of decisions, not a list of adjectives

Everyone wants to sound clear, smart, and concise, so those words tell a model nothing. Your voice is the set of decisions you make: what you notice first, how you build an argument, where you place tension, how long you stay abstract before an example, which metaphors you reach for, what you refuse to exaggerate, and what kinds of sentences feel dishonest coming from you.

So do not describe your voice from memory. Derive it from evidence. Give the model several things you actually wrote, from different contexts, and have it find the recurring patterns. Then correct it, because its first read will fixate on the surface. Your corrections are the training, even when no model is technically being trained.

The rules worth stating, mostly negative

The most useful house rules are the "do nots," because they name the defaults you want to override. Ours, adapt your own:

Do not flatter the reader.
Do not inflate an ordinary observation into a civilizational revelation.
Do not use corporate throat-clearing.
Do not manufacture false balance when the argument supports a clear conclusion.
Do not resolve every productive tension into something tidy.
Do not end every section like a keynote.
Do not explain a sentence right after writing it.
No em-dashes. Emphasis is italic, never bold.

The tells to cut

AI prose is recognizable not by a secret set of forbidden words but by structural repetition. No single habit is fatal; the accumulation is. Cut for it:

the sweeping opener about a fast-changing world;
the tidy rule of three;
the false binary, "this is not merely X, it is Y";
headings that just restate the thesis;
"critical," "transformative," "profound," on repeat;
the uplifting abstraction where a concrete conclusion belongs;
disagreement flattened into a list of equally reasonable perspectives;
every tension closed too cleanly.

The cure is texture, not a banned-word list. Human writing lingers in some places and moves abruptly through others, trusts the reader to infer, and lets a sentence stand without a gloss.

The one test

Ask it of every draft: could any competent person with the same prompt have written this? A piece can be excellent and still be generic. If it could have come from anyone, reclaim the passages that carry the most judgment, the opening, the central claim, the decisive transitions, the conclusion, and write those yourself.

Keep exercising the taste

A style guide is not a substitute for taste; it is how you scale it. So keep the muscle alive. Write the first ugly paragraph yourself. Read the primary source before the summary. The guide keeps AI on the rails. Your hand keeps the writing yours.

Adapt every rule to your house. The point is not this exact list. It is that you wrote one down, so that "sounds like us" stops being a feeling and becomes a standard you can hold.

Don't Automate the Struggle

Sun, 05 Jul 2026 00:00:00 GMT

I was talking with a group of academics about how I use AI to write, and their worry was not plagiarism, or disclosure, or whether the prose can be detected. It was deeper. If we let AI help us write, will we slowly lose the ability to think?

It is a fair fear, and it deserves a real answer.

Writing is not the packaging around a finished idea. Often, writing is how the idea comes to exist. You start with an intuition, try to explain it, find it does not quite hold, revise, hit a contradiction, and arrive somewhere you could not have named when you began. The friction is the work.

An AI can erase that friction in seconds. Hand it a half-formed thought and it returns a clean thesis, three tidy arguments, and a conclusion that gestures confidently at the future. That can feel like progress. Sometimes it is. Sometimes it is only premature coherence, an idea made to sound finished before it has earned it.

The fear is real, but it aims at the wrong thing

Here is what the fear gets right. If you use AI to replace the struggle, the struggle atrophies. Outsource the part where you work out what you actually mean, and that muscle weakens, exactly as the academics worry.

But that is a fact about a mental model, not about the tool. The atrophy comes from replacing how you think. It does not come from updating how you think.

Change the model, and the same machine does the opposite. Used to finish your thought, AI makes you lazier. Used to make your thought harder to finish badly, it makes you sharper. The goal was never to have the machine complete your idea. It is to keep your idea from closing too soon.

Expand the problem before you compress the answer

Most people ask AI to synthesize far too early. They want the outline, the argument, the draft, before they have walked the whole terrain of the idea. That is the move that hollows out thinking.

Do the opposite. Before you ask AI to write a word, ask it to make the problem harder.

[Diagram: Expand, then decide]

What am I assuming? What is the strongest case against this? Where would an expert call it naïve? Which parts are genuinely mine, and which are familiar ideas in new clothes? What is the most uncomfortable implication if it is true? What would change my mind?

Those are not drafting prompts. They are thinking prompts. A good model will hold several competing readings at once, generate objection after objection without getting defensive, and pull in a field you would not have thought to check, long after a human colleague would have gone home. That does not make it wiser than a person. It makes it fast, available, and relentlessly patient. Point those traits at friction instead of away from it, and you leave the conversation with a more complicated understanding than you arrived with, and a sharper claim because of the complication.

Then choose what you believe

After the terrain, one decision cannot be delegated. What do I actually believe?

AI can lay out theses and tell you which is most defensible or most provocative. It cannot tell you which one you are willing to stand behind. Before you draft, say the claim in your own words: what you believe, why, what would make it false, and why it matters. Only then is drafting useful, because now the machine is building the road, not choosing the destination.

Keep the tells out, and keep some work by hand

When you do draft with AI, strip the tells. Not a list of forbidden words, the structural habits: the sweeping opener about a fast-changing world, the tidy rule of three, the false binary, the transition that only transitions, the uplifting abstraction where a concrete conclusion belongs. AI prose feels synthetic because every sentence performs its job too visibly. The cure is texture and judgment, not a banned-word list. Ask one thing of every draft: could any competent person with the same prompt have written this? A piece can be clean and still be nobody's.

And keep some of the work manual, on purpose. Write the first ugly paragraph yourself. Sit with a contradiction before asking the model to resolve it. Read the primary source before you request the summary. Calculators did not end arithmetic and GPS did not end knowing where you are, but the more powerful the tool, the more deliberately you have to keep the capacity to judge what it hands you. Call it cognitive maintenance.

The one test

There is a single test for whether AI accelerated your thinking or replaced it. Could you defend every major claim to a skeptical expert, explain where the idea came from, name its weak points, and say where your thinking changed, without leaning on the generated text?

If yes, the tool sharpened you. If no, it stood in for you. That is the same standard as everything else here: there is no AI work product, only AI-assisted human work product, and you own all of it.

Artifact: The Think-Harder Writing Workflow

Update the model, not just the tools

This is the cognitive version of being AI-native. The AI-native company does not run its old assumptions faster, it asks which assumptions still deserve to exist. The AI-native thinker does the same with their own mind. Do not hand AI the struggle to work out what you mean. Hand it everything that gets you to that struggle sooner, and more often, and you will not lose your capacity to think. You will have more of it.

Take an idea you have been circling, and do not ask AI to write it up. Ask it to attack it. Make it list your assumptions, argue the other side, and name the implication you have been avoiding. Then close the laptop and write the first paragraph yourself. The blank page was never sacred. The struggle to decide what you mean is. Automate your way to more of that struggle, and guard the struggle itself.

FAQ: Do I hire an AI Product Partner, or grow one?

Sun, 05 Jul 2026 00:00:00 GMT

Grow one, in most cases. The role rewards range over pedigree: product judgment, enough technical fluency to tell commodity from advantage, real curiosity about how your scientists and operators work, and the humility to discover the original problem was the wrong one. The tool fluency is the easy half to teach. The judgment and the empathy are not.

So look first for someone who already knows a function well enough to see its friction, and whom people trust, then give them the AI fluency and the standing to act. Standing matters more than the reporting line. They need real authority across Permission, People, and Programs, not a seat buried in a backlog taking tickets.

Where do they sit? Close to the work, not off in a central lab. The whole point of the role is to live where capability meets the work, and to change how it happens.

The full role is on The AI Product Partner.

Artifact: The Think-Harder Writing Workflow

Sun, 05 Jul 2026 00:00:00 GMT

The principle

Use AI to reach the hard part of thinking more often, not to skip it. The struggle to work out what you actually mean is the part that has to stay yours. Everything that gets you to that struggle sooner is fair game. Run a piece through these eight steps and you spend AI on friction, not on avoiding it.

The eight steps

Originate. Start with something only you could have produced: an observation from experience, an unresolved contradiction, a voice memo from a walk, a paragraph that does not quite work, a claim you suspect is true but cannot yet defend. It should be rough. The roughness is evidence of your thinking.
Interrogate. Before you ask AI to write a word, ask it to make the problem harder. What am I assuming? What is the strongest counterargument? Where would an expert call this naïve? Which parts are genuinely mine, and which are familiar ideas in new language? What is the most uncomfortable implication if it is true? What would change my mind? These are thinking prompts, not drafting prompts.
Decide. State the thesis in your own words, before drafting. Be able to say what you believe, why, what would make it false, why it matters, and what you are asking the reader to see differently. AI can compare theses. It cannot choose the one you are willing to stand behind.
Structure. Now bring AI back in. Ask it to organize the argument, compare a few possible architectures, and flag where an example or a piece of evidence is missing. You are choosing the road; it is helping you lay it.
Draft. Write directly, collaborate paragraph by paragraph, or have AI produce a draft from the decisions you already made. The order does not matter. What matters is that the thinking happened first.
De-synthesize. Strip the tells. Not forbidden words, structural habits: the sweeping opener, the tidy rule of three, the false binary, the transition that only transitions, the uplifting abstraction where a concrete point belongs. Ask of every draft: could any competent person with the same prompt have written this?
Reclaim. Rewrite the passages that carry the most judgment yourself, the opening, the central claim, the decisive transitions, the conclusion. These are where your voice has to be unmistakable.
Defend. The test. Could you explain every major claim to a skeptical expert, name its weak points, and say where your thinking changed, without leaning on the generated text? If yes, AI accelerated your reasoning. If no, it stood in for it, and you have work to redo.

The blank page was never sacred. The struggle to decide what you mean is. Use this to reach that struggle more often, and never to automate it.

Stop Swinging for the Fences

Fri, 03 Jul 2026 00:00:00 GMT

You have been in the meeting. The one where a team debates a big AI platform for a year while the small, obvious win, the thing that would make one scientist's week better, sits unbuilt because it is not strategic enough to bother with.

That instinct is expensive, and in the age of AI it is backwards.

The line moved toward build

Start with what changed. For most of software history the safe money said buy. Building was slow, expensive, and risky, so you bought the commodity and reserved building for the few bets that would define the company. That wisdom has not vanished, but the line it drew has moved, hard, toward build. AI made building faster and cheaper than it has ever been. A focused tool that used to be a two-quarter project is now a week. So when you reach for a vendor out of habit, stop and ask whether a small, sharp build would be faster than the buying cycle it would replace.

The trap is only building big

Here is the subtle part. Once people accept that they can build, they only want to build big. They swing for the fences. The platform. The flagship. The strategic bet that will look good in a board deck. And while they spend a year designing it, the hundred small problems people have every day go unsolved.

In an AI-native company, adoption and change are the entire game. A brilliant platform nobody adopts changed nothing. A tiny tool a scientist reaches for every morning changed how the work happens. Permission, People, Programs already told you the hardest part is behavior, not deployment. This is that same truth, pointed at your build list.

Solve for one, unlock the institution

[Diagram: Solve small, unlock the institution]

So solve small, on purpose. Take the unglamorous problem one person has and fix it this week. Then something happens that no roadmap predicts. That person trusts the tool, and they trust you, and they come back with a bigger idea than they ever would have raised before, because now they believe it is possible.

Solve for one individual's real need, and you unlock the larger thinking that solves the institution's. The small build is not a distraction from the strategic work. It is how you earn the trust and the momentum to do the strategic work at all.

Which is which

None of this means build everything. You still buy the commodity, the system of record no one wins on, and you do not write your own cloud or your own lab notebook. The discipline is knowing which is which, and where the line sits this year. I put it on one page.

Artifact: The Build-vs-Buy Decision Framework

Forget your AI strategy for a week. Find the smallest real problem a good person on your team keeps hitting, the one too small to have made any roadmap, and solve it this week. Then watch what they bring you next. That is not a detour from transformation. That is where it starts.

FAQ: How do I tell a real build from rebuilding a commodity?

Fri, 03 Jul 2026 00:00:00 GMT

There is a single test. Could you buy this, and if you did, would you lose nothing that sets you apart? If yes, it is a commodity. Buy it, and do not let pride talk you into a custom version of software the market already builds better.

You build for two reasons. You cannot buy it, because your proprietary data and your particular workflow are the whole point and no vendor has them. Or you will not buy it, because it is bespoke enough that a vendor implementation would cost more work and compromise than building it yourself. Everything else is a system of record you should license.

The trap in this era is rarely too little building. With AI in hand, it is building the wrong things: rebuilding the commodity while the small, differentiating tools go unbuilt. Route each request on purpose.

The whole discipline is on Buy the Record. Build the Intelligence.

There Is No AI Work Product

Thu, 02 Jul 2026 00:00:00 GMT

The first thing almost everyone asks me is a version of the same question. What should our AI policy be? They are bracing for a long document, a committee, a quarter of legal review before anyone is allowed to touch a tool.

Here is the whole thing in one sentence.

There is no such thing as an AI work product. There is only AI-assisted human work product.

It does not matter who drafted it

Read that again, because it decides everything else. The person whose name is on the work owns all of it. Every fact, every number, every claim. It does not matter whether they wrote it, a colleague wrote it, or a chatbot wrote it. The author of record is accountable, completely, for what they hand over.

[Diagram: One accountable human]

The fear that melts

This is the part that moves mountains. The moment accountability sits with the human, the fears that freeze companies lose their grip. Hallucinations. Uneven quality. A confident, fluent, wrong answer. None of these are new. They are the ordinary hazards of any first draft from any source, and you already know how to handle them, because you read the work before it leaves your hands.

A chatbot is a fast, tireless, sometimes-wrong colleague. You would not send a junior analyst's memo to the board unread. Treat the machine's output the same way, and suddenly you can use it for far more, far faster, because you are the backstop, and you always were.

Two tiers of data

Everything else is logistics. Most of what people call an AI policy is really a data policy, so keep it simple enough to hold in your head. The sensitivity of the information decides the environment it is allowed to enter.

Tier 1 is confidential: unpublished results, program data, patient information, anything not yet public. It goes only into contracted, enterprise-secure environments you have approved for that class of data. Tier 2 is open: anything public, or that safely could be. There the default is yes, so explore. That is the whole model, and if someone cannot say which tier a thing belongs to, that is a classification question to answer first, not a reason to freeze.

The question you have to answer

The hardest part hides inside Tier 1, and it is not technical. It is whether you trust your own contracts. If you hold an enterprise agreement that a vendor will not train on or keep your data, then you have already made the decision. Trust it, and let people work.

Reopening that debate on every single use is not caution. It is paralysis dressed as diligence. Responsible innovation means you do not relitigate settled questions out of principle. And if you genuinely do not trust the agreement, then be honest with yourself: you do not have a tooling problem, you have a Permission problem, and the work is on the front end, choosing terms you can stand behind. Do that once. Then get out of the way.

Write it on one page

So write your policy, and write it short. The few duties that come with total accountability are simple: verify before it leaves you, name the human on consequential work, disclose where it is material, and ask early when unsure. You do not have to start from a blank page.

Artifact: A Lightweight AI Use Policy

Here is Monday morning. Do not commission a policy. Write the sentence at the top of a blank page, there is no AI work product, only AI-assisted human work product, and then add only what you need underneath it: which data goes where, and who to ask when in doubt. If your draft runs past a page, you are writing to cover yourself, not to help your people. The shortest honest policy is the one that gets read, and the only one that lets the work move.

FAQ: Which pillar should I fix first?

Thu, 02 Jul 2026 00:00:00 GMT

Grade yourself honestly on all three, then start with your weakest, not your favorite. Almost everyone wants to start with Permission, because writing a policy feels like progress and it threatens no one. But a clean policy sitting on top of people who work exactly the way they did last year has changed nothing.

The pillar that decides the outcome is almost always People, because behavior is the hardest and least visible part. Someone can have the tool, the training, and the policy in front of them and still not change how they do the job. If your governance is tidy but adoption is flat, you have Permission without People, and no amount of new policy will fix it.

So the honest first move is to find one place a respected person on your team would change their Tuesday, and make that real. Then the other two pillars have something to grow around.

The full model is on Permission, People, Programs.

Artifact: A Lightweight AI Use Policy

Thu, 02 Jul 2026 00:00:00 GMT

The one idea

There is no such thing as an AI work product. There is only AI-assisted human work product. Whoever puts their name on a piece of work owns all of it, every fact, every number, every claim, no matter whether they, a colleague, or a chatbot produced the first draft. That single principle is the whole policy. Everything below is how to live it.

Why this frees you

Once accountability sits squarely with the human author of record, the usual fears lose their grip. Hallucinations, uneven quality, a confident wrong answer, these are not new risks that AI introduced. They are the ordinary risks of any draft from any source, and you already know how to manage them, because you check the work before it leaves your hands. A chatbot is a fast, tireless, sometimes-wrong colleague. You would not forward a junior analyst's memo to the board without reading it. Treat AI output the same way and you can use it for far more, far faster, because you are the backstop.

The two tiers of data

Most of what people call an AI policy is a data policy in disguise. Keep it simple enough to hold in your head. The sensitivity of the information decides the environment it is allowed to enter.

Tier 1, Confidential. Anything business-confidential: unpublished results, program data, sequences, patient information, financials, legal matters, anything under an NDA or partner agreement, anything not yet public. Tier 1 information goes only into contracted, enterprise-secure environments that [Company] has approved for that class of data. Never a personal or consumer account.
Tier 2, Open. Public or non-confidential information: published literature, general knowledge, marketing copy, anything already public or that safely could be. Use any approved tool freely, and explore. The risk is low and the upside is high, so the default here is yes.

If a person cannot say cleanly which tier a piece of information belongs to, that is a classification question to resolve first, not a reason to freeze.

On trusting your contracts

The hardest Tier 1 question is whether an enterprise agreement is really enough to protect your data. It is a fair question, and it deserves to be settled once, deliberately, up front, not relitigated on every use.

Responsible innovation means not reopening settled debates out of principle. If [Company] has done the diligence and holds an enterprise agreement that a vendor will not train on or retain your data, then decide, and let people work. But be honest that a contract is one control, not the whole story. The full picture is the control environment around it: access controls, retention and residency, subprocessors, incident response, and monitoring. Frameworks like the NIST AI Risk Management Framework exist to map that terrain, and for regulated records the standards below govern. If you do not trust the arrangement, you do not have a tooling problem, you have a Permission problem, and the work is on the front end, choosing vendors, terms, and controls you can stand behind. Do that once, then get out of your people's way.

What you still owe the work

Accountability is total, so a few duties come with it.

Verify before it leaves you. Facts, figures, citations, and quotes are yours to confirm. AI is a strong first draft, never a source of record.
Name the human on consequential work. For anything that becomes part of an official record, a regulatory submission, a clinical judgment, a legal position, a published result, a specific person owns the decision and a human reviews before it ships. Higher stakes, more review.
Disclose where it is material, not everywhere. You do not caveat every email. But where the origin of the work matters to the reader, the scientific record, a regulatory filing, be transparent about AI assistance.
When in doubt, ask. [Name or role] is the person to ask before, not after. Asking early is always the right call, and it is never held against you.

What this policy is not

It is not a surveillance program and it is not a ban. It is a one-page employee quick guide, the layer people actually read, and it sits inside a fuller governance architecture your quality, security, and legal functions own: provenance, access controls, retention, subprocessors, validation, incident response, and monitoring. This page makes people accountable and fast; it does not replace that control standard. The goal is more capable people doing better work, and accountable for all of it.

Adapt the bracketed items for [Company], approve your environments and your point of contact, and this is ready to use. Keep it to a page. If it grows, it stops getting read.

Sources and further reading

NIST, AI Risk Management Framework (AI RMF 1.0) (2023), for the fuller govern/map/measure/manage control model
FDA, 21 CFR Part 11, Electronic Records; Electronic Signatures, where AI touches regulated records
EMA, Reflection paper on the use of AI in the medicinal product lifecycle (2024)

The Biotech of Tomorrow

Wed, 01 Jul 2026 00:00:00 GMT

Picture the biotech that did everything right. It bought the licenses. It wrote the responsible-use policy. It ran the pilots, counted the hours saved, and put the numbers in a board deck. A year later it was faster. It was also the same company it had been the year before. Faster at the same documents. Faster at the same meetings. Faster at the same decisions, in the same order, for the same reasons.

That is not transformation. That is efficiency wearing transformation's clothes.

Almost everyone is in this trap. The reason is the question they started with: how can AI help us do our existing work faster? Reasonable question. It also guarantees you rebuild the past at a discount.

This publication starts from a different one. What would we build if today's capabilities had existed when this company, this function, this workflow was first designed?

That swap is the whole game. It is the line between an AI-enabled biotech and an AI-native one.

The wrong debate

Walk into most strategy rooms and you will hear an argument about models. Which foundation model. Which vendor. Build or buy the copilot. The choices matter. But they do not decide your future, and pretending they do has a cost. It lets everyone feel busy while the company stands still.

The model is not the transformation. The organization is the transformation.

A frontier model behind a login is not a new company. A thousand licenses are not a new company. Three hundred pilots are not a new company. Those are inputs. The output is an institution that spots a new capability, decides where it changes the work, gives people permission to act, redesigns the workflow around it, and can do it again next quarter. That chain, from raw capability to real advantage, is the product. Everything else is a demo.

[Diagram: Inputs are not the transformation]

Why efficiency is a dead end

Efficiency is seductive because it is safe. Hours saved is a clean number. It fits in a deck. It threatens no one.

That last part is why leaders reach for it. Redesigning work changes who does what, who decides, and whose job was built around a limit that no longer exists. Efficiency changes the numbers without changing the powerful. So the powerful pick efficiency, call it transformation, and wonder a year later why nothing feels different.

There is a deeper problem. When you automate a process, you freeze it. You take a workflow shaped by the limits of an older technology and pour concrete around it. Faster concrete. Still concrete. The handoffs, the review gates, the separations of duty that existed because information used to be expensive to move, are now fixed in place. You made yesterday permanent and called it progress.

Automating a broken process does not fix it. It gives you a faster broken process.

What AI-native means

Not a company where machines do everything. That is a boring fantasy. An AI-native biotech is built on an honest read of what people do well, what machines do well, what software can now carry, and how freely information can move when moving it costs almost nothing.

It keeps asking hard questions about its own design. Should this workflow exist as it does, or only because it always has? What still needs to be separate now that one system can hold all of it at once? Which decisions could happen earlier, with better evidence, if the right person saw the right thing in time? Where does human judgment matter more, not less?

None of those are questions about a model. They are questions about the institution. The technology is the catalyst. The organization is what changes.

So here is Monday morning. Pick one workflow that matters. Not the easy one. Not the one with the loudest AI request. One that carries real weight for the science or the business. Ask two questions. If we designed this today, knowing what these systems can do, what would we build? And what is actually stopping us, a hard constraint or a habit we inherited? The gap between those answers is your transformation. Everything else is a purchase order.

The map

Translational Intelligence is the capacity to turn new capability into durable advantage, again and again, as the technology keeps moving. That is the whole idea in one line. This publication builds it out.

The system that creates the capacity is Permission, People, and Programs. Permission is knowing where you are allowed to move. People is behavior change, the hardest and most decisive part. Programs is what you self-serve, buy, build, or redesign.

The role that makes it real is the AI Product Partner, the person who sits where capability meets the work and turns one into the other.

The destination is the AI-native biotech, the company that never stops translating, with no final form to reach.

Over the coming weeks I will take each of these apart, one issue at a time, with the frameworks and the language to use them. This is issue zero.

Why I am doing this

I have spent more than a decade in AI, most of it back when biotech saw it as a lab tool and nothing more. The last five years I have spent inside organizations, rebuilding them to meet the technology of today with an operating model built for tomorrow. Pandemic response at Google. A genotype-to-phenotype engineering team at Colossal. Enterprise AI transformation at Avidity. The same charge now at Alloy, through Vigilance. Different missions. Same work. And the same lesson every time: the technology is the easy part, and the human part is most of the job, by a wide margin.

People call my strategies surprisingly practical. The first time, it was a small dig, a way of saying they sounded too simple to matter. The next conversation, that person had tried it, and they had learned how hard simple is. Now we talk all the time about the human part, because that is where transformation is won or lost.

I get asked how to start almost every day. I want to help all of you, but I cannot sit with everyone. So this is my answer at scale. Nothing held back, nothing confidential. The gig is up. The edge was never a secret formula. It was the willingness to do the hard, human work of change, and then to do it again.

I called this translational intelligence on purpose. Because the more intelligently we all operate, the faster we translate science into therapies.

FAQ: Where do I actually start with AI at my biotech?

Wed, 01 Jul 2026 00:00:00 GMT

I get this one almost every day, usually from a CEO who has already been pitched ten platforms and is no closer to an answer.

Here is the honest version. Do not start with a tool. Do not start with a task force, a strategy offsite, or a backlog of three hundred use cases. Those all feel like progress and produce none.

Start with one workflow that matters. Not the easiest one, and not the one with the loudest AI request. One that carries real weight for the science or the business. Give it a single owner whose job is the outcome, not the software. Then ask two questions about it. If we designed this today, knowing what these systems can now do, what would we build? And what is actually stopping us, a hard constraint or a habit we inherited?

The gap between those two answers is your starting point. It is concrete, it belongs to someone, and it will teach you more about transforming your company than any platform demo. Do that once, learn from it, and do it again. That is the whole method, and it is why I called this translational intelligence in the first place.

If you want the long version, read The Biotech of Tomorrow and Permission, People, Programs.