A big part of Bloomberg’s remaining hook is fixed income, they have the best data, they have structured it better than competitors, and they have such a strong network effect that people trading bonds will rely on it for pricing and trading even when it is wrong (and can be proven wrong). There is no single data source that can hook into any AI with the depth, breadth, and history of Bloomberg’s fixed income data, analytical tools, source documents, and data presentations in terminal.
They’re not unassailable, but I think much of the competition (Factset, Refinitiv, etc.) have tried to attack via the equities vector, and equity data, news and quotes, analysis tools are commodity products. AI won’t necessarily change that, not until someone can put together a high quality data source that can value bonds properly that can be plugged into AI
Agreed that Bloomberg has the largest dataset, and the longest history. But their share of market has declined since the 2010 peak. Since then, Tadeweb, Marketaxess, Trumid, the IDBs, ICE bonds, LTX and the rest (Algomi, Liquidnet, MTS, Neptune, Bondcliq, CBond, Bondblox) have all found varying levels of growth. Yes, their fragmentation is what makes Bloomberg one-stop shop attractive. But that has mostly been a market-structure and incentive problem that no one has bothered (or needed) to solve.
The market is too lucrative and too large to challenge Bloomberg directly; plenty of growth remains in each of their lanes. But the next decade will see consolidation in FI, as some network effects run away while others don’t.
BLP’ s competitors have repeatedly tried to compete with Bloomy as a data company. It really isn’t. It’s a marketplace and workflow platform. The data became consequence of that position. That’s why their FICC data is so strong. The street is littered with the corpses of those who’ve gone after Bloomy because they all fundamentally misunderstood what they were trying to compete with. Particularly Thomson Reuters.
I have always thought that BLP will never be displaced by a single competitor. If it happens, it will come from an open ecosystem where many companies/propositions compete from the inside out, within an open ecosystem. Each replacing a piece of the workflow rather than trying to recreate the entire Terminal.
I think that Mr. T is on an important point here. MCP and agentic AI may prove to be an important step in the direction of an open ecosystem, along with other real time and marketplace initiatives.
Yeah, I’m not a BBG fan (ex FactSetter here) but it’s amazing to me that nobody has figured out or has tried hard enough to figure out the fixed income piece. I guess the fragmentation of source data, and the collection thereof, is a lot to overcome. All things equal, I’ll buy the Bloomberg IPO when Mike “retires” and his charitable foundation needs to sell the company.
This analogy is very powerful. The shift from access via internal vendor Data loader to bespoke API to MCP as end use cases change is following the playbook exactly. It also points to the return of increased value to the equivalent of the App store developers in a way that is set to change how the entire data universe is viewed in financial markets as a whole. Straight to retail is an obvious route for FinApp developers
Long time reader, one of the best (if not the best) writers covering this space. We've been building a financial market data business for the last few years, so a lot of this resonates.
One thing I'd add from the supply side. MCP isn't a new pipe. It's a new way of interacting with, understanding, and consuming data. What it really gives us is flexibility. We can interact with the data in the most efficient manner for each use case.
Right now the industry runs on standardised APIs, feeds, and websockets. These are rigid by design for production level deliverability and scale. MCP lets us spin up client-focused custom endpoints and delivery methods on demand. It removes the constraint of being locked into a fixed API or websocket spec. The access pattern can shape itself to what the client is actually trying to do.
That plays out differently across two use cases. For individual developers, investors, and small teams, the MCP connector is often the whole product. It collapses the friction of getting to the data, and for that tier the flexibility is the value. Explore, connect, build, done. I expect that to keep growing, and we've seen this surge in the last few months.
For institutional and enterprise, MCP is the context and assembly layer. It's how a client explores the surface area, understands what's available, and figures out what the pipe should carry. But when they move to production, tracking entire markets or servicing users inside their own app (i.e. Perplexity Finance), the actual fulfilment still runs on API and custom delivery built for high volume and low latency.
I think, based on what I've seen so far, the fulfilment layer might not commoditise the way the argument implies. For certain use cases and client needs, sure, MCP does flatten things. If you're exploring, prototyping, or serving light usage, the access layer becomes interchangeable and the differentiation thins out. But for institutional scale it comes back to the underlying data itself, the licensing and redistribution rights, and the volume, latency, and reliability guarantees that let a client build a production product on top of you. That layer could be the sticky, hard to displace part, because those things are expensive to earn and easy to lose.
Some thoughts and questions I expect we'll see play out: does value migrate entirely to the orchestration layer? Or does a meaningful chunk stay anchored in the data, licensing, and delivery underneath it?
Excellent precision added through this comment. Thank you. I agree the big question is how value splits between orchestration and data layers.
One frame to use is that prior terminal-era orchestration within walled gardens accrued considerable value. The terminal was an orchestration product, focused on data within a single aggregator. It made multi-supplier data coherent within its UI by abstracting away a lot of complexity under the hood. We didn't have to call it orchestration because it was fully packaged; the orchestration was done to the information before it arrived at the user. The next frontier is now orchestration after information arrives at the user.
In the post-terminal era, the term orchestration is required because complexity at the user end, outside the terminal, has significantly increased. As you say, assembly is incredibly difficult. Multiple data vendors, multiple model providers, plenty of internal context and IP, and various decision and monitoring systems. No coherent single interface to make productive use of all of it frictionlessly. Will it apply to all financial user types? Yes, but not equally. Information overload is not a diminishing problem in any use case, so the opportunity will be plentiful.
If you can view old terminals as latent intra-vendor orchestration platforms, the next iteration is explicit inter-vendor orchestration. If so, would not a similar amount of value be captured by the new layer? If you are inclined to agree, I think the question can be refined to who does it compress to earn its keep - the data source layer or the old orchestration/terminal layer? My view is the latter.
Agreed, and you've touched on this in other pieces. FactSet and Refinitiv are the clearest examples. Both made multi-supplier data work inside their own workstations, and that's the exact job that compresses once an open protocol does the same thing across every source. They're likely more exposed than Bloomberg, having opened an MCP server and given up the interface. The proprietary datasets survive as backend inputs. It's the interface and the aggregation that compress.
I think there's value to be captured in the new layer, as well as in the data source and ownership layer.
Yes, value is till captured in the orchestration layer. Standing one up takes technical work, the infrastructure to run it, and a real grasp of market data and its nuances. It's become easier to build (relative to infrastructure and processes set up by incumbents over the past few decades), but it's still a value-add layer. It's just being approached differently now.
The second is sourcing and owning the data itself. What used to take teams sifting through filings by hand is much quicker now. Not in the naive sense of pointing an LLM at EDGAR and telling it to pull every filing and build a structure, that's the wrong approach and a waste of the model. But building the actual data infrastructure, with LLMs helping, is genuinely faster. Same quality, more speed and scale, far less overhead.
Exciting times to be in the space, and to see these changes first hand
Whatever comes next will likely not be limited to changing how existing data (Bloomberg, LSEG, etc.) are distributed and consumed but also in entirely new forms of data that don’t depend on today’s incumbents. The Comcast/Netflix analogy is one part of what new technologies did to filmed entertainment; the other half is YouTube and TikTok where the battle wasn’t over who captured value from Seinfeld reruns, and the behavior change wasn’t limited to watching Seinfeld weekly or all at once. Instead it was user generated video that bypassed the studios and Netflix alike, building a massive user base for YouTube; in TikTok’s case, it was the instrumentation of viewing itself that allowed for an algorithm to create massive viewership without any preexisting audience. YouTube didn’t need network back catalogues to capture attention;TikTok didn’t need to know who your friends were to make content viral. Together they are a new era of production and distribution of filmed entertainment free from shared studio/Netflix constraints.
What’s the comparison to financial information? If the broader analogy holds then the battle moves beyond today’s data and into data produced outside of institutions (YouTube creators) and behavior instrumented in new ways (TikTok’s algorithm). Prediction markets could be one possibility for market intelligence that bypass expert institutions entirely, a nascent version of the early years of YouTube ugc. Then there’s a world increasingly more instrumented by sensors and ai, where people, places, and businesses throw off new data that cannot be captured by today’s incumbents and will instead be utilized by new ai-native businesses. Something more like TikTok’s ability to inspect every aspect of online viewing and recommend content based on that granular understanding.
This second category - not Netflix and Comcast battling over who controls access to the same content, but YouTube and TikTok inventing entirely new forms of content and consumption - is where the promise of new technologies unencumbered by existing market structure lies. It suggests that there’s another chapter to this essay to be written that looks to the production and instrumentation of new data made possible by today’s technologies.
Thank you for such a thought provoking post. It’s incredibly refreshing to read pieces that lean into the history of tech and other industries to contextualize what’s happening in FS. This is a new corner of FS for me and I learned a lot.
I like the TCP/IP analogy, but I think it also points to one nuance. TCP/IP didn’t make discoverability a non-event - it standardized communication once you knew where to connect. The discoverability layer (DNS, search engines, hyperlinks, app stores, etc.) emerged separately.
Isn’t MCP in a similar position? It standardizes how agents interact with tools once they’ve found an endpoint, but discoverability still seems to depend on registries, marketplaces, or enterprise catalogs built on top of MCP rather than on the protocol itself. In other words, it feels like the protocol solves interoperability, while the ecosystem solves discovery.
Top 5 Push-Backs — The Terminalist, “Bloomberg’s Last Stand”
Great post by The Terminalist and I could not have made the piece much better. I do build in this space. A lot of right. Some of it deserves pushback, and I can push from experience rather than theory. My company runs an AI research platform. So rather than agree with the multitude of points I agree on, the only way to add value is to be a negative Nancy. Here goes:
Claim: Distribution 2.0 means a dataset only has to clear one bar, winning an agent's query.
Push back: There are two bars, and MCP lowered only the plumbing bar. The enterprise contract is the speed bump.
Claim: The layer commoditizes its complements and can't help it.
Push back: Comparison requires the client to keep paying two data vendors for the same data, and the whole point of the comparison is to cut one. I pay two transcript providers every day and even though they are the exact same transcripts their .json shape is different which means each adds value.
Claim: The orchestration layer's bring-your-own-contract model is where analysts will work from.
Push back: In a business model where the AI vendor sees your firm's name on every prompt is a major problem for investment firms. One of our selling points to investors, the AI’s will never know it is you, they will see your activity as ours…you’re anon.
Claim: MCP is the TCP/IP of financial data.
Push back: Correct on the tech mostly, but the TCP/IP handled public data, not data distributed by firm’s that want to be paid. Every data vendor I know that has an MCP requires a contract where you pay them. MCP is just a new pipe. Claude is just a new UI. Albeit a pretty good one.
Claim: Only the super-aggregating layer can govern agentic source selection.
Push back: That problem only exists when the AI can pick from anything, and it mostly goes away when it can only pick from sources a human or platform already vetted. You don't need a giant platform, you need a short list of good data sources. We get paid for that culling today.
All my best,
Drew
PS -- I've been away for a minute, so this might be caught/refutes in the comments I have not yet read. Either way, it was my first group of thoughts based on what I know.
Thanks for the thoughtful take Drew. I can see most of these as being solvable.
1- Are you referring to the legal side of enterprise contracts, the operational side of governance, or the technical mess post deployment?
2- Well, under consumption-based pricing, you do only need to pay for consumption. If 90% of terminal data isn’t used by the average user, there is immediate savings there, which can then be used to query 2-3 vendors for the 10% of their data needs. Even if that comes up to 30% of the prior contract, there is plenty of savings to bank. The promise of CBP is that it brings a future where consumers can have multiple providers for their specific data needs, rather than a single vendor providing a firehose of data they don’t need.
3- Anonymising the user and the firm making the query is a critical component, but also largely a solved problem within the privacy and security discipline. Would be trivial for the orchestration layer to implement.
4- Yes, MCP is a new pipe, and data vendors wanting payment do not change what MCP permits. It’s available to many primary sources for whom distribution infrastructure was previously difficult. TCP/IP made technical access easy, and MCP does the same. Both may still have legal access restrictions via manual contracts, but they are after all technical not legal protocols. We need more innovation in protocols that integrate contractual access, like CarbonArc and Brickroad.
5- Agreed, when supply side proliferates, what gains value is selection, curation and judgement. Core modules of the orchestration layer.
Thanks again for the pushback, always helps refine my thinking!
I sit in the camp where I see out-of-control AI costs as poorly wired implementation, bad user habits, insufficient guardrails by enterprises and CFOs and CTOs not putting the hard work in when approving deployment. That is slowly changing, and you only have to look at who is getting it under control and for what usecases to know what is possible. Posts by CEOs at Databricks, Coinbase, and Shopify are leading signals on the customer side. Further confirmed by posts by the founders of Cognition and Perplexity on the orchestration platform side.
Long time reader… I’ve been building in this space for a decade now — a YC-backed fintech, a L/S quant equity fund, and now GitHub for investment methodology.
You said to get in touch with you if we have novel thoughts on how to play this era of disruption. I have a playbook I’m building against (implemented through a harness). I would be interested in your thoughts and believe I may have some insight to add as well.
Interesting take - I agree Claude (and others) will change the economics for the incumbents, perhaps unfavourably because 1) switching costs are now smaller, from connector to connector, models are smart enough to swap out 'skills', end points, models in days not months 2) For the 1st time data plumbing is aggregated through one one protocol, so comparison between vendors is quick and easy - no bloated data lakes with hundreds of vendors data, and reduced data lineage on the client side 2) and permissively licensed challengers (like the ones you mentioned) will challenge premium pricing for the large vendors FDS, BBG, LSEG.
However, I disagree on full disintermediation, and my counter argument is around data provenance and entitlements. The App store analogy has one structural gap; apps never needed carrier permissions to reach a user, but agents do need vendor entitlements to reach licensed data. Every LLM query into market data still terminates at a vendor controlled authentication check (i.e. OAuth 2.0). More importantly, the orchestration layer can relay provenance but cannot remanufacture it. Only the data owner can attest where a bond yield came from a specific methodology, source and and timestamp, and that this user held the rights to use it that way.
The more unscripted the composition (which you rightly celebrate) the worse the problem gets for buy-side and sell-side firms that need to report a NAV, a stress test or a best execution trade. Compliance teams cannot sign off synthesis with invisible provenance, no traceability or auditability. And more importantly, Portfolio Managers won't trade on a source they can't trust or understand.
Plus, proprietary sources that are hard to replicate like hundred of journalists with boots on the ground, sit behind the same entitlement layer.
So in my view, the vendor's durable role isn't the interface or the bundle. It's being the entitlement and provenance authority the orchestration layer structurally requires, priced as a service rather than a gate. That may defend a smaller moat than the old one, I'll concede. Therefore, the question for me is around economics, the app developer gets more traffic through the store, but on whose terms? Your Spotify example cuts both ways. The music labels kept perfect legal containment and still became price-takers. Whether provenance authority carries enough scarcity to avoid that outcome is the bet my side of the industry is now making.
Would these be solutions the market eventually builds?
In a revised protocol, provenance and entitlements can be embedded into pass-through tokens, managed by the orchestration layer, not too dissimilar to how Apple Pay works. Visa and Mastercard want to ensure none of its cards are used unauthorised or go over limits. Apple Pay creates unique tokens per user to manage this anonymously, ensuring transactions are signed off with the right keys on each side. The challenge was getting enough market power as Apple had to bring Visa and MC to the table. Whether we see this in Distribution 2.0 remains to be seen.
Your second suggestion is on auditability and traceability. I don’t think either of them are unsolvable. I think agents can be forced into higher self-documentation standards than humans. We are not used to them as those aren’t the kind of agents the frontier labs are pushing for. But they soon will as they try to gain compliant, FS services adoption. Most harnesses self-document already, it's just not visible to the user.
On your final point, I think it will come down to whose positional power dominates. the orchestration layer, or the data layer. I don’t disagree with all the roles you’ve listed for the data layer, whether that sustains pricing power when higher order value is created above it - insights and decision is where we may differ in conviction.
A big part of Bloomberg’s remaining hook is fixed income, they have the best data, they have structured it better than competitors, and they have such a strong network effect that people trading bonds will rely on it for pricing and trading even when it is wrong (and can be proven wrong). There is no single data source that can hook into any AI with the depth, breadth, and history of Bloomberg’s fixed income data, analytical tools, source documents, and data presentations in terminal.
They’re not unassailable, but I think much of the competition (Factset, Refinitiv, etc.) have tried to attack via the equities vector, and equity data, news and quotes, analysis tools are commodity products. AI won’t necessarily change that, not until someone can put together a high quality data source that can value bonds properly that can be plugged into AI
Agreed that Bloomberg has the largest dataset, and the longest history. But their share of market has declined since the 2010 peak. Since then, Tadeweb, Marketaxess, Trumid, the IDBs, ICE bonds, LTX and the rest (Algomi, Liquidnet, MTS, Neptune, Bondcliq, CBond, Bondblox) have all found varying levels of growth. Yes, their fragmentation is what makes Bloomberg one-stop shop attractive. But that has mostly been a market-structure and incentive problem that no one has bothered (or needed) to solve.
The market is too lucrative and too large to challenge Bloomberg directly; plenty of growth remains in each of their lanes. But the next decade will see consolidation in FI, as some network effects run away while others don’t.
BLP’ s competitors have repeatedly tried to compete with Bloomy as a data company. It really isn’t. It’s a marketplace and workflow platform. The data became consequence of that position. That’s why their FICC data is so strong. The street is littered with the corpses of those who’ve gone after Bloomy because they all fundamentally misunderstood what they were trying to compete with. Particularly Thomson Reuters.
I have always thought that BLP will never be displaced by a single competitor. If it happens, it will come from an open ecosystem where many companies/propositions compete from the inside out, within an open ecosystem. Each replacing a piece of the workflow rather than trying to recreate the entire Terminal.
I think that Mr. T is on an important point here. MCP and agentic AI may prove to be an important step in the direction of an open ecosystem, along with other real time and marketplace initiatives.
Indeed, fixed income is quite a MOAT for Bloomberg! Equities can be done quite cheap these days and decent quality.
Yeah, I’m not a BBG fan (ex FactSetter here) but it’s amazing to me that nobody has figured out or has tried hard enough to figure out the fixed income piece. I guess the fragmentation of source data, and the collection thereof, is a lot to overcome. All things equal, I’ll buy the Bloomberg IPO when Mike “retires” and his charitable foundation needs to sell the company.
If only. Spitting out $3-4bn a year in fcf if not more. No need to sell
This analogy is very powerful. The shift from access via internal vendor Data loader to bespoke API to MCP as end use cases change is following the playbook exactly. It also points to the return of increased value to the equivalent of the App store developers in a way that is set to change how the entire data universe is viewed in financial markets as a whole. Straight to retail is an obvious route for FinApp developers
Long time reader, one of the best (if not the best) writers covering this space. We've been building a financial market data business for the last few years, so a lot of this resonates.
One thing I'd add from the supply side. MCP isn't a new pipe. It's a new way of interacting with, understanding, and consuming data. What it really gives us is flexibility. We can interact with the data in the most efficient manner for each use case.
Right now the industry runs on standardised APIs, feeds, and websockets. These are rigid by design for production level deliverability and scale. MCP lets us spin up client-focused custom endpoints and delivery methods on demand. It removes the constraint of being locked into a fixed API or websocket spec. The access pattern can shape itself to what the client is actually trying to do.
That plays out differently across two use cases. For individual developers, investors, and small teams, the MCP connector is often the whole product. It collapses the friction of getting to the data, and for that tier the flexibility is the value. Explore, connect, build, done. I expect that to keep growing, and we've seen this surge in the last few months.
For institutional and enterprise, MCP is the context and assembly layer. It's how a client explores the surface area, understands what's available, and figures out what the pipe should carry. But when they move to production, tracking entire markets or servicing users inside their own app (i.e. Perplexity Finance), the actual fulfilment still runs on API and custom delivery built for high volume and low latency.
I think, based on what I've seen so far, the fulfilment layer might not commoditise the way the argument implies. For certain use cases and client needs, sure, MCP does flatten things. If you're exploring, prototyping, or serving light usage, the access layer becomes interchangeable and the differentiation thins out. But for institutional scale it comes back to the underlying data itself, the licensing and redistribution rights, and the volume, latency, and reliability guarantees that let a client build a production product on top of you. That layer could be the sticky, hard to displace part, because those things are expensive to earn and easy to lose.
Some thoughts and questions I expect we'll see play out: does value migrate entirely to the orchestration layer? Or does a meaningful chunk stay anchored in the data, licensing, and delivery underneath it?
Excellent precision added through this comment. Thank you. I agree the big question is how value splits between orchestration and data layers.
One frame to use is that prior terminal-era orchestration within walled gardens accrued considerable value. The terminal was an orchestration product, focused on data within a single aggregator. It made multi-supplier data coherent within its UI by abstracting away a lot of complexity under the hood. We didn't have to call it orchestration because it was fully packaged; the orchestration was done to the information before it arrived at the user. The next frontier is now orchestration after information arrives at the user.
In the post-terminal era, the term orchestration is required because complexity at the user end, outside the terminal, has significantly increased. As you say, assembly is incredibly difficult. Multiple data vendors, multiple model providers, plenty of internal context and IP, and various decision and monitoring systems. No coherent single interface to make productive use of all of it frictionlessly. Will it apply to all financial user types? Yes, but not equally. Information overload is not a diminishing problem in any use case, so the opportunity will be plentiful.
If you can view old terminals as latent intra-vendor orchestration platforms, the next iteration is explicit inter-vendor orchestration. If so, would not a similar amount of value be captured by the new layer? If you are inclined to agree, I think the question can be refined to who does it compress to earn its keep - the data source layer or the old orchestration/terminal layer? My view is the latter.
Agreed, and you've touched on this in other pieces. FactSet and Refinitiv are the clearest examples. Both made multi-supplier data work inside their own workstations, and that's the exact job that compresses once an open protocol does the same thing across every source. They're likely more exposed than Bloomberg, having opened an MCP server and given up the interface. The proprietary datasets survive as backend inputs. It's the interface and the aggregation that compress.
I think there's value to be captured in the new layer, as well as in the data source and ownership layer.
Yes, value is till captured in the orchestration layer. Standing one up takes technical work, the infrastructure to run it, and a real grasp of market data and its nuances. It's become easier to build (relative to infrastructure and processes set up by incumbents over the past few decades), but it's still a value-add layer. It's just being approached differently now.
The second is sourcing and owning the data itself. What used to take teams sifting through filings by hand is much quicker now. Not in the naive sense of pointing an LLM at EDGAR and telling it to pull every filing and build a structure, that's the wrong approach and a waste of the model. But building the actual data infrastructure, with LLMs helping, is genuinely faster. Same quality, more speed and scale, far less overhead.
Exciting times to be in the space, and to see these changes first hand
Whatever comes next will likely not be limited to changing how existing data (Bloomberg, LSEG, etc.) are distributed and consumed but also in entirely new forms of data that don’t depend on today’s incumbents. The Comcast/Netflix analogy is one part of what new technologies did to filmed entertainment; the other half is YouTube and TikTok where the battle wasn’t over who captured value from Seinfeld reruns, and the behavior change wasn’t limited to watching Seinfeld weekly or all at once. Instead it was user generated video that bypassed the studios and Netflix alike, building a massive user base for YouTube; in TikTok’s case, it was the instrumentation of viewing itself that allowed for an algorithm to create massive viewership without any preexisting audience. YouTube didn’t need network back catalogues to capture attention;TikTok didn’t need to know who your friends were to make content viral. Together they are a new era of production and distribution of filmed entertainment free from shared studio/Netflix constraints.
What’s the comparison to financial information? If the broader analogy holds then the battle moves beyond today’s data and into data produced outside of institutions (YouTube creators) and behavior instrumented in new ways (TikTok’s algorithm). Prediction markets could be one possibility for market intelligence that bypass expert institutions entirely, a nascent version of the early years of YouTube ugc. Then there’s a world increasingly more instrumented by sensors and ai, where people, places, and businesses throw off new data that cannot be captured by today’s incumbents and will instead be utilized by new ai-native businesses. Something more like TikTok’s ability to inspect every aspect of online viewing and recommend content based on that granular understanding.
This second category - not Netflix and Comcast battling over who controls access to the same content, but YouTube and TikTok inventing entirely new forms of content and consumption - is where the promise of new technologies unencumbered by existing market structure lies. It suggests that there’s another chapter to this essay to be written that looks to the production and instrumentation of new data made possible by today’s technologies.
Thank you for such a thought provoking post. It’s incredibly refreshing to read pieces that lean into the history of tech and other industries to contextualize what’s happening in FS. This is a new corner of FS for me and I learned a lot.
This is an amazing comparison. As someone that worked inside this industry for more 14 years, I'm intrigued to see how they react.
Epic take, thought provoking as always, thank you!
MCP does not solve discoverability.
I like the TCP/IP analogy, but I think it also points to one nuance. TCP/IP didn’t make discoverability a non-event - it standardized communication once you knew where to connect. The discoverability layer (DNS, search engines, hyperlinks, app stores, etc.) emerged separately.
Isn’t MCP in a similar position? It standardizes how agents interact with tools once they’ve found an endpoint, but discoverability still seems to depend on registries, marketplaces, or enterprise catalogs built on top of MCP rather than on the protocol itself. In other words, it feels like the protocol solves interoperability, while the ecosystem solves discovery.
“the protocol solves interoperability, while the ecosystem solves discovery.”
Great take.
Top 5 Push-Backs — The Terminalist, “Bloomberg’s Last Stand”
Great post by The Terminalist and I could not have made the piece much better. I do build in this space. A lot of right. Some of it deserves pushback, and I can push from experience rather than theory. My company runs an AI research platform. So rather than agree with the multitude of points I agree on, the only way to add value is to be a negative Nancy. Here goes:
Claim: Distribution 2.0 means a dataset only has to clear one bar, winning an agent's query.
Push back: There are two bars, and MCP lowered only the plumbing bar. The enterprise contract is the speed bump.
Claim: The layer commoditizes its complements and can't help it.
Push back: Comparison requires the client to keep paying two data vendors for the same data, and the whole point of the comparison is to cut one. I pay two transcript providers every day and even though they are the exact same transcripts their .json shape is different which means each adds value.
Claim: The orchestration layer's bring-your-own-contract model is where analysts will work from.
Push back: In a business model where the AI vendor sees your firm's name on every prompt is a major problem for investment firms. One of our selling points to investors, the AI’s will never know it is you, they will see your activity as ours…you’re anon.
Claim: MCP is the TCP/IP of financial data.
Push back: Correct on the tech mostly, but the TCP/IP handled public data, not data distributed by firm’s that want to be paid. Every data vendor I know that has an MCP requires a contract where you pay them. MCP is just a new pipe. Claude is just a new UI. Albeit a pretty good one.
Claim: Only the super-aggregating layer can govern agentic source selection.
Push back: That problem only exists when the AI can pick from anything, and it mostly goes away when it can only pick from sources a human or platform already vetted. You don't need a giant platform, you need a short list of good data sources. We get paid for that culling today.
All my best,
Drew
PS -- I've been away for a minute, so this might be caught/refutes in the comments I have not yet read. Either way, it was my first group of thoughts based on what I know.
Thanks for the thoughtful take Drew. I can see most of these as being solvable.
1- Are you referring to the legal side of enterprise contracts, the operational side of governance, or the technical mess post deployment?
2- Well, under consumption-based pricing, you do only need to pay for consumption. If 90% of terminal data isn’t used by the average user, there is immediate savings there, which can then be used to query 2-3 vendors for the 10% of their data needs. Even if that comes up to 30% of the prior contract, there is plenty of savings to bank. The promise of CBP is that it brings a future where consumers can have multiple providers for their specific data needs, rather than a single vendor providing a firehose of data they don’t need.
3- Anonymising the user and the firm making the query is a critical component, but also largely a solved problem within the privacy and security discipline. Would be trivial for the orchestration layer to implement.
4- Yes, MCP is a new pipe, and data vendors wanting payment do not change what MCP permits. It’s available to many primary sources for whom distribution infrastructure was previously difficult. TCP/IP made technical access easy, and MCP does the same. Both may still have legal access restrictions via manual contracts, but they are after all technical not legal protocols. We need more innovation in protocols that integrate contractual access, like CarbonArc and Brickroad.
5- Agreed, when supply side proliferates, what gains value is selection, curation and judgement. Core modules of the orchestration layer.
Thanks again for the pushback, always helps refine my thinking!
Thought provoking as always. I’d be interested to know how you see this alongside the expected AI bubble….ballooning costs etc.
I sit in the camp where I see out-of-control AI costs as poorly wired implementation, bad user habits, insufficient guardrails by enterprises and CFOs and CTOs not putting the hard work in when approving deployment. That is slowly changing, and you only have to look at who is getting it under control and for what usecases to know what is possible. Posts by CEOs at Databricks, Coinbase, and Shopify are leading signals on the customer side. Further confirmed by posts by the founders of Cognition and Perplexity on the orchestration platform side.
Seems like founder mode ftw again :)
Idk if it’s just me, but today’s letter is very difficult to read due to the odd spacing :(
Ah didn’t realize it was on justified. Fixed!
Much much better. Thank you :)
Long time reader… I’ve been building in this space for a decade now — a YC-backed fintech, a L/S quant equity fund, and now GitHub for investment methodology.
You said to get in touch with you if we have novel thoughts on how to play this era of disruption. I have a playbook I’m building against (implemented through a harness). I would be interested in your thoughts and believe I may have some insight to add as well.
I also live between London and NY.
Have sent you a DM. Happy to chat.
Interesting take - I agree Claude (and others) will change the economics for the incumbents, perhaps unfavourably because 1) switching costs are now smaller, from connector to connector, models are smart enough to swap out 'skills', end points, models in days not months 2) For the 1st time data plumbing is aggregated through one one protocol, so comparison between vendors is quick and easy - no bloated data lakes with hundreds of vendors data, and reduced data lineage on the client side 2) and permissively licensed challengers (like the ones you mentioned) will challenge premium pricing for the large vendors FDS, BBG, LSEG.
However, I disagree on full disintermediation, and my counter argument is around data provenance and entitlements. The App store analogy has one structural gap; apps never needed carrier permissions to reach a user, but agents do need vendor entitlements to reach licensed data. Every LLM query into market data still terminates at a vendor controlled authentication check (i.e. OAuth 2.0). More importantly, the orchestration layer can relay provenance but cannot remanufacture it. Only the data owner can attest where a bond yield came from a specific methodology, source and and timestamp, and that this user held the rights to use it that way.
The more unscripted the composition (which you rightly celebrate) the worse the problem gets for buy-side and sell-side firms that need to report a NAV, a stress test or a best execution trade. Compliance teams cannot sign off synthesis with invisible provenance, no traceability or auditability. And more importantly, Portfolio Managers won't trade on a source they can't trust or understand.
Plus, proprietary sources that are hard to replicate like hundred of journalists with boots on the ground, sit behind the same entitlement layer.
So in my view, the vendor's durable role isn't the interface or the bundle. It's being the entitlement and provenance authority the orchestration layer structurally requires, priced as a service rather than a gate. That may defend a smaller moat than the old one, I'll concede. Therefore, the question for me is around economics, the app developer gets more traffic through the store, but on whose terms? Your Spotify example cuts both ways. The music labels kept perfect legal containment and still became price-takers. Whether provenance authority carries enough scarcity to avoid that outcome is the bet my side of the industry is now making.
Would these be solutions the market eventually builds?
In a revised protocol, provenance and entitlements can be embedded into pass-through tokens, managed by the orchestration layer, not too dissimilar to how Apple Pay works. Visa and Mastercard want to ensure none of its cards are used unauthorised or go over limits. Apple Pay creates unique tokens per user to manage this anonymously, ensuring transactions are signed off with the right keys on each side. The challenge was getting enough market power as Apple had to bring Visa and MC to the table. Whether we see this in Distribution 2.0 remains to be seen.
Your second suggestion is on auditability and traceability. I don’t think either of them are unsolvable. I think agents can be forced into higher self-documentation standards than humans. We are not used to them as those aren’t the kind of agents the frontier labs are pushing for. But they soon will as they try to gain compliant, FS services adoption. Most harnesses self-document already, it's just not visible to the user.
On your final point, I think it will come down to whose positional power dominates. the orchestration layer, or the data layer. I don’t disagree with all the roles you’ve listed for the data layer, whether that sustains pricing power when higher order value is created above it - insights and decision is where we may differ in conviction.