Everyone’s using AI. Fewer people are using it well.

The mistake isn’t choosing the wrong AI — it’s using the right AI in the wrong context. Teams try to automate a workflow through a chatbot. Developers paste snippets into a chat interface when they should be working in a terminal. Operations people manually do work that an agent could run on a schedule.

The Claude ecosystem has three distinct layers. Each one is built for a different kind of work. Get the mapping right and you stop burning time and start compounding output.

The advantage isn’t “using AI”. It’s knowing which layer to use — and when.

Layer 1 — Claude AI

Chatbot in your browser or app

Claude AI is where you go when the work is fundamentally thinking in words.

It’s exceptional at taking vague, half-formed input and turning it into structure. A wall of messy notes becomes a one-page brief with a clear recommendation. A clunky draft gets rewritten in your voice and tightened. A complex decision gets mapped out with options, trade-offs, risks, and a recommended next step.

The key distinction: Claude AI gives you clarity. But you still execute elsewhere. It’s a thinking partner, not an executor.

What it’s good for:

• Turning messy notes into a 1-page brief with a clear recommendation
• Rewriting a draft in your voice and tightening it by 30%
• Creating a decision memo: options, trade-offs, risks, next step

If the output is a document, a plan, or a structured thought — this is your layer.

Layer 2 — Claude Code

Agent in your terminal

Claude Code is where things get genuinely powerful for anyone who works with software.

It lives in your terminal. It has access to your actual codebase — not a snippet you’ve pasted into a chat box, but the real thing. It can navigate across files, run commands, make edits, and iterate with you in real time. Think of it as a pair programmer who doesn’t need a coffee break, has no ego about the review process, and can hold the entire repo in context.

The key distinction: this isn’t about writing — it’s about doing. The work lives in a repo, and the agent works inside it.

What it’s good for:

• Creating a new application with real, working functionalities
• Debugging an existing module safely, with context across the whole codebase
• Generating a migration plan, implementing it, and validating with automated checks

If the output is working, tested code — this is your layer.

Layer 3 — Claude Cowork

Desktop agent across files and apps

Claude Cowork handles a different problem entirely: not thinking, not coding, but workflow.

This is the layer for work that is repetitive, multi-step, and honestly beneath your attention. Organising folders. Extracting tables from PDFs into a clean spreadsheet. Renaming and sorting hundreds of files by a consistent taxonomy. Updating a weekly report pack — pulling inputs, cleaning data, exporting outputs — without you touching it.

The key distinction: this isn’t intellectually hard work. It’s friction. Cowork turns that friction into a repeatable automation so you stop doing manual glue work.

What it’s good for:

• Extracting tables from PDFs into a clean spreadsheet template
• Renaming, tagging, and sorting hundreds of files into a consistent taxonomy
• Updating a report pack weekly: pull inputs, clean data, export outputs

If the output is a completed repetitive task — this is your layer.

The Framework

One mental model to carry forward:

Most people default to Layer 1 for everything because it’s the most visible. That’s fine for drafts and decisions. But leaving Layers 2 and 3 untouched means leaving most of the compounding value on the table.

The organisations that pull ahead won’t be the ones who use AI most — they’ll be the ones who deploy it most precisely.

Same stack. Three very different jobs. Know which layer to reach for.

Watch the Video

This post accompanies a short video explainer walking through each layer with examples. If you find this kind of breakdown useful — covering AI strategy, data science, and how emerging technology actually impacts organisations — subscribe to RogueLoop for more.

RogueLoop — where AI meets real-world innovation.

Microsoft has begun quietly reshaping the architecture behind Microsoft 365 Copilot, and the change tells us a lot about where enterprise AI is heading.

Until now, Copilot has largely been powered by OpenAI models, which makes sense given Microsoft’s deep partnership and multi-billion-dollar investment in the company. But Microsoft is now introducing Anthropic’s Claude models into the Copilot ecosystem.

This isn’t just a small technical update. It signals something bigger: enterprise AI platforms are moving toward a multi-model world.

Below is a short video where I explain what’s changing and why it matters.

Watch the Video

What Microsoft Is Changing

Microsoft announced that Anthropic’s Claude models will now be available in two areas of Microsoft 365 Copilot.

1. Researcher: Deep Analysis Across Data Sources

The first integration is in Copilot’s Researcher feature.

Researcher is designed to conduct deep research across multiple information sources, including:

• Emails
• Teams conversations
• Internal documents
• Files stored in Microsoft 365
• Web sources

Previously, this capability ran primarily on OpenAI models. Now, users will also be able to run Researcher using Claude Opus 4.1, Anthropic’s most advanced model.

This capability could support tasks such as:

• Building detailed go-to-market strategies
• Analysing emerging product trends
• Producing comprehensive reports
• Synthesising internal knowledge across documents and conversations

In other words, it’s about turning enterprise data into structured insights.

2. Copilot Studio: Building Custom AI Agents

The second integration appears inside Copilot Studio.

Copilot Studio allows organisations to build custom AI agents that automate tasks and workflows across Microsoft 365.

With Claude models now available in the platform, organisations will have more flexibility when designing those agents. Different models can be used depending on the task, whether that’s summarisation, reasoning, planning, or structured analysis.

This is important because no single AI model is best at everything.

The Bigger Shift: From Single Model to AI Platform

The most interesting part of this announcement isn’t the specific model being added.

It’s the architecture behind the decision.

Even after investing more than $10 billion in OpenAI, Microsoft is clearly designing Copilot to operate as a multi-model orchestration platform.

Instead of relying on one AI system, enterprise software will increasingly:

• Route tasks to different models
• Optimise for cost, speed, or reasoning capability
• Combine models in complex workflows

In other words, the future of enterprise AI may look less like a single assistant and more like an operating system coordinating multiple AI systems behind the scenes.

For organisations using AI tools, this shift could bring several benefits:

Better performance

Different models excel at different tasks. A multi-model platform allows organisations to pick the right tool for the job.

Reduced vendor dependency

Companies won’t need to rely on a single AI provider.

More robust AI systems

Combining models can improve reliability, reasoning quality, and resilience.

Faster innovation

New models can be integrated without redesigning the entire platform.

This is likely to become a defining pattern in enterprise AI architecture over the next few years.

The story here isn’t really about Claude versus OpenAI.

It’s about the evolution of AI platforms.

Microsoft appears to be positioning Copilot as a flexible orchestration layer capable of running multiple AI models behind the scenes. And that design pattern may soon become the norm across enterprise software.

About RogueLoop

RogueLoop explores the intersection of AI, data science, emerging technology, and real-world innovation.

If you’re interested in practical insights about how AI is shaping organisations, keep an eye on the channel for:

• AI strategy and architecture
• Data science and analytics
• Automation and intelligent systems
• Emerging technology trends

RogueLoop — where AI meets real-world innovation.

Before Mendeleev published his periodic table, chemists had circa 60 elements and a pile of empirical rules but no organising principle. His table didn’t just sort what was known, it predicted what wasn’t, with gaps that implied undiscovered elements later found exactly where he said they’d be.

That’s the spirit behind the Deep Variational Multivariate Information Bottleneck (DVMIB) framework, just published in JMLR. It’s a periodic table for variational dimensionality reduction — a field that has accumulated hundreds of loss functions with no shared mathematical language.

The Problem

If you’ve worked in multimodal ML, you know the drill: new problem, need to compress multiple modalities into a useful representation, spend weeks comparing β-VAEs, CLIP, DVCCA variants, and contrastive methods largely by trial and error. The question the authors asked is deceptively simple: is there a single mathematical language that describes all of them? Yes. And it comes from physics.

The Core Idea

DVMIB is built on the Multivariate Information Bottleneck. Every dimensionality reduction method, the authors argue, can be understood as a trade-off between two Bayesian networks:

• An encoder graph — specifying what to compress
• A decoder graph — specifying what to reconstruct or predict

The loss takes one minimal form:

Encoder multi-information is minimised (compression); decoder multi-information is maximised (reconstruction/prediction). β is the control knob. The authors then derive explicit variational bounds for every information term type that appears in these graphs, creating a library of building blocks: write down your encoder graph, write down your decoder graph, plug in the bounds, get a trainable loss. No heuristics, no starting from scratch.

What Falls Out

The following all emerge as special cases, distinguished only by graph structure:

This isn’t just taxonomy. It surfaces a genuine gap: the DVCCA family was missing a β trade-off parameter all along. Adding it back (β-DVCCA) consistently outperforms the original. It also gives CLIP its first information-theoretic interpretation — and raises the question of whether removing the correction term might improve it. That’s an open empirical question worth pursuing.

The New Method: DVSIB

The framework’s flagship contribution is a method it was used to design: the Deep Variational Symmetric Information Bottleneck. The loss is:

Two encoder terms compress. Three decoder terms enforce mutual informativeness and reconstruction. The MI between latent spaces is estimated by a neural critic (MINE/SMILE/InfoNCE — SMILE wins on stability in practice).

Results on Noisy MNIST: 97.8% linear SVM accuracy versus 96.3% for β-VAE. More interesting than the peak is the efficiency: DVSIB accuracy scales as n^0.345 with sample size, versus n^0.196 for β-VAE — meaningfully faster convergence with less data. The trend holds on Noisy CIFAR-100 with CNNs, and on ResNet-18 architectures comparable to Barlow Twins.

The reason it works: methods whose graph structure matches the actual dependency structure of the data produce better representations at lower dimensionality. DVSIB keeps X and Y in separate latent spaces, mirroring their real relationship. Forcing correlated-but-distinct modalities through a shared bottleneck discards signal.

The Physics Mindset

ML, by and large, is an empirical field: train, measure, iterate. Theory follows practice at a lag. The authors come from physics, where the instinct runs the other way, find the minimal principles from which everything else follows.

DVMIB doesn’t say “here are methods that work.” It says “here is the space of methods of this type, here is how they relate, and here are the dimensions along which you can move.” The practical payoff: you spend less time trying things because theory narrows the search. You derive a loss for a new problem the way you’d derive an equation — write down the variables, write down their relationships, apply known operations.

For Practitioners

Before you choose a loss function, ask two questions: what should my encoder graph look like, and what should my decoder graph look like? Answer both, and the variational bounds determine the rest. This is more disciplined than “try β-VAE, try CLIP, see what sticks” — and it gives you a principled basis for your choices, which matters increasingly as AI systems enter domains where interpretability is non-negotiable.

The code is available, the paper is open access. If you work with multi-view data, multi-omics, neuroimaging, sensor fusion, audio-visual, this framework is worth your time.

Abdelaleem, Nemenman & Martini, JMLR 26 (2025) 1–49. Open access at jmlr.org.

After months of writing, rewriting, refactoring code, updating examples, and expanding chapters, it’s now in the hands of the production team. This is where the invisible craft of publishing begins.

This edition is not a cosmetic refresh; it reflects how our field has evolved.

Writing a second edition is an interesting exercise: You revisit your past self, keep what still holds, and upgrade what no longer does. Data science, Machine Learning and indeed AI have changed, tooling has shifted, expectations have risen. The book needed to reflect that.

Now comes the quiet phase, production schedules, proofs, fine-tuning figures. before it makes its way into your hands.

Grateful to everyone who has supported the journey so far: readers, reviewers, colleagues, and colleagues who keep asking the right questions

When I first wrote Advanced Data Science and Analytics with Python, natural language processing (NLP) occupied a niche corner of the data science landscape. Back then, much of the focus in Python revolved around parsing and vectorising text: extracting tokens, counting frequencies, maybe applying a topic model or two. Fast forward a few years, and NLP has become one of the engines driving modern AI, powering everything from search and recommendation to summarisation and chat interfaces.

That shift is at the heart of Chapter 2 in the second edition, where “Speaking Naturally” has been thoroughly reimagined for today’s ecosystem. Instead of stopping at token counts and bag-of-words, this chapter bridges the gap between traditional text processing and the language-rich representations that underlie contemporary AI systems.

From Soup to Semantics

We start where most real text projects begin, with acquisition and cleaning. Python’s Beautiful Soup still plays a starring role for scraping structured text off the web, but the focus now goes beyond parsing tags to extracting meaningfulcontent. Regular expressions, Unicode normalisation and tokenisation are introduced not as academic subjects but as practical tools you’ll reach for every time you ingest text.

Finding Structure in Language

Once you have clean text, the chapter furthers your intuition with topic modelling, an unsupervised way of surfacing latent themes across documents. These techniques remain valuable for exploration, summarisation and even automated labelling in the absence of annotated training data.

Encoding Meaning: Beyond Frequency Counts

The real leap comes with representation learning. Rather than relying on sparse counts, modern NLP encodes text as dense vectors that capture contextual meaning. Word embeddings — and their contextual successors — turn raw text into numbers that machine learning models can reason about. This edition makes that leap accessible, showing how to generate, visualise and use these representations in Python.

Semantic Search with Vector Engines

Building on embeddings, we explore vector similarity search — the backbone of semantic retrieval. Using tools like FAISS, you’ll learn how to retrieve text not based on matching keywords but on meaning, opening the door to advanced search, clustering and recommendation applications.

The NLP landscape has moved faster than almost any other area of AI. Transformers, contextual language models and embedding systems have shifted what’s possible — and what’s practical — for practitioners. This chapter is carefully redesigned to reflect that evolution, giving you the grounding you need to work with text data that isn’t just cleaned and counted, but understood.

More soon. Stay tuned.

One of the chapters I’ve been spending time with recently dives head-first into forecasting. Not the hand-wavy, crystal-ball-gazing sort (sadly no actual precogs were harmed in the process), but practical, defensible forecasting that you can deploy without fear of your future self cursing your name.

Enter the Prophet

Yes, that Prophet.

Facebook’s (now Meta’s) Prophet framework gets its own dedicated treatment. Not because it’s fashionable, but because it occupies a genuinely interesting space: expressive enough to handle real-world seasonality, trends, and holiday effects, yet accessible enough that you don’t need to disappear into a cave with nothing but state-space equations and a beard.

The chapter walks through:

• How Prophet decomposes time series into trend, seasonality, and effects you can actually explain to stakeholders
• When it works beautifully; and when it really, really doesn’t
• Why it’s often a strong baseline, even if you later graduate to more exotic architectures

Think of Prophet as the Millennium Falcon of forecasting: not the newest ship in the galaxy, occasionally held together with duct tape, but astonishingly reliable in the right hands.

The Bit Everyone Skips (and Shouldn’t)

Forecasting models are easy to build. Evaluating them properly is where things usually fall apart. So this chapter leans hard into time series cross-validation and forecast evaluation. No random shuffling. No accidental peeking into the future. No Schrödinger’s test set.

We cover:

• Rolling and expanding windows (and why they matter)
• Forecast horizons and why “one-step ahead” tells only half the story
• Metrics that actually align with decision-making, not just leaderboard vanity

If you’ve ever had a model that looked flawless in development and then collapsed in production like a soufflé near a subwoofer, this section is for you.

In applied data science, forecasting sits at an awkward crossroads. It’s everywhere — demand planning, operations, finance, healthcare, energy — and yet it’s often treated as a dark art or an afterthought.

This chapter is about demystifying that space. About treating time seriously (literally), respecting causality, and building forecasts you can defend in a meeting without resorting to interpretive dance or “the model felt confident”.

This is just one chapter. Over the coming weeks, I’ll be writing about other additions and revisions in the second edition — from modern modelling techniques to deployment considerations, and a few opinionated takes on where data science education often goes wrong.

If this chapter is about seeing the future, the rest of the book is about making sure you survive it — preferably with clean code, reproducible results, and fewer existential crises.

More soon.

This new edition follows closely on the heels of the updated companion volume, Data Science and Analytics with Python (2nd ed.), and together they form a slightly opinionated but well-armed duo. Think Luke and Leia, but with pandas and NumPy instead of lightsabers. (Although, to be fair, NumPy broadcasting can feel like the Force when it works.)

Since the first edition, a lot has happened. Transformers are no longer robots in disguise; they’re the backbone of modern AI. Generative AI has gone from research curiosity to dinner-table conversation. Reinforcement learning has escaped the lab and is now quietly optimising things that actually make money. In short: the map changed, so the field guide had to as well.

This edition responds directly to that shift. The deep learning chapter has been split into two — not out of indulgence, but necessity — making room for reinforcement learning, GANs, transformers, and large language models, all without sacrificing the practical, hands-on ethos that the book was built on. No ivory towers. No mystical incantations. Just working code, clear ideas, and a healthy suspicion of anything claiming to be “fully autonomous”.

The foundations remain reassuringly solid. Python is still our language of choice, and stalwarts like pandas, NumPy, scikit-learn, SciPy, and friends continue to do the heavy lifting. That said, the ecosystem has matured, and the book has matured with it.

All code examples have been updated for modern Python (3.12+), and the libraries reflect current, real-world versions — the ones you’re actually likely to encounter outside a museum of deprecated APIs. The result is a book that doesn’t just explain ideas, but does so in a way that fits naturally into contemporary workflows.

If you’ve read the first edition, the tone will feel familiar. The book remains conversational, practical, and lightly dusted with sci-fi, pop culture, and the occasional Monty Python reference. Margin notes still lurk at the edges, code still lives in boxes, and the Jackalope (curious, adaptable, and faintly mythical) still serves as our official mascot.

This is not a cookbook. It’s not a manual. It’s a field guide for practitioners who are already moving and want to move further. The chapters remain modular and self-contained, ranging from time series and NLP to network analysis, deep learning, generative AI, and the ever-thorny question of deployment: how models escape the notebook and survive contact with users.

What’s Coming Next

In the coming weeks, I’ll be publishing a series of follow-up posts, each diving into what’s new (and what’s evolved) in individual chapters: from modern NLP and vector search, through graph embeddings and reinforcement learning, to deploying models as real data products, including on-device AI using Apple’s Foundation Models.

Think of it as a guided tour of the upgrade: what changed, why it matters, and how you can put it to work without summoning ancient spirits or breaking production.

Until then: may your models generalise well, your deployments behave themselves, and your curiosity remain stubbornly unquenchable.

That moment hits differently when you’ve spent years thinking about data, machine learning pipelines and intellectual property. It’s one thing to talk theoretically about the dangers of unlicensed scraping or dataset opacity. It’s quite another to find your own name on a list you never asked to be on.

The settlement: a corrective instrument — but by no means a full remedy

In September 2025, Anthropic agreed to pay USD 1.5 billion to settle a class-action lawsuit brought by authors who alleged the company used pirated copies of their books for training.  

Key points under the deal:

• Anthropic must destroy the pirated-books libraries and any derivative copies used internally.  
• The settlement covers past use only — it does not grant a blanket licence for future ingestion of authors’ works. Any new usage remains outside the settlement.  
• The funds are distributed on a per-work, equal basis, subject to deductions (legal fees, administration). If there are multiple rightsholders (co-authors, publishers), the payment is split accordingly.  

For me, and for many others, this represents a concrete — if modest — recognition. It is better than nothing. But the payout surely doesn’t reflect the true creative value of a book: its intellectual labour, the ecosystem of readers, the potential future royalties or derivative work.

What this episode reveals about the misuse, mis-attribution and dilution of creative work

• Creative labour becomes “data points”

Large volumes of written works — novels, non-fiction, technical books — were reportedly downloaded, stripped of metadata, and absorbed into generic “training corpora.” This transforms books from expressive creations into mere text blobs. The original authors vanish from the metadata, alongside their ownership, context and consent. In short: creative labour becomes raw fuel.  

• Consent and control evaporate with scale

The speed and scale at which AI developers can scrape data make traditional author consent or licensing agreements impractical unless there is structural enforcement or legal incentive. This threatens to normalise the idea that creative works are “free for mining,” undermining authors’ control over how — or whether — their works are used. It is a systemic shift, not just a few bad actors.  

• Market and value dilution — for authors and readers

Once an AI model is trained on thousands of books and can synthesise or summarise their ideas, the perceived need (and therefore market) for the original works may decrease. This risk is exacerbated for technical or niche works (like mine) whose value depends on depth, structure, and the author’s voice. The economics get skewed.  

• Settlements are remediation — not restoration

The settlement may compensate authors financially for past unauthorised use. But it does nothing to restore authorship, attribution, control, or moral rights. Nor does it guarantee future respect for those rights. In the long run, the architecture of AI training needs rethinking.

For authors, AI practitioners and the community — what we must do now

Given my dual identity as both technologist and author, I see this not simply as a “gotcha” moment, but as a tipping point. Here’s what I think should happen next — and why all stakeholders should pay attention.

• Authors and rights-holders should assert proactive control. In jurisdictions like the UK, regulatory reforms are under discussion to give right-holders meaningful control over whether their works can be used for AI training.  Collective licensing frameworks, metadata protection, opt-out registries — these will matter.
• AI developers must embrace responsible data sourcing. Building models on legally licensed, consented, or public-domain corpora must become the norm. Scraping shadow libraries or ambiguity-laden datasets must no longer be an accepted shortcut.
• Transparency and traceability should be standard. Just as industrial data engineering tracks provenance, versioning and lineage, AI training pipelines should log data origin, rights status, and consent metadata. This isn’t just ethical — it’s essential for long-term sustainability of both the AI and creative ecosystems.
• Policymakers and the public need to demand balance. The goal should not be to stifle innovation — AI can bring enormous value. But it must not do so at the expense of creators. Legal frameworks should evolve to support licensing, fair remuneration and respect for authorship, while allowing AI research to proceed under agreed terms.

My personal stance — and why I write this

Having worked in data/ML for over two decades, and having published technical books myself, this situation lands uncomfortably close to both sides of the divide. My professional instinct understands the allure of large-scale textual datasets. My moral and creative instinct recoils at the idea that human labour — years of writing, revising, editing — can be bypassed, ingested, and re-used without notice, consent or attribution.

I don’t believe the settlement is the end of the story. Instead it feels like a first step — a belated recognition, but also a warning shot. If we don’t act now — to demand consent, build transparent training pipelines, and ensure fair remuneration — creative work risks being commoditised into anonymous data bricks.

Because once we accept that, we are no longer just building AI. We’re building on the cultural, intellectual, and emotional labour of real people — and we should treat it with the respect it deserves.

The play sits quietly at the intersection of love, uncertainty and the strange clarity that arrives when life throws a curveball. Two people, a long marriage and a hospital room—nothing flashy, but everything truthful. For me as a director, the real task was creating a space where silence carried weight, glances spoke paragraphs and the characters could sit vulnerably in their own questions: What do we hold on to? What do we let go of? And who do we become when the familiar starts shifting under our feet?

Working with Nora and Alfredo was a genuine gift. They brought emotional intelligence, humour and an honesty that made rehearsals feel less like blocking scenes and more like unearthing something already living beneath the page. There were moments when we rehearsed a single breath, a small hand gesture, or the way one character sits just an inch closer—tiny choices that ended up feeling seismic.

Showcase nights at the OSO always have that delightful energy of discovery: new writing finding its voice, actors taking creative risks and audiences leaning in a little further than usual. To be part of that environment is equal parts invigorating and humbling. You’re reminded how fragile and powerful storytelling can be when it’s kept intimate and personal.

I’m incredibly proud of what the team created—quiet strength, gentle humour and a sharp emotional truthfulness that resonated with audiences across the weekend.

And, selfishly, it reminded me why I love directing: the collaborative alchemy that turns a script into something breathing.

Here’s to more stories, more experimentation and more moments that make us ask ourselves, “What’s going to happen to us?”

Whatever it is… hopefully something honest, brave and human.