Why Enterprise AI Agents Still Cannot Read Social Data

Enterprise AI has quietly split into two problems, and only one of them is being solved quickly. Reasoning has improved faster than almost anyone forecast. Retrieval has not. A model that can draft a competitive analysis in seconds is still, in most deployments, working entirely from documents somebody remembered to upload. Ask it what customers said about your product launch last week and it either declines or, worse, produces something plausible from training data that is months stale.

This is not a model capability problem. It is an integration problem, and social platforms are where it bites hardest. The tooling to connect an assistant directly to a live data source has improved enormously in the past two years. The commercial access sitting underneath that tooling has not moved nearly as fast, and the gap between the two is where most agent projects quietly lose momentum.

Enterprise agents reach internal systems easily. Public social data sits behind separate access controls and commercial terms.

The retrieval gap is now the bottleneck

Most enterprise agent projects begin with internal data because internal data is reachable. A CRM has an API your team already has credentials for. A data warehouse sits inside your own network. Wiring an agent to either is a normal engineering task with a predictable end date.

External public data breaks that pattern. It sits behind someone else's access controls, someone else's commercial terms, and someone else's rate of change. The result is a strange asymmetry in what deployed agents can do: they answer questions about your own operations well, and questions about your market badly. For a competitive intelligence or brand monitoring use case, the market half is the entire point, which is why so many of these projects stall after a promising internal pilot.

Why social platforms are the hard case

Public social data looks like it should be the easiest external source to reach. It is public, it is structured, and platforms publish documented APIs. In practice it is among the hardest, for three reasons that have nothing to do with your engineering team.

Start with access. Every major social media API is gated by approval rather than payment. Reaching X's API means an approved developer account before a single request, which turns a technical decision into a procurement timeline. Second, terms change on the platform's schedule, not yours, and an agent built against one access model can be repriced or re-scoped without warning. Third, the shape of the data is genuinely awkward: threaded conversations, quote chains and deleted content do not map cleanly onto the flat document model most retrieval pipelines assume.

None of these are unsolvable, and that is precisely why they get underestimated. Each one looks like a week of work in isolation. Together they turn a feature into a small programme with its own dependencies, and they surface after the budget is set rather than before, because nobody hits them during a proof of concept run against a handful of sample records.

What MCP actually fixed, and what it did not

The Model Context Protocol, released by Anthropic in late 2024 and since adopted well beyond it, addressed a real part of this. Before MCP, every assistant and every data source needed bespoke glue, so integration work scaled with the product of the two. MCP standardises that interface, and there is now a substantial catalogue of reference servers covering common systems.

What it standardised is the plumbing. It did not create access. An MCP server for a social platform still needs credentials, still pays for reads, and still lives inside that platform's terms. The practical consequence is that wiring an assistant to a source it is already entitled to read now takes minutes rather than sprints, while the question of who supplies that data, and on what commercial terms, is exactly as open as it was before. Teams that read MCP as solving access rather than integration tend to discover this late, usually after the demo has been shown to a stakeholder who now expects it to work at scale.

Three ways to close the gap: platform APIs, in-house collection, or data as a service

Enterprises have been buying alternative data for years in finance and market research, and the same three procurement routes apply here. They trade off along one axis: control against time.

Going direct to the platform gives you first-party terms and first-party support. X now describes its API as offering pay-per-usage pricing, which is a meaningful improvement on flat tiers for variable workloads, though the developer account requirement remains the gating step. Building your own collection is the second option, and it is almost always underestimated: the ongoing cost is not the initial build but the permanent maintenance of something that breaks whenever the source changes. The third route, and the one most enterprises land on, is data as a service: buying from third-party data providers who absorb that maintenance and bill per request, typically without an approval process. GetXAPI is one such option, at $0.001 per call with a standard call returning roughly 20 posts, which works out near $0.05 per 1,000 posts across 72 endpoints.

The questions worth asking before you commit

Four questions separate a pilot that ships from one that quietly stops.

How long from decision to first request? If the answer includes an approval queue, add it to the project timeline honestly rather than hoping. What happens when the terms change, and how much of your architecture assumes they will not? What does a bad month cost, modelled at the volume you expect in a year rather than today? And critically, what does the agent do when retrieval degrades? An agent that returns partial data without flagging it is more dangerous than one that fails loudly, because a confident answer built on two thirds of the evidence looks exactly like a good one.

Conclusion

The interesting constraint on enterprise AI has moved. It is no longer whether a model can reason over your market, it is whether anything in your stack can put your market in front of it. MCP removed a genuine layer of friction and made the integration itself close to trivial. It left the harder question untouched: which source, on what terms, at what cost, and how you find out when it stops working. Organisations that treat data access as a procurement decision with the same seriousness they apply to model selection will ship agents that answer questions about the world. The rest will ship very capable assistants that can only talk about the documents they were handed.