The first two posts covered: CLI vs MCP is a fight over pipes — what’s actually missing is the faucet (post one); Agent adoption is blocked by two layers of barriers — platform lock-in and organizational control (post two). This post looks at how different players are actually responding to those two walls.

Three Strategies

Faced with data barriers, three distinct strategies have emerged:

Strategy 3 has plenty of representatives. OpenClaw runs 24/7 on a Mac mini, and the community has built Skills for auto-generating daily standup reports[2] and financial statements. Perplexity launched Personal Computer[5] in March 2026, also running on a Mac mini, connecting to 40+ services including Gmail, Slack, GitHub, Notion, and Salesforce for $200/month. Anthropic’s Claude Cowork positions itself as a locally autonomous Agent. The demo videos show data flowing seamlessly across platforms.

These capabilities are real. But they all share one prerequisite: you already have API access to every tool involved. As analyzed in post two, that prerequisite simply doesn’t hold in most real work environments — platforms may not expose APIs at all, and even when they do, your company’s IT department may not approve access.

There’s a telling asymmetry worth noting: the same idea — having AI operate apps on behalf of users — is celebrated on the PC side (OpenClaw) while being actively blocked on mobile (Doubao Phone (ByteDance’s AI phone)), where WeChat, Alipay, and other major apps banded together to shut it down[6]. The reason is obvious: every app on mobile is a closed ecosystem, and a system-level AI assistant strikes directly at the heart of their traffic monetization.

Let’s focus on the first two strategies.

Strategy 1: Build a Closed Loop Inside the Wall — Alibaba’s Two-Front Push

Alibaba’s strategy is the clearest: don’t break down the walls — build the closed loop inside your own walls first. And they’re doing it on both the consumer and enterprise sides simultaneously.

Consumer Side: Qwen App — The Full “Search → Decision → Payment → Fulfillment” Chain

The “Qwen Do It” feature in the Qwen (Alibaba’s AI assistant app) App has already integrated the core consumer scenarios across the Alibaba ecosystem[^9]:

This isn’t a demo — Alibaba is putting real money behind making this closed loop work. The Qwen App’s “First Order of the Day” promotion[10] distributes 15 million coupons daily, covering food delivery, hotels, flights, ride-hailing, and movie tickets, with all payments processed through Alipay AI Pay. A user can say “order 30 cups of bubble tea for me” and Qwen handles the entire flow: understanding the request, selecting items, automatically claiming coupons, and landing directly on the checkout page.

Quantum Bit’s assessment: Alibaba has become “the world’s first tech company to open the full AI ‘search-decision-payment-fulfillment’ chain at scale”[9]. Technically, it’s built on MCP + A2A protocols with a multi-Agent architecture — a primary Agent breaks down tasks, and multiple sub-Agents execute independently within their respective domains.

Auth within the ecosystem is nearly invisible — on first use, you complete an OAuth-style account binding between Qwen and Amap/Taobao/Fliggy (similar to gh auth login), and every subsequent operation carries the session automatically. The entire Alibaba ecosystem shares the Alipay account system, so users never have to re-authorize.

Enterprise Side: Wukong — Enterprise AI Agent Platform

On March 17, 2026, Alibaba launched “Wukong (Alibaba’s enterprise AI agent platform)”[4], an enterprise AI Agent platform embedded inside DingTalk (Alibaba’s enterprise chat), which serves over 20 million business organizations. DingTalk CEO Chen Hang was direct about the positioning:

“Unlike every other lobster Agent on the market, Wukong is natively embedded in the enterprise organization.”

DingTalk, with its 800 million users, underwent a complete rewrite of its underlying codebase for this — a comprehensive CLI transformation[11]. Wukong natively operates DingTalk’s thousands of capabilities rather than simulating human clicks. Notably, this CLI was designed specifically for AI: commands can be long and detailed (AI doesn’t need to memorize them), and output is directly in JSON (AI parses structured data far more efficiently than reading formatted text). This validates the efficiency advantage of CLI for Agent tool-calling discussed in post one. Alibaba’s enterprise capabilities — Taobao, Tmall, 1688, Alipay, Alibaba Cloud — are being progressively integrated as Skills, with the first batch covering ten industry verticals[4]. AI Agents automatically inherit enterprise permission rules, bypassing the “organizational control” barrier analyzed in post two.

Ecosystem Comparison

Alibaba’s edge: closest to the transaction, and closed loops on both consumer and enterprise sides. The ultimate value of an Agent isn’t conversation — it’s completing the full chain of decision → execution → payment. Alibaba is currently the only platform that has made this chain work on both the consumer side (Qwen App) and the enterprise side (Wukong).

But There’s a Structural Tension Here

The essence of a private-ecosystem Agent: trading the convenience of AI for the user’s right to comparison-shop. Qwen can help you automatically claim coupons, bundle orders, and check out on Taobao Flash Buy — but it won’t tell you the same order might be cheaper on DoorDash.

Strategy 2: Climb Over the Wall — Scraping in a New Form

Rather than waiting for platforms to open up, some players are forcing their way through:

Several representative products have taken this route, each with different technical approaches but the same underlying logic:

AutoGLM (Zhipu AI’s mobile agent)[^7]: Gives AI a “cloud virtual phone.” The Agent runs inside a cloud VM, uses a vision model to understand screen content, and simulates human interactions to complete cross-app tasks (ordering food, booking flights, posting on Weibo). No API required — it just “sees” the screen.

Doubao Phone (ByteDance / UI-TARS)[^6]: A mobile GUI Agent, also vision-driven. A single voice command can handle everything from scheduling a dinner to booking the venue and syncing everyone’s calendars. After launch, it was blocked by WeChat, Alipay, and several other major apps. A phone that retails for ¥3,499 was being resold on the secondhand market for ¥36,000.

Manus[^8]: Each task gets its own dedicated Firecracker microVM (the same technology behind AWS Lambda). The Agent runs a browser, writes code, and manipulates files inside a full cloud sandbox environment, then delivers results when the task is done.

Different technical forms, same fundamental approach: bypassing the platform’s authorization system to access data and execute actions without going through the API front door. From scraping web pages to scraping screens to spinning up virtual machines, the techniques keep evolving — but the fragility and legal gray areas haven’t fundamentally improved. A UI redesign breaks everything. A platform ban shuts it down. Legal risk hangs over it indefinitely.

And “climbing the wall” isn’t just fragile — it’s dangerous. The OpenClaw security incident[1] is a cautionary tale:

• 10,000+ instances leaked user credentials due to misconfiguration
• 12% of community Skills were found to be malicious — injecting code, stealing data, establishing persistent backdoors
• 770,000 Agents were found to be vulnerable to remote hijacking

These aren’t code bugs. They’re inevitable consequences of the architecture — when you give an Agent shell access without authorization boundaries, security incidents are a matter of when, not if. This is also why MCP’s OAuth and permission isolation still have real value in enterprise contexts.

These products are genuinely pushing something important forward, but doing it in a way that’s unsustainable — not just technically, but from a security standpoint as well.

Analogy: The Evolution of Video Streaming

The Agent ecosystem today looks like video streaming in 2008 — delivering value to users on the back of “scraped” content (data). Users genuinely benefit, but the model isn’t sustainable.

Legitimization requires platforms to proactively open up — just as video streaming eventually moved toward licensing deals. But in the Agent world, that means platforms surrendering control over data, which strikes at the foundation of their business models.

What Forces Will Push Over the First Brick?

Not technology. Three things drive change:

1. The Irreversibility of User Expectations

If Alibaba’s closed-loop Agent gets there first, and users experience “say one sentence and get a hotel booked, flights arranged, and a route planned” inside the Alibaba ecosystem — going back to manually searching on other platforms becomes unbearable.

2. Regulatory Pressure from Outside

The EU’s Digital Markets Act (DMA) has already produced real enforcement results[^12]:

• 6 gatekeepers designated: Alphabet, Amazon, Apple, ByteDance, Meta, Microsoft (September 2023)
• First fines issued in April 2025: Apple €500 million (restricting App Store openness) + Meta €200 million (forced “pay or consent”) = €700 million combined
• Maximum penalty: 10% of global annual revenue (20% for repeat violations)
• Article 7 mandates interoperability for messaging services (WhatsApp and Messenger must support cross-platform messaging)
• Apple and Google have been forced to open cross-platform data portability (iOS 26.3 beta added a “Transfer to Android” feature)

China’s Personal Information Protection Law (PIPL), Article 45, also establishes data portability rights — users can request that their personal information be transferred to another processor of their choosing. But current enforcement has focused on privacy protection (cracking down on doxxing, facial recognition abuse, etc.), and there are no cases yet of data portability rights being used to force platforms to open data to third-party Agents.

The gap is stark: the EU is using fines to force openness, while China’s data portability provisions remain largely on paper. If China were to introduce enforcement comparable to the DMA, that would be the real turning point.

3. The Prisoner’s Dilemma of Competition

Just like UnionPay/NetsUnion (China’s payment clearing networks) opening up payments — nobody chose to open up voluntarily. It was driven by regulation, competition, and user expectations working together.

What Alibaba is doing right now looks, in the short term, like reinforcing its own walls. In the long run, it may actually be the first domino that knocks the walls down — because it creates a user experience gap that forces other platforms to follow.

So What Are We Waiting For?

The bottleneck in the AIGC era isn’t that AI isn’t powerful enough — it’s that data holders have no incentive to let AI make choices on behalf of users.

Because the moment an Agent can help users make optimal decisions, platforms lose their ability to manipulate user choices. The value Agents deliver to people’s lives and the threat they pose to platform profits are two sides of the same coin.

There’s no technical solution to this problem — it requires user expectations, regulatory pressure, and market competition to push it forward together. And those three forces are slowly building.

Where will the first brick fall? My guess: Alibaba’s closed-loop Agent creates an experience gap first, then competitive pressure propagates to other platforms, then regulation gives it a final push.

As for how long that takes — probably slower than the tech optimists think, and faster than the pessimists expect.

This is the third post in the “Thinking About the Agent Ecosystem” series. The core thesis of this series comes down to one sentence: **CLI vs MCP is a fight over pipes — what’s missing is the faucet.* The technology is all ready. We’re waiting for data holders to make their choice.*

References

[1]: OpenClaw security incident data from ScaleKit, “MCP vs CLI: Benchmarking AI Agent Cost & Reliability”, Mar 2026. Also cited in Skills vs MCP: The Token Efficiency War.

[2]: OpenClaw community Feishu integration Skills, including feishu-ai-dailyreport (automated team daily reports) and finance-report-analyzer (financial statement generation).

[3]: Microsoft AutoGen framework (55,000+ GitHub stars), unified with Semantic Kernel into Microsoft Agent Framework in Q1 2026. Early enterprise adoption cases include KPMG audit automation and BMW vehicle telemetry analysis. See Microsoft Agent Framework GA: Production Adoption Strategy.

[4]: Alibaba launched enterprise AI Agent platform “Wukong” on March 17, 2026, embedded in DingTalk, with Alibaba enterprise capabilities integrated as Skills. See Sina Finance report and Jinglin Xianghai in-depth analysis.

[5]: Perplexity launched Personal Computer on March 11, 2026 at the Ask 2026 developer conference, running on a Mac mini at $200/month (Perplexity Max subscription), connecting to 40+ services. See The Verge report.

[6]: Doubao Phone (ByteDance UI-TARS technology) launched a technical preview in December 2025, subsequently blocked by WeChat, Alipay, and several other major apps. A phone retailing at ¥3,499 was resold on the secondhand market for ¥36,000. See Sina Finance: “What Manus and Doubao Phone couldn’t do — why did a ‘lobster’ pull it off?”.

[7]: AutoGLM (Zhipu AI’s mobile agent): the world’s first mobile Agent, based on the GLM-4.5V multimodal model, using a “cloud virtual phone” architecture where the Agent runs in a sandbox. Open-sourced in December 2025 (Apache-2.0). See GitHub: Open-AutoGLM.

[8]: Manus: a general-purpose Agent platform where each task gets its own dedicated Firecracker microVM sandbox (2 vCPU, 8GB RAM), with the Agent running autonomously in a full cloud environment. Acquired by Meta in 2026. See Manus Sandbox core mechanism explained.

[9]: Qwen App’s “Qwen Do It” feature integrates Taobao Flash Buy, Fliggy, Amap, Damai, Alipay, and other Alibaba ecosystem services, enabling the full “search → decision → payment → fulfillment” chain. Built on MCP + A2A protocols with a multi-Agent architecture. See Quantum Bit, “AI is starting to ‘take action’ — and Alibaba’s Qwen is leading the world”.

[10]: Qwen App “First Order of the Day” promotion rules: 15 million coupons distributed daily, covering food delivery, snacks and groceries, hotels, movie tickets, flights, train tickets, and ride-hailing. Services fulfilled by Taobao Flash Buy, Damai, Fliggy, and Amap; payments and coupon redemption handled by Alipay. Data source: Qwen App promotion rules page (effective February 18, 2026).

[11]: DingTalk’s comprehensive CLI transformation: DingTalk, with 800 million users, completed a full rewrite of its underlying codebase and shifted entirely to a CLI architecture. Unlike the DOS-era CLI, this one is designed specifically for AI — commands can be long (AI doesn’t need to memorize them), and output is in JSON (structured data). See Tencent News, “DingTalk has gone fully CLI”; Chaoji Net, “DingTalk 2.0 major upgrade: full underlying code rewrite, comprehensive CLI command-line interface transformation”.

[12]: EU DMA enforcement data: first fines issued April 23, 2025 — Apple €500 million + Meta €200 million = €700 million combined. See 36Kr, “€700 million: EU issues first fines under the Digital Markets Act against Apple and Meta”; Security Insider, “The EU Digital Markets Act compliance exam is over — what did the six gatekeepers submit?”, March 2026. China’s Personal Information Protection Law Article 45 establishes data portability rights, but enforcement has focused on privacy protection; see the Supreme People’s Procuratorate’s typical cases of personal information protection procuratorial public interest litigation, January 2026.

Most web servers are built for clients whose security behavior is handled by mainstream general-purpose operating systems.
In that world, TLS handling by the web server is usually straightforward: one server name, one endpoint, one certificate chain, and broad interoperability across the signature schemes those stacks support.

The situation is different when clients fall outside that mainstream.
In IoT, device fleets, industrial gateways, legacy SDKs, or application-to-application integrations, clients often have hard restrictions on which server authentication algorithms, certificate public key types, and certificate signature schemes they can use.

One important subset of those cases concerns the signature algorithms supported by the client.
Cryptographic algorithms evolved over time, and different generations of clients ended up with support for different sets of algorithms.
As a result, one client may support only RSA, another may support only ECDSA, and a third may support both.

When implementing a web server that must serve all those clients, this creates a specific requirement for the server.
During the TLS handshake, it must inspect the client’s capabilities and present a certificate with a signature algorithm that the client supports.

This article is about how to handle that requirement directly in ASP.NET Core Kestrel, without moving certificate management into a reverse proxy, external gateway, or other edge tier.

Note: ASP.NET Core implementation, and most of the information available on this topic, focus on SNI-based certificate selection, where different server names map to different certificates, which is not the case here.
Because of that, most people and LLM-based AI assistants conclude that this scenario is impossible to implement in ASP.NET Core Kestrel.

Note: The reader should have a deep understanding of TLS, especially the negotiation phase of the handshake.

Visualization

The visualization below illustrates the exact case addressed in this article.
The backend exposes one endpoint and clients have different capabilities.

Open in mermaid.live

The Common Approach

This case is not unique and occurs frequently in some areas.
It is often addressed by offloading TLS certificate management to a dedicated edge service placed in front of the web server.
More specifically, that edge service is often a reverse proxy such as NGINX or HAProxy, a managed edge gateway such as Azure Application Gateway, or a Kubernetes Gateway implementation.

While this approach certainly works, it also brings drawbacks, such as:

• one more network hop,
• one more system to provision,
• one more failure domain,
• one more place where TLS configuration can drift,
• one more operational surface that costs money and must be managed.

In mutual TLS scenarios, this is even less attractive.
Once certificate negotiation and identity extraction move to an edge service, authentication logic gets split across services.
The edge service now owns part of the security model, while the application owns another part.
This is especially problematic in regulated or protocol-driven environments that require strict end-to-end client authentication and certificate binding at the application layer.
In zero-trust environments, it may also be unacceptable to leave traffic unencrypted between the edge service and the web server.

Visualization

Open in mermaid.live

The Optimal Approach

For the specific case discussed in this article, the optimal design is to keep certificate selection inside the application host.

That produces a much cleaner model:

• There is no extra hop and no extra failure point.
• TLS management stays with the host that actually owns the endpoint.
• Certificate selection is implemented exactly where the handshake happens.
• In mutual TLS (mTLS) scenarios, client certificate negotiation and application-side identity handling are in one place.

Visualization

Open in mermaid.live

How Certificate Selection Works During TLS

Before moving forward, it is important to clarify how server-side certificate selection works.

This process must occur during the initial phase of the TLS handshake: after the client sends ClientHello and before the server responds with ServerHello.

The server-side flow is as follows:

1. Receive the incoming TLS record.
2. Parse the record as TLSPlaintext and verify that it contains a Handshake message with a ClientHello body.
3. Extract the client capabilities relevant to certificate selection from ClientHello.
4. Select the appropriate certificate based on those capabilities and your server’s selection policy.
5. Respond with ServerHello and continue handshake, including Certificate message.

How to get client capabilities

To determine which certificates are compatible, the ClientHello message must be inspected.

The exact location of the information needed for certificate selection depends on the TLS version:

How the Server Chooses a Certificate

The actual certificate to present is chosen by considering both the client’s capabilities and the web server’s certificate selection policy.

The specific selection policy is determined by the server implementation and may depend on organizational requirements or security policies.

Typical strategies include:

• Prefer the certificate with the strongest algorithm supported by both server and client.
• Present a default certificate if it matches the client’s capabilities.
• If no compatible certificate is available, abort the handshake.

This is the core mechanism for dynamic certificate selection based on client capabilities.

Implement using ASP.NET Core Kestrel

Since ASP.NET Core 2.1, Kestrel provides the ability to configure TLS handshake behavior via HttpsConnectionAdapterOptions.

The HttpsConnectionAdapterOptions provides a ServerCertificateSelector property that allows configuration of a callback that is called during the TLS negotiation phase.

Historically, this API was designed for SNI-based certificate selection, where the server name influences which certificate is returned.
However, nothing prevents using a different certificate-selection logic, such as client capabilities provided in ClientHello and implementation-specific policies.

The method assigned to ServerCertificateSelector accepts an argument of type ConnectionContext.

The ConnectionContext implements the IMemoryPoolFeature interface, which exposes a MemoryPool property.

The MemoryPool property can be used to access the raw TLS records as bytes sent by the client during the handshake. The relevant TLS record is a TLSPlaintext struct that carries a Handshake message with a ClientHello body. This enables custom parsing of handshake data if needed.

Starting with ASP.NET Core 10.0, HttpsConnectionAdapterOptions also provides the TlsClientHelloBytesCallback property.
This callback enables inspection of the incoming ClientHello before the certificate selection callback is invoked.

These APIs provide all the necessary hooks to implement dynamic certificate selection in Kestrel based on client capabilities, not just SNI.

Reference Implementation

Everything required to implement the optimal approach described in this article has already been implemented by me in the following GitHub repository:

• tls-server-certificate-selection

This is not a toy demo.
The repository contains production-grade code for parsing ClientHello and extracting the data required for certificate selection.

It also contains tests that can be used to study the behavior in detail, including integration tests that show how to wire the mechanism into ASP.NET Core Kestrel.

More specifically, the repository provides:

• low-level parsing of ClientHello,
• extraction of the TLS data relevant to certificate selection,
• a reusable implementation that can be inspected independently from the article,
• Kestrel-based integration tests that demonstrate end-to-end certificate selection behavior.

The repository shows the implementation in full, with tests that make the behavior easy to verify and explore.

Conclusion

If you have one logical endpoint and heterogeneous non-browser clients, deploying an extra TLS tier should not be your default response.

When the requirement is simply:

• same host,
• same application,
• different certificate algorithms per client capability,

Kestrel can solve it where the problem actually lives: inside the server during TLS negotiation.

If you found this article useful, feel free to buy the author a cup of coffee ☕.

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:

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

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:

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 barrier[1].

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.

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:

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:

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:

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:

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.

Most AI agent demos look impressive.

They answer questions, generate content, and automate simple tasks.
**
But once you try to use them inside a real business workflow, things start breaking.**

This is where the gap exists.

The Demo vs Reality Gap

In demos:

Clean input
Clear output
No edge cases

In real systems:

Messy data
Incomplete inputs
Unexpected user behavior

AI alone can’t handle this reliably.

AI Agents Need Structure

A working AI agent is not just:

LLM + Prompt

It’s more like:

Input validation
Decision layer (AI)
Workflow execution
Error handling
Logging

Without these, your system is fragile.

Example: Lead Automation Flow

Instead of:
“AI replies to leads”

A better system:

Capture lead
Validate data
AI qualifies lead
Route based on conditions
Save to CRM
Trigger follow-up

AI is just one part of the pipeline.

Reliability > Intelligence

Developers often try to make systems smarter.

But in production:

Predictable systems win
Controlled outputs matter
Fail-safes are critical
Add Human-in-the-Loop

Fully autonomous agents sound great, but they fail in edge cases.

A better approach:

Add approval steps
Use fallback responses
Log uncertain outputs
Tech Stack That Works

In 2026, a practical stack looks like:

LLM (OpenAI / Claude / etc.)
Workflow tools (n8n, Zapier)
Backend APIs
Database for memory
Final Advice

Don’t build AI agents for hype.

Build them to solve specific problems.

Start small.
Test heavily.
Scale slowly.
For real-world AI automation use cases and systems:
https://bitpixelcoders.com

API free tier abuse happens when users exploit free credits or trial access to AI APIs for commerci

As developers, we’ve all been there: glued to a desktop, stuck in a repetitive loop of messaging Claude/Codex, waiting for AI responses, firing up the ADB Android emulator to test features, sifting through logs for bugs, and then replying to the AI again—only to repeat the cycle. It feels like our work is chained to a single screen, and stepping away means hitting a wall.
I asked myself: Why do we still rely on desktops for AI development, debugging, and agent management? All the work I do on my computer—monitoring AI tools, testing emulators, editing files—should be possible on my phone. But every existing tool I tried either forces me to use CLI/SSH (a desktop-first relic) or locks me into black-box automation that’s risky and unmanageable.

That’s why I built MobileVC—an open-source tool that breaks the desktop barrier, bringing full AI dev workflow control to your phone, with native touch/voice interaction and zero black-box risks. Let’s dive into what it does, why it’s different, and how you can start using it today.

What Is MobileVC?

MobileVC is an open-source mobile-first tool designed to free developers from desktop screens. It lets you manage your entire AI development, debugging, and agent workflow—all from your phone—without a single line of CLI input or SSH connection. Think of it as a “control center” for your AI agents (Claude, Codex, etc.) and remote computer, built for how we actually use our phones: tapping, swiping, and speaking.

Key Features (Built for Developers, By a Developer)

I built MobileVC to solve the exact pain points I faced daily. Here’s what makes it stand out:

1. Native Mobile Interaction (No More CLI/SSH)

Forget typing commands or struggling with SSH on a tiny phone keyboard. MobileVC adapts to how you use your phone:

• Chat directly with Claude/Codex in the app to assign tasks

• One-tap authorization for all operations (no more manual permission checks)

• Swipe cards to switch between development plans

• Use radio buttons to select plan modes—intuitive and fast

• Visual memory management panel: enable, disable, or edit AI memory with a tap

1. Voice-Controlled AI Editing

Typing on a phone to edit files or AI configurations is a chore. With MobileVC, just use voice commands like:

“Optimize this code file for readability”
“Modify this AI memory to include my project’s API key”

The app generates full, professional prompts for your AI agent, runs the edit, and lets you confirm all changes before finalizing. You stay in control—no hidden edits, no surprises.

1. Real-Time Backend Logs (Anywhere, Anytime)

Debugging doesn’t have to wait until you’re back at your desk. MobileVC lets you check backend logs in real time on your phone. Spot a bug? Sync the log directly to Claude/Codex and iterate instantly—no need to wait to get back to your computer.

1. Transparent Control (vs Black-Box Agents Like OpenClaw)

OpenClaw and similar tools are popular for their automation, but they’re essentially black boxes: you can’t see what’s happening under the hood, can’t intervene mid-process, and risk unexpected behavior or失控 (loss of control). MobileVC takes the opposite approach:

• Full transparency: See every step of your AI agent’s workflow

• Manual control: You approve every edit, every configuration change, every authorization

• No hidden risks: No “set it and forget it” chaos—you’re always in charge

Think of it like a car analogy (developers love these!):

• OpenClaw = Automatic Transmission: Fast and convenient, but you lose control when something goes wrong

• MobileVC = Manual Transmission: You control every gear, every step—safer, more predictable, and tailored to your needs

They’re not competitors—they’re complementary. Use OpenClaw for lightweight automation, and MobileVC for oversight, control, and remote management.

Quick Start: Deploy in 1 Minute (No DevOps Expertise Needed)

I wanted MobileVC to be accessible to every developer, regardless of their DevOps skills. Here’s how to get started:

1. Deploy the backend via npm (one line of code):
   npm install -g mobilevc-backend

2. Run the setup command and follow the on-screen prompts:
   mobilevc setup

3. Once setup is complete, you’ll get a URL and QR code

4. Download the MobileVC mobile app, scan the QR code, and you’re ready to go!

No complex dependencies, no server configuration—just 4 simple steps to start controlling your AI workflow from your phone.

Open Source & Contributing

MobileVC is 100% open-source (MIT License) because I believe great tools are built together. The code is available on GitHub, and I’m actively looking for contributors—whether you’re a frontend dev, backend dev, or just want to test and give feedback.

👉 Check out the GitHub Repo (MobileVC)

🌟 Star the repo if you find it useful

💬 Open an issue if you have ideas, bugs, or questions

🚀 PRs are always welcome—let’s make MobileVC even better together!

Closing Thoughts

As developers, we should be able to work anywhere—not just at our desks. MobileVC isn’t just a tool; it’s a shift in how we think about AI development: accessible, controllable, and mobile-first.

If you’re tired of being chained to your desktop, frustrated with CLI/SSH on mobile, or worried about black-box AI agents, give MobileVC a try. It’s built for you—for the developer who wants freedom without sacrificing control.

Let’s Connect!

Have questions? Want to share how you’re using MobileVC?
contact me and welcome to join me
github link: MobileVC

opensource #aidevelopment #mobileagent #adb #remotedevelopment #aidevtools #opensourceprojects #developerproductivity