This is the English edition of an article I originally wrote in Chinese, translated with AI assistance.
I started writing code in 2011 and moved to frontend in 2016. Looking back on the past decade, what I've built most, if I'm honest, is "entry points": login pages, home pages, nav bars, forms, onboarding pop-ups. We all took one thing for granted: if a user wants to get something done, they first open a piece of software, then learn its interface. Open a budgeting app to track expenses, open an editor to cut a video, open the CMS dashboard to publish a post. One task, one app. We've been trained on that habit for over twenty years, and it's become muscle memory.
Over the past couple of years, as AI arrived, most companies responded by stuffing AI into the entry points they already had: an "AI Assistant" button in the bottom-right corner of the editor, a chat box in the admin sidebar, an LLM API wired in behind it, and, for the more ambitious, a home-grown built-in agent. From a product-roadmap perspective, that makes total sense: users stay in my app, and retention stays in my hands.
But I'm increasingly convinced this road leads the wrong way. Not because it's executed badly, but because the direction itself is wrong.
Every App Ships Its Own Half-Baked Agent
Picture an ordinary user's day. They use AI summarization once in their notes app, AI reply once in their email, AI task breakdown once in their project management tool, and AI generation once more in their design tool. Four AIs, four chat boxes, four different prompting habits, and none of them knows what the others did.
The problem is that context gets shredded. The AI in your notes doesn't know what you promised in your email; the AI in your project tool doesn't know about the plan you already wrote in your notes. Each vendor only sees its own little slice of data, so each vendor's agent can only do its own little slice of work. Add the fact that most companies simply can't nail model calls, tool orchestration, long-running tasks, and permission confirmations, and what you usually end up with is a half-finished product that "can chat a bit, but can't be trusted when it counts."
What's even more awkward is that the user's learning cost hasn't dropped at all. They still have to remember which feature is hidden in which menu of which app; the only difference is that every menu now has a talking button next to it.
This is really just old inertia: AI is treated as a "new feature" rather than a "new entry point."
There Should Be Only One Entry Point
Here's my take: in the AI era, the primary users of software are no longer people operating interfaces directly, but agents doing work on their behalf. Entry points should converge onto a handful of official agents from the big players: ChatGPT, Claude, Grok, and in development, Cursor and Codex, with maybe a few more down the line. Everyone else building software shouldn't be building yet another entry point; they should be providing capabilities to these agents: plugins, Skills, MCP Servers.
Here's an analogy that isn't exactly flattering: the future agent is WeChat, and Skills and MCP Servers are mini programs. (If you're not familiar: WeChat is China's super-app, and third-party "mini programs" run inside it, so users never have to leave WeChat.) Users never leave that super entry point from start to finish; hailing a ride, ordering takeout, tracking a package all happen inside it. And those of us who build software live as guests inside that ecosystem. It doesn't sound dignified, but I think that's where things are headed.
I'm not saying this because I blindly trust big tech. I'm saying it because user behavior has already changed. More and more people would rather describe what they need in one sentence of natural language than spend half an hour learning how a piece of software works. That used to be wishful thinking, because software couldn't understand human language. Now agents can, and they learn software far faster than people do, provided you write the manual for them.
The division of labor among these building blocks is actually pretty clear:
A Skill is a manual written for the agent. It tells the agent what problem this software solves, when to use it, what steps to follow, and what it must never do. Anthropic introduced Agent Skills in October 2025, and in December released it as an open standard at agentskills.io. The format is dead simple: just a SKILL.md with a YAML header. At startup, the agent reads only the name and description, and loads the full text when it actually needs it. I love their own analogy: writing a Skill is like putting together an onboarding guide for a new teammate.
MCP is the agent's hands. The manual tells it how to do something; MCP tools let it actually do it: read state, create objects, start tasks, cancel and retry. Last December, MCP was donated to the Agentic AI Foundation under the Linux Foundation. The announcement noted more than ten thousand published MCP Servers, with ChatGPT, Claude, Cursor, VS Code, Gemini, and others already supporting it; OpenAI's Apps SDK is built directly on MCP too. At the protocol layer, there's basically no bet left to place. I'll cover what it can concretely do today in its own section below.
CLIs and APIs are the fallback execution surface: usable by humans, by agents, and by scripts and CI alike.
Authentication lives in the local keychain. Credentials shouldn't show up in the conversation, shouldn't show up in MCP parameters, and certainly shouldn't show up in logs. A local process fetches them on its own when needed.
You can still have a backend and a remote database. "Agent-first" doesn't mean "local-only," and it doesn't mean "no server." It just means the server no longer has to play the role of "entry point."
So what about the UI? The UI won't disappear, but it will shrink into a dashboard: a place to check status, review results, compare options, and give final sign-off. It's a dashboard for humans to look at, not a workflow machine for humans to click through step by step.
What MCP Can Do Today
A lot of people still think of MCP as "hooking up a few tools to a model," but it has changed quite a bit over the past two years. As I write this, the latest stable release is 2026-07-28, published on July 28, 2026; the previous one was 2025-11-25.
The basic architecture hasn't changed: a host (an app like ChatGPT, Claude, or Cursor) runs multiple clients, each client connects to one server, and messages travel over JSON-RPC 2.0. There are two transports: stdio for local, where the host launches your program directly, and Streamable HTTP for remote. The old HTTP+SSE transport is now officially deprecated.
The biggest change in this release is that the protocol is now stateless: the initialize handshake and Mcp-Session-Id are gone, and every request carries its protocol version and client capabilities in _meta. If you want to know up front what a server supports, you call the new server/discover. HTTP requests must also include Mcp-Method and Mcp-Name headers. In practice, this means an MCP Server can sit behind a load balancer and scale horizontally like any ordinary web service, and gateways can route and rate-limit based on request headers alone. For state across calls, the official recommendation is for tools to return explicit handles that the model passes back as parameters in later calls, which is the same idea as passing projectId and taskId around in content-studio.
Servers still offer three kinds of things: tools for the model to call, resources that provide data and context, and prompts as templates for users to pick from. Tools can declare an outputSchema and return structured results via structuredContent, or they can return a resource_link, handing over just a link to a resource instead of cramming all the content into the context. List results now carry ttlMs and cacheScope caching hints, making it easier for clients to cache tool catalogs.
On the client side, the thing most worth watching is elicitation: midway through executing, a tool can ask the user for a confirmation or an extra parameter. Form mode collects structured input; URL mode sends the user to an external page to handle sensitive operations, and the spec explicitly forbids using form mode to ask for sensitive information like passwords or tokens. In the new release, these requests all go through multi-round-trip requests (MRTR): the server returns input_required, and the client retries the original request with the user's answer attached. The "confirmation gate" I mentioned earlier already has a ready-made home in the protocol. Also, sampling, roots, and logging are marked deprecated in this release. They'll keep working for at least twelve months, but don't build new projects on them.
Authorization is based on OAuth 2.1. Servers must provide Protected Resource Metadata (RFC 9728) to tell clients which authorization server to use; for client registration, Client ID Metadata Documents are the preferred approach, and Dynamic Client Registration is now deprecated.
Beyond the core protocol there's also a formal extension mechanism, and three official extensions are most relevant to this article. The Tasks extension handles long-running work: the server returns a task handle, the client polls it with tasks/get, and responds with tasks/update when input is needed midway. Jobs that take a few minutes, like recording a video or running CI, depend on it. MCP Apps lets a tool declare a ui:// resource, which the host renders in a sandboxed iframe as a form, chart, or dashboard, so "the UI shrinks into a dashboard" can live right inside the conversation. Skills over MCP lets servers distribute Agent Skills via resources, so the manual can ship alongside the tools from the same server, though SDK and host support are still rolling out. On the distribution side, the official MCP Registry is a directory and API for public MCP Servers, currently still in preview.
My Own Practice: content-studio
Opinions are cheap, so let me use the open-source project I'm building, content-studio, as an example. It's built pretty much along these lines.
It's a local-first console for producing and publishing content: it reads a project's facts and the brief for a "publishing activity," produces articles, image posts, short updates, video scripts, and channel-specific versions, and then handles screen recording and downstream media production through tasks that are observable, cancellable, and retryable. The current deterministic compiler can generate content packs for 19 channels, and for a channel like Bilibili, a single activity can produce a short update, an image post, and a video script all at once.
The key is how it's exposed to agents. The repo has a plugin/ directory that, following OpenAI's plugin conventions, consists of three things: a .codex-plugin/plugin.json manifest, a skills/ directory, and .mcp.json. There are three Skills: onboard-project handles onboarding a project and confirming scope; produce-activity handles planning and version-by-version review of content; review-and-handoff handles publishing coordination and human takeover. The MCP Server is launched with content-studio-host mcp --stdio, runs over stdio, and doesn't listen on any port; if HTTP is needed, it binds only to 127.0.0.1. There are twenty-some tools, from get_project_view, create_publishing_activity, and save_activity_content_pack to start_production_task, get_task, cancel_task, and retry_task. They're all high-level, project-scoped operations, and none of them accept arbitrary scripts, selectors, or file paths.
There's a line in the produce-activity Skill that basically sums up this whole article: the agent conversation is the primary entry point for content drafts, video scripts, storyboards, and final sign-off; MCP stores versions, confirmation gates, tasks, and artifacts; the Workbench is only for viewing these projections at any time. It also deliberately spells out one rule: "having looked at the page" does not count as confirmation. Confirmation has to happen in the conversation, stated explicitly against the exact current version.
So that Vue 3 workbench is the dashboard I keep talking about. Dark background with a splash of bright neon green; it shows project overviews, publishing activities, a task panel, asset previews, and a human-takeover inbox. You can see recording receipts, preview frames, and failure reasons, and you can cancel or retry local production tasks. But it doesn't duplicate any generation, recording, compositing, or publishing logic; it shares the same core and application services as the CLI and MCP. One of the product principles I wrote down is blunt: headless is the foundation, UI is an enhancement. Without the UI, the tool can still run the entire workflow end to end. The few content-saving forms currently in the workbench are, as the README notes, just manual test entry points from before the AI/MCP integration.
I split actual channel publishing out into a separate repo, marketing-ops. It goes even further: the very first paragraph of the README says there's no web admin interface, the CLI is only for initial setup and diagnostics, and day-to-day work starts with a single natural-language sentence in Codex. It exposes only seven MCP tools, things like channels_status, publish_campaign, and get_publish_status. Bluesky App Passwords, DEV API keys, and Mastodon tokens can only be entered through a hidden-input terminal prompt; each one goes through a read-only identity check first and is then stored in the macOS keychain. The docs explicitly forbid passing credentials via command-line arguments, environment variables, JSON, chat, or MCP inputs. For channels without a suitable open API, like the Chinese platforms Juejin, Zhihu, and Bilibili, it falls back to "human takeover": the content pack is prepared automatically, and I handle login, CAPTCHAs, and that final "Publish" click myself on the official site.
Here's how I actually use it now: in Codex I say "prepare a publishing activity for such-and-such project, with a Juejin article and a vertical Bilibili video," and the agent reads the Skills, calls MCP, and pastes the drafts into the conversation for me to edit. Every so often I open that black-and-green dashboard to glance at task progress and the finished video. I barely need to remember what pages this software has, because I'm not its primary user. The agent is.
I should come clean: this project is still early. The README is clear about it: AI generation for articles, images, and video plans, along with a background AI executor, are still on the roadmap, and a one-click installer hasn't shipped yet. But its boundaries and shape are settled. Any capabilities added from here go into Skills and MCP, not into the UI.
Where This Idea Stops
I don't want to overstate my case. There are a few categories where using a UI directly is still better.
The first is creative and visual tools. Tweaking a curve, dragging a layer, listening to a mix: human hands and eyes are the fastest feedback loop, and describing "a tiny bit to the left" in natural language only slows you down. The second is high-frequency, precise operations, like hundreds or thousands of small adjustments in a spreadsheet, or cursor movement in an IDE; interfaces are optimized for exactly these scenarios. The third is games, and any software where the experience itself is the point. You don't want an agent playing for you.
Then there's an unavoidable problem: platform dependence. Handing the entry point to a few big companies means handing over distribution. How plugins get discovered, whether you can charge for them, who sets the ranking rules: we already fought over all of this in the App Store era, and mini programs made the cost of living inside someone else's platform crystal clear. The platform sets the rules, launches require review, the platform decides how traffic is split, and payments follow the platform's rules too. The agent era will only be more centralized, and living as a guest depends on the host being willing to keep you. My stance: bet on open standards at the protocol layer as much as possible. MCP and Agent Skills no longer belong to any single company. Keep capabilities local and on your own backend as much as possible, and keep the plugin package itself thin. That way, even if you switch agents one day, the migration cost is just rewriting a few manifests.
Finally, security and permissions. An agent that can act can also act wrongly, and content on web pages and in comments can smuggle in instructions at any time. In both projects I've been conservative: credentials never enter the conversation, tools don't accept arbitrary scripts or paths, generated content packs don't automatically carry publishing permission, every external write requires explicit authorization matching the current activity, and any unknown state fails closed. These constraints are written into the Skills and also into MCP's input validation. You need both layers.
These are all real problems, but they're questions of "how to do it well," not "whether to do it at all."
What This Means for Developers
If you buy that the entry point is migrating, then the center of gravity in building software should shift:
Write Skills as first-class documentation. Spell out when to use it, in what order, and what must never be done; that's far more useful than yet another onboarding pop-up. MCP and the CLI need to be stable, and tool granularity should follow business semantics. Don't expose a pile of low-level APIs as-is and leave the agent to guess. Make operations idempotent and let retries reuse the same identity, because the agent will retry. Make state readable: long-running tasks need events and receipts so the agent can ask "what's actually going on right now" instead of guessing from conversation memory. As for the UI, just do a solid job on the dashboard and review surface: let people see status at a glance and sign off at the key checkpoints.
As a frontend developer who has spent ten years building interfaces, saying "the UI will shrink into a dashboard" sounds a bit like talking myself out of a job. But honestly, I find it freeing: we used to pour enormous effort into teaching users how to use software. Now we can hand that job to the agent, and we just need to get the software itself right.
content-studio, the project mentioned in this article, is open source. Feel free to check out the code and open an issue: https://github.com/IllegalCreed/content-studio
Top comments (0)