From Coding Agents to Digital Workforce: AI Applications Are Converging on a Single System Architecture

Walking through the Agent product booths at the Yunqi Summit, the most counterintuitive finding emerges: despite appearing across wildly different industries, they have all grown into the same underlying OS.

Qoder powers software development, QwenWork handles knowledge work, TinyFish drives Web browsing, WonderClip enables video production, and OpenSearch powers search and research.

Strip away the industry-specific applications, and their underlying structure shows remarkable convergence:

Context → Planning → Skill → Execution → Verification → Memory → Business Outcome

This is the unified system architecture that Agent products are converging toward.

⚠ This article uses the Alibaba Cloud ecosystem (Qoder/QwenWork/TinyFish/WonderClip/OpenSearch) as the on-site sample. However, the architectural judgments below apply equally to self-built scenarios, Huawei Cloud, AWS, Azure, and GCP Agent platforms—the seven-layer stack represents engineering structure convergence, not a private conclusion for any single cloud provider.

1. The Core of Agents Has Shifted from “Can Answer” to “Can Execute Continuously”

In the chatbot era, the system’s basic loop was simple: user input, model output.

In the Agent era, tasks can run for minutes, hours, or even longer. It needs to read files, use browsers, call APIs, execute code, wait for asynchronous tasks, check results, retry on failure, and save state.

A single prompt plus a model cannot accommodate all of this.

The system must start acquiring a Runtime.

The Legal Document Fill Out task showcased at QwenWork is highly illustrative: it runs in a standalone sandboxed container, with the agent equipped with a virtual desktop and access to document processing tools. Marketing Content Generation stacks multiple tools—PPT, images, lip sync, Python, Pillow, FFmpeg, and more.

The agent’s execution environment increasingly resembles a programmable computer—a work unit protected by sandboxing, capable of calling various runtimes and tools, and able to run tasks continuously without interruption. The sandbox container provides isolation, the virtual desktop offers visual operational capabilities, and tool calling enables the model to move from “talking” to “doing.” Only when this combination stabilizes can agents truly begin replacing the operational layer of human work, not just the cognitive layer.

Qoder’s “One Foundation” Is a Product Signal, Not a Buzzword

The Qoder booth featured this statement:

One workbench. Four entries. One foundation.

The top layer includes Workbench, CLI, IDE, and the JetBrains plugin, and can be extended with Cloud Agents and the Agent SDK.

But the real focus is the shared Foundation underneath.

If each entry point reimplemented its own Agent, the system would quickly become unmanageable. A more sensible approach is to build a common harness for task scheduling, permissions, tools, sandbox, memory, model router, and verification.

Each entry point is responsible only for adapting to different users and scenarios: CLI for programmers, IDE for developers, Workbench for non‑technical users, JetBrains for legacy‑code migration, Cloud Agents for asynchronous triggers, and the Agent SDK for third‑party integration. Underneath, the scheduling, memory, tool gateway, verification, and security models are all shared.

After abstracting from the scenarios above, I’ve broken down the Agent Stack into seven layers. The table below answers the most practical question any organization faces: which layers should be built in-house, which can be shared via open source or purchased, and which remain unclear.

Layer	Content	Investment Decision (2026 On-site Observations)
1. Entry	Web / CLI / IDE / IM / API / GitHub Issue / Enterprise Dashboard	Adaptation layer, don’t build in-house — Choose the entry form that best suits your users
2. Task	Goal / Spec / Context / Acceptance / Priority / Budget	Build in-house, but keep it lean — The Task contract is foundational; sloppy definition breaks everything downstream
3. Context & Memory	Enterprise knowledge, code knowledge, historical tasks, decisions, user preferences, current state	Must build in-house — Context is an organizational asset that cannot be purchased
4. Planning & Skill	Task decomposition, Skill selection, model selection, parallel execution strategy	Build Skills in-house, Planning can be outsourced — Skills are your competitive moat

5. Runtime & Tools

Shell / Browser / Computer Use / Filesystem / Git / Database / MCP / Enterprise API

Semi self-built — generic runtimes can leverage open-source stacks like Browser Use or Anthropic Agent SDK; however, the enterprise API gateway must be built in-house.

6. Verification & Recovery

Testing, rule validation, result evaluation, failure recovery, retry and rollback

Self-built — verification rules are tightly coupled with business logic, and off-the-shelf solutions simply won’t work.

7. Governance

Permissions, Secrets, Audit, Cost, Policy, Human Approval

Must be self-built — and designed from an engineering perspective rather than a compliance checkbox exercise.

Below are key takeaways for each of the seven layers, condensed into one sentence each:

Layer 1 — Entry. Whether it’s web, CLI, IDE, instant messaging, API, GitHub Issues, or an enterprise workflow console, these are all just entry points for tasks and generate zero business value on their own.

The Second Layer: Task

Goal, Spec, Context, Acceptance Criteria, Priority, and Budget all belong to the Task layer. A well-defined Task description should clearly articulate: what needs to be achieved, why it matters, what completion looks like, its priority level, and how much budget is available. If an Agent system lacks even one of these six fields, tasks start drifting aimlessly through the system.

The Third Layer: Context & Memory

Corporate knowledge, code knowledge, historical tasks, decisions, user preferences, and current state all reside here. Qoder’s on-site emphasis on Repo Wiki, Knowledge Graph, and Knowledge Cards are concrete manifestations of this layer—transforming “scattered facts” into “machine-retrievable assets.”

The Fourth Layer: Planning & Skill

The system determines how to decompose a task, selects which reusable Skills to leverage, identifies which steps require frontier models, and which can run in parallel. This layer is where the Agent truly begins to “think,” and where model capabilities are most intensively invoked.

Layer 5: Runtime & Tools. Shell, Browser, Computer Use, Filesystem, Git, Database, MCP, and enterprise APIs all belong here. This is the seam where an Agent truly connects with the outside world.

Layer 6: Verification & Recovery. Testing, rule validation, result evaluation, failure recovery, retries, and rollbacks.

Layer 7: Governance. Permissions, secrets, audit trails, cost control, policy enforcement, and human approval. This also encompasses finer-grained concerns—algorithm registration (algorithmic filing with regulators), model interpretability, error accountability, third-party dependency management, and cross-border data transfer controls—these are the hard constraints that heavily regulated industries (healthcare, finance, transportation, media, public safety) simply cannot bypass when deploying Agents.

Models run through everything, but models are no longer synonymous with the entire Agent platform. This is the most underestimated认知迁移 over the past two years—too many teams have spent excessive time benchmarking models, when the real determinant of whether a system can go into production lies in the other six layers.

Four, Browser Agent Fills the Gap Between Agents and the Real World

Products like TinyFish are highly representative of this category.

Many real-world business systems lack usable APIs, or require users to log into websites, interact with dynamic pages, fill out forms, switch between tabs, or download files. Traditional automation relies on Playwright or Puppeteer scripts, which break the moment a page changes. Browser Agent enables models to directly understand web pages and execute actions.

This capability fills a critical gap in the Agent Runtime: real-world web interaction.

An external link submission agent, operations agent, procurement agent, or research agent may all need to complete actions within websites.

But the real difficulty has never been “can you click a button.” Production systems must also address session management—how to handle Cookie/Token lifecycle and expiration; concurrency—how to synchronize operations across multiple tabs within a single task; failure recovery—how to resume after page crashes or network interruptions; duplicate submission prevention—how to avoid repeated action execution after network jitter; proxy—how to bypass geographic/IP restrictions; CAPTCHA—how to pass bot detection; permissions—how to isolate multiple accounts; and finally, “proving the task was actually completed”—how to verify that actions truly took effect.

Going a step further, indirect prompt injection represents the most realistic security threat for Browser Agents in 2026: OWASP ranks prompt injection as the top AI threat for 2026, and simply embedding hidden text in a webpage can trick an Agent into exfiltrating user cookies. There’s no complete architectural solution—teams can only make engineering trade-offs around sandboxing, action whitelisting, and ambient credential controls.

Browser Use also needs to be incorporated into the toolchain. Capabilities at the demo level are far from sufficient. An organization actually deploying Browser Agents in production would spend enough resources to build an RPA system from scratch.

So Browser Agents may look like applications, but they’re really part of the runtime.

Five, Verification Determines Whether Agents Can Gain Elevated Privileges

Agent systems follow a straightforward principle: the greater the autonomy, the stronger the verification and governance must be.

An Agent that can only draft emails has limited error costs.

An Agent that can modify production databases, commit code, allocate ad spend, or operate back‑office systems carries a fundamentally different risk profile.

A truly mature Agent platform must do more than just answer “what can it do?” It also needs to clearly articulate:

What it is allowed to access;
What it is allowed to modify;
Which actions require approval;
What audit trail is recorded for each step;
How it recovers from failures;
How the system verifies that a task has truly been completed.

Here’s an engineering judgment: if an Agent cannot provide verifiable evidence for each of its actions, its autonomy should be capped at the “advisor” role. In other words, autonomy is granted incrementally as capabilities are validated within a compliance framework, not unlocked by a feature list. An Agent that can call 100 APIs but cannot prove that each call achieved the intended outcome can only stay in the “advisor” role in heavily regulated domains such as finance, healthcare, or cross‑border data.

This is why Governance will become increasingly important in enterprise contexts—it isn’t just the compliance team’s concern; it’s a capability that engineering must design from the outset together with the Runtime.

Model Routers Are Becoming the Default Scheduler — Just Don’t Over-Provision Every Layer

Multi-model architectures are increasingly prevalent.

A valuable multi-model system isn’t just about giving users a dropdown to pick between GPT, Qwen, Claude, or other models.

A smarter approach: let the system route tasks automatically.

Reserve powerful models for complex planning and architectural decisions; use cost-efficient models for routine code implementation and text cleanup; apply multimodal models to vision tasks; route bulk classification to fast models; then bring back powerful models for critical reviews.

Underneath this is a straightforward engineering principle: different tasks have completely different “capability-to-cost” requirements. Using a frontier model for bulk classification is wasteful; using a fast model for architectural decisions leads to constant rework. Requesty published a telling figure in 2026: routing 70% of routine tasks to nano models, 20% to mid-tier, and 10% to frontier models can cut average per-query costs by 60% to 80% with almost no quality loss — this is a directional indicator; actual numbers vary by task type and routing strategy.

Models are increasingly becoming a schedulable compute resource. The Agent Platform handles dynamic trade-offs between quality, speed, cost, and risk.

Example of tiered routing in practice: When an Agent receives the task “analyze competitor pricing strategy and provide recommendations,” it uses a powerful model for the steps of understanding the task, breaking it down, and determining priorities. Then it switches to a fast model when it comes to classifying 100 SKUs into price ranges. Once the classification is complete, it switches back to the powerful model for the final comprehensive judgment.

If you route all tasks through the most expensive model, system costs skyrocket. If you route everything through cheaper models, you’ll keep failing at complex nodes. The real engineering value comes from the scheduling strategy, not from choosing which model to use.

Seven, Skills Are the Key Layer Connecting the General Runtime to Vertical Business—and the Future Moat

A general-purpose Agent Runtime has no business value on its own.

It needs to engage with real-world scenarios through Skills.

Coding Skill knows how to read Repos, write Specs, run Tests, and generate PRs. It defines when unit tests must be run first, when they’re allowed to be skipped, what fields the PR description must include, and which changes require manual Review.

SEO Research Skill knows how to find keywords, analyze Search Intent, verify competition intensity, generate content outlines, and confirm that pages have been indexed. It’s not just “do keyword research”—it’s an entire workflow.

E-commerce Creative Skill understands brands, SKUs, platform formats, compliance requirements, and review processes. It needs to be aware of image dimension limits, prohibited terms, category qualifications, and the final audit workflow before ad deployment.

Ops Skill knows how to inspect monitoring dashboards, logs, containers, databases, and execute rollbacks. It must be able to distinguish which alerts can be handled automatically versus those requiring human intervention, and what constitutes a safe rollback point.

A Skill is more than a SOP—it is an executable asset equipped with version control, dependency management, iteration tracking, and failure safeguards. Drawing from Anthropic’s Skills protocol released in October 2025, each domain of expertise can be packaged into a SKILL.md folder, allowing different Agent platforms to load it on demand rather than recreating it from scratch every time.

Skills bridge generic execution capabilities with domain knowledge.

Consequently, the moat for many future AI applications will lie in Domain Skills that have been validated across a large volume of real-world tasks. These Skills embody “how things get done in this field”—they cannot be easily overtaken by new models or replaced by new platforms, and instead appreciate in value over time.

Learn AI Slowly — AI Adoption Insights for the Enterprise

An organization that continuously accumulates Skills—treating every new task as an incremental update to its Skill library—is not buying AI capability, it’s growing it.

8. Industry Lens: How Four Types of Organizations Put AI into Practice

What follows isn’t narrative—it’s mapping the abstract “seven-layer Stack” to specific industries to see where the bottlenecks differ.

Telecom / Carrier: Plan changes, enterprise circuit provisioning, and cross-domain fault localization all require traversing multiple systems—BSS, OSS, CRM, and billing. The biggest pain point for Agent deployment is cross-domain reconciliation—when an Agent modifies a customer’s plan in the CRM, it must simultaneously notify billing and OSS, otherwise accounts won’t align at period close. On the Stack, the most valuable layers are Layer 5 (Runtime & Tools, for unifying multi-domain interfaces) and Layer 7 (Governance, for financial auditing).

Financial/Banking: Risk control, anti-money laundering, reconciliation, and regulatory reporting all demand explainability, auditability, and traceability. Every “approval” or “rejection” made by an AML Agent must be traceable to a specific rule, transaction history segment, or piece of customer documentation. The most critical layers in the Stack are Layer 6 Verification (explainable evidence chain) and Layer 7 Governance (algorithm registration + cross-border data control) — under China’s financial regulatory framework, these two layers are hard prerequisites for going live, not optional add-ons.

Manufacturing: MES, ERP, QMS, and SRM have long operated in silos, and cross-domain decision-making (such as “given insufficient capacity, should we place additional material orders?”) requires coordination across all four systems. In manufacturing, an Agent’s practical role is as a cross-system orchestration layer, not as a replacement for any individual system. It simultaneously reads material data from ERP, defect rates from QMS, capacity utilization from MES, and supplier performance from SRM to reach a comprehensive judgment. The most valuable layers in the Stack are Layer 5 Runtime (enterprise API gateway) and Layer 3 Context (accumulated process knowledge, historical failure records, and shop floor experience).

E-commerce: Large-scale promotions span multiple domains (ordering, payment, inventory, logistics, customer service), involving stress testing, inventory consistency, anti-fraud measures, and cross-platform reconciliation. The earliest Agent implementations in e-commerce are creative operations (swapping product images, changing backgrounds, generating multilingual assets) and customer service agent assistance. The most valuable layers in the Stack are Layer 4 — Skill (compliance and review workflows for each platform SKU/channel) and Layer 6 — Verification (automated checking of whether materials meet platform standards).

Common ground across all four types of organizations: the lower the Stack layer, the more worthwhile it is to share; the higher the layer, the more worthwhile it is to build in-house. Foundational capabilities like Runtime, Model Router, and Tool Gateway are more cost-effective when developed collaboratively or sourced from mature open-source stacks. Skill, Context, and Governance, however, must be built in-house because they’re tightly coupled with business operations, compliance requirements, and organizational assets.

9. The Final Product May Look Completely Different on the Surface, Yet Shares the Same Underlying OS

A Coding Agent and a Video Agent have entirely different UIs, user bases, and business models.

But underneath, both require: Context, Task, Skill, Tools, Runtime, Verification, Memory, and Governance — and ultimately, both must deliver tangible business results.

An enterprise knowledge Agent and a Browser Agent may seem worlds apart, but at the end of the day, both have to tackle the same underlying challenges: permissions, state management, failure recovery, and audit trails.

That’s why when you’re building multiple AI products, it’s worth drawing a clear line between two layers.

Keep the top layer vertical. Each product centers on a complete Job, with its own user experience, data objects, and business metrics. A Coding Agent works with Repos and Code Reviews. A video Agent works with Scripts and Assets. A research Agent works with Sources and Citations. The vertical depth in each of these domains can’t be substituted by general-purpose capabilities.

Make the bottom layer as shared as possible. Agent Runtime, Model Router, Tool Gateway, Memory, Audit, Secrets, and Evaluation can all be built as common infrastructure.

This approach does double duty. It keeps each product from reinventing the wheel, and it prevents you from building a massive “do-everything Agent platform” with zero users right out of the gate—which is a trap that caught a lot of teams over the past two years. Trying to nail all use cases at once means none of them ever reach usable depth.

The more stable path is to first validate value through concrete tasks, then extract the underlying capabilities that repeatedly surface. The reasoning behind this: the general-purpose layer can only grow from specific scenarios, not from an architecture diagram. Designing a Runtime that “supports all scenarios” from the start typically means you’ve failed to do justice to any one scenario.

Three Reverse-Check Questions (use after writing to compare against your own work)

Has the Runtime we’ve abstracted been validated for generality across at least two concrete scenarios?
Does each layer of our design correspond to a real business problem that has actually caused errors?
If we had our budget cut in half today, which layers would we still keep? If the answer is “context and skill,” the direction is right; if it’s “runtime and gateway,” it might be time to go back to the drawing board.

This is also the long-term takeaway I left CloudTown (Yunqi) Conference with: a new system layer is growing above the model. It’s not tied to any single product, but is gradually becoming the OS of the Agent era. Whoever solidifies this OS layer first will be better positioned to reap the rewards in the next product iteration.

Implications for Decision-Makers

If you’re the AI lead (CDO/CIO/CTO) at a company with annual revenue exceeding 5 billion RMB, there are three things you can start on right now:

Take a Snapshot of Your Organization’s Current Seven-Layer Agent Stack

Before rushing to buy new tools, map out what you currently have at each layer—whether it’s a gap, an off-the-shelf solution, or something in between. This diagram alone will reveal your real bottlenecks.

Pick One High-ROI Use Case and Build Out a Complete Vertical Loop

Resist the urge to build a platform first. Choose one of these: Coding Agent, customer service augmentation, or R&D assistant. Run the full cycle through Context, Task, Skill, and Verification layers, then talk about platform construction.

Elevate Governance to an Engineering Discipline—Don’t Treat It as Compliance

Permissions, audit trails, explainability, error attribution, and third-party dependency management should be designed alongside your business agents from day one. Don’t retrofit them later.

Frequently Asked Questions

Q1: How does this seven-layer Stack differ from the multi-agent orchestration frameworks that Gartner and IDC talk about?

Gartner and IDC focus on inter-organizational multi-agent collaboration and governance. The seven layers described here represent the internal engineering architecture of a single agent. An organization can work on both levels simultaneously—the seven layers for individual agents, and orchestration for how multiple agents interact. The Stack is micro; orchestration is macro.

Q2: Why isn’t the model layer a standalone layer?

Because models function as horizontally distributed resources across the Agent system, rather than occupying an exclusive layer. Model Router treats different models as various computational resources to be dispatched, placing them on the same level as Shell and Browser within the Runtime—“tools” with equivalent standing. While models are undoubtedly critical, they shouldn’t monopolize the Agent’s complexity.

Q3: Should small teams skip this layer entirely and use end-to-end products like ChatGPT or Claude?

Yes. Teams with annual revenue below 100 million and low organizational complexity will find it more cost-effective to use off-the-shelf Agent products (Browser Use, Manus, Alibaba Cloud Bailian Agent, etc.). The seven-layer framework discussed in this article emerges from the question of whether organizations with annual revenue exceeding 5 billion should build their own Agent platforms—for small teams, constructing a platform would be reverse optimization.

Reverse Self-Check (For You, and For Myself)

If you find yourself nodding to any of these three statements, you may be getting carried away by the narrative rather than following the evidence:

Learn AI Slowly

“Strong models will make Agents work autonomously.” (Models are necessary but not sufficient—the upper layers of the stack determine production readiness.)
“We need a one-size-fits-all Agent platform.” (The cost of this approach will most likely exceed any business value it delivers within six months.)
“Skill development can wait until models stabilize.” (Skills are organizational assets—every day of delay is a day without compounding returns.)

If you don’t agree with all three statements above, keep reading.

References

(Individual citations with evidence hierarchy and stance annotation)

“One workbench. Four entries. One foundation.” —From the official Qoder booth materials and blog at the 2026 Cloud栖 Conference, plus the article “Introducing Qoder 1.0” published on Alibaba Cloud Community on 2026-08-31. Evidence level: Vendor claim (Alibaba’s position).
QwenWork Legal Document Fill Out: Sandbox Container + Virtual Desktop + Tool Invocation —From the Alibaba Cloud QwenWork live demo, as documented in the Alibaba Cloud Community article dated 2026-09-25. Evidence level: Vendor claim (Alibaba’s position).
QoderWake as a “Digital Employee” product, released by Alibaba on 2026-04-30 —From the Baidu Encyclopedia entry on Qoder and Alibaba’s official channels. Evidence level: Vendor claim (Alibaba’s position).
OWASP 2026 Threat List Ranks Prompt Injection First — State of Browser Use, May 2026 roundup (Michael Livs blog). Evidence level: Third-party synthesis (OWASP position, industry consensus).
Requesty: Tiered Routing with a 70/20/10 Allocation Can Cut Costs by 60–80% — Requesty official blog, 2026. Evidence level: Vendor claim (model routing provider perspective; figures are optimistic, to be used only as a directional indicator).
Microsoft Agent Governance Toolkit (AGT), open-sourced under MIT on 2026-04-02 — reported by niteagent.com. Evidence level: Third-party synthesis (Microsoft position; however, AGT is an open-source project with verifiable numbers).
Anthropic Skills Protocol: Released 2025-10-16, Open-Sourced as Open Standard 2025-12-18 — Anthropic Engineering Blog + Substack synthesis + Medium LM Po. Evidence Level: Vendor Claim + Third-Party Synthesis (Anthropic’s position).
IDC Predicts 40% of Manufacturers Will Adopt AI-Driven Scheduling in 2026 — Groovy Web 2026 review, citing IDC report. Evidence Level: Third-Party Synthesis (IDC’s position; figures are directional reference only).
Stripe “Minions”: 1,300+ PRs Merged Weekly, Zero Lines of Code Written, All-Human Review — Stripe engineering team, Steve Kaliski on How I AI 2026-03-25 + ByteMonk 2026-02-14 recap. Evidence Level: Vendor Claim (Stripe’s position; figures are reference-worthy; scenario is Stripe engineering internal; not generalizable to industry average).
BCG 2026 Applied AI Index: Agentic AI accounts for 22% of total AI value (2026) → 39% (2030) — Publicly available report by BCG. Evidence level: Third-party synthesis (consulting firm perspective, directional figures for reference).
Gartner forecasts that 40% of enterprise applications will incorporate task-based AI Agents by 2026, up from <5% in 2025 — Paul Okhrem’s 2026 comprehensive review, citing Gartner. Evidence level: Third-party synthesis (Gartner perspective, directional reference).
China’s CAC, NDRC, and MIIT jointly issued the “Implementation Opinions on Standardized Application and Innovative Development of Agents,” effective 2026-07-15 — Rimon Law’s July 2026 Monthly China AI Regulatory Briefing. Evidence level: Third-party synthesis (legal firm perspective, regulatory documents available for verification).
TinyFish: $47M Funding, Clients Including Google/DoorDash/Amazon, Browser Cold Start <250ms ——SwitchTools 2026 Roundup. Evidence Level: Third-Party Synthesis (from a product review site’s perspective; figures should be verified with TinyFish directly).

If you’re evaluating how to build an enterprise internal Agent platform, which capabilities should be built in-house / purchased / shared, and which Agent Runtimes offer the highest reuse value, let’s chat. We specialize in enterprise AI transformation consulting—spanning Agent architecture, Runtime design, and Skill accumulation—helping you evolve from “point Agent” to “organizational-level Agent platform.”

Enterprise Training: Tailored for executives and business leaders, this 3-day foundational course runs ¥90,000 per session. We break down the Agent Stack Seven-Layer framework, Governance from an engineering perspective, and the Skill Accumulation Methodology for your team.

Specialized Consulting: Starting at ¥3,000 for a 90-minute architecture diagnosis, we provide an independent assessment of your organization’s current Seven-Layer snapshot, layer gaps, and third-party vs. in-house build recommendations. Deep engagement is quoted per project.

Executive Briefings & Industry Speaking: Keynotes and closed-door sessions at industry conferences and forums. Contact us to customize the agenda.

Contact: [email protected]

Further Reading: The Seven-Step AI Transformation Framework, a comprehensive guide to the complete journey of enterprise AI adoption.

Localization Key Points (Multi-Language Translation Reference, IAIUSE Multilingual Strategy · 2026-08-09 Agreement)

When translating across 19 languages, replace the following elements according to target market localization while maintaining structure and visual layout:

中文稿内容	英文版	日文版	德文版	阿拉伯版
Qoder / QwenWork / TinyFish / WonderClip / OpenSearch	Qoder / QwenWork / TinyFish / WonderClip / OpenSearch	Qoder / QwenWork / TinyFish / WonderClip / OpenSearch	Qoder / QwenWork / TinyFish / WonderClip / OpenSearch	Qoder / QwenWork / TinyFish / WonderClip / OpenSearch

中文	English	日本語	Deutsch	العربية
阿里云 / 钉钉 / 飞书	Alibaba Cloud / DingTalk / Feishu (Lark)	アリババクラウド / ディンスタック / 飛ぶ本 (Lark)	Alibaba Cloud / DingTalk / Feishu (Lark)	علي بابا كلاود / دينج توك / فيشو (لارك)
中国电信 / 移动 / 联通（企业 Agent 部署场景）	AT&T / Verizon / T-Mobile	NTT / KDDI / ソフトバンク	Deutsche Telekom / Vodafone	STC / Etisalat
中国制造业代表企业（ERP / MES / QMS / SRM 案例）	GE / Honeywell / Rockwell	Toyota / Hitachi / NTT Data	Siemens / Bosch / SAP	SABIC / Aramco / STC

Bank of China (financial case)	JPMorgan / Goldman Sachs	Mitsubishi UFJ / SMFG	Deutsche Bank / Commerzbank	Emirates NBD / QNB
Sandbox Container / Virtual Desktop / Tool Calling	Sandbox Container / Virtual Desktop / Tool Calling	Sandbox Container / Virtual Desktop / Tool Calling	Sandbox Container / Virtual Desktop / Tool Calling	Sandbox Container / Virtual Desktop / Tool Calling
One Foundation / Harness	One Foundation / Harness	One Foundation / Harness	One Foundation / Harness	One Foundation / Harness

| Domain Skill / Coding Skill / SEO Research Skill / E-commerce Creative Skill / Ops Skill | Domain Skill (retain) / Coding Skill / SEO Research Skill / E-commerce Creative Skill / Ops Skill | Domain Skill / Coding Skill / SEO Research Skill / E-commerce Creative Skill / Ops Skill | Domain-Skill / Coding-Skill / SEO-Research-Skill / E-Commerce-Creative-Skill / Ops-Skill | Domain Skill / Coding Skill / SEO Research Skill / E-commerce Creative Skill / Ops Skill |

About This Series

“Cloud Computing Summit Observations” is an industry field research series from IAIUSE, departing from the 2026 Cloud Computing Summit. It adopts a researcher’s lens to dissect the real transformations unfolding in the AI industry—not chasing trends, but focusing on the directions being bet on and the strength of the evidence behind them.

The series covers topics spanning system layers above foundational models, Agent deployment, Context assets, enterprise AI organizational design, and the migration of AI product competitive units, among others—totaling approximately 10 articles.

I have nearly eight years of experience in enterprise consulting and business analysis, having worked at IBM on projects across telecommunications, financial services, insurance, and manufacturing. After that, I continued working on the front lines of operator products, internet products, and AI application development, focusing on requirements analysis, product design, and cross-functional implementation.

This newsletter is actually run by a small team—myself and one or two long-term collaborators, each handling different areas: AI coding tool research, organizational governance case analysis, and coaching conversations. Most of the projects where “we helped enterprises navigate challenges” were delivered jointly by our team.

The research database has accumulated over 200 articles. The assessments in this series are based on my on-site observations and cross-industry validation, reflecting a clear authorial perspective and do not represent the views of any vendor.