In the previous post we argued that the CLI vs. MCP debate is really a debate about pipes — and what’s actually missing is the faucet. This post digs one level deeper: even if you open the faucet, you probably still can’t connect to it. The reasons agents struggle in the real world are more structural than most people realize.

A Common Promise

“Let an agent automatically write your weekly status report — it reads your Git commits, Slack channel history, Jira ticket updates, and Google Calendar meetings, then generates a report your manager can actually read.”

This is the story agent products love to tell. It sounds reasonable — the data is all yours, you’re already using all the tools, you’re just automating what you’d otherwise do by hand.

But if you actually try it, you’ll find that only 1 out of 5 data sources works:

graph TB Agent["Agent: Write your weekly report"] Agent --> Git["Git log ✅
SSH key is local, works immediately"] Agent --> Slack["Slack messages ❌
Requires creating a Slack app and admin approval"] Agent --> Jira_t["Jira tickets ❌
IT has disabled Personal Access Tokens"] Agent --> Cal["Google Calendar ❌
OAuth app requires admin whitelist"] Agent --> Email["Email ❌
Corporate IMAP is blocked by security policy"] Git --> OK["✅ Accessible"] Slack --> Blocked["❌ Inaccessible"] Jira_t --> Blocked Cal --> Blocked Email --> Blocked style Agent fill:#6366f1,color:#fff style OK fill:#22c55e,color:#fff style Blocked fill:#ef4444,color:#fff

It’s not that the agent isn’t smart enough. It’s not that the CLI isn’t efficient enough. The data simply isn’t reachable.

There are, of course, some “workaround” approaches that try to bypass this limitation: browser extensions that piggyback on your login session to scrape Slack messages, RPA tools that simulate clicks to export Jira data, reverse-engineered wrappers around corporate email APIs. These can make a demo work. But they’re fundamentally web scrapers — a UI redesign breaks them, a security policy update kills them, and the legal exposure never goes away. Building a workflow on top of these approaches is building on quicksand.

We’ll take a detailed look at these “workaround” approaches and their limitations in the third post. For now, let’s focus on a more fundamental question: why don’t the legitimate paths work?

An Agent’s Real Capability Depends on Three Variables

graph LR subgraph "Agent capability = the intersection of all three" A["LLM reasoning ability
✅ Already sufficient in 2026"] B["Tool-calling efficiency
✅ CLI and Skills largely solved"] C["Accessible data scope
❌ Severely lacking"] end style A fill:#22c55e,color:#fff style B fill:#22c55e,color:#fff style C fill:#ef4444,color:#fff

The entire industry is racing to improve LLM capability and tool protocols. But the real bottleneck is data access. It’s like having a top-of-the-line race car and a perfect track — with an empty fuel tank.

Two Walls: Why the Data Is Out of Reach

“Data is inaccessible” isn’t a vague problem. It has two distinct walls, each with a fundamentally different character:

graph TB subgraph "Wall 1: Platform Lockdown" W1["WhatsApp, Amazon, DoorDash, TikTok
No open API
Their business model depends on keeping it closed"] end subgraph "Wall 2: Organizational Control" W2["Slack, Jira, Google Workspace
Platform has an API, but corporate IT won't approve it
You can see the data, but your program can't read it"] end W1 --> W2 W2 --> After["Once you have the data
Inconsistent formats? LLM can handle that
↑ That's engineering friction, not a wall"] style W1 fill:#ef4444,color:#fff style W2 fill:#f97316,color:#fff style After fill:#22c55e20,stroke:#22c55e

Wall 1 gets the most attention, but in practice, Wall 2 is the one most people actually hit.

Wall 1: Platform Lockdown

WhatsApp won’t ship a CLI. Amazon won’t open a price-comparison API. TikTok won’t give you access to its recommendation data. The previous post argued from a technical standpoint that CLI is perfectly capable of implementing OAuth (gh auth login is proof), so this isn’t a technical barrier1.

So why don’t they do it? Because data enclosure is the foundation of these platforms’ business models.

Once an agent can make optimal decisions on a user’s behalf — comparing prices, comparing ratings, searching across platforms — the platform loses its ability to steer user behavior through recommendation algorithms. That directly threatens the core revenue from advertising and traffic monetization.

A simple heuristic: whether a platform will open up to agents depends entirely on whether opening up serves its commercial interests.

Platform typeExamplesOpen to agents?Logic
Sells subscriptions / servicesGitHub, Notion, Vercel✅ Actively openMore agent integrations → users more dependent → more paid conversions
Sells traffic / advertisingWhatsApp, Amazon, TikTok❌ Locked downAgents help users skip recommendations → ad value drops
Sells enterprise softwareSlack, Microsoft Teams⚠️ Partially openRich bot ecosystem → enterprises more dependent on the platform

Wall 2: Organizational Control — Visible Doesn’t Mean Accessible

Here’s a concrete example. You open Slack in your browser at work and can see all your channel history and shared files. Now you want to write a script so an agent can read the same messages. You’ll discover you need to create a Slack App on the Slack API dashboard, request channels:history and channels:read scopes, and then submit it to your workspace admin for approval. The admin might ask what you need the permission for — and then deny you.

Data you can see in a browser is not necessarily data your program can read. The two paths use completely different authentication chains:

graph TB L1["Visual access
Can see it in a browser"] -->|"✅ You have this"| OK1["Using it every day"] L2["API access
Can extract it via programmatic interface"] -->|"❓ Not guaranteed"| Maybe["Requires an API token"] L3["Organizational authorization
Corporate IT allows you to call the API"] -->|"❌ Probably not"| Nope["Security policy blocks it"] style L1 fill:#22c55e,color:#fff style L2 fill:#eab308,color:#fff style L3 fill:#ef4444,color:#fff

Every day you open Slack to read messages, check Jira tickets, and read email — that’s visual access. Your browser holds the session, cookies are sent automatically, everything is seamless.

But an agent takes a completely different authentication path:

graph TB subgraph "Browser access" Browser["Your browser"] Browser --> Cookie["Cookie / Session
Sent automatically"] Cookie --> Server["Server returns data"] end subgraph "Agent / API access" AgentAPI["Agent / script"] AgentAPI -->|"requires"| Token["API Token / OAuth Credential"] Token -->|"requires"| IT["IT department approval"] IT -->|"requires"| Policy["Security policy allows it"] Policy --> API["API server"] end Browser -.->|"Two completely different paths"| AgentAPI style Browser fill:#22c55e,color:#fff style AgentAPI fill:#ef4444,color:#fff style IT fill:#f97316,color:#fff

Having the former doesn’t mean you have the latter. Agents can only take the latter path.

From the perspective of an ordinary developer (non-admin), here’s the actual API accessibility of common tools:

ToolVisible in browserCallable via APIWhere it gets stuck
Git (local)SSH key is local — no approval needed
SlackCreating a Slack App requires workspace admin approval for sensitive scopes2
Microsoft TeamsCustom apps require IT admin sideloading approval
Jira Cloud⚠️Depends on whether the company has disabled Personal Access Tokens
Corporate emailIMAP/SMTP typically blocked by security policy
Google WorkspaceOAuth apps require admin to whitelist them
Notion (personal)Personal Integrations don’t require workspace admin involvement3

The conclusion is clear: the only things you can freely access via API are local files, personal Git repositories, and personal Notion workspaces. Everything else is blocked at the organizational admin approval step.

This also explains a pattern: why is coding assistance currently the most successful agent use case? Because code lives in your local filesystem — no one’s permission required.

A Note: What Happens After You Get the Data?

Someone might ask: even if you break through both walls, the data is scattered across Git, Slack, Jira, email, and other systems in different formats — doesn’t that count as a third wall?

Honestly, with 2026-era LLMs, this isn’t a real barrier. Git log is plain text, Jira’s API returns JSON, Slack messages are structured data — as long as data can be converted to text, current models can read and synthesize it. Identity mapping (Git email ≠ Slack user_id) just needs to be told to the model once. Time alignment, semantic extraction, deduplication and categorization — these are exactly what LLMs are best at.

Inconsistent data formats are engineering friction, not an architectural barrier. They’re not in the same league as the first two walls (platform lockdown and organizational denial of access).

The only two things that actually block agents are: platforms that won’t open up, and organizations that won’t allow it. Once the data is in hand, the model can handle the rest.

The Real Boundaries of Agent Capability

Taking both walls into account, here are the true capability boundaries for agents in 2026:

Use caseTechnically feasibleActually usableBlocked by
Coding assistance (writing code, debugging)No wall — code is local
Search public information and summarizeNo wall — public internet data
Auto-write weekly status reportWall 2: Slack / Jira API permissions
Cross-platform price comparison (flights, hotels)Wall 1: Booking.com / airline sites not open
Customer relationship managementWall 2: CRM API requires IT approval
Auto-process emailWall 2: IMAP is blocked
Cross-platform content publishingWall 1: platforms don’t interoperate
Personal health data analysisWall 1: health apps don’t open up

Technically feasible across the board. Actually doable for almost none of them.

Conclusion

Your agent can’t help you — not because it isn’t smart enough. It’s because of two walls:

  1. Platform lockdown: Business models are built on data enclosures. They won’t voluntarily open their APIs. This is a commercial negotiation problem.
  2. Organizational control: Even when a platform has an API, your company’s IT security policy may not allow you to use it. This is an organizational management problem.

As for inconsistent data formats and the need to integrate information across systems — with current LLM capability, that’s just engineering friction, not a real obstacle. Once the data is in hand, the model can handle it. The problem is that the data never gets there.

And most agent product marketing never mentions any of this. It simply assumes “you have API access.”

Next time someone pitches you on “automating your workflow with agents,” ask two questions first:

  1. Does the platform provide an API for this data?
  2. Does my organization allow individuals to use that API?

Both need to be Yes for anything to actually work. In the reality of 2026, scenarios where both are Yes are still rare.


This is the second post in the “Thinking About the Agent Ecosystem” series. Next up: since the data is out of reach, who is working around it and how? Alibaba’s closed-loop ecosystem, Doubao’s screen-scraping phone agent, and what forces might eventually push things toward openness.


References


  1. On the relationship between platform data lockdown and business models, see MCP vs. CLI for AI Agents: The Answer Is Both and The MCP vs CLI Debate Is Missing the Point. The first post in this series argued from a technical standpoint that CLI is fully capable of implementing OAuth — so the reason platforms don’t open up is a business choice, not a technical limitation. ↩︎

  2. Creating a Slack App with sensitive OAuth scopes (such as channels:history, chat:write) requires workspace admin approval. See the Slack API documentation on scopes. Enterprise Grid workspaces enforce even stricter approval workflows for custom integrations. ↩︎

  3. Notion’s Internal Integration allows individual users to create integrations directly, without involving a workspace administrator; see the Notion API documentation. This makes it one of the few collaboration tools that supports personal-level OAuth. ↩︎