A regulatory change doesn't change a health plan until someone rewrites the policy and the process that enforces it. Readily just announced an $11 million Series A led by Define Ventures. The company intends to connect regulatory changes with internal health-plan policies and compliance processes. That connection is the gap worth looking at. A new rule is published in one place. The health plan's internal policies live in another. The compliance process meant to carry out the rule lives in a third. When those three sit apart, someone has to link them by hand. That is the cost: manual translation work between what the regulation says and what the plan actually does. The pattern persists because each piece looks fine on its own. The regulation is clear. The policy exists. The compliance process exists. The failure sits between them, where nobody owns the translation. Funding matters because translating regulation into operational controls sits right next to payer rules and authorization workflows. Those workflows are where a regulatory requirement becomes a decision about a specific request. If you build or buy in this space, use one test: pick any regulatory change and trace it to the internal policy it touches, then to the compliance process that enforces it. Wherever the trace breaks, the control is missing. A regulation is only as real as the controls that carry it out.

A career change doesn't reset you to zero. Mistake 1: Waiting until you feel qualified The feeling of being qualified arrives after the work. So the work has to come first. Confidence follows action. You feel qualified once you've done the work. Waiting for the feeling means waiting for something that can't show up first. Start with one small piece of real work. Pick a single task from the new field and finish it. A finished task gives you something concrete to point to. Treat feeling unqualified as your starting condition. It's where you are on day one. Begin from there. Mistake 2: Writing off your past experience Ten years in another field is context, so use it. It's the first asset you bring to the new field. Your old field is context you already own. Years of work in one field mean years of knowing its problems, its people, and its standards. That knowledge doesn't expire when your job title does. List what transfers. Write down the skills, projects, and relationships from your previous work. Then match each one to a need in the new field. Lead with your history when you explain the move. What you did before is part of why you're useful now. Put it in the first sentence of your story. Mistake 3: Copying someone else's path Their route fit their starting point, not yours. You're starting from different ground. The same steps land differently from a different start. Someone else's sequence worked for them. Your starting point changes where those steps lead. Treat their path as one example. Study what they did and take the ideas that fit. Then build your own route from where you stand. Build your map from your own inventory. Mistake 2 is the starting material: the experience you listed decides your first move. Their path can't tell you that. A career change doesn't reset you to zero. You carry everything you already know into the new field.

We continue to see AI’s march on drug discovery and biotech, proving that the model is not the finish line. Multiply Labs just raised $75 million in Series B funding to expand its robotics platform for pharmaceutical manufacturing. The money is going to the physical side of the problem. The details are worth reading: - It started with cell and gene therapies and is extending into antibodies, viral vectors, and mRNA-based products. - Its robots are designed to work alongside existing manufacturing instruments. - Customers operate the systems in their own facilities. I read this as another piece of AI moving into physical space. Wearables, on-device models, and now lab robotics all point in the same direction. The cost of ignoring this layer is easy to see. A model can propose a candidate on a screen, but a medicine still has to be made. Advances in computational drug discovery still depend on scalable physical manufacturing. A design that can't be produced reliably stays a design. That is why the robots matter. They plug into the instruments a lab already runs, which puts automation into the physical workflow instead of beside it. When you see a bold AI claim in biotech, ask one question: where does the physical step happen, and what automates it? Reliable automation of biologics production could become an important enabling technology. The model is one half of the system. The robot arm is the other.

Want to write clearly about AI? Shrink the task until it's one decision. My smallest AI writing task: replace one vague phrase with a specific one. Vague: "AI improves healthcare." Specific: "AI can help clinicians review medical images faster." GOAL: Clearer meaning, same claim. FORMAT: The revised phrase only. WORD CHOICE: Concrete nouns and verbs. Ban "revolutionary," "powerful," and "transformative." Three lines of rules. One example that follows them exactly. Run enough phrases through it, and your style will be written down.

The model is the smallest part of an AI product: 3 mistakes teams make when building the rest Three mistakes keep teams from building AI products that last. All three come from treating the model as the product. Mistake 1: Starting with models instead of problems A model is a capability. A problem is why someone would use it. Teams that start with the model go looking for a place to put it. Teams that start with the problem can evaluate the model as one option among several. The second approach keeps the product tied to something a user needs. Mistake 2: Confusing a working demo with a product A demo shows the model can do a task under conditions you chose. A product has to do that task for people you didn't choose, inside workflows you don't control. The demo answers "can this work?" The product answers "will this keep working for the people who depend on it?" Those are different questions, and only the second one matters after launch. Mistake 3: Underestimating integration and maintenance A model that sits outside the tools people already use becomes one more tab to remember. Integration connects the model to the data and workflows around it. Maintenance keeps that connection working after launch. Both are ongoing work, and neither shows up in a demo. The system is the product. Each mistake skips a part of the system: the problem, the proof beyond a demo, the connections, the upkeep. The model sits in the middle of all four. The hardest part of AI isn't the model. It's the system around it. Before you pick a model, write down the problem it solves, the workflow it has to live in, and who will maintain it.

A medical AI that only reads the image is answering half a clinical question. A chest X-ray shows what the scan contains. The physician's history shows what the clinician already knows about the patient. A new paper from Jialu Pi et al. combines the two. It pairs chest X-rays with physician-authored histories for opportunistic cardiovascular-risk prediction. The results show what the image-only approach leaves out. The combined approach outperformed unimodal baselines and medical vision-language baselines. It did so across three cohorts: internal, emergency-department, and MIMIC. The architecture is the part I'd study. It uses a role-decoupled dual-LLM design with causal reinforcement learning. Reasoning is explicitly separated from risk prediction. That separation changes the job. The model no longer just interprets an image. It selects which clinical evidence matters, then predicts risk. If you evaluate a multimodal medical AI system, ask two questions: - Does it use the physician's context, or only the pixels? - Is the reasoning step separate from the prediction step? Image interpretation is one input. Clinical reasoning starts with choosing the evidence. Paper: arxiv.org/abs/2609.38924

3 mistakes people make when starting a business: Building before talking to customers. Spending months perfecting a product. Mistaking social media attention for demand. Find someone willing to pay before you build something worth selling.

3 mistakes people make when changing careers: 1. Waiting until they feel qualified. The feeling arrives after the work, so start the work. 2. Writing off their past experience. Ten years in another field is context. Use it. 3. Copying someone else's path. Their route fit their starting point, not yours. A career change doesn't reset you to zero. You carry everything you already know into the new field.

3 mistakes teams make when building AI products: Starting with models instead of problems. Confusing a working demo with a product. Underestimating integration and maintenance. The hardest part of AI isn't the model. It's the system around it.

30 days. I'm writing every day. Three topics: → Applied AI research & evaluation → Building & deploying AI in the real world → Healthcare AI & health technology The full series lives on Substack and here on X.

Healthcare is treating AI agents as someone else's story. Agents have been framed as a tool for coding and for other industries. Healthcare leaders read those headlines and file them under "later." Then Heidi launches Heidi II. According to Fierce Healthcare, it expands the company's ambient platform into agents that can handle: - referral management - chart preparation - follow-up coordination - population-health reviews - patient outreach None of that is note-taking. It is the administrative work that surrounds the visit. Two details matter more than the task list. Organizations can configure approval controls. And they can save agent workflows as reusable routines. Approval controls mean a person stays in the loop. Reusable routines mean a workflow gets built once and run again. That is how software becomes part of daily operations. The cost of missing this shift is a planning error. If you treat agents as a coding trend, you won't evaluate them against the work your own team does around every patient encounter. The pattern persists because ambient scribes looked like a contained product: one tool, one job. Heidi's launch is one of the clearest examples yet of that wedge expanding into a broader clinical workflow operating layer. Heidi is one case. The question it raises applies to any clinical team. Pick one administrative workflow your team repeats, such as referrals or chart prep. Write down each step, then mark where a human must approve before anything moves forward. That map is what an agent will be configured against.

Raw evidence is not reasoning, and AI that only retrieves it will only respond. Tying raw evidence to meaningful natural-language reasoning is a critical path to AI that understands. That reasoning needs a place to run, and for clinical AI that place is the clinician's workflow. Look at what Becker's Hospital Review reported on September 28. OpenEvidence confirmed a $250 million financing led by Andreessen Horowitz and Byers Capital. The round values the clinical decision-support company at $15 billion. Its physician-facing search product is increasingly embedded into health-system workflows, including Epic environments. The pattern to watch is treating clinician-facing evidence retrieval as a feature. A feature gets bolted onto a product. A platform sits where clinicians already work and turns evidence into answers in natural language. Becker's frames the valuation as investor conviction that clinician-facing evidence retrieval can become a major platform category rather than a feature. When you evaluate a clinical AI product, ask two questions: 1. Does it connect raw evidence into a natural flow of reasoning, or does it only return sources? 2. Does it live inside the health-system workflows clinicians already use, Epic environments included? Investors are reaffirming this path.

Wearables already produce informative data. That data rarely makes it into the clinical flow. It stays in a proprietary phone app. That is the symptom of a bigger gap. Health tech and AI are heading toward wearables and physical devices. AI is moving out of the cloud and into the real world. But a device only helps clinical care if its data can travel. The cost is easy to see. The wearable captures information, and the clinician working from the EHR and imaging never sees it. Each data stream gets treated as its own separate problem. That pattern persists because each stream feels like its own product. The wearable has its app. The EHR has its system. Imaging has its own. Each one works on its own terms, so nobody has to solve the cross-integration. Duke's Center for Computational and Digital Health Innovation just launched a program that goes the other way. It integrates imaging, EHR data, wearables, behavioral signals, and computational models into continually updated digital twins. The first focused pilot is in heart failure. That is a concrete attempt to operationalize longitudinal multimodal modeling instead of treating each data stream as a separate AI problem. A decision rule for anyone building in this space: before asking how smart the device is, ask where its data goes next. If the answer is a proprietary app, the device is not yet part of the clinical picture. The model only gets better when the data is connected.

Healthcare AI passes short tests. Long-running operations need evals built to match. AI is earning trust one short exchange at a time. A single question gets a good answer. A targeted feature does its one job well. The errors that we're chasing are becoming more and more nuanced every day. Obvious hallucinations, while not a thing of the past, are exceedingly rare in relative terms these days. Those results are real progress, and they are why these models are being considered for bigger work. The next job is long-running, complex operations, and our evals haven't caught up to it yet. Short exchanges and targeted features are much easier to test. The input is small, the output is verifiable against evidence, and the scope is clear. That is why the support is strongest there. Healthcare AI is starting to prove itself in exactly these settings, and that deserves credit. Models are now being applied to complex, long-running operations with evolving timelines. Software engineering is one place this is happening. Healthcare is another. In a long-running operation, the model carries information forward, acts on it, and keeps working as the situation changes. We know much less about how healthcare AI behaves under those conditions than we know about how it behaves in a single exchange. The fix is to have evaluation follow the work. If deployment is moving from moments to long stretches of operation, the tests have to cover long stretches of operation too. Evaluation is shifting toward longitudinal and system-level reliability: Belief updating over time. When new information arrives, does the model revise what it believes, and does it do so correctly as a case unfolds? Post-market performance of commercial AI. How do products behave after release, in real use, once the launch-day testing is over? Judge validity. If a model grades another model's output, can we trust the grade? Explicit action and completion gating for agents. What decides when an agent may act, and when it can say a task is finished? Together they treat reliability as something that accumulates over time and across a whole system. A good single answer no longer counts as proof of reliability. That shift is encouraging, because the field is asking better questions as the stakes rise. One recent benchmark, Synthetic Hospital, is attempting this longitudinal style of evaluation along with multi-axis assessment. It looks at a model across time and across several dimensions of performance instead of scoring one exchange on one axis. Evaluation paper is here: arxiv.org/abs/2610.02684 Synthetic Hospital: arxiv.org/abs/2609.30027 It shows the approach can be built, and it gives other teams something to react to, extend, and improve. We need more of them. One benchmark won't cover all of healthcare operations.

AI in medicine isn't doctor versus AI. It's doctor + AI. Patients now arrive with AI-generated summaries, possible diagnoses, and treatment options. Then they sit across from their doctor and ask what they think. They want the machine's access, speed, and breadth. They also want a human who understands the person behind the data. AI expands access to information. Clinical judgment turns it into care.

Data is still the new oil. We keep picturing the wrong oil. Snorkel AI raised $350M at a $3.5B valuation on September 22. The more telling detail is what Snorkel now sells. It started primarily selling data-labeling software. It has shifted toward finished expert datasets and reinforcement-learning environments, including work involving medicine and other specialist domains. That is a different product. Labeling software hands you a tool. A finished expert dataset hands you the refined output. A reinforcement-learning environment hands you a place to test the model against it. The old analogy treated data as a raw resource you pile up. The pattern this raises suggests the value sits further down the pipeline: in the expert judgment baked into the data and in the environments that evaluate models. Medical AI feels this most. Domain-expert labeling and judging remain expensive. A model can only be as good as the specialists who shaped its data and graded its answers. The cost of misreading the analogy is concrete. If you think volume is the asset, you collect more data. If expert data and evaluation environments are becoming their own major infrastructure market, the scarce part is the expert judgment inside the data. When you evaluate a data strategy for a medical AI product, ask two questions: - Who with real domain expertise contributed to this? - Who judges whether the model got it right? Data is still the resource. The expertise baked inside it is what makes it worth refining.