And on August 2, the EU AI Act's major provisions came into force, with penalties reaching €35 million or 7% of global annual turnover. That single date reframes every deployment decision made this quarter. Capability stopped being the bottleneck; accountability became it.

I build AI infrastructure for a living — ingestion pipelines, retrieval systems, and evaluation harnesses — and I have shipped side projects in clinical wellness and personal finance, so these are the three industries I watch closely and can judge rather than just report. Each is also at a different stage of the same journey. Healthcare is the most regulated and the slowest to adopt, so the news there is about permission — what a regulator will now allow. Software engineering is the furthest along, already past the question of whether the tools work, which makes it the best preview of what “mature” adoption actually looks like. Financial services sits between them: heavily supervised, but with a clear class of work where automation is safe enough to have already scaled. Read together they show the same shift arriving at three different speeds.

Healthcare

The Regulator Finally Drew a Line

Healthcare has spent three years asking a question nobody could answer: what happens when a language model talks directly to a patient? In late June, the FDA answered it. UpDoc, a Palo Alto clinical AI company, received clearance for what it describes as the first Software as a Medical Device using patient-facing large language models — and by early July, healthcare law firms were publishing analyses of what the clearance opens up.

Why this matters more than another model release: until now, patient-facing AI lived in a grey zone, marketed as "wellness" to stay outside device regulation. A clearance creates a documented pathway. UpDoc's platform deploys agentic AI inside a provider's electronic health record with clinician oversight, initially for chronic disease management, and is live at four major health systems. The company's own framing is notable: designed to support doctors, not replace them.

The business impact: clearance changes who can buy. A hospital compliance officer can approve a cleared device; they cannot approve an unregulated chatbot that gives medical guidance. That single distinction moves clinical AI from innovation-lab budgets into capital procurement — a different order of magnitude in deal size and deployment scope.

The measurable returns, meanwhile, are coming from the least glamorous application in the building: ambient documentation. Houston Methodist's enterprise rollout of Ambience Healthcare's platform reported a 40% reduction in documentation time, roughly 80% clinician utilization across specialties, and a 27% increase in patient face time. Note what that is — not a diagnostic breakthrough, but paperwork removed from expensive people's evenings.

The pattern in healthcare AI right now: the regulated frontier gets the headlines, and the administrative middle gets the ROI.

Software Engineering

From Better Models to Governed Fleets

If any industry has already been transformed, it is this one. Coding assistants are the fastest-growing segment of enterprise software spend, and three products — GitHub Copilot, Claude Code, and Cursor — have each independently crossed a billion dollars in annualized revenue. GitHub and Accenture measured 55% faster task completion across 4,800 developers, with pull-request turnaround dropping from 9.6 days to 2.4.

July's releases continued that climb. Claude Opus 5 became the default in Claude Code on July 24, with a one-million-token context window and 89.1% on Terminal-Bench 2.1. Claude Fable 5, available again from July 1, leads SWE-bench Verified at 95.0%. But here is the thing worth telling a non-technical reader: those numbers are no longer where the business problem lives.

The real July story was organizational. On July 17, Anthropic, Blackstone, and Hellman & Friedman launched Ode — a standalone enterprise AI services firm built on the acquisition of Fractional AI, embedding engineers and models directly inside mid-to-large enterprises. Its stated purpose is the unglamorous work: integrating AI into existing operations, navigating compliance, and handling workflows that off-the-shelf tools were never designed for.

Read that as a market diagnosis. When a frontier lab and two private-equity giants co-found a services company, they are betting that the gap between what models can do and what enterprises can actually deploy is large enough to build a business inside. Databricks made a parallel bet, closing roughly $3 billion at a $188 billion valuation with proceeds aimed at governance across multiple AI systems, data-to-action automation, and infrastructure built for agent workloads.

For decision-makers, the implication is a budget shift. The question moved from "which assistant do we license?" to "who reviews what the agents wrote, where do they run, and what stops one from touching production?" Sandboxing, permission boundaries, audit logs, and model routing are now line items.

Chart — Published coding-agent benchmark scores as of early August 2026. View it at https://siddarthadarisi.com/newsletter/issue-001-they-shipped-the-plumbing/

Financial Services

Agents Arrive Where the Work Is Auditable

Banking adopted AI exactly where a regulated institution would: procedural, high-volume work with a containable cost of error. Financial-crime detection, regulatory-change triage, and transaction monitoring led the way, and the deployment style is consistent — governed environments, logged decisions, a human approving outputs.

Two July developments show the direction. Nasdaq Verafin is expanding what it calls an Agentic AI Workforce, with an Agentic Fraud Analyst and an Agentic AML Analyst reaching general availability this quarter. The AML agent automates alert triage the way an experienced human investigator handles cases, starting with cash-structuring alerts — the pattern where large sums are deliberately broken into smaller deposits to stay under reporting thresholds.

Meanwhile on July 20, wealth-tech provider d1g1t launched an MCP server: a connector built on the open Model Context Protocol standard that links an enterprise wealth-management platform directly to general-purpose assistants including Claude, ChatGPT, and Copilot. This is a small announcement with a large implication — firms are no longer buying a vendor's embedded chatbot. They are exposing their own governed data to whichever model they choose, and swapping models becomes a configuration change rather than a migration.

The operational numbers explain the enthusiasm. Mature fraud deployments report false-positive reductions of 60% or more, and compliance automation delivers 30–50% less manual work on AML and KYC. False positives are worth dwelling on: every one is an analyst hour spent on a legitimate customer who was also inconvenienced. Cutting them improves cost and customer experience simultaneously, which is rare.

Lloyds Banking Group offers the clearest governance model. Having prevented more than £1 billion of fraud in 2025 after investing £100 million in fraud technology since 2023, it deployed multiple agents in real time — and stated plainly that colleagues remain fully accountable for outcomes and can override AI suggestions. That sentence is the entire design philosophy of banking AI in 2026.

Chart — Reported operational impact across the three industries covered in this issue. View it at https://siddarthadarisi.com/newsletter/issue-001-they-shipped-the-plumbing/

At a Glance

The Use Case Worth Watching: Agentic Alert Triage

Of everything above, the commercial application I would watch closest is agentic triage in financial crime, because it is the cleanest example of AI succeeding by being deliberately unambitious.

Consider the economics. A bank's monitoring system generates far more alerts than analysts can investigate, and the overwhelming majority are false. Each one still requires someone to pull transaction history, check the customer profile, look for a benign explanation, and write it up. The judgment at the end is genuinely difficult; almost everything before it is retrieval and assembly.

That split is why this works. The agent does not decide whether a customer is laundering money — it gathers the evidence, drafts the case, and hands a human the decision with the legwork done. The requirement that must never fail (a real case being closed incorrectly) stays with a person, while the work that consumes the hours gets automated. Compare that with the failures we have all read about, where a model was handed the consequential judgment itself.

The future potential is significant, and so is the constraint. Regulators have not written agent-specific rules, which does not mean there are no expectations — the EU AI Act's explainability requirements now apply to financial systems, and institutions still owe supervisors a defensible account of every decision. The winners will be the firms that can produce an audit trail for what an agent did and why, and that treat the human override as architecture rather than a courtesy.

Three Industries, One Pattern

Three industries, one pattern. In healthcare the unlock was a regulatory clearance. In software engineering it was a services company and a governance platform. In financial services it was a connector standard and a human-accountability model. Not one of those is a model improvement.

The lesson for anyone deciding where to spend: model capability is increasingly a commodity you can swap, and the durable advantage sits in the layer around it — clean data access, clear accountability, an audit trail, and a well-drawn line between what the machine decides and what a person does. Capability got cheap. Trustworthy deployment did not.

Sources

1. UpDoc Inc. (2026, June 25). UpDoc debuts first FDA-cleared clinical AI platform built for real-time patient care delivery. PR Newswire.
2. McGuireWoods. (2026, July 6). A pathway for clinical AI developers opens: FDA clears first software as a medical device with patient-facing LLM.
3. Ambience Healthcare. (2026). Houston Methodist enterprise rollout of AI platform. Business Wire.
4. PLANADVISER. (2026, July 20). AI product & service launches: d1g1t launches MCP server for advisers.
5. Nasdaq, Inc. (2026). Nasdaq Verafin announces expansion of its agentic AI workforce.
6. Lloyds Banking Group. (2026). Lloyds Banking Group deploys agentic AI to strengthen real-time fraud protection.
7. Ink & Algorithms. (2026, July). AI Weekly Pulse #4 — Ode launch; Databricks funding round.
8. MorphLLM. (2026, August). Best AI coding agents: scored leaderboard.
9. AngelHack DevLabs. (2026, July). The latest AI trends reshaping enterprise software development in 2026 — EU AI Act timing; GitHub–Accenture productivity study.
10. 360factors. (2026, June 29). Agentic AI updates reshaping compliance in 2026.

AI assistance was used to search and cross-check the developments reported here and to help format this issue. Source verification, industry selection, the analysis, and the conclusions are my own.

The Setup, and the Win

The training run itself was the part that went to plan. I fine-tuned Llama 3.2 3B with QLoRA — 4-bit NF4 quantization, LoRA rank 16 — on an 8 GB RTX 3070 laptop GPU, using 10,752 emotional-support conversations. Validation perplexity fell from 32.6 for the base model to 9.79 for the fine-tune: a drop of roughly two thirds, and comfortably past the success criterion I had written down before touching any data.

By my own definition of success, the project had worked. The model sounded warmer, stayed in role, and predicted held-out supportive dialogue far better than the base model. If perplexity had been the only thing I measured, this post would be a victory lap — and I would have shipped a worse product.

What the Behavioural Suite Caught

Alongside perplexity I ran an 18-prompt behavioural suite split into crisis, control, and boundary prompts — the questions where the right answer is not a warmer answer. The crisis results were the ones that mattered: the fine-tuned model's crisis pass rate fell to 25%, against 62.5% for the base model I had started from. My training run had made the model measurably less safe than doing nothing at all.

The mechanism, once I saw it, was obvious. The empathy data taught the model warmth, and warmth is exactly the wrong register for a crisis message. Where the base model would break role and point to help, the fine-tune had learned to stay soft, reflective, and conversational — because that is what ten thousand supportive conversations rewarded. The regression wasn't a bug in the pipeline. It was the pipeline doing precisely what I asked.

The regression wasn't a bug in the pipeline. It was the pipeline doing precisely what I asked.

The Two-Part Repair

The first repair was the one every ML practitioner reaches for: more training. I built a targeted safety-patch set and ran a second pass, and it worked as far as training can — the crisis pass rate recovered to 75%, beating the base model's 62.5%. That is a genuinely better model, and it is also not an acceptable answer. When the failure mode is a person in crisis getting a soft deflection instead of a crisis line, a number that starts with 7 is not a number to celebrate.

So the second repair moved the requirement out of the model entirely. Haven's server now has a crisis layer that detects crisis messages and guarantees — regex-verified, on every response — that real resources appear: 988, text 741741, 911. The model still generates the reply, but the property I actually care about no longer depends on the model. No future fine-tune, no new dataset, no clever prompt can trade it away, because the training loop cannot touch it.

Optimization Targets Versus Constraints

The general lesson took me longer to phrase than to learn: iteration produces expected behaviour, not guaranteed behaviour. Training pushes a distribution around; it does not sign a contract. That is fine for the requirements you are optimizing — tone, fluency, helpfulness — and disqualifying for the requirements you are promising.

So the discipline I took from Haven is to name, before training, which requirements are optimization targets and which are constraints — and then to put the constraints somewhere no future training run can trade them away. Targets live in the loss function and the eval dashboard. Constraints live in code, at a layer the model cannot reach. If a requirement would be a headline when it fails, it should not be a metric; it should be architecture.

An Aside on Averages

The same week handed me a smaller version of the same lesson from Haven's other model. My DistilRoBERTa emotion classifier, scoring 28 labels per message, looked respectable at a flat 0.30 decision threshold: micro-F1 of 0.596. But macro-F1 — where every class counts equally — was 0.395, below my TF-IDF baseline's 0.411, and several rare classes, including grief and nervousness, sat at an F1 of exactly zero. For a mental-wellness app, grief is not a class you are allowed to miss.

Per-class threshold tuning fixed it honestly: micro-F1 eased to 0.563 while macro-F1 rose to 0.433, beating the baseline on both. I traded a little average performance for the classes that matter. It is the same failure shape as the perplexity story, one level down — averages hide exactly the failures that matter most, and any single headline number is an average of something.

Sources

1. Haven — project repository (GitHub)
2. Haven — portfolio artifact page

AI assistance was used to help format this post. The work, numbers, and conclusions are my own.

A Triage Assistant for the 3am Page

The project is a scoped triage assistant for the AWS services I actually operate, grounded in curated runbook documentation covering Lambda ↔ Redshift failure modes. You paste in an alert description, and it returns three things: the first checks to run, the likely causes ranked, and the criteria for escalating instead of continuing to debug. That is the entire product. It is aimed at a very specific user — an engineer who has just been paged at 3am and needs help sequencing an investigation, not company.

Advise, Never Execute

The defining constraint is deliberate: the assistant advises and never executes. The reasoning is not caution for its own sake. The assistant cannot see live system state — no metrics, no logs, no current configuration — so anything it recommends is built from an alert description and a runbook. Acting on its output would mean acting on stale information, and stale information plus write access is how incidents get worse.

The same honesty is forced into its answers. Every hypothesis it offers comes with a stated confidence level and a falsification condition — the one check that would prove it wrong. An on-call engineer at 3am does not need a confident narrator; they need to know how much weight an idea can bear and how to knock it over quickly.

Finding One: The Weak Part Was Not the Model

The first surprise came from tracing bad answers backwards. When the assistant gave a weak response, the cause was usually weak source material, not a weak model. A vague runbook section produced a vague answer. Escalation criteria that existed only in someone's head produced an assistant that could not tell you when to escalate — because nobody had ever written it down.

Grounding an assistant in institutional knowledge turns out to be an involuntary audit of that knowledge. Every gap the model exposed was a gap a half-asleep human would have hit too; the model just hit it reproducibly, in daylight, where I could fix it. The documentation improved more in the course of building this assistant than in any deliberate documentation push I have been part of.

Finding Two: Test the System, Not the Artifact

The second surprise was sneakier. During testing I found that a platform-level "Initial Message" setting was silently overriding one of the constraints I had written into the prompt. My instruction was correct at the layer I controlled — and defeated at a layer I had not thought to check. Nothing in the prompt was wrong; the system as deployed simply did not do what the artifact I wrote said it should.

That is the through-line this shares with my last post, and the closest thing I have to a rule for building with AI right now: decide what the system must never do, then enforce it somewhere the model — and the layers wrapped around the model — cannot reach. Test the system you shipped, not the artifact you wrote. The prompt is one layer of a stack, and the stack is what your user meets.

Sources

1. Triage Copilot — portfolio artifact page

AI assistance was used to help format this post. The work and conclusions are my own.