The most resilient financial firms are disciplined about personnel. They engineer fail-safes for their trading stacks and diversify their counterparties to ensure no single technical glitch can halt operations. We understand that in almost every other context, a lack of backup is an unacceptable risk.

Yet, a glaring vulnerability persists in research departments: the Expert Bottleneck. This is where a firm’s most critical strategic intelligence is trapped solely within the minds of a few indispensable people. Keeping institutional memory siloed within an individual is an unsustainable burden that risks exhausting the expert, leaves their hard-won insights at risk of being lost and creates a bottleneck that leaves the entire team vulnerable to an information blackout.

The “Hero Culture” of research is often celebrated as a mark of elite talent, but it’s a systemic risk. Relying on a few star analysts who hold the keys to the kingdom creates massive hidden costs. When a team depends on the brilliance and intuition of a few, the pace of the entire firm is limited by those individuals’ bandwidth. This creates a linear relationship between headcount and output that is difficult to scale; if your lead researcher is occupied, the rest of the firm’s strategic pipeline sits idle.

Beyond simple availability, there is the issue of “shadow data.” When an analyst performs a complex synthesis of market trends, the final memo is often the only surviving record of that work. The hundreds of intermediary steps, the rejected hypotheses, and the nuanced connections between entities are often lost the moment the analyst closes their laptop. This loss of provenance means that a firm is constantly paying to reinvent the wheel, as subsequent team members lack the “logic trail” required to build upon previous work.

As markets become more volatile and regulatory landscapes shift, the manual retrieval of data has become a tax that even the best analysts can no longer afford to pay. Professionals are currently drowning in fragmented workflows where tools often add more complexity than clarity. Every hour spent hunting for lost context or reformatting a document is an hour stolen from high-level decision-making. We see this daily in the way research teams interact with their data; they are forced to act as manual “data janitors” before they can act as strategic thinkers.

This tax is compounded by the sheer volume of unstructured data entering the firm. Current research solutions often increase the noise rather than the signal. An analyst might find a relevant insight in a 300-page filing, but if that insight cannot be seamlessly linked to the firm’s proprietary data or previous investment theses, it remains a stranded asset. This fragmentation is a direct contributor to increased error rates and missed opportunities, not just a nuisance.

To de-risk the expert, firms must move from a model of individual starpower to one of system-based intelligence. This requires a workspace that preserves the logic and history of every insight. By decoupling intelligence from headcount, the firm’s collective knowledge remains a secure, navigable asset.

In an era where markets move faster than any one person can read, the firms that thrive will be those that have integrated team expertise into their processes. Felix Research is developing FelixOne, an intelligent harness that unifies frontier AI models with secure infrastructure to ensure the brain of the operation remains an institutional asset.

By investing in a system that captures and scales knowledge, you ensure that even when your people move on, your momentum does not. It’s time to stop relying on the luck of the Hero and start building the certainty of the system.

Subscribe now

In the current AI arms race, there is a persistent misunderstanding that the model is the entire product. Investors and users alike often ask why bespoke solutions are necessary when frontier models like Claude and similar exist as “standalone powerhouses”.

However, treating an LLM as a complete solution is like admiring a high-performance engine while forgetting it requires a surrounding structure to actually move.

I sat down with Felix Research’s Founding Engineer, Dimitri, to address the myth of the “naked” LLM. We discussed why the future of specialised research doesn’t lie in the brilliance of a single model, but in the “glue”; the programmatic tools, the guardrails, the architecture and crucially, the domain expertise.

Sav: So, we already discussed context windows for the recent piece. How it’s not just an issue of bigger and bigger because of the costs... they increase quadratically.

Dimitri: Yeah. They skyrocket.

Sav: Exactly. But what I’m curious about is your answer, as the engineer, when investors are like, “Why can’t I just use Claude? Why do I need you guys?” Is it frustrating? Or do they have a point? Articulate the reasoning!

Dimitri: Okay. Well. It’s because everyone is looking at the software and attributing all of it to “the LLM” because they are “AI companies.” But what they’re forgetting is that these companies hire engineers to build around the LLM. That’s the final product you interact with. Not just a lone LLM.

Dimitri’s frustration is backed by the latest industry research; the industry is moving away from evaluating LLMs as standalone “brains” and toward evaluating them as Composite Systems. A recent arXiv paper, entitled Precision Proactivity: Measuring Cognitive Load in Real-World AI-Assisted Work, asserts that “Agents are systems, not models,” and that single-turn accuracy (the “naked” output) is no longer a viable metric for real-world enterprise utility.

D: What LLM’s are really good at is: you give it text, it understands it [to varying degrees, depending on what “understand” means to you], and it gives you output. Output specifically (predominantly) in text format. Now, that doesn’t sound very powerful, but it is in the context of a programmatic system that can do something with that output.

Ours [Felix Intelligence] is a bit different because it’s using a visual LLM. It’s taking in an image and producing text. But the system we built - the parts that show the tables, the RAG (Retrieval Augmented Generation), the bit where you ask a question and it finds the relevant source - that’s a tool built using normal programming languages. It’s engineering glue.

S: So there’s an architectural misunderstanding going on. People think the entire product is the “naked” LLM. They don’t realise that Claude and similar are (often) a blend of engineering and models?

D: Yeah so if you go to GPT and press “Deep Research/ Web Search” they are providing a programmatic tool to the LLM to use if it wants to - a tool where the LLM inputs text into the tool and the tool returns text. To be clear for a second, this isn’t prompt engineering or fine-tuning. This is giving it access to tools, regardless of prompt engineering.

S: What do you actually mean by “tools”?

D: Okay, so, you have the LLM in a box. You have the prompt going in, and the output being spat out. But the output doesn’t have to be just raw text. It can be a specific structured format.

Then you have “LLM tools.” These are mechanisms the LLM can use, for example to query our database. These tools are programmatic. It’s basically like giving the LLM an API so it can pull information from the external world. Importantly, we have to build each of those tools programmatically before the LLM can touch them.

S: So the efficiency and power that the industry is speaking of at the moment doesn’t come from the lone LLM.

D: It comes from a system. Multiple LLMs plus programmatic engineering to put it all together and tell it what to do. That’s what people forget. Take Claude Code; the reason it’s so powerful is that Anthropic built engineering tools around the LLM, to enable it.

The rise of “Claude Code” and OpenAI’s “Deep Research” proves that the frontier labs are no longer just selling intelligence; they are selling orchestration. However, as the ArXiv paper notes, these general tools often fail in production because they lack “operational constraints” and “domain-specific safety” that specialised systems like Felix provide.

D: That’s the problem with investors [with love! We love you]. They go, “Why should I invest in this when Anthropic is going to replace you?” Well, because they’re not. Because if they want to go into a specific domain and create purpose-built tools at our level of granularity, they would need a team like ours.

S: If you were on an investor call and you could speak freely, what would you actually say in response to that line of questioning?

D: I mean [he laughs to himself], I’ve done this many times. I tell them: an LLM is a tool, and what you’re investing in is the system around it that makes it powerful and specialised. There’s a reason the frontiers are still hiring engineers like crazy and paying them however many hundreds of thousands to millions a year. It’s because the LLM is useful, but the real power comes from the enabling system.

It’s like... using power tools-

S: -A jackhammer is powerful and effective but you can’t just hand it to anyone and expect perfect outcomes with no mistakes or destruction.

D: Exactly.

S: So when someone says, “Why can’t I just use Claude?”, they’re ignoring that you still have to build all these domain-specific tools.

D: Yeah. Look at what Anthropic did with Claude code. They provided a tool for the LLM to write raw Bash. Bash being a system level Language.

S: Bash is the programming language that... what? Controls the computer?

D: Yeah, well at least Mac and Linux. Anthropic couldn’t - and wouldn’t - write a specific tool for every single thing. So instead they said, “Here’s Bash. Bash can do everything. If we give the LLM the ability to use Bash, we don’t need to write a tool for every little task.”

S: [Likely looking perturbed] Um…subject to…permissions…?

D: Yeah. Because of the potential for danger, the LLM will ask you for permission every single time it wants to use Bash - rather than it being like an on switch that stays on. Like if you tell it to do something it shouldn’t, it can technically send an email to your boss or the government.

Lepine, Kim, Mishkin and Beane highlight that “reliability is more valuable than brilliance.” In financial research, an agent that can write Bash is “brilliant,” but an agent that can reliably navigate a proprietary financial database without violating PII (Personally Identifiable Information) boundaries is “valuable.” Felix’s value lies in this bridge between raw power and operational safety.

D: The important thing to get across is that we’re not reinventing the wheel. We’re creating value addition. We’re building a powerful system around various LLM’s, as well as blending models and proprietary RAG guardrails.

S: They think it’s a brain; it’s actually an engine. And we’re building the car.

D: Yeah. You can’t generalise expertise. You have to build the specific tools for the domain.

Subscribe now

References: https://arxiv.org/pdf/2505.10742

One Useful Thing

Claude Dispatch and the Power of Interfaces

AIs are already far more capable than most people realize. A large part of this so-called capability overhang comes not from the limits of AI (though, of course, they still have many limits), but from how people interact with it. The vast majority of people access AI through chatbots, and usually the free versions with less capable models. A chatbot is …

Read more

a month ago · 541 likes · 26 comments · Ethan Mollick

For the past year, the AI landscape has been locked in a singular arms race: the size of the context window. We’ve watched models expand from handling a few pages of text to processing entire novellas.

The logic seemed intuitive: the more data you can cram into a model’s short-term memory, the better the output. This expanded window was touted as the ultimate tool for synthesis, allowing researchers to feed in a 200-page regulatory filing and expect instant clarity.

At Felix Research, where we prefer the augmented over the strictly artificial, this initially felt like a breakthrough. However, using massive context windows in high-stakes environments, such as financial analysis, has exposed a crucial flaw.

The future isn’t about the size of the window; it’s about the precision of the architecture.

The primary issue with massive context windows is now a documented failure: LLMs tend to forget information presented in the middle of a large prompt.

Researchers call this the “lost-in-the-middle” phenomenon. A model might recall the first few paragraphs and the final few sentences, but the hundreds of pages sandwiched in between often dissolve into digital noise, taking nuance with them.

If you are an analyst using an AI to find a contradiction between a CEO’s statement on page 3 and a risk factor buried on page 112, a large context window will often fail you. The model provides a superficial summary (the flavour of the text) rather than the surgical substance required for a true edge. This forces humans to spend hours manually validating the AI’s work, which entirely defeats the point of automation.

Beyond the “cognitive” failure, there is a physical cost to the CramEverythingIn approach: computation.

The relationship between input length and the power required to process it isn’t linear; it’s quadratic. Doubling the context window can quadruple the inference time and the costs. Using a 128k token window to answer a simple question is not just overkill; it is economically and environmentally unsustainable. To optimise for the future, we have to stop throwing more data at the problem and start throwing more logic at it.

The industry pivot is already shifting away from linear context toward structured context.

Standard Retrieval-Augmented Generation (RAG) was the first step. Instead of sending a 500-page book to the model, a system identifies the ten most relevant paragraphs and presents only those to the LLM. The AI is no longer a library; it is an analyst.

But even standard RAG has its limits. If you ask, “What is our exposure to tariff fluctuations?” a basic system might pull snippets about trade and currency, but it often fails to connect the thematic dots. The model receives the ingredients, but it still doesn’t have the recipe.

To solve this, the frontier of AI isn’t focused on longer inputs, but on smarter, pre-computed (synthesised) context.

Instead of retrieval being a simple keyword search, the next generation of data architectures acts like a cognitive sous-chef. Before a user ever asks a question, the system continuously processes incoming data - organising relationships, indexing nuance, and building a hierarchical knowledge graph.

When a query is made, the system doesn’t just grab chunks of text; it retrieves a pre-synthesised, multi-modal context. This drastically reduces the load on the LLM, cuts inference time, and eliminates the lost-in-the-middle effect.

The defining breakthrough of the next year won’t be measured in token length. It will be about how useful the context inside that window has become.

Don't let your insights get lost in the middle of context bloat. Visit our site today and try Amuse-Bouche to see how our architecture delivers the surgical substance your high-stakes analysis demands.

Subscribe now

“Check out my quant” is something nobody has ever said about me, and for good reason.

I am not a financial analyst, nor am I a financier by training; I am firmly in ops management and qualitative research - much more accustomed to researching by interpreting and cross-referencing texts, tracing arguments and identifying conceptual (meta)structures than by interrogating balance sheets or corporate filings. When FRx’s CEO, Ben, suggested that I would make a suitable guinea pig for purposes that were still yet to be explained, I was game.

The brief I received was deceptively simple. He provided me a name, which we will change to Markus Poole, and said: “I’m your manager at a firm. You have three hours to come back with something I haven’t already found.”

No template, no predefined output and no checklist of questions. The instruction was open ended and intentionally so. Should be straightforward enough. Right?

The manual process

I began where I figured one is supposed to begin: with a search on Companies House.

A trawl through filings, directorships, dates and changes in shareholdings. A few entities that appeared dormant. One that might be active. How can I even be sure that this person exists? “He” could be some kind of shell holdings entity… I wondered.

LinkedIn next.

Employment history, board positions, mutual connections, universities and events. Markus’ professional trajectory appeared coherent enough - not very information rich, however.

On to Google.

News mentions, archived interviews, conference panels. A local newspaper article from a decade ago. A blog post here, a podcast appearance there. Each source opened another tab. Each tab introduced another thread and within forty minutes I found myself with over thirty tabs open.

I was taking “notes” (read: scrappy little fragments, copy-and-pasted excerpts and half-baked hypotheses) in a text editor. Externalising is a favourite coping mechanism of mine and I was sure that when I looked back at the notes I would remember what they signified. Or referred to. Or labelled?

Is there a pattern in the types of companies he joins?
Are there overlapping directors across these entities?
What do the accounts suggest about performance?

The process felt unstructured, lossy and honestly a bit anxiety inducing. I was conscious that I was losing context with every new tab. A date copied into my notes lost its meaning while a quote from an article was detached from its publication source and author. The difficulty was the absence of structure, rather than the absence of information. Provenance was like sand slipping between clenched fists. The more information I gathered, the less confident I felt about my grip on it.

This is an information architecture problem.

The hidden friction

Professionals in financial research are deeply habituated to this workflow. They toggle between tools. They copy and paste. They reconstruct context manually. They hold mental maps of relationships between people and entities. They are highly skilled at it. But the process itself is fragile.

Small errors creep in easily. A misattributed quote. A company with a similar name but a different registration number. I found myself constantly backtracking and triple-checking.

Where did that claim originate?
Was that figure from the 2021 accounts or 2022?
Was that directorship current or resigned?

Each question required reopening a tab, rescanning a page, and reorienting myself.

Three hours, in this context, is not long. It is barely sufficient to construct a coherent map of a moderately active professional life. I began to understand how much of the analyst’s role involves simply maintaining orientation across a sea of fragmented data.

Judgement requires synthesis. Synthesis requires clarity. Clarity requires structure and data quality. Without structure, effort dissipates into some kind of corporate ether.

Introducing Amuse-Bouche into the workflow

At the halfway mark, Ben suggested that I run the same materials through Amuse Bouche.

And while AB’s UI is elegant, it isn’t theatrical. It’s purpose built and restrained, but what changed dramatically was the feeling of cognitive load.

Documents were not treated as flat text, corporate filings retained their internal structure. Names, dates and roles were extracted in relation to one another. Entities were recognised as entities rather than as strings of characters.

Instead of maintaining my own fragile web of notes, I could explore a structured representation of the information.

• Markus Poole was linked to Company A as a director from 2018 to 2021.

• Company A shared a co-director with Company B.

• Company B had filed late accounts twice.

• A news article referencing Company B was tied back to the specific entity rather than floating as an isolated citation.

Crucially, finally, each extracted element retained provenance. I could trace a claim back to its source document instantly and the genuine anxiety of context loss subsided.

AB did not replace judgement. It did not generate an opinion for me. It altered the substrate on which judgement could operate and I was no longer expending energy on bookkeeping.

The bottleneck in financial analysis is rarely access to information. It is the management of it.

Amuse-Bouche is a small demonstration of a larger thesis.

If the early stages of research are dominated by manual extraction, context reconstruction and error minimisation, then a significant portion of analytical capacity is diverted away from higher order thinking. Over time, this shapes the profession itself. Analysts become adept navigators of fragmented systems rather than beneficiaries of coherent ones.

For someone like me, entering from a qualitative background, the contrast was stark. The manual workflow felt like playing darts in a pitch-black room. The structured workflow turned the research and discovery process into something intentional and fruitful.

Financial research demands rigour, scepticism and traceability. None of these qualities are enhanced by forcing professionals to act as human glue between incompatible tools.

Amuse Bouche does not claim to solve every dimension of this problem. It does demonstrate that document interaction can feel different.

Subscribe now

We are pleased to announce the launch of Amuse-Bouche, our first tech demo. This release marks a significant milestone for us, and it is already garnering a great deal of attention. This early interest is a testament to the dedication of the team, particularly the hard work put in by Dimitri to get the project ready for the public.

Pitching in Monaco

While the digital launch was taking place, the team was also active on the ground. We have just returned from a trip to Monaco, where we focused our efforts on pitching and fundraising. It was a fantastic experience that provided valuable opportunities to connect with partners. As an added bonus, the trip offered a brief but very welcome reprieve from the typical British weather.

Looking Ahead

We are eager to share more updates with you in the coming weeks as our work progresses. In the meantime, we invite you to try Amuse-Bouche for yourself. We are hungry for feedback and would value your thoughts on the experience.

You can find the demo here: Amuse-Bouche

(Pictured: Amuse-Bouche knowledge graph of IBM 2024 Annual Report)

We are very excited to launch Amuse-Bouche.

It’s our first public tech demo; a small plate. A taste of what we’ve been building at Felix Research.

Whilst it represents only a fraction of what’s to come, it stands on its own. It works. It’s useful. It’s fast. And we think you’ll enjoy exploring it, here.

Why we built this

Ben founded Felix Research less than a year ago with the simple aim of addressing the pain points he faced as a professional in private equity. What began as a tool for personal use, quickly caught the attention of his colleagues; they wanted a taste.

Fast forward to 2026 and we find ourselves amidst a technological renaissance, traversing an exciting and unpredictable landscape. It’s clear that powerful enterprise AI capabilities already exist, but the way professionals actually work hasn’t caught up.

Analysts toggle between tools.

They copy and paste.

They format.

They reformat.

They reconstruct context manually.

They try to minimise errors.

They lose time to process instead of spending it on judgement.

Amuse-Bouche is not our full solution to that problem but it is a demonstration of the underlying technology we’ve been developing. We hope it serves as a glimpse into how information architecture, extraction and intelligent interaction can feel when designed properly from the ground up, by people with domain expertise.

What Amuse-Bouche does

Amuse-Bouche showcases a core capability of our stack: structured document interaction and no context lost.

Instead of treating documents as flat text, it understands form, structure, and relationships. It extracts intelligently. It preserves context. It allows you to explore content in a way that feels fluid rather than fragmented.

We’ve intentionally kept the interface simple; our goal is not to overwhelm clients with features, it’s to let you experience the speed and clarity of the underlying technology.

Crucially, Amuse-Bouche is not a mock-up, not a slide deck, not a conceptual prototype.

It is real software.

Built with care (and restraint)

We are young, ambitious and moving quickly but we are not cowboys.

If you work in financial services, or any sensitive domain, you know that trust, accuracy and reliability matter more than novelty or speed. So let us be explicit:

Amuse-Bouche was built with data privacy and security as foundational constraints, not afterthoughts. Add to this meticulous provenance structuring and tracking as a USP and you have at your fingertips a force multiplier that revolutionises financial research whilst respecting client data.

We are launching our first tech demo now, simply because building in public forces clarity. We want feedback from real users and we believe the best way to communicate ambition is through execution.

Amuse-Bouche demonstrates:

• The quality of our extraction engine

• The speed of our processing

• The clarity of our referencing

• The design philosophy underpinning Felix Research

Who Amuse-Bouche is for

If you work with dense documents.If you routinely extract structured information from unstructured sources.If you care about speed, precision and traceability.If you are curious about what AI-native tools might feel like when purpose-built rather than retrofitted.

This is for you.

Even if you’re just curious, explore it. We built it to be intuitive, so no onboarding call required.

Click through, upload something real, explore your Knowledge Graph. If it surprises you, tell us. If it frustrates you, definitely tell us.

This demo is both a showcase and a conversation starter.

Bon appétit.

The FRx Team

Prediction markets such as Polymarket and Kalshi sit uncomfortably between finance, gaming, gambling and information markets. Their recent growth has less to do with regulatory blind spots and more to do with a genuine categorisation problem. These platforms do not map cleanly onto existing regimes and that ambiguity has shaped both their trajectory and the intensity of regulatory attention they attract. Rather than asking whether prediction markets are socially beneficial or politically problematic, a more productive lens is to examine how regulatory classification determines what these platforms are permitted to become.

The Discomfort

Prediction markets have grown quickly because they do not fit neatly into existing regulatory categories. They challenge long-standing distinctions between speculation and information gathering, entertainment and financial exposure. This discomfort has prompted uneven regulatory responses, with authorities reaching for familiar frameworks even where the underlying activity only partially aligns.

What Prediction Markets Actually Are

At their core, prediction markets translate probabilistic beliefs about future events into tradable positions, blending elements of financial instruments, information markets, gambling and behavioural incentives. Participants are rewarded for being right rather than persuasive, and prices function as aggregated signals of collective belief. This structure explains why prediction markets are often defended as tools for forecasting rather than gambling. However, the presence of monetary stakes introduces exposure, incentives, and potential harm that go beyond pure information aggregation.

"Prediction market contracts are structured as commodity derivatives (https://kalshi-public-docs.s3.amazonaws.com/kalshi_finance_faq.pdf) which are explicitly tied to events. In essence, they represent binary positioning opportunities for traders, though many contracts mirror traditional exchange-traded contracts in that they can be structured to reflect e.g. a hurdle rate above or below a contract would pay out.

..As commodity derivatives, rather than company-linked equity derivatives, they are not generally encompassed by insider trading rules or other restrictions, allowing financial professionals (in principle and making no assumptions about company-specific guidelines) to engage in these markets. A key difference between prediction markets and “traditional” betting is that the prediction sites are generally exchanges rather than market makers. Whereas betting companies generally take the opposing side of a bet that is placed, on prediction markets, positioning is matched by participants, prices and probabilities then settling at the clearing price & volume rather than otherwise defined algorithmic outcomes." - Ben, FRx CEO

The Classification Problem

The central regulatory challenge posed by prediction markets is not their subject matter, whether political, economic, or cultural, but their classification. Are they derivatives contracts, gaming products, or data-driven forecasting tools? Each framing carries different assumptions about risk, consumer protection, and market integrity. Classification is not a semantic exercise. It determines which regulatory body has jurisdiction, which rules apply, and which behaviours are treated as unacceptable.

Why Classification Shapes Everything Downstream

Once a market is classified, its regulatory destiny follows. Oversight authority, capital requirements, disclosure obligations, and enforcement mechanisms are all downstream consequences of that initial decision. A platform treated as a financial market is assessed primarily through the lens of systemic risk, market manipulation, and participant protection. A platform treated as gaming is regulated around fairness, addiction, and consumer harm. Information markets, by contrast, face far lighter scrutiny. The difficulty for prediction markets is that they borrow features from all three.

Polymarket and Kalshi as Contrasting Case Studies

The divergence between Polymarket and Kalshi illustrates how regulatory posture, rather than market design alone, shapes legitimacy and operational scope. Kalshi has pursued registration and approval under the US Commodity Futures Trading Commission, positioning itself as a regulated derivatives exchange. Polymarket, by contrast, has operated largely outside formal US regulatory approval, relying on decentralised infrastructure and offshore positioning. The result is not simply different compliance burdens, but different ceilings on growth, partnerships, and institutional participation.

The Role of the CFTC and Financial Logic

The involvement of the Commodity Futures Trading Commission reflects a broader regulatory instinct to prioritise financial risk and market integrity over the informational value of forecasts. From the CFTC’s perspective, the key questions concern leverage, manipulation, concentration of positions, and exposure to loss. Whether a market produces accurate predictions is largely irrelevant to this assessment. What matters is whether the structure creates incentives or vulnerabilities that could undermine confidence or cause harm.

"Given the rapidly increasing scale of these markets, they actively engage with regulators, as is their duty, to ensure proper handling of information and safeguarding against market manipulation. Large PMOs (prediction market operators) do not allow insider trading on their contracts in principle, and state that they actively monitor, much like most traditional exchanges, for suspicious activity. Given the reliance on crypto for trade financing and a degree of anonymity, this cannot be entirely ensured. However, it is important to keep in mind the typical / highest volume contracts on these exchanges, most of which focus on events that are either difficult or prohibitively expensive to manipulate by a single player. For example, while it is conceivable, many bets are simply not feasible to directly manipulate, except by parties to the outcome themselves." - Ben

A Note on the UK and EU Regulatory Posture

From a UK and EU perspective, prediction markets remain largely peripheral rather than explicitly addressed, but their underlying characteristics intersect with several existing regimes. In the EU, the focus remains anchored in financial classification through instruments such as MiFID II and, where applicable, market abuse frameworks. Prediction markets that resemble derivatives may therefore encounter regulatory scrutiny by extension rather than by design. The UK doesn’t have an explicit “prediction market” regulatory category; instead, most real‑money prediction markets are treated as gambling under the UK Gambling Commission’s regime (with binary / purely financial derivatives treated or restricted under FCA financial rules).. 

While there is no bespoke regime for prediction markets, their operation would likely be assessed through a combination of financial services regulation, gambling law, and, increasingly, digital governance principles around consumer protection and platform responsibility. What is notable is the absence of clear guidance rather than the presence of active prohibition. This ambiguity creates space for experimentation, but also reinforces the likelihood that any future regulatory engagement will prioritise structural risk and governance maturity over the social or informational value of prediction itself.

Structure Over Outcomes

Whether prediction markets accurately forecast elections or economic indicators is largely secondary to how incentives, participation, and risk are structured. A market that produces accurate signals but concentrates exposure among a small group of actors presents a different risk profile from one that is widely distributed and tightly constrained. Regulatory attention therefore gravitates towards design choices rather than predictive success. This mirrors developments in other areas of digital regulation, where system architecture increasingly matters more than stated intent.

Boundary-Setting Over Endorsement

Effective regulation in this space is less about endorsing or suppressing prediction markets, and more about setting clear boundaries that align market behaviour with institutional risk tolerance. Clear classification allows regulators to articulate what is permitted, what is prohibited, and where responsibility lies. It also gives market operators a clearer basis on which to design compliant products, rather than operating in a perpetual state of ambiguity.

Closing

Prediction markets ultimately test whether modern regulatory systems can accommodate hybrid instruments without forcing them into ill-fitting categories that obscure rather than manage risk. As these platforms continue to evolve, the central question is not whether they are good or bad, but whether regulatory frameworks are capable of recognising their complexity without defaulting to blunt analogies. Classification, more than outcome, will determine their future.

Intro

Artificial Intelligence enters 2026 with less novelty and greater consequence. Over the past eighteen months, the focus has shifted away from demonstrations of capability and towards questions of governance, accountability and institutional readiness. This period has been marked by a steady accumulation of regulatory signals, from the EU AI Act entering into force in mid-2024 through to successive UK guidance initiatives across 2025 and early 2026. AI systems are no longer confined to experimental deployments, they are increasingly embedded within core enterprise workflows, influencing decisions, markets, and the distribution of responsibility between humans and machines.

This shift reflects a broader maturation of the AI ecosystem. Early optimism has given way to more sober assessment as organisations confront the limits of automation in practice. The challenge is no longer whether AI can generate outputs at speed, but whether those outputs can be trusted, explained, and governed at scale. In high-stakes environments such as financial research and decision-making, these questions are not abstract. They determine risk exposure and strategic confidence.

Regulation is an inevitable response to this moment, but it is also a revealing one. The sequencing of regulatory activity over the past two years shows governments experimenting with guidance, voluntary codes and formal legislation in parallel. The way states and regions choose to regulate AI reflects a necessary balancing act between risk appetite and the pursuit of technological and economic opportunity. Overcorrection risks stifling innovation, while under-reaction erodes public trust and institutional legitimacy. Navigating this balance has become one of the defining policy challenges of the current decade.

This piece lightly discusses that challenge through a number of lenses including: the growing body of literature interrogating AI’s concentration of power; the EU AI Act as a reference point; recent UK regulatory initiatives that have unfolded incrementally since early 2025; and the UK’s evolving attempt to align digital ambition with credible oversight.

AI Regulation Enters Its Literary Phase

Over the past year, AI has become the subject of a different kind of scrutiny. Alongside technical papers and policy consultations, a growing body of long-form writing has emerged that treats AI less as a breakthrough technology and more as a social and economic system. This literary turn has unfolded in parallel with the EU AI Act’s publication in August 2024. Karen Hao’s Empire of AI: Dreams and Nightmares in Sam Altman’s OpenAI (Empire of AI) exemplifies this shift, moving the conversation away from model performance and towards questions of institutional control and exploitation of both labour and resources.

At the heart of Hao’s argument is a reframing of AI as an extractive enterprise. Rather than portraying progress as the natural outcome of innovation, she highlights the concentration of resources and influence within a small group of firms. These organisations shape the direction of AI development through scale and capital, while the costs of that development are often distributed elsewhere. The book draws attention to the human labour that underpins modern AI systems, much of it invisible, precarious and geographically distant from centres of decision-making.

What makes Hao’s commentary particularly relevant to the regulatory conversation is the insistence that governance cannot be separated from incentive structures. Hao does not argue that AI is inherently harmful, nor does she call for sweeping prohibition. Instead, she exposes how existing market dynamics reward speed, opacity and centralisation, even when these qualities undermine accountability or long-term resilience. In this framing, regulatory missteps are less about technical ignorance and more about institutional misalignment.

The significance of this perspective lies in how it reshapes public expectations at a time when regulators are still calibrating their approach. As AI becomes more embedded in everyday systems, narratives that emphasise concentration and dependency resonate more strongly than abstract promises of efficiency.

Generally speaking, literature has a unique ability to surface these concerns in a way that technical documentation often cannot. It connects individual experiences of confusion or mistrust to broader structural patterns, creating a shared vocabulary for critique. For regulators, this literary turn presents both opportunity and challenge. On one hand, it broadens the scope of oversight beyond narrow safety metrics, encouraging consideration of fairness and long-term ESG impact. On the other, it risks accelerating regulatory urgency ahead of empirical clarity. Stories are persuasive, but they do not always map cleanly onto enforceable rules.

The emergence of works like Empire of AI signals that AI regulation is no longer driven solely by engineers and lawyers. It is increasingly shaped by public sentiment and political interpretation. Effective governance in this context requires discernment; literature can illuminate the stakes and expose blind spots, but regulation must translate those insights into proportionate and durable frameworks.

From Narrative to Governance

Literary critique alone does not produce regulation, but it shapes the conditions under which regulation becomes politically possible. This has been evident over the past two years as public concern has grown alongside formal regulatory action, particularly following the EU AI Act’s entry into force in 2024. At times, public opinion calcifies into prescriptive and paternalistic overreach, locking in assumptions that outpace evidence. At others, scepticism towards intervention can drift into inertia, allowing structural risks to accumulate unchecked. Both tendencies risk distorting regulation away from its core function: establishing clear, accessible guidelines grounded in risk mitigation and sustainable organisational benefit.

Completely dismissing literary influence is a mistake. Public legitimacy and trust matter. Regulation that fails to address widely understood concerns is out of touch with real end users and struggles to command compliance, regardless of architectural sophistication. The task for policymakers is to extract durable insights without codifying transient sentiment.

Distinguishing between risks that warrant formal oversight and broader anxieties that require transparency rather than restriction is imperative. This distinction underpins the EU AI Act’s risk-based architecture and is echoed, in softer form, in the UK’s subsequent guidance-led approach. Questions of cultural unease or speculative future harm are, at times, better addressed through standards, disclosure and ongoing review.

The challenge is heightened by the public’s tendency to frame regulation as a binary choice between protection and control. In the aftermath of the Grok episode, explained below, public debate quickly spun out into concerns about censorship, surveillance and overreach. Whilst these legitimate concerns merit serious consideration in general, within this context, they risk obscuring the narrower and more practical question of system accountability. Effective digital regulation must resist false dichotomy. Safeguards designed to prevent demonstrable harm do not require expansive monitoring of speech or behaviour; they require clarity about responsibility, proportionate controls and credible mechanisms for redress. 

The EU AI Act as a Regulatory Reference Point

The EU AI Act is a (rightly) ambitious step towards codifying AI governance into law. Published and having entered into force in August 2024, it introduced a risk-based framework that categorises AI systems according to their potential to cause harm, with obligations scaling accordingly. For firms operating within or alongside the European market, the Act offers something that has long been absent from AI oversight:  shared regulatory vocabulary.

From a UK perspective, the importance of the EU AI Act lies less in direct applicability and more in its role as a reference point. Even outside the Union, British companies building or deploying AI systems will encounter its influence through cross-border operations, investor expectations and emerging norms of best practice. The Act effectively sets a baseline against which other regulatory approaches, including those developing in the UK, will be compared, particularly as it becomes generally applicable in August 2026.

One of the Act’s strengths is its explicit definition of boundaries. By identifying prohibited uses and high-risk categories, it seeks to clarify what is unacceptable whilst allowing space for lawful innovation. This approach aligns with a jurisprudential preference for outlining constraints rather than prescribing permissible activity. In theory, such clarity should reduce uncertainty for developers and deployers alike.

In practice, however, the challenge lies in implementation. Many of the Act’s definitions are necessarily broad, reflecting the diversity and pace of AI and machine learning development. This creates an interpretive burden, particularly for organisations without extensive compliance infrastructure. There is a risk that complexity, rather than risk, becomes the primary driver of regulatory cost. Smaller firms may struggle to navigate layered requirements, even where their systems pose limited harm.

As a regulatory artefact, the EU AI Act marks a turning point. It moves AI governance from principle to operational. Whether it succeeds will depend on how effectively its requirements are translated into enforceable, proportionate practice.

Sequencing Security and Innovation in the UK

In contrast to the EU’s legislative approach, the UK’s regulatory posture over the past year has been characterised by sequencing and experimentation. Since the January 2025 publication of the AI Cyber Security Code of Practice (“guidance to help stakeholders across the supply chain for AI systems, particularly Developers and System Operators, to meet the cyber security provisions outlined for AI systems in the UK Government’s Code of Practice (and subsequently ETSI TS 104 223)”), followed by the Software Security Code of Practice in May 2025 and its update in January 2026, the emphasis has been on laying foundations for secure design before hardening expectations.

Alongside the Digital and Technologies Sector Plan, which frames AI as a driver of national growth, the recent launch of the Software Security Ambassador Scheme (January  2026) signals a deliberate trust-led approach to governance. The scheme builds on earlier guidance by encouraging industry-led adoption, peer learning and demonstrable implementation, rather than immediate enforcement.

The Code, co-designed with industry and the National Cyber Security Centre, sets out principles for embedding security across the software lifecycle. A cohort of signatories has committed to championing these principles and sharing practical insight on implementation. This staged approach allows voluntary practice to mature into shared expectation, giving regulators a clearer view of organisational capability before escalating intervention.

Taken together, these initiatives suggest a regulatory philosophy focused on learning, iteration and institutional readiness. They reflect an understanding that effective oversight depends as much on operational maturity as on formal rules.

When Strategy Meets Reality: The Grok Backlash

The EU AI Act reflects a structured attempt to regulate AI through risk categorisation, while the UK’s guidance-led initiatives emphasise proportionality and innovation. Recent events surrounding Grok, the generative AI chatbot integrated into the social media platform X (formerly Twitter), illustrate how quickly these frameworks can be tested.

A significant controversy emerged after users demonstrated that Grok’s image generation and editing features could be used to produce non-consensual sexualised images of real individuals (including minors). As examples circulated publicly, the issue drew rapid political and regulatory scrutiny, particularly in the UK.

What followed exposed the tension between strategic ambition and operational accountability. The speed and visibility of harm shifted regulatory response from future-proofing to immediate containment and in the UK, the episode was framed through online safety, raising questions about how existing regimes apply to AI-mediated harms.

The (ongoing) episode highlights the limits of voluntary safeguards once systems are deployed at scale. While mitigations were introduced, the incident reinforced a broader reality: public-facing AI systems understandably attract hard expectations of accountability. For policymakers pursuing innovation-led strategies, this underscores the need for governance mechanisms that function under pressure.

Closing: Clarity, Restraint and Risk as Organising Principles

The current moment calls for clarity of purpose on all sides of the regulatory landscape. For regulators and lawmakers, this means defining boundaries rather than enumerating acceptable use. The most effective frameworks will remain firm regarding impermissible actions whilst allowing for flexibility where application is concerned. The rapidly evolving landscape requires restraint, however, risk must remain the organising principle. 

For organisations and builders, governance is no longer a downstream compliance exercise. It is an operational cornerstone that must shape the full AI supply chain, from Ethics-by-design, through R&D, all the way to deployment and monitoring. As ever, firms that embed oversight early will be better positioned as regulatory expectations harden. 

Regulation of AI/ML and Digital in 2026 is no longer solely about playing catch-up with technology. It is about governance maturity. Literary critique of the levers behind AI development, the EU’s formalisation of oversight and the UK’s incremental, trust-led guidance all reflect the spreading recognition that AI governance must be framed and managed as a component of broader institutional responsibility.

This is the defining task of the new regulatory era.

Timeline & References

• August 2024 EU AI Act enters into force

• January 2025 AI Cyber Security Code of Practice published

• April 2025 ETSI TS 104 223 published

• May 2025 Software Security Code of Practice published

• January 2026 Software Security Code of Practice updated

• January 2026 Software Security Ambassador Scheme announced

• August 2026 EU AI Act becomes generally applicable 

Further References

• The UK’s Modern Industrial Strategy - Digital and Technologies Sector Plan 

• BBC XAI Grok Coverage 

• The Observer Karen Hao interview on Empire of AI

If you're anything like me, you may have recently heard people talk about AI a bit more. Apparently there are one or two companies that have made some progress in the field.

While I consider myself technologically savvy enough to use a computer and save a PDF, I've mostly spend time with my mind wandering whenever the topic comes up of how machine learning and neural networks function.

Nowadays, that's not the healthiest attitude, and since we at Felix Research are rather actively engaged in the field of using and developing Artificial Intelligence solutions, it became time to learn a bit more.

The problem that I have repeatedly faced is that many of the explanations of how the more complex models work feel a bit like this guide to drawing an Owl,

which while technically correct, sort of leaves out some key details.

Understandably, the large commercial providers (and cough 'non-profit' organisations) don't particularly have an interest in writing a guide for how to compete with them.

I'm in the fortunate position of not having to do all of our coding anymore (and I think the team is quite glad that we have Dimitri on board as our Founding Engineer), but I believe that I should know as much as possible about the subject, since it's pretty core to our business. As I learn, I figured I'd share this, and some of our readers might find it a useful 101-guide or reminder.

Linear Predictions with ML Models

The simplest possible model is a linear regression that takes an input and predicts an output.

Using Torch as one of the classic foundations for model building, we can quite simply write such a model.

In this simplest example, we are trying to train the model to learn y = 2x. Not really worth building a neural network for, but this example shows the basic structure of a neural network:

We define the Input and Output data for testing, our X and Y values, MSE loss and stochastic gradient descent (SGD). This is the most basic form of a model.

In this type of model, we use a mean squared error loss function to calculate the "wrongness" of a model prediction, and then gradient descent over epochs to train the model to be... less wrong. Our learning rate defines the step size at which we conduct this gradient descent.

Changing our learning rate significantly impacts how and at what rate our weights get optimized to reduce loss, and involves a fair amount of trial and error.

The difference between gradient descent and stochastic gradient descent is primarily that in SGD we pick a random sample of our data at a given point in time rather than using the full sample of data to compute a gradient at each step, thus being more computationally efficient. [^1]

Important to note for the curious is that:

Strictly speaking, SGD was originally defined to update parameters by using exactly one training sample at a time. In modern usage, the term “SGD” is used loosely to mean “minibatch gradient descent,” a variant of GD in which small batches of training data are used at a time. The major advantage to using subsets of data rather than a singular sample is a lower noise level, because the gradient is equal to the average of losses from the minibatch. For this reason, minibatch gradient descent is the default in deep learning. Contrarily, strict SGD is rarely used in practice. These terms are even conflated by most machine learning libraries such as PyTorch and TensorFlow; optimizers are often called “SGD,” even though they typically use minibatches.

[^1] See IBM's great explainer on SGD for a better and more in depth explanation

import torch
import torch.nn as nn
import torch.optim as optim
import numpy as np

# 1. PREPARE DATA
# X is our input data, Y is our target data (labels).
# We must convert python lists into PyTorch Tensors.
X = torch.tensor([[1.0], [2.0], [3.0], [4.0], [5.0]], dtype=torch.float32)
Y = torch.tensor([[2.0], [4.0], [6.0], [8.0], [10.0]], dtype=torch.float32)

# 2. DEFINE THE MODEL
# We create a class that inherits from nn.Module
class SimpleNet(nn.Module):
    def __init__(self):
        super(SimpleNet, self).__init__()
        self.linear = nn.Linear(1, 1)

    def forward(self, x):
        return self.linear(x)

model = SimpleNet()

# 3. DEFINE LOSS AND OPTIMIZER
# Loss Function: Measures how wrong the model is.
# MSE (Mean Squared Error) is standard for regression.
criterion = nn.MSELoss()

# Optimizer: Updates the weights to reduce the error.
# SGD = Stochastic Gradient Descent. lr = learning rate.
optimizer = optim.SGD(model.parameters(), lr=0.01)

# 4. THE TRAINING LOOP
# This is the heart of AI programming.
# Adding history to let us inspect what happens
history = {
    'loss': [],
    'weight': [],
    'bias': []
}

epochs = 200
print("Training started...")

for epoch in range(epochs):
    # A. Forward pass: Compute predicted y by passing x to the model
    y_pred = model(X)

    # B. Compute loss: Difference between predicted and actual
    loss = criterion(y_pred, Y)
    
    # We use .item() to get the plain python number out of the Tensor
    history['loss'].append(loss.item())
    history['weight'].append(model.linear.weight.item())
    history['bias'].append(model.linear.bias.item())

    # C. Zero gradients: Clear old gradients before calculation
    optimizer.zero_grad()

    # D. Backward pass: Compute gradient of the loss with respect to model parameters
    loss.backward()

    # E. Step: Update parameters (weights) based on gradients
    optimizer.step()

    if (epoch+1) % 100 == 0:
        print(f'Epoch [{epoch+1}/{epochs}], Loss: {loss.item():.4f}')

checkpoint = {
    'model_state': model.state_dict(),
    'history': history
}

torch.save(checkpoint, "model_and_metrics.pth")
print("\nModel and metrics saved to model_and_metrics.pth")

This trains our most simple model that takes 1 input and 1 output over 200 epochs, and saves the model weights to a file, so we can load it again later.

Visually, we see graphs that may look familiar - as the training epochs go on, the MSE of the model decreases toward zero, and our weight and bias approach the actual mathematical function we are trying to imitate here.

In this case given the simplicity of the model, even a few epochs are enough to 'correctly' predict our output, but we do see that if we run the model at only 200 epochs, we are left with an output that is close, but given the equation, pretty far off the mark.

We can also train our model for a longer period, that is for more epochs, which... changes very little in this case, really.

Training started...
Epoch [100/100000], Loss: 0.0173
Epoch [200/100000], Loss: 0.0088
Epoch [300/100000], Loss: 0.0045
Epoch [400/100000], Loss: 0.0023
Epoch [500/100000], Loss: 0.0012
Epoch [600/100000], Loss: 0.0006
Epoch [700/100000], Loss: 0.0003
Epoch [800/100000], Loss: 0.0002
Epoch [900/100000], Loss: 0.0001
...
Epoch [100000/100000], Loss: 0.0000

Model and metrics saved to model_and_metrics.pth

We are left with an essentially perfect model that predicts y = 2x, and we could now run this model to predict a value for this equation:

input_value = 20.0

# Convert the number into a Tensor of shape (1, 1)
input_tensor = torch.tensor([[input_value]])

# Turn off gradient calculation (saves memory/speed for inference)
with torch.no_grad():
    # Pass the tensor to the model
    prediction = model(input_tensor)

# Get the simple float value out of the resulting tensor
result = prediction.item()

print(f"Input: {input_value}")
print(f"Model Prediction: {result:.12f}")

Input: 20.0
Model Prediction: 39.999973297119

So What?

Now that we have wasted many orders of magnitude of compute beyond what's useful to predict that 20 * 2 in fact does equal 40 (or rather, failing to do so since we predict not quite 40), how do we make something that approaches a base level of usefulness?

ReLU

The above "model" is an example of linear regression, where we use the model to take an input and simply predict an output (Y = 2x + bias).

More use can be gotten from understanding how models can classify data, like a very simple example using colour. First, let's make a test set of data in the form of some spirals!

def create_spiral_data(n_points=1000):
    theta = np.sqrt(np.random.rand(n_points)) * 2 * np.pi 
    
    # Class A (Red) -> Target 0
    r_a = 2 * theta + np.pi
    data_a = np.array([np.cos(theta) * r_a, np.sin(theta) * r_a]).T
    x_a = data_a + np.random.randn(n_points, 2) * 0.2
    
    # Class B (Blue) -> Target 1
    r_b = -2 * theta - np.pi
    data_b = np.array([np.cos(theta) * r_b, np.sin(theta) * r_b]).T
    x_b = data_b + np.random.randn(n_points, 2) * 0.2

    # Combine
    X = np.vstack([x_a, x_b])
    # Labels: 0 for Class A, 1 for Class B
    Y = np.hstack([np.zeros(n_points), np.ones(n_points)])
    
    return torch.FloatTensor(X), torch.FloatTensor(Y).view(-1, 1)

X, Y = create_spiral_data()

Let's use a new model, with an additional (and larger) layers to address the added complexity of our data, and supporting two inputs (our X and Y coordinates).

Importantly, we still output just one number, this being our probability (for the classification of red and blue dots)

class SpiralNet(nn.Module):
    def __init__(self):
        super(SpiralNet, self).__init__()
        self.layer1 = nn.Linear(2, 64)
        self.layer2 = nn.Linear(64, 64) 
        self.layer3 = nn.Linear(64, 1)  # Output is 1 number (Probability)
        self.relu = nn.ReLU()
        self.sigmoid = nn.Sigmoid() # Squishes output between 0 and 1

    def forward(self, x):
        x = self.relu(self.layer1(x))
        x = self.relu(self.layer2(x))
        x = self.sigmoid(self.layer3(x)) # Final activation for probability
        return x

model = SpiralNet()

We've added "ReLU" here, at which point I became scared of maths again and closed my computer.

When I returned, I put on my big boy pants and entered google, at which point I became scared again, since anything with more letters than numbers in maths is inherently scary, and that isn't helped when the second result starts with "A Gentle Introduction to..."

What are Rectified Linear Units?

Actually, quite simple!

ReLU(x) = max(0,x) where the output = input if the input is >= 0, and 0 otherwise.

Unlike linear functions like in the example above, where no transformation is applied at the cost of being unable to teach the model any complex functions, we can address this using ReLU, by being able to pass what appears to be a linear input to a model for backpropagation, since we receive the input for all values > 0, and 0 for those below, leaving us with a piecewise linear function.

The adoption of ReLU around 2010-11 is one of the significant milestones that has enabled significant progress in the deep learning field. Before its use, the primary methods used were logistic sigmoid and hyperbolic tangent functions, with both have problems with saturation.

See the excellent Gentle Introduction for mode detail on these.

A general problem with both the sigmoid and tanh functions is that they saturate. This means that large values snap to 1.0 and small values snap to -1 or 0 for tanh and sigmoid respectively. Further, the functions are only really sensitive to changes around their mid-point of their input, such as 0.5 for sigmoid and 0.0 for tanh.

We now set the loss criterion. In our Linear function, this was a Mean Squared Error loss, which works well for regression tasks.

For classification, like in our example, we want to use a loss function that maximises the penalty for incorrect guesses, which leads to better training results than a MSE-based version, where we consider the distance to a correct guess.

Cross Entropy Loss is more commonly used in these classification problems, as it measures the divergence between the predicted probability distribution and the true distribution of target classes.

If you're a mathematician, it looks like this:

If you're a programmer using the torch library, it looks like this:

import torch.nn as nn
nn.BCELoss()

# We changed MSELoss -> BCELoss (Binary Cross Entropy)
# This is used for Yes/No (1/0) classification questions
criterion = nn.BCELoss()
optimizer = optim.Adam(model.parameters(), lr=0.01)

# 4. TRAINING LOOP
# Adding history to track loss and accuracy over time
history = {
    'loss': [],
    'accuracy': []
}

epochs = 10000
print("Training on Spiral Data...")

for epoch in range(epochs):
    y_pred = model(X)
    loss = criterion(y_pred, Y)
    
    # Calculate accuracy (How many did we get right?)
    predicted_classes = y_pred.round() # Round to 0 or 1
    acc = (predicted_classes.eq(Y).sum() / float(Y.shape[0])).item()
    
    # Track history
    history['loss'].append(loss.item())
    history['accuracy'].append(acc)
    
    optimizer.zero_grad()
    loss.backward()
    optimizer.step()
    
    if (epoch+1) % 200 == 0:
        print(f'Epoch [{epoch+1}/{epochs}], Loss: {loss.item():.4f}, Accuracy: {acc*100:.2f}%')

# Save model state and history
checkpoint = {
    'model_state': model.state_dict(),
    'history': history
}
torch.save(checkpoint, "spiral_model.pth")
print("Model and metrics saved to spiral_model.pth")

After training our model, we can load the spiral again, and see that we have a red and a blue region respectively, showing the model's mapping of the space after it has been trained. In this dataset with clear space and separation between the two spirals, the model has very few regions in which it cannot confidently separate the red and blue regions.

However, looking at the generated outputs and boundaries, it's clear that the model we have built here does not actually know what's 'red' or 'blue', it just splits the space into those two regions, leaving us with areas that are, visually, quite clearly outside the region of either spiral, and yet the model predicts with high confidence that this is a 'blue' or 'red' region respectively.

We can train the model with a third spiral, to separate the space further.

# 1. CREATE 3-CLASS SPIRAL DATA
def create_spiral_data(n_points=1000, classes=3):
    X = []
    y = []
    for i in range(classes):
        theta = np.sqrt(np.random.rand(n_points)) * 2 * np.pi 
        r = 2 * theta + np.pi
        
        # Rotate the spiral based on the class index
        # Class 0: 0 deg, Class 1: 120 deg, Class 2: 240 deg
        rotation = i * (2 * np.pi / classes)
        
        # Math to generate the spiral arms
        d = np.array([np.cos(theta) * r, np.sin(theta) * r]).T
        
        # Apply rotation matrix
        rot_mat = np.array([[np.cos(rotation), -np.sin(rotation)],
                            [np.sin(rotation), np.cos(rotation)]])
        d = np.dot(d, rot_mat)
        
        # Add noise
        d += np.random.randn(n_points, 2) * 0.2
        
        X.append(d)
        y.append(np.zeros(n_points) + i) # Label is 0, 1, or 2

    X = np.concatenate(X)
    y = np.concatenate(y)
    
    # Note: CrossEntropyLoss expects LongTensor for labels (integers), not Float
    return torch.FloatTensor(X), torch.LongTensor(y)

X, Y = create_spiral_data(classes=3)

# 2. DEFINE THE MODEL
class MultiSpiralNet(nn.Module):
    def __init__(self):
        super(MultiSpiralNet, self).__init__()
        self.layer1 = nn.Linear(2, 64)
        self.layer2 = nn.Linear(64, 64)
        # OUTPUT CHANGE: We now have 3 output neurons!
        # [Score for Class 0, Score for Class 1, Score for Class 2]
        self.layer3 = nn.Linear(64, 3) 
        self.relu = nn.ReLU()
        
        # Note: We do NOT put Softmax here. 
        # PyTorch's CrossEntropyLoss includes Softmax automatically for numerical stability.

    def forward(self, x):
        x = self.relu(self.layer1(x))
        x = self.relu(self.layer2(x))
        x = self.layer3(x) 
        return x

model = MultiSpiralNet()

# 3. LOSS (The "Big Gun" of AI)
criterion = nn.CrossEntropyLoss()
optimizer = optim.Adam(model.parameters(), lr=0.01)

# 4. TRAINING
epochs = 2000
print("Training 3-Class Spiral...")

for epoch in range(epochs):
    # Forward
    logits = model(X) 
    
    # Loss
    loss = criterion(logits, Y)
    
    # Backward
    optimizer.zero_grad()
    loss.backward()
    optimizer.step()
    
    if (epoch+1) % 200 == 0:
        # Calculate accuracy
        # torch.max returns (max_value, index_of_max_value)
        # We want the index (0, 1, or 2)
        _, predicted = torch.max(logits, 1)
        acc = (predicted == Y).sum().item() / Y.size(0)
        print(f'Epoch [{epoch+1}/{epochs}], Loss: {loss.item():.4f}, Accuracy: {acc*100:.2f}%')

torch.save(model.state_dict(), "spiral_3class.pth")
print("Model saved.")

This leaves us with regions that are closer to the actual spiral areas, but this shows us what this model does, and importantly, what it does not do.

We want the neural networks we build to be useful. The small model that we have put together above is useful, but only for this one specific task.

Rather than the model actually recognizing red / blue / neither, it essentially builds a map of our space, predicting the likelyhood of any of the options appearing in that space.

We can visualise this by changing the input from a spiral, where we can see quite clearly that we have not built a model good at differentiating colour, but one that learns a space.

As we can see with the test data below where instead of a spiral, we generate a set of lines of coloured data, the model is entirely useless for this task. If we wanted the model to be able to classify these arrangements, we would have to train it again.

What's next?

In order to proceed beyond simple classification or simple prediction, as we have looked at in this brief overview post, we have to start talking about Convolutional Neural Networks, which can begin to use training data, like the classical MNIST example set, to understand handwritten numbers.

What is a CNN?

From Wikipedia:

CNNs are also known as shift invariant or space invariant artificial neural networks, based on the shared-weight architecture of the convolution kernels or filters that slide along input features and provide translation-equivariant responses known as feature maps. Counter-intuitively, most convolutional neural networks are not invariant to translation, due to the downsampling operation they apply to the input.
Feedforward neural networks are usually fully connected networks, that is, each neuron in one layer is connected to all neurons in the next layer. The "full connectivity" of these networks makes them prone to overfitting data. Typical ways of regularization, or preventing overfitting, include: penalizing parameters during training (such as weight decay) or trimming connectivity (skipped connections, dropout, etc.) Robust datasets also increase the probability that CNNs will learn the generalized principles that characterize a given dataset rather than the biases of a poorly-populated set.
Convolutional networks were inspired by biological processes in that the connectivity pattern between neurons resembles the organization of the animal visual cortex. Individual cortical neurons respond to stimuli only in a restricted region of the visual field known as the receptive field. The receptive fields of different neurons partially overlap such that they cover the entire visual field.

Essentially, in a CNN, the input is broken into kernels. For example, in the model we set up below, we take a 28x28 pixel image, and break it into 3x3 kernels. The model then extracts a set of "features" from the images that it learns over epochs of training.

Importantly, as you are no doubt aware, when anyone talks about model responses, these are always, ultimately, a probability expression of the most likely answer out of the possible options.

At the end of our model, we have a layer with 10 outputs (numbers 0-9), which we flatten (with ReLU), to arrive at the activation of the layer that corresponds to our number value, which is the final model response.

In a dataset like the MNIST training set, we train the model with a large amount of test data, where each test image is labelled with its corresponding number. The model here effectively learns what shapes correspond to what labelled number, so that when we ask it to identify a number after training, it can identify the closest likely matching number.

import torch
import torch.nn as nn
import torch.optim as optim
from torchvision import datasets, transforms
from torch.utils.data import DataLoader

# 1. PREPARE DATA (MNIST)
# Transforms allow us to turn raw images into Tensors
transform = transforms.Compose([
    transforms.ToTensor(),
    transforms.Normalize((0.1307,), (0.3081,)) # Standard normalization for MNIST
])

# Download data
train_dataset = datasets.MNIST('./data', train=True, download=True, transform=transform)
# DataLoader handles batching (giving us 64 images at a time)
train_loader = DataLoader(train_dataset, batch_size=64, shuffle=True)

# 2. DEFINE THE CNN MODEL
class SimpleCNN(nn.Module):
    def __init__(self):
        super(SimpleCNN, self).__init__()
        
        # --- FEATURE EXTRACTION (The "Eyes") ---
        # Layer 1: Input 1 channel (grayscale) -> Output 32 features
        # Kernel 3x3 means it looks at small 3x3 squares
        self.conv1 = nn.Conv2d(in_channels=1, out_channels=32, kernel_size=3, padding=1)
        
        # Layer 2: Input 32 features -> Output 64 features
        self.conv2 = nn.Conv2d(in_channels=32, out_channels=64, kernel_size=3, padding=1)
        
        # Pooling: Shrinks image by half (2x2)
        self.pool = nn.MaxPool2d(kernel_size=2, stride=2)
        
        # --- DECISION MAKING (The "Brain") ---
        # We need to calculate the size of the flattened input.
        # MNIST is 28x28. 
        # After Pool 1 (28->14). After Pool 2 (14->7).
        # Final Grid is 7x7 pixels. We have 64 feature maps.
        # So: 64 * 7 * 7 = 3136 inputs.
        self.fc1 = nn.Linear(64 * 7 * 7, 128)
        self.fc2 = nn.Linear(128, 10) # 10 Outputs (Digits 0-9)
        
        self.relu = nn.ReLU()
        self.flatten = nn.Flatten()

    def forward(self, x):
        # Pass 1: Conv -> ReLU -> Pool
        # Input: [Batch, 1, 28, 28] -> Output: [Batch, 32, 14, 14]
        x = self.pool(self.relu(self.conv1(x)))
        
        # Pass 2: Conv -> ReLU -> Pool
        # Input: [Batch, 32, 14, 14] -> Output: [Batch, 64, 7, 7]
        x = self.pool(self.relu(self.conv2(x)))
        
        # Flatten: Turn Grid into Line
        # Output: [Batch, 3136]
        x = self.flatten(x)
        
        # Classification
        x = self.relu(self.fc1(x))
        x = self.fc2(x)
        return x

model = SimpleCNN()

# 3. LOSS & OPTIMIZER
criterion = nn.CrossEntropyLoss()
optimizer = optim.Adam(model.parameters(), lr=0.001)

# 4. TRAIN
print("Training CNN on MNIST digits...")
epochs = 3 # CNNs learn FAST. 3 epochs is enough for >98% accuracy.

for epoch in range(epochs):
    running_loss = 0.0
    for batch_idx, (data, target) in enumerate(train_loader):
        # Standard training steps
        optimizer.zero_grad()
        output = model(data)
        loss = criterion(output, target)
        loss.backward()
        optimizer.step()
        
        running_loss += loss.item()
        
        if batch_idx % 100 == 0:
            print(f'Epoch {epoch+1}, Batch {batch_idx}: Loss {loss.item():.4f}')

print("Training Complete.")
torch.save(model.state_dict(), "mnist_cnn.pth")

When we run this model, training takes quite a bit longer to train than the previous little testers we've built, as a result of the added complexity of our model and its layers.

We can see the difference in structure between the simple model we built for our spirals

and the MNIST training model

What can this model do? The MNIST training model is a sort of classic learning piece, which lets us recognize handwritten numbers from their training set, for example we can load one of the test images for the number '1', and indeed

The model correctly and confidently predicted our number.

Neat.

What now?

None of the above is new, but by going through the stages of models to this point logically, and beginning to understand some of the choices that are made to achieve the desired results, it helps us to be able to speak the language of neural networks, and to begin playing around with more complex cases. We went from a simple linear model all the way to a basic convolutional neural network, from predicting y = 2x to recognizing handwritten numbers.

Interviewing CEO & Founder, Ben Jaletzke  

Ben and I head over to a Battersea pub for an informal interview about the origins of Felix Research, the mission driving it and the industrial pain points that inform Ben’s approach to product building. We are joined by James (CCO & co-founder) to discuss AI for enterprise use, as well as the past and future of the workforce.  

Sav: Of course I already know this, but tell me how the idea came to you. Give us the origin story. Discovery. Pain points. Perceived opportunity. 

Ben: Well, you can read all about it in my new book, Felix One! 

Sav: "Rags to Riches" for the low, low price of five ninety-nine, ninety-nine! 

Ben: But in seriousness, I mean, I don't think there was that... eureka moment. 

We get comfortable in their chairs, having opted for stools outside but under the glow of space heaters – crucial for a brisk November evening in London. 

Intro & Background

I'd thought about various ideas before, but I don't think there was ever a moment where I was like, “That's The Thing”. It was more that while I was working elsewhere, I was playing around with a bunch of ideas in little elements that either annoyed me or that I thought I had a better approach to. So I starting programming. 

I wait expectantly.

Ben: Well I was just sort of playing around with thoughts and one of them was how do you make it easier for people in the team to share files and links and data with each other? Rather than doing it in an email or a teams chat or a WhatsApp chat, having one sort of centralised space where every time you share a thing, you do it there. That could have just been a plugin or whatever, but it was one my initial frustrations.  

Sav: Okay we'll certainly get back to that but before we do, at the time what were you working on?  

Ben: Like, job wise or? 

Sav: Yeah, like give us a bit of personal background but also some context in terms of where you were encountering these pain points. 

Ben: Yeah, I mean having spent some years in industry [institutional finance], as much as the efficient markets people want to say that there's some theoretically perfect information and yada yada, no one has even a modicum of genuine information. Like, if you wanted to break down any investment decision or possible investment decision into like its “prime factors”, - 

Sav: - Nice. 

Ben: - then there's too many of them to consider. So we just never have the actual data for it. That's broadly why Felix Research exists.

For example, if you really want to get into what inflation’s going to be like next year, there's too much data to do that. It's a very simple thing at a high level - you can look and see it’s at 2% right now and think that there's going to be a supply demand. So the assumption is that it's going to be slightly higher or lower and then you shift that 2% by some decimal place. But if you tried to do the real math, you would need an infinite amount of data to practically do that, because every single payment and every single action and every single choice would flow into that. 

So when I was doing the fundamentals, it became clear that we have a chance here to actually set up a very clean research infrastructure, from scratch, for a firm without - I don't know what you want to call it - like corporate debt, almost. 

Sav: And by that you mean figurative debt? Like an unpleasant residual? 

Ben: Yeah, I mean the overhang of bad behaviours and practices. Like, if you're a company subscribed to certain databases, then those are the databases you use to inform decision-making. If you have Bloomberg, you have a lot of data and you're sort of lucky in that sense, but most people either don't have it or can't use all of it.  And that led me to the practical question of how can we actually do this? Because, again, practically speaking, I can't download 500 terabytes of information and then search it. I don't even know how to search it. 

You have your one investment bank that sends you investment reports, so you use those, plus of course, other information. But that's sort of the only primary source you have in that sense. So you miss out on 99.99999999... essentially 100% of the information in the market if you're only considering that single source. So the question that I wanted to answer, from an investment perspective - which made me want to do the startup – was: How can we get closer to not missing out on the 100%? The only way to do that is programmatically. To have something that can search millions of data points or millions of ideas at the speed of core cycles. 

Sav: Can I push you to elaborate on “the missed 100%”? Get into that a bit more. 

Ben: So if you have your one advisor database and we assume you don't have any other database, from a numbers perspective, you have let's say 10 thousand documents. But there's 50 million documents out there. So you have a dismally small fraction of the total information. If you break it down by industry or sector or company type, the numbers change, but the ratios probably only get worse. Because if I'm only searching, let's say, the Goldman Sachs database, they have a lot of information, but they don't have any macro information outside of what's in their report. So if I didn't have a macro database, then in terms of making any kind of macroeconomic assumptions, I would have zero data, effectively, except whatever I read in a given report.  

So now if I add a macro database to my set, I have much more information. But now I have another problem: how do I combine that information sensibly? I don't want to be reading an article and then having to go to my macro browser, then to looking up the time series, understanding the data, and then going back to my project workspace - that takes too long. It's unwieldy.  

If you look at the European Central Bank, for example, they have so many small data points. They're all reliable, but you need a consolidated version of that.  So all that’s to say, you need to expand how much data you could have as your input, you need that amount of data to be manageable to work with and you achieve this by having a system that can look through whatever you want it to look through. 

Sav: So if we drew a straight line, narratively, from the link sharing exploration stuff to Felix One, what would it look like? 

Ben: The link sharing process, in relation to Felix One, was me trying to take a first step. There's this sort of philosophical ideal of what research data should look like, which is to be able to search all data from any source in any fidelity, perfectly and instantly. That's essentially sort of like quantum computing for data, if you will. Like, ideally you search infinite mutations and get the result you want, yes, but we can't do that. That doesn't work. It's not feasible. What we can do at least - with the link sharing thing, for example, is if we have a file, I can make sure that you also have that file or you can see that file. So we're not yet cutting out the noise, but we're at least making a tiny fraction of working with some amount of data more manageable. So Felix One is a first step into extending a researcher's dataset and also making it easier to work with the data. 

Workflows & Enterprise Finance

Sav: Talk to me a bit about workflows. We spoke earlier this year on the blog about technology alone being an insufficient strategy; how do developers close the gap between the software and the human end user - financial researcher or otherwise? 

Ben: Within the finance industry there is nothing except for your take on something; essentially it’s your IP that separates you from another firm. There is functionally no difference between two boutique investment banks in that there’s nothing that one bank generally has that another bank can't also get - that goes for industry knowledge too. You can always hire the person with whatever expertise you’re looking for. In that way it’s kind of a people-driven business. Therefore, if you leave a big firm where you became very good at a Thing, you're going to leave it to do that Thing for someone else or for yourself. But the inverse means that even if you're smaller, you can be highly effective.  

If you were making Citadel, like, 2B a year, then you can usually do that exact same thing one-for-one in a different context. Oftentimes, you even take your old team with you after a while. So that's not only Citadel losing your revenue, but they're losing potential investors who might go with that team, which is why that kind of thing is strictly regulated.  

Sav: Sounds fairly zero-sum-y. 

Ben: Yeah the vibe is very zero-sum but the situation isn’t entirely. It's largely the attitude people have that creates the zero-sum game. And you know, that's partly a function of it being an industry where the thing you're producing is also the thing that you get paid.  

Sav: Sure. 

Ben: It's not like car manufacturing, where you make a lot of cars and then some percentage of that after cost and after supply chain might be a bonus of like your performance or whatever. It's like if you make more money, you get more money. Therefore, people are very much all in that zero-sum mindset. Like "I would like all of the money if I can". And that's reasonable.  

But, going back to the idea for Felix One and the idea of the Super-Empowered Professional,  I think part of the problem is that some of the ideas that I'd like to pursue are ones that are actually quite complex in that they require both immense man-power and considerable compute. Some issues and ideas are conceptually very easy to understand, but the Doing It is a different matter. Sometimes a million connections have to be made for something to work the way it's supposed to, as seamlessly as it's supposed to. But then that’s sort of what I hope the future work of Felix Research to be, more broadly once we’re able to do so. 

So, the link sharing thing would have involved the huge headache of connecting every single thing that someone could possibly use to chat and figuring out how to do that securely and quickly.  

Sav: Sounds as unwieldy as it would be helpful! 

Ben: Yeah, I mean, I think helpfulness has to be the Ultimate Good for our purposes - it's no good if you design a thing that makes people's lives easier but you’ve actually ended up adding steps to the workflow. 

Sav: Definitely. 

Ben: With some footnotes to that, of course. Ultimately, the trade-off has to make sense.  

Sav: Yes. How many steps are you adding versus how much better is it? 

Ben: If you're adding five workflow steps, but each step actually adds value, then maybe it's okay to add the five steps. 

Sav: And I guess we're in interesting times for AI-powered workplace software in that people are rushing to the table with “Productivity Tools” that neither eradicate the administrative bloat meaningfully, nor create massively valuable output. Hello! James has just joined us. 

 James Enters. 

 James: Hello! Please continue. 

James pulls up a stool and casts a glance at the recording setup - a very artfully/ precariously balanced phone atop a coffee cup, if memory serves.

Sav: I was going to say, on this issue of creating diminishing returns, where you're catering to a pain point, but actually making the process more complicated. You're seeing this emerging issue wherein companies are implementing these AI pilots that are glorified wrappers and putting their staff through training. That's nonsense.  

James: Yep to then use a tool that isn't very agile, doesn't reflect the reality of their workflow and ends up gathering dust a year later. 

Sav: So it seems that you're uniquely positioned because the solution you're creating was a pain point to an end user within industry - yourself. Rather than a reverse engineered attempt to see whatever businesses will pay for. 

Ben: I mean the overarching mission has been to build a simple website that makes mundane parts of the workflow easier. There have been so many fleeting instances of like “If I could just improve this one tiny thing, I would find Product much nicer to use”. 

So there are lots of these opportunities for little tweaks, where something is really good but there’s a gap to be bridged as far as real life usability. Like, I just need to adjust these things for my personal workflow - now, my personal workflow is by no means the best workflow, but I found that by making these tweaks, I inadvertently started learning more about these tools and what it takes to develop one. 

There's also a kind of connectivity to the learning. An example is another orbiting idea that I placed on the back-burner because it was never intended to be a standalone product. It was a multi-format text editor, where instead of having four different editors for four different text formats, we just have one page where I can, at the click of a button, switch between HTML, markdown, rich text and other formats and get an output ready to paste into website code.  

Sav: And why wasn't it ever intended to be or developed into a standalone product? 

Ben: I wanted it to exist differently. The principles of centralisation and interoperability are attractive, evidently, but people don't pay for text editors. It's the kind of thing that you would bundle it in some subscription where you get it as an add-on for some extra pounds per month or something. 

James: Fair. Realistic. I suppose a benefit of having familiarity with the landscape you’re trying to sell within. 

Ben: Yeah, but at the same time, it was another step in the direction of like, okay, what can I use of the available tools? And then tweak them slightly or put them together a bit like Lego and put them together in a slightly different way to make them nicer for myself. And that’s how we get to the early stages of Felix One. After those practical functional questions came the kind of... self-belief part. 

On Personal Process

I was catching up with some friends from my old job and one of them said to me, “Oh, I never thought you'd stay in finance long. I always thought you'd do a startup at some point”. And he kind of gave me the impetus to consider, “Maybe I should give it a try”. And the more I kept talking to people, the more I got these enthusiastic responses – I found it really encouraging. Honestly, Rebecca had a huge role in getting me out of my head and out there doing validation. You know, I don't like to talk ideas because I see all the reasons why they're not good enough ideas, or why not yet. But she was like, “Just talk to people. You have to talk to people about it to get feedback on what could make it better.” 

Sav: Amazing.  

Ben: And so that's how I started.  

Sav: And so to be clear, you were in the mode of “I would benefit from this” purely.  

Ben: I was in the mode of "I would benefit from it and there's probably a way to turn that into larger benefit for others". The original idea for Felix One was called Parsley and it was just the idea of parsing data. I called it DocParse, which, you know - very Me Naming A Product. And Rebecca looked at it and was like, “Oh, you can call it Parsley, like the leaf”. 

 Sav: Love that. 

James: That's so good.

Ben: Right? I was like, "Fuck, that's a really good name". So the first time I went to one of the Gathr events as a founder was for Parsley. And then it kind of, you know, quickly snowballed from there. Obviously you and I started talking and I started to work on it more with the explicit aim of making it a product how can we make this a product?  

I never liked the idea of doing something that's just a little bit useful, because that doesn't feel as satisfying if it's a plugin. You also probably wont like using it as much. Its unmemorable. I didn't like that. Then I would have rather taken a standard job; I also didn’t want to start a company for the sake of starting a company. And then it just sort of took shape.

As I started working on it in April ish, I was more like, okay, so actually the link sharing thing and the centralised editing things are kind of connected in that if we can make it easier for you to share files and we could make the files more readily available to edit, what we're essentially doing is reducing the workflow to its core component of Words In A File. You don't care about the formatting anymore. You care about the information contained in it and the relevant context. The parsing function is obviously just an extracting exercise. But that eventually morphed into the idea of well how can we build a full interface in which you can, you know, read PDFs easily?  

No one likes whatever tool they use for PDFs. Yeah, like I will give Apple's preview a sort of shout out here, not that I'm in a position to shout out to Apple, but there's a lot of annoyance in the modern workflow itself and there's a dearth of good products that are made specifically for the financial industry. And that’s always slightly baffled me because it's the largest and most important - well, important in that it's one of the most significant - industries in the world. 

But its an issue of How. How is it that video editors and photographers and doctors and academics and industrial designers, everyone has their own domain-specific software and for finance its like, “Ah, you just use Excel.” Fuck off?

Sav: Is that, I mean, within the sector, is that almost a point of pride? You know, people who actually enjoy using a kind of no nonsense, no fuss, no frills, bells or whistles kind of thing? 

Ben: So this is the other thing. It’s a mixture. It is a big point of pride for people in finance to become good at using Excel and Bloomberg and those sorts of tools that all require quite a learning curve. 

Sav: Understandably. 

Ben: And I get it, because once you become good at it, it is very powerful. But more and more, no doubt also because of AI and everything, you see people actually becoming far worse at it nowadays. I was talking to a friend the other night. He was struggling to find anyone who could build a really good financial model. 

James: Why? 

Ben: Just because you're learning it less and the people who learned it as stringently are becoming more senior, so they're not the ones training the people anymore.  

With Excel, there's always been this issue which is that you have to justify whatever you're doing as a junior to your senior, who's the actual stakeholder. Excel and PowerPoint are easy in that they’re tangible for the older generation to use - even if the senior doesn't model himself anymore, he can still go into an Excel spreadsheet and know how to navigate it. If you click F2 on a cell, you see the calculation - it's there in that cell, in front of your eyes. And the entire thing, start to finish, is auditable, which you don't get in the same way if you're in a web application oftentimes. You can learn all the rules and you can work with it, but it's not auditable in the same way. And the problem is, the only other option so far for finance has essentially been Python programming or C++, sort of like what you see in quantitative terms for building algorithmic models. And they are way faster and way better in a lot of ways, but the problem is, you can't manipulate them as easily. You can't take Python code and just be like, “What if we replace this entire table with the Q3 table?” It's static code that requires a greater level of learning that language properly, learning how to use it, learning the tools required to display images and dashboards, and so on. 

AI & The Modern Workflow

Now we're at a stage where, because of AI, you can still give someone a spreadsheet, but you can have a thing that works in the spreadsheet alongside them. And I do think as the industry changes and as everything adapts to AI, there'll be a big adjustment in finance. There's already a growing movement in some private firms to stop hiring juniors. A senior who knows what they're doing financially and from an investment perspective has much less need for an analyst to build them a full model because he can still build enough of it to not need the analyst to do all the number crunching.  

So what we need to do is to become part of that more modern workflow and make it such that, I guess in a slightly romantic way, the people who work in finance are people who are really good at finance. But you don't also have to be really good at Excel modelling specifically to be good at finance.  

Just like if you went back 60 years and saw people doing industrial and architectural design, you would have offices with like 50 or 100 people doing Blueprint drawings and calculations on paper, essentially. And now you have your CAD software that is orders of magnitude more effective. 

James: A guy with a CNC and CAD software can make what would have taken a team of 100 people to design. 

Ben: Yeah. I still feel like Excel and probably things like Bloomberg are the only real innovations that have happened in terms of how you do finance. Everything else has been a philosophical adjustment of private and public markets or emerging markets. But the sort of, the workflow itself has never really caught up. And it's probably because until the introduction of AI, there hasn't been a need really to change anything it out the workflow. 

Sav: So regarding the advent of AI, what do you think? I mean, obviously the disruption is already happening, but what do you see as the effect of AI on finance?  

Ben: Well, so there are different ways to approach that. One is obviously from an investing perspective, which isn't really the point of this right now, but it's shifted what you have to focus on. Because you now have to, for example, look at how much more resilient a business is to either integrating with or existing in spite of AI, which from an investing perspective changes the game a bit.  

Why does Docusign, for example, have 10,000 employees? There's a good chance that as AI models get better and better, a lot of those roles become redundant. And the same thing in things like marketing. So all of a sudden when you're doing company analysis, you have to take a different approach. But what it's also meant is that other industries are seeing the effects of the benefits of simple AI, like summarising a dot com, or email apps that reply and manage your calendar. We're getting closer to the point of being able to use AI for fundamental analysis. And it's, you know, novel in the sense that for a long time there have been people building ML models (pre-LLM) that try to analyse the tone of, for example, the Fed Board of Governors meeting - “were they sounding positive or negative?” For years there’ve been these investigations, not that they've ever been particularly accurate, but they're better than having to read a thousand tweets. 

Sav: Indeed. I guess for some of us that's our hobby. 

Ben: Quite. But if you do it 10 times a day for 10 companies, it becomes something else entirely. 

But I think there's good and bad ways to use AI and it's important to be wary of it. But equally, I think if you are too wary of it and you have competitors starting to use it properly, then you're going to lose out. Like, if you're still using antiquated workflows that are also much more painful from a quality of life perspective for the people using them, then you're much less attractive as a place to work as well.  

But most important is speed of analysis. There's a lot of events that you have to react to quite quickly in finance and usually whatever happens, there's a lot of source data and a lot of calculation that goes into those reactions. If, for example, there's a regulatory announcement by a government party, there’s usually a great many implications to that. And if you do read over those regulatory documents, the way that they're written is deliberately difficult to understand - it makes them annoying to read. So just having a thing that simplifies without reducing the depth of context available will become a game changer for the industry. 

Sav: And you said there are good ways of using AI and bad ways of using AI and you know, you don't want to lose an advantage that your competitor has, but you want to be wielding it properly. Why don't you just tell me a bit about what that means practically, not as a industry commentator, but as a business owner. To close out. 

Ben: For the most part, I think the bad ways to use AI are to rely on the outputs as factual. I mean, there's plenty of proof that AI models lie almost as much as they don't. Well, actually that's not true.  

*All laugh* 

It's like 80% true, but that's a 20% error rate, which is unacceptable by most standards, let alone professional standards. In finance, if you look at a model and there a 20% chance of what you see being wrong, then it's entirely useless. The problem with AI is a lot of the time you don't necessarily know which 20% is wrong. It's not like the first 80% are really good and then at the end it drops off. It can be sprinkled here and there. So that is the bad way to use it.  

The good way to use it is to employ it in ways such that it has less of a chance to make a mistake. Build auditability into your workflow. Essentially, if you ask it to “summarise a document” or to “extract the table A”, it's much easier to check. You just want to have the information to hand for reference - if you're extracting the table, you can visually see both results next to each other. You can even do a little Excel true/ false thing just to highlight if all the cells match. That's a good way to use AI because it takes you more time to do that than it takes the AI. It's sort of a speed enhancement, not a replacement for thinking. And I think that's the core issue - if you use it to free up valuable time and activities, it's good. If you use it to replace your thinking, then at least for now, it's bad. 

James: The benefits of keeping a human in the loop! 

Sav: The mission is Clarity at the speed of Thought for a reason!  

Who has the right to create or “create”?  

My CEO sent me a quote tweet (or Xeet, or post, or whatever the correct nomenclature currently is) about Nano Banana and AI in general and told me to blog about it. The tweet: 

This is a Xeet after all, so we’ll gloss over the misappropriation of the generalised “AI” label to refer solely to generative AI. We also won’t question too closely the aptness of “god complex” in this situation. A God Complex is a delusion of grandeur and superiority - albeit, the link to creation is elegant. 

We can understand the sentiment of this tweet as:   

“Generative AI’s main use case is ostensibly empowering the lazy, the untalented and the unqualified to create things they have no business creating. If they had any business creating those things, they would value and invest in the journey/ slog and consequently they would become initiated via their own passion and aptitude – at which stage they would have little to no interest in using GenAI. Instead, the mediocre reap the fruit of the labour of the contributors, whose uncredited and uncompensated work trained these models and is the foundation of anything the interlopers go on to “create”.    

Or maybe I’m completely incorrect in my interpretation. For the purposes of this piece, however, we will work with the above.  

What's Wrong with Using AI to "create"? 

A) Energy usage and ESG concerns. These are practical issues that are relatively simply handled - if the relevant parties choose to handle them. This will not be the focus of the piece. The more slippery issue is, by nature, harder to name and implied in @supermoongirl9's tweet. I will attempt to identify, name and unravel it within my breakdown of the below. 

B) Plagiarism & lack of originality. Why is this an issue? Because of a lack of renumeration and credit for the original contributors. However, this is a normal (not good, but also not unique) function of capitalism. 

The issue with centring stolen/ uncredited/ uncompensated IP in discussions about genAI use, is that such a thing is a practical issue in the domain of contract law, not morality (apologies to those who think of the two as tied).   

Consider the following situation: You join an organisation and sign your employment contract, which means signing over your work-related IP to your employer. During your tenure, you create a revolutionary internal program that saves your company hundreds of thousands. For this, you get a promotion and raise (which is a fraction of the revenue you have generated). After your exit, your employer repackages and sells the program to third parties and you don’t see a penny of that sales revenue because it is not and was never your IP.  

If we are going to delineate the concept of credit, we must figure out how we value visibility/ exposure. Consider the structure of author contributions to a scientific journal – these are usually not financially compensated. If LLMs had an academia-style inbuilt citation system that assigned credit to sources of training data, would this be a solution? Partly, but there seems to be an additional aspect to the general public's discomfort with "AI Creators" and I suspect it is the intangible reward that is acclaim and cultural currency. 

The dichotomy we are presented with is: "pick a side - you either think genAI is like traditional media production but BETTER (superlative of the same thing) or you think it’s outright THEFT".  

Mightn’t there be a third option? That genAI is a different (value neutral) kind of creation?  

To draw on a parallel, let’s look at driving. There is no moral implication associated with only knowing how to drive automatic (it’s important the reader knows that all three men in my office were quick to disagree with this) but it’s understood that there is a fundamental skill that manual drivers possess, which automatic drivers lack. This isn’t an issue because the machine compensates for the gap in the latter’s skillset. The question is therefore purely practical – are you road safe and is the end result competence?  

But if we were discussing Formula 1 drivers, the conversation would surely be different; namely being one to do with desert and reward, rather than practical outcomes.   

What I’m getting at here, is that acclaim, recompense and appreciation for effort (i.e. components of credit) are muddying factors. "If you want to enter the market, don't cheat" is the sentiment here. Don't try to enter the market and you can do what you like.  

These nuances within the wider umbrella of credit bring to mind two parallels: 

1) The invention of the camera.  

This critique boils down to the above "you're cheating and unskilled" argument. But perhaps what is emerging, similar to the advent of photography, is a new type of creation and therefore a new kind of skill?  

Is the invention of genAI to media production what the invention of photography was to traditional art? Or is the invention of genAI to media production what piracy is to media production companies? Prompt engineering is a skill (spoiler: it's philosophy (more specifically, theory of mind)) that requires some effort and development and perhaps deserves some credit. This, however, does not answer the issue at the heart of the second parallel... 

2) "Reality stars are (undeservedly) famous for being famous (doing nothing)!"  

We can take this critique to mean "We/ society doesn't value the "skill" which is being rewarded here". The response to this sentiment is arguably "So?" Our hypothetical complainant might level either of the following retorts: i) we should care to police that which contributes to cultural rot ii) we should be wary of creating incentives (like attention and resultantly money) to degrade culture. 

The problem is, “rot” is subjective and even if we could reach consensus on such a thing, when something is lucrative, or even just profitable, that is a factual demonstration of how this given thing is valued by our society. 

So how do we decide what is permissible and what isn’t? Maybe we examine risk and impact ad hoc and determine what our societal values are? Lofty and easier said than done! Do we posit that intellectualism is virtue whilst anti-intellectualism is vice and use this as a rubric? What does this mean for productivity tools and AI given MIT's findings? 

Enter Felix Research's philosophy of Augmented Intelligence. Wherein keeping a human-in-the-loop leads to the prioritisation of both clarity and speed. 

Practicalities of Avoiding Slop & FRx's Clean Data Proposal 

Thus far, we have looked at AI slop as a general phenomenon. If we examine it in the context of enterprise use, AI slop is not just an irksome source of noise, but rather a technical challenge and source of risk.  

Existing genAI systems create an environment where, frankly, plausibility of output is conducive to complacency in end users. The generated outputs sound correct, especially when the work is shallow or unfamiliar, however using an LLM for deep research, or for an esoteric subject that you have expertise in will quickly reveal its limitations. If an uncritical LLM user is working in a team, sharing their work and findings with others, this makes it all the more difficult to distinguish accurate output from misinformation further down the line. 

The systems that generate slop are often well-engineered at their core, but poorly supervised, unexamined and unchecked. What they lack is structure. For organisations that depend on reliable intelligence, particularly in financial contexts, this absence of rigour is untenable.   

Felix Research’s proposal in favour of clean data addresses this challenge directly. We put forth the below introductory framework for keeping AI fast, trustworthy and transparent by embedding governance principles into its foundations. The simple truth is that speed is only an advantage if you can trust your outputs; when AI systems produce results that cannot be traced or validated, acceleration becomes a liability. Clean data restores balance by ensuring that every layer of automation is grounded in provenance and accountability.   

"A primary concern for enterprise data governance is the lineage of information" notes Ryan Daws in his recently published article on AI and threats to business data accuracy. Every dataset carries a lineage, and knowledge of that lineage is essential to judging the reliability of any conclusion derived from it.   

Provenance is therefore the first pillar of clean data in the context of AI for enterprise use. Like a house of cards, if we lack this clarity on the fundamental layer that is good data provenance, outputs cannot be meaningfully verified. Clean data therefore depends on disciplined data hygiene: structured ingestion, active validation and documented review. These are long-standing practices in Business Intelligence, but they must now become rigorously enforced standards in AI.   

The second pillar is Ethics-by-Design. Responsible AI cannot be achieved by policy alone; it must be built into systems architecture. This means defining transparent parameters for how data is collected, processed and applied, as well as ensuring that accountability is distributed rather than deferred. In finance, where AI systems could conceivably shape regulatory reporting and investment decisions in the future, such clarity is not a moral preference but a compliance necessity.   

Our third pillar is Hybrid Reasoning. By combining symbolic AI (which uses explicit rules and logic) with generative models /unsupervised components that learn and adapt, organisations can achieve both speed and interpretability. Symbolic reasoning provides a structured framework for traceability and compliance whilst generative and unsupervised systems add flexibility and contextual understanding. Together, they create an AI stack capable of producing insight that is dynamic yet dependable. 

AI Slop vs Clean Data AI Table 

Dimension 

AI Slop 

Clean Data AI 

Output Quality 

Superficially fluent, factually fragile 

Transparent, traceable, and domain-specific 

Data Integrity 

Unverified, poorly sourced, feedback-looped 

Curated, validated, and provenance-tracked 

Governance Approach 

Ad hoc, siloed oversight 

Cross-functional governance (Compliance + BI + Engineering) 

Human Role 

Removed from the loop, human as observer 

Central to the loop, human as sense-maker 

Architecture 

Purely generative, prone to hallucination 

Hybrid symbolic + probabilistic reasoning & RAG systems 

Compliance Risk 

High, opaque decisions and unverifiable outputs 

Low, auditable data lineage and deterministic logic 

Business Value 

Volume-driven productivity illusion 

Decision-ready insight and reputational resilience 

At Felix Research, we seek to create a centralised workflow environment wherein data lineage, validation and reasoning coexist seamlessly. Analysts should be able to move quickly without surrendering oversight and organisations should be free to innovate without compromising trust.   

Our philosophy is not a rejection of automation but a refinement of it. We understand that innovation with lacklustre governance is unsustainable and that acceleration without clarity leads nowhere useful. By treating data integrity as an enabler rather than a constraint, institutions can build systems that are both efficient and ethical.   

Watch this space.   

"I cannot define it, but I know it when I see it." This is something we're all distinctly familiar with, and it's becoming increasingly relevant in the age of AI. As various models approach (and often surpass) human capabilities in numerous domains, it's the differences between AI and humans, not their similarities, that draw our greatest frustration. 

"More British please" is a prompt I find myself making constantly when using AI as a tool in my daily work. As a professional doing outreach (cold, warm, and everything in between), tone and subtlety are what I look for. Asking for investment, building rapport, getting replies, and acquiring customers all depend on unwritten textual and social rules that cannot be expressed in any concise or quantifiable manner. 

The American-heavy nature of AI development and training data means modification via prompts is increasingly required but also increasingly difficult. The challenge lies not in the AI itself but in the user's desired yet nebulous output. I can describe what "British tone" means based on my own background and experience, but is that the same as what the AI understands? And is that the same as how everyone else interprets it? 

This goes far beyond spelling and grammar. Much of my work has been UK-based, and through in-person meetings and phone calls, you develop a feel for what works (and more importantly, what doesn't). In a culture like the UK, which values subtlety generally and directness only occasionally, these nuances matter enormously. 

The Hybrid Approach: Keeping Humans in the Loop 

However, this struggle illuminates the benefits of a hybrid approach; Augmented Intelligence means keeping humans in the loop. Why have a human write from scratch when we can refine? The last 20% is often 80% of the value (and effort!). 

I'm not suggesting all writing should be done by AI, but when time is constrained, it's better for both creator and recipient that effort is allocated to the value-add. Personalisation and tone are where humans excel. Navigating relationships is what we've evolved to do and what we're paid to do in client-facing roles. The charismatic, eloquent salesperson is in the company to spend their time driving value, not drafting approximate emails to reach as many targets as possible. AI should enable you to focus on your strengths. 

At Felix Research, we understand this is true across all domains, and especially in finance where costs are high and time constraints the highest. The analyst, partner, or senior has studied hard, worked hard, and thought hard to reach a position where they add value. Why continue doing things the old way? How much of a £100k analyst's salary is spent sorting and scanning PDFs? 

Beyond Cultural Untranslatables: Domain-Specific Meaning 

But untranslatables aren't unique to cultural contexts. Consider: if I ask for "the European gas price", what does that mean? Or "a good wine to invest in"? Or "a company that could be the next GameStop"? All of these have multiple interpretations and contextual meanings. 

In finance, terms often have more specific, generally agreed-upon interpretations, but these are built on agreements and assumptions. Assumptions, however, don't always create clear or concise answers. Only someone (or something) trained to understand the industry-specific interpretation can give you a good answer. And crucially, a fast one. 

This is where Felix One differs from generic AI.  A standard LLM available today is good at being verbose and covering all bases, but misses the mark for the professional user. A professional needs the correct answer, and often needed it yesterday. Speed and accuracy are crucial, but so is traceability and referenced findings. After all, no one likes being asked where they found that data. 

An AI Built for Finance 

Take a real example: an analyst researching renewable energy exposure across European utilities. With a generic LLM, you'd spend time crafting the perfect prompt, sifting through verbose responses, then manually tracking down sources to verify claims. With Felix Research, our AI-driven financial research platform is trained specifically on financial documents and understands domain-specific terminology. Ask about renewable energy exposure, and you get precise data points with direct citations to the relevant regulatory filings, investor presentations, and annual reports. 

The platform doesn't replace the analyst's judgment about which utilities represent the best investment opportunity. Instead, it eliminates the hours spent gathering and verifying basic information, allowing the analyst to focus on what they do best: analysis, pattern recognition and strategic thinking. 

This is how AI should work in professional contexts. It gets you to the stage where you add value faster by finding sources, showing them clearly, and being correct. Humans are still needed, and still wanted, for making crucial financial analysis and decisions. The £100k analyst should be synthesising insights and advising clients, not wrestling with PDF searches. 

The Path Forward 

The future isn't about AI replacing financial professionals. It's about purpose-built AI platforms that understand finance specifically, not generically. Platforms that cite their sources. Platforms that understand what "European gas price" means in context. And most importantly, platforms that free professionals to do what only humans can: apply judgment, build relationships, and make the critical decisions that drive value. 

Ready to reclaim your time for high-value work? 

Written by James Hall

Every day brings another wave of AI-generated reports, analyses and summaries, promising insight but delivering an uncanny simulacrum of some other familiar output. As volume grows, discernment declines; what remains is what we may call AI slop.

This phrase captures a growing problem in modern information work: content that appears intelligent but is not. It describes the confident output (read: regurgitation) of automated systems that imitate understanding without demonstrating it, producing analysis that sounds convincing but lacks reasoning, evidence, or domain context (in the worst cases, the evidence will be present but fictional). In finance and research, such imitation can be dangerous. When language models mimic logic rather than exercise it, they risk creating a polished illusion of expertise, one that will avoid telling you it doesn't know a given thing and habitually conceals its own fallibility.

Financial analysis depends on trust and traceability. Analysts operate under constant pressure to deliver clear, timely insight from vast and shifting data sets. Automation promises relief from this strain, yet when AI tools deliver results without interpretability, they introduce a new problem. They accelerate confusion instead of clarity.

AI slop emerges when systems prioritise fluency over substance. It is partially the product of relying on probabilistic models rather than hybrid structures that can “understand” within a closed environment. The effect is easy to miss at first; the sentences read smoothly, the conclusions appear sound, but the logic that should underpin them is absent. In research and financial settings, this disconnect is more than bewildering and inconvenient, it is an issue of unnecessarily increased risk and time wasted on double-checking.

The solution is not to reject automation, but to redesign it. Progress will come from tools that enhance human thinking rather than replace it. This is the principle of Augmented Intelligence. It positions AI as a partner in reasoning rather than a substitute for it. Machines handle scale, speed and synthesis; humans provide context, interpretation and validation. Together, they form a system that is faster than the human could be alone, yet remains transparent and scrutable.

When applied to financial research, this approach creates an environment where every conclusion can be tested and every assumption examined. Analysts retain oversight of the process and automation becomes a trusted collaborator rather than a black-box magic 8 ball (i.e. opaque and mystically wise whenever it is not wrong). Transparency and velocity do not have to be mutually exclusive; they can reinforce each other. The faster a system operates, the more important it becomes to understand how and why it reaches its results. That metadata can be used to propel learning and advancement to the end of long-term, sustainable gains.

AI slop reflects the principle that true intelligence, in humans or machines, lies in the ability to explain decisions and adapt reasoning when faced with uncertainty. The next generation of financial AI must therefore prioritise transparency and comprehension alongside performance.  

Automation will (rightly) continue to shape how research is done, but the goal is not more and more automation; it is better automation. Systems that merge human discernment with computational precision will define the next phase of workplace and financial innovation. They will replace hollow speed with meaningful acceleration, producing insight that is both rapid and robust.

The future of AI in finance will not be measured by how much data it can process, but by how clearly it can think. That is the purpose of Augmented Intelligence and the standard to which Felix One aspires: delivering Clarity at the Speed of Thought.

Why Financial Research Needs More Than Just LLMs

Financial research cannot rely on LLMs alone. Moving from big data to smart data means combining language models with reasoning and BI principles to deliver insights that are rigorous, transparent and decision-ready. The institutions that make this shift will be better equipped to navigate complexity and act with confidence.

Financial institutions are facing an unprecedented flood of information. Market data streams arrive by the second, economic indicators shift daily, client communications generate vast amounts of unstructured content and research reports accumulate faster than most teams can process. The sheer scale of this material has created an environment where simply having access to data is no longer enough. What matters is transforming it into insights that are rigorous, reliable and decision-ready.

For years, business intelligence platforms have been the workhorses of data management, helping firms organise and visualise information. Now, with the rise of artificial intelligence, large language models (LLMs) such as ChatGPT and its peers have entered the conversation. Their ability to summarise, translate and generate text at scale has understandably caught the attention of financial professionals. Yet it would be a mistake to assume that these tools alone can meet the demands of financial research.

LLMs excel at detecting surface-level patterns in language and producing fluent text, but financial analysis depends on more than prediction. It requires reasoning, validation and the ability to connect signals across structured and unstructured sources. When billions are on the line, plausible-sounding answers are not enough. Decision-makers need confidence that insights are supported by evidence, traceable to source data and consistent with a coherent logic.

This is where the concept of moving from big data to smart data comes in. Smart data is not just information that has been aggregated; it is information that has been contextualised, validated and prepared for action. Achieving this shift means combining the strengths of LLMs with models designed for reasoning and action, sometimes called language reasoning models (LRMs) or language action models (LAMs). These systems can enforce structure, apply rules and ensure that insights are not only well phrased but also trustworthy.

For financial research, the implications are clear:

• LLMs are useful, but insufficient: they help manage volume, reduce time spent on repetitive tasks and create first drafts of analysis. But without reasoning and validation layers, their outputs risk being shallow or even misleading.

• Reasoning systems add rigour: by integrating BI principles and structured frameworks, LRMs and LAMs ensure that outputs can withstand scrutiny, align with compliance requirements and trace back to source evidence.

• Smart data enables better governance: financial institutions operate under strict regulatory oversight. Structured reasoning models help maintain auditability and transparency, which LLMs alone cannot guarantee.

For example, imagine an analyst tasked with understanding sectoral impacts of a sudden interest rate change. An LLM might summarise recent news and research reports quickly, but a reasoning-enabled system could go further. It could link rate changes to sector models, validate findings against historical data and flag inconsistencies with current economic forecasts. The result is not just a narrative but a structured assessment that a risk committee can act upon with confidence.

The future of financial research lies in this integration. Big data will continue to expand, but the competitive edge will belong to firms that can consistently transform it into smart data. That means building AI strategies that do not stop at surface-level pattern recognition but instead embed structured reasoning, validation and governance.

LLMs will remain part of the toolkit, but they must be complemented by systems capable of structured thought and decision support. Financial research is not about producing more words; it is about producing better judgements. The firms that recognise this will be best positioned to navigate complexity, manage risk and identify opportunities in a market that never slows down.

Artificial intelligence has moved from being a sector of investment to a practical toolkit that private equity firms are using across the deal lifecycle. From sourcing and due diligence through to value creation and exit planning, AI is influencing how funds operate and where they expect to capture value. Over the past two years adoption has accelerated. Limited partners are asking more questions, specialist AI funds have emerged and portfolio companies are beginning to integrate predictive and generative models into core operations. The discussion has shifted from whether AI is relevant for private equity to how quickly firms can adapt their playbooks. 

Trends Shaping Private Equity and AI 

One of the most visible developments is the dual role of AI. General partners continue to invest in AI-native companies such as vertical model providers, machine learning enabled SaaS and data infrastructure platforms. At the same time they are embedding AI into traditional portfolio companies to drive operational gains, margin expansion and cost efficiency. 

Deal sourcing is also undergoing rapid change. Natural language processing and machine learning tools can now scan filings, job adverts, patents and customer signals at scale, producing a more targeted pipeline. Early adopters report faster funnel conversion and higher quality outreach. 

Technical and data due diligence is now a standard component of the investment process. Buyers assess data quality, the robustness of existing models, and the maturity of machine learning operations. Weaknesses in these areas are increasingly treated as red flags that can affect valuation or even derail a transaction. 

In value creation, firms are moving toward AI-first operating playbooks. Pricing optimisation, churn prediction, demand forecasting and automation of back-office processes are among the most common applications. Some firms are building centralised AI centres of excellence or bringing in operating partners with machine learning expertise to accelerate rollouts. 

Competition is intensifying. Specialist funds focused on AI infrastructure, sector-specific applications in healthcare and fintech, and data-centric software have entered the market. At the same time the main constraints are shifting from capital to talent and data infrastructure. Access to clean, well-structured data and the ability to attract senior machine learning leadership often determines the pace of adoption. 

Alongside opportunity comes heightened risk. Concerns around explainability, transparency, data privacy, bias and cybersecurity are growing, particularly in regulated sectors. Limited partners increasingly want to understand how funds manage these risks and what governance structures are in place. 

Finally, pricing dynamics are evolving. While AI-driven improvements in revenue and margin can justify higher multiples, competition for attractive assets is fierce. Buyers without a clear operational playbook may find expected returns compressed. 

Implications for Firms 

For deal making, private equity teams should expand diligence capabilities to include data scientists and engineers able to review models and assess data lineage. Execution risk must be priced realistically, with earn-outs or conditional structures tied to actual delivery of AI-driven value. 

For value creation, firms will often see the highest return from practical use cases that are quick to implement. Automating repetitive processes or refining pricing strategies can yield results within a year. More ambitious projects requiring significant R&D can be pursued selectively but should not delay initial gains. 

Organisationally, the most effective model is often a lean centre of excellence that provides shared capabilities in data engineering, model deployment and change management. Recruiting or upskilling operating partners with relevant expertise is critical. 

Risk management frameworks should be established early. This includes versioning of models, monitoring for drift, maintaining audit trails and preparing incident response plans. Ethical guidelines and transparency policies help protect reputation and build trust with stakeholders. 

LP and GP Responses 

Limited partners are sharpening their questions. They want to know not just how firms intend to capture value through AI but also how risks are being managed.

General partners are responding in varied ways. Some have launched dedicated AI funds, while others are integrating AI mandates into growth or private credit strategies. Direct investments in infrastructure such as data platforms or MLOps vendors are also increasing, giving firms greater control over the ecosystem. 

A Practical Playbook 

For General Partners 

• Define a clear AI thesis that specifies whether the focus is revenue, cost or retention. 

• Run quick pilot projects that can show measurable ROI within six to twelve months. 

• Integrate AI diligence into the standard checklist and budget for remediation where data maturity is lacking. 

• Link earn-outs or incentives to actual AI-driven performance improvements. 

 For Portfolio Companies 

• Focus first on high-impact applications such as pricing, churn reduction and procurement automation. 

• Establish strong data governance practices early, since clean data compounds in value. 

• Combine AI initiatives with process change and adoption planning to ensure real operational impact. 

 For Limited Partners 

• Ask targeted questions about governance, technical capability and exposure to regulatory risk. 

• Assess whether the GP has sufficient access to talent and partnerships for implementation. 

• Evaluate the GP’s track record in operationalising AI across a portfolio. 

Outlook 

Artificial Intelligence is now central to private equity strategy. The firms that will emerge strongest are those that combine financial discipline with credible technical capacity, robust governance and repeatable operating models that can scale across a portfolio. Private equity is evolving into a discipline that integrates operational transformation with traditional buyout expertise. Success will belong to those who do not just invest in AI but who operate with it at the core of their approach. 

A new MIT study shows again that AI is not a panacea for stalled revenue or lost competitiveness, as some have claimed. This paired with IBM’s recent CEO Study, shows a clear message is emerging to the myriad stakeholders in enterprise AI; whilst generative AI has become a strategic imperative and near ubiquitous investment, its successful implementation is more elusive.

The burgeoning gap between AI capability and profitable utilisation makes clear that business fundamentals remain essential; the true differentiator is how and where AI is applied.

FortuneSheryl Estrada

IBM’s 2025 CEO Study: 5 Mindshifts to Supercharge Business Growth, surveying over 2,000 CEOs across 24 industries, outlines five conceptual “Mindshifts” intended to guide enterprise leaders through structural and operational change. Yet the most compelling insight lies not in the shifts themselves, but in the dissonance between executive belief and organisational readiness.

IBMTom Hogan

Unsurprisingly, 68% of CEOs believe that generative AI is fundamentally transforming their business models. 61% agree that competitive advantage will increasingly depend on their ability to adopt and scale it. However, 25% of AI initiatives have not delivered their desired results. The Issue is not willingness to implement but the actual use cases and methods that are being adapted.

At Felix Research, we interpret this divergence as validation of our central philosophy: the future of enterprise AI lies not in general-purpose automation, but in domain-specific human-centric Augmented Intelligence applications. The difference is nontrivial. Most Large Language Models currently deployed in enterprise settings are designed for maximum generality. The demand for purpose-built tools that champion human-in-the-loop principles remains neglected in the market.

The IBM report’s fourth Mindshift, Ignore FOMO, lean into ROI, speaks directly to this challenge. The data confirms that early adopters who rushed into AI pilots often did so without clear KPIs, governance, or integration pathways. Felix Research believes that the future of AI implementation will be with platforms that allow humans to focus on high value critical task using AI to handle routine functions. In turn, high-value research is generated, and ROI is clearly measurable.

The third Mindshift, Cultivate a vibrant data environment, is another area wherein the gap between vision and execution remains wide. Although 72% of CEOs consider integrated data architecture essential for AI success, actual approaches to achieve this shift are far and few between.

Perhaps the most important theme emerging from IBM’s report is that trust remains a structural constraint on AI adoption. Though not framed as a discrete Mindshift, it permeates each of the five. In high-stakes, research-rich fields, model transparency, auditability, and explainability are not optional, they are the bedrock of ethics-by-design and consequentially, sourcing, trust and functionality. There is little use for work you cannot trust.

IBM’s final Mindshift, Borrow the talent you can’t buy, may be the most telling. In a landscape where speed-to-deployment and domain expertise are both required, external partnerships are not a liability; they are a strategic advantage. There is a dearth of institution-grade tools, developed in close collaboration with project-based professionals, and tested against the real workflows it aims to support. Felix Research encourages you to watch this space.

IBM’s 2025 CEO Study provides a useful framework for assessing the future of AI adoption. But the study’s most important implication may be that generative AI alone will not produce transformation.

Only well-scoped, governed, and trusted AI systems, purpose-built for specific domains, will do so.

Felix One is that system.

The idea that technology should amplify, not substitute, human intelligence isn't new.

It was first proposed in 1960 by American psychologist and computer scientist J.C.R. Licklider in his seminal paper “Man-Computer Symbiosis”. Licklider envisioned a future in which humans and machines would form close working partnerships, with computers handling the mechanical tasks and humans focusing on creative, strategic thinking.

That vision came to life eight years later in what’s now called the “Mother of All Demos”. In a single 90-minute presentation, computing pioneer Douglas Engelbart introduced an astonished audience to the mouse, hypertext, graphical interfaces, real-time document collaboration, and even early video conferencing. But the real breakthrough wasn’t the technology, it was the mindset.

Engelbart’s purpose wasn’t to replace the professional. It was to augment them. He believed computers could help humans think better, work faster, and collaborate more effectively. It was a direct continuation of Licklider’s symbiosis; practical, powerful, and crucially human.

Today, as financial institutions adopt AI into research, analysis, and compliance, that original vision is more relevant than ever. We shouldn’t be asking whether machines can take over entire roles, but how they can remove the friction from work and free up professionals to do what they do best.

Augmented intelligence is not a new idea. But it's now here. And those who embrace it won’t just be more efficient. They’ll be smarter, faster, and ultimately, more human in the way they work.

The term “Augmented Intelligence” may sound like just another tech buzzword, but its origins speak to something deeper: a belief that AI should amplify human capabilities, not replace them. The concept is about using AI to support and enhance human expertise. It's not about handing over control, but making professionals more effective at what they already do best.

Let’s be honest: resisting AI is no longer a viable strategy.

The institutions that ignore or fear it are setting themselves up to be outpaced, outsmarted, and ultimately left behind. But the opposite extreme, treating AI as a complete replacement for human professionals is both technically flawed and strategically short-sighted.

Even the best models cannot yet fully replicate human judgment, insight, or instinct.

Man and machine; better than either alone

Imagine an analyst who no longer spends hours compiling fragmented data, manually formatting reports, or trawling PDFs. Instead, AI takes care of the heavy-lifting by surfacing insights, automating structure, and connecting dots. What’s left? More time for strategy, sharper insights, and faster execution. That is the power of augmented intelligence.

In short: AI shouldn’t replace the analyst. It should unleash them. The future of work is not artificial, it’s Augmented.