Atoms: Multi-Agent AI Application Builder

01 · Project Overview

Atoms, formerly MetaGPT X (MGX), is a multi-agent AI Coding and application-building platform developed by DeepWisdom. It enables users to describe product requirements in natural language and collaborate with specialized AI agents to transform an initial idea into a functional application.

During the building process, AI product managers, engineers, architects, and data analysts work together to complete requirement analysis, product design, technical architecture, code generation, backend configuration, testing, preview, and deployment.

Unlike conventional development tools designed primarily for professional engineers, Atoms aims to make application development accessible to a broader group of builders. Users do not need to fully understand programming languages, databases, authentication, model APIs, cloud infrastructure, or deployment environments before creating an application.

As a Full-Stack AI Product Manager Intern, I participated in the core product design of Atoms, focusing on Builder Runtime and AI Infrastructure. My work covered Secrets, Auth, Storage, AI Capability, Cloud & AI Balance, App Overview, Analytics, Preview, Restore, Version, and Publish.

The central product challenge was to translate complex engineering concepts into understandable and controllable user experiences, enabling non-technical builders to create, publish, operate, and commercialize AI applications safely and efficiently.

02 · Product Positioning and User Challenges

The target users of Atoms include entrepreneurs, product managers, designers, independent creators, small teams, and other builders who have application ideas but may lack complete software engineering capabilities.

Although generative AI has significantly reduced the cost of producing code, creating a production-ready application still involves many invisible technical tasks. Users must manage API keys, configure authentication, connect databases, select AI models, understand resource usage, distinguish development and production environments, and handle preview, publishing, and version recovery.

For professional engineers, these are familiar development concepts. For non-technical builders, however, they create substantial cognitive and operational barriers. A single incorrect API key, missing production variable, misunderstood permission, or unexpected model cost may prevent an application from working after publication.

Atoms therefore does not only generate frontend pages or code. It provides an integrated environment in which AI agents coordinate product design, implementation, backend capabilities, cloud resources, and deployment.

My product work focused on three principles:

1. Hide technical complexity that users do not need to understand.

2. Clearly explain risks, costs, and permissions that users must understand.

3. Preserve sufficient control for advanced users without making the default workflow complicated.

03 · Secrets and Environment Management

Secrets are used to store API keys, access tokens, and other sensitive configuration values required by an application. Although essential to modern application development, the concept is difficult for non-technical users because it involves security, reuse scope, runtime environments, and publishing behavior.

I led the redesign and two rounds of optimization for the MGX Secrets module, covering product concepts, information architecture, interaction design, edge cases, and PRD development.

The redesigned workflow allowed the Agent to identify when an application required an external API key and guide the user through configuration at the appropriate moment. Instead of forcing users to search through backend settings, the experience followed a more natural sequence:

Chat detection → contextual prompt → Secret configuration → automatic application

The design supported different reuse scopes, including configuration for the current Chat and reusable global configuration. This allowed users to balance convenience with security and avoid repeatedly entering the same credentials.

I also designed a two-layer Key model for development and production environments. The development Key supported application building and preview, while the production Key was used by the published application. This separation reduced the risk of exposing development credentials or publishing an application without a valid production configuration.

Publish-stage validation and fallback mechanisms were added to identify missing or invalid Secrets before deployment. The overall design reduced the likelihood of credential misuse while keeping technical concepts understandable to ordinary builders.

04 · Authentication and User Management

Authentication is a critical capability for applications that contain personal data, user-generated content, subscriptions, or differentiated permissions. However, conventional authentication systems require developers to understand identity providers, login methods, sessions, databases, permissions, and security configurations.

I participated in the design of Atoms’ built-in Auth capability, with the objective of enabling builders to add secure user authentication without manually implementing an entire identity system.

When the built-in backend is enabled, the platform can automatically configure the fundamental login capability. If Auth is not yet configured but becomes necessary, the Agent can identify the requirement and guide the user to add it through a natural-language instruction such as “Add MGX Auth to my app.”

The design also considered OIDC as a potential authentication method, allowing the product to support more standardized identity integrations.

For application user management, the proposed experience supported searching by name, UID, or email, together with pagination and registration-date filtering. Phone-number search was not included in the initial scope.

The product principle was to make permissions understandable rather than completely invisible. Builders should not need to become authentication experts, but they should still understand who can access their application, what data is protected, and how user accounts are managed.

05 · AI Capability Library

AI was initially easy to treat as another external integration. Through product analysis, we redefined AI as a first-class backend capability parallel to Secrets, Auth, and Database.

The capability was divided into two complementary parts:

1. AI Capability Library: A library of built-in model APIs and reusable AI capabilities.

2. App AI Usage Overview: A view of the models and AI capabilities currently used by an application.

I participated in designing how builders discover, understand, and add large language models, multimodal models, and Agent capabilities to their applications.

The proposed interactions included capability cards, “# Add to Chat,” # autocomplete, automatic detection of hidden AI requirements, and contextual recommendations. For example, when a user described an image-generation feature without specifying a model, the Agent could recognize the requirement and recommend an appropriate capability.

The design also considered where an added capability should be inserted into the conversation, how the cursor should behave, and how prompts should remain consistent across different interface languages.

AI capability cards and Agent responses needed to explain what each model would do inside the application, rather than only presenting technical model names. This helped builders understand the relationship among product functions, model behavior, and expected cost.

Prototype scenarios covered text generation, image generation, video generation, and music generation, demonstrating how multiple AI capabilities could be combined within a single creative application.

06 · Cloud and AI Balance

AI application costs are generated by two fundamentally different types of resources: AI model calls and cloud infrastructure. If these costs are combined into one abstract credit balance, users may struggle to understand where their credits are being consumed and how to control future spending.

I participated in the planning of Cloud & AI Balance, which separated AI usage from cloud-resource usage while presenting both within a unified account experience.

AI usage represented costs associated with large language models and multimodal model calls. Cloud usage represented resources required to host and operate an application, such as runtime, storage, databases, and related infrastructure.

The product design covered usage visibility, free quotas, tiered Auto Top-up, abnormal-consumption alerts, risk-control fallbacks, and balance-insufficiency handling.

We also refined credit-consumption visibility at the Chat level, allowing users to understand how many credits a particular building session had consumed. This connected abstract billing information with specific product actions.

The objective was not merely to display a balance. The system needed to help users understand which product behavior generated a cost, distinguish one-time building costs from ongoing operating costs, and avoid unexpected interruptions after publishing an application.

07 · App Overview and Analytics

After an application is published, a builder’s priorities change. During development, the focus is on completing features. After publishing, the focus shifts to availability, traffic, growth, operational risks, and commercialization.

I designed the product positioning and information architecture for the post-publication App Overview, defining it as a growth and operations dashboard rather than another configuration page.

The design followed a clear interaction constraint: builders should be able to complete key actions within three steps. Complex configuration was moved into the corresponding functional modules, while Overview presented conclusions, key indicators, risks, and primary calls to action.

The proposed Overview included:

• Application identity and live status;

• Primary URL and custom domains;

• Sharing entry points;

• Today’s unique visitors and page views;

• Seven-day visitor trends;

• Top traffic sources;

• Analytics empty states and configuration entry points;

• Google Ads status and commercialization entry points;

• Shortcuts to production resources;

• Availability and operational-risk notifications.

This structure allowed builders to quickly answer several essential questions: Is the application live? Is it operating normally? Is anyone using it? Where are users coming from? What should I do next?

08 · Preview, Publish, and Version Recovery

An AI-generated application is not complete when code generation ends. Builders must still verify the result, resolve configuration issues, publish the application, and recover from unexpected changes.

I participated in the product design of Preview, Publish, Restore, and Version-related capabilities, focusing on the application lifecycle from development to production.

Preview allows builders to verify the current application before making it publicly available. It must accurately reflect the latest generated result while distinguishing the development state from the published version.

Publish connects the application with production configuration, runtime resources, domains, authentication, Secrets, and AI capabilities. Before publishing, the system needs to identify missing production configurations and communicate risks in understandable language.

Restore and Version capabilities provide builders with a recovery path when an Agent-generated change produces an unwanted result. Instead of requiring users to understand Git or manually reverse code changes, the platform can present recoverable application states through a productized version experience.

The product objective was to make the development-to-production transition visible and reliable without requiring users to understand the underlying deployment pipeline.

09 · Product Research and Competitive Analysis

To understand how AI builders simplify software development, I conducted product research on Lovable, Replit, Dify, and other AI application-building platforms.

The research focused on several areas:

1. How API keys and environment variables are configured;

2. How development and production environments are separated;

3. How authentication and permissions are explained;

4. How databases and storage are connected;

5. How AI models are discovered and added;

6. How usage and cost are communicated;

7. How preview, publishing, and version recovery are handled.

The objective was not to copy individual features, but to identify reusable product principles. These included invisible configuration, understandable permissions, contextual guidance, progressive disclosure, and clear resource-consumption feedback.

Based on this research, I helped abstract the Atoms Builder experience around three directions: seamless backend configuration, understandable authorization, and immediately comprehensible AI capabilities.

10 · Product Workflow and Prototyping

My responsibilities covered the complete product workflow rather than only requirement documentation. The process included user-problem analysis, mental-model construction, interaction strategy, information architecture, prototyping, PRD development, technical alignment, and product validation.

I used Feishu MCP, Figma MCP, and Cursor to connect different stages of product development:

Requirement analysis → Product flow → Interactive prototype → PRD → Technical solution → Runnable demo

Figma was used to validate information architecture and interaction flows. Cursor and Vibe Coding were used to rapidly create runnable frontend demos, allowing product concepts to be tested beyond static design files.

Runnable prototypes made it easier to evaluate states, transitions, edge cases, content hierarchy, and technical feasibility. They also created a more concrete foundation for discussions among product, design, and engineering teams.

This workflow allowed product ideas to be examined through actual interactions before entering full development, reducing ambiguity between written requirements and implementation.

11 · My Contributions

As a Full-Stack AI Product Manager Intern, my primary contribution was translating complex AI and backend infrastructure into product experiences designed for ordinary builders.

My work included:

• Leading the redesign and iterative optimization of Secrets;

• Designing development and production Key separation and publish-stage validation;

• Participating in built-in Auth and application user-management design;

• Defining AI as a first-class backend capability;
  Designing the AI Capability Library and App AI Usage Overview;

• Participating in Cloud & AI Balance and resource-consumption strategies;

• Designing the post-publication App Overview and Analytics structure;

• Participating in Preview, Publish, Restore, and Version experiences;

• Conducting competitive research on AI Builder and Vibe Coding products;

• Producing product flows, prototypes, PRDs, technical proposals, and runnable demos;

• Collaborating with product, design, and engineering teams during design reviews.

These contributions supported a more complete application-building experience, extending Atoms beyond code generation into backend configuration, AI integration, publishing, operation, and commercialization.

12 · Project Value and Reflection

The value of an AI application builder is not determined only by how quickly it generates code. Its real value depends on whether users can transform generated code into a secure, reliable, maintainable, and commercially viable product.

Working on Atoms helped me understand that AI-native product design requires a balance between automation and user control. If the product exposes every technical concept, non-technical users become overwhelmed. If everything is hidden, users may lose trust when permissions, costs, or production risks become important.

Effective AI-native experiences therefore require selective abstraction. Configuration can be automated, but critical consequences must remain visible. Agents can recommend actions, but users should understand what will change. Costs can be simplified, but users still need to know what they are paying for.

Atoms addresses this challenge by combining Agent collaboration with productized backend and runtime capabilities. Its broader objective is to allow more people to move from an idea to a functioning AI application without first becoming professional software engineers.