Z Potentials | Milton Yan: Gen Z Dropout Building an Agent-Native PaaS, A Launchpad for Viral Agents
Z Potentials invited Milton Yan, founder of CoreSpeed, to give a talk.
Since ChatGPT ignited public awareness, AI has been rapidly permeating applications like writing, programming, and design—ushering us into the age of intelligent agents. What once seemed like distant dreams of automated interaction are now becoming reality. Behind this shift lies a quiet but profound reconstruction of infrastructure—from model capabilities to deployment experiences. Whoever can solve the “last mile” of intelligent agent delivery will hold the keys to this paradigm shift.
It’s in this context that Agent-native PaaS (Platform-as-a-Service) has emerged as a new category. These platforms are not only expected to meet technical demands like container isolation and persistent interaction, but also to empower developers and unlock the full potential of AI models.
At this turning point, we saw a glimpse of what’s possible: DeckSpeed, an AI-powered pitch deck generator, was built in just two weeks—and climbed to the top of Product Hunt’s monthly leaderboard. The platform powering this viral success? CoreSpeed, an Agent-native development and deployment platform.
In this edition, we speak with Milton Yan, a Gen Z founder and the creator of CoreSpeed. From tinkering with microcontrollers as a teen to transitioning from hardware to software—and now building the runtime infrastructure for agents—Milton takes us inside his journey.
Together, we’ll explore:
Why the real challenge of Agent products isn’t the model itself, but deployment and delivery
What it means to give “every user their own container”
The systematic engineering and product philosophy behind DeckSpeed’s rapid success
Join us as we unpack a story of system-level innovation in the age of AI agents. Enjoy!
“We’ve consistently followed one core principle: only work on things where we have a shot at achieving a 10x improvement—not just chase directions that look technically hard.”
“Every company building Agents inevitably has to deal with container lifecycle management, user-level routing, and other orchestration tasks during deployment. These tasks are completely unrelated to the core logic of the Agent itself, and the required skill sets don’t align with those of Agent developers. That’s precisely why an infra-focused company is well-positioned to build the “wheel” once—turning every Agent company’s marginal cost into one company’s fixed cost.”
“Building a smart Agent is no longer the hard part. The real challenge is getting it online—in other words, deploying it to the cloud. The reality is: most people can build an Agent, but they can’t deploy one, let alone scale it. The “last mile” problem is exactly what we’re here to solve.”
“An Agent-native PaaS isn’t about “optimization” or “stacking another orchestration layer.” It’s about replacing legacy components that constrain Agent performance—and rebuilding infrastructure specifically for Agents from the ground up.”
“Whether it’s product or growth, we’ve developed our own way of thinking. It’s rooted in deep, first-principles understanding of the “why,” which gives us a raw, relentless edge in the “how.” And I love that.”
01 | A “restless” Gen Z dropout entrepreneur on a mission to democratize both Agent development and deployment
ZP: From tinkering with microcontrollers in your early years to winning hackathons in college—what key moments shaped your technical mindset and entrepreneurial drive?
Milton: Ever since I was a kid, I wanted to be both an engineer and an entrepreneur. That inspiration came from my grandfather—he was experimenting with radio tech when he was still in elementary school. His very first project was building a radio, and under his influence, I made my own version as my first ever “creation.” Later, I replicated projects like railguns, ZVS drivers, and Tesla coils—once even remotely detonating a homemade mushroom cloud behind our school.
In online forums and global tech communities, I found a group of like-minded tech nerds, and together we dove deep into microcontroller projects. These “electrical” hacks were pretty basic, but I wanted to build things that were more fun and creative—so naturally, I got into coding.
As an undergrad, I initially majored in IoT engineering, but within a few months realized I’d already learned most of the material back in high school. I switched to Information Systems to challenge myself with something new. College gave me the freedom to work on my own projects. In my freshman year, I built a voice-controlled smart planter using Siri. It was rough, but the user experience was great—and I won 100,000 RMB in one day at the China-U.S. Maker Competition. I later designed the full structure in SolidWorks, 3D printed the components, and assembled a functional prototype with sensors, motors, and control modules. That was the first time I met real investors.
After that, I pulled together some of the strongest CS students in my university—Hao Su, Jingzhou Xu, Zi'ang Wu, Su Wang, Zihan Lü , Hang Yuan—and we built a series of ambitious software and hardware projects. We racked up awards and prize money with things like the ESGrow robotic arm, a skiing robot, a brain-computer interface exoskeleton, QuickGPT, the Speed VPN, Meep, Keting (an audio learning tool), and Zhizhi (a knowledge assistant), among others.
ZP: You just mentioned entrepreneurship. Can you talk about how that mindset developed over time?
Milton: Honestly, I think the entrepreneurial mindset has been there since birth. Back in kindergarten, I was already assigning roles to the kids around me—imagining what positions they'd hold in my future company. In elementary school, I’d actively seek out people—online and in real life—who had unique skills and try to bring them into my circle.
In college, the university provided office space and storefronts for promising student ventures. I ended up securing four or five of those. In the entrepreneurship park, I brought together some of the strongest talents I could find—people from rival teams I respected, and the best individuals across various majors—and pulled them into my own team. I just wanted to build something big together.
Once we moved into software, the pace changed entirely. Compared to hardware, software has shorter development cycles, faster launch timelines, and is easier to mature and commercialize. Starting in 2022, the "Year One" of ChatGPT, we built a series of software products. Some of the GPT wrappers we created didn’t make much money—but our product Speed, a virtual private network (VPN), generated over 400,000 RMB in revenue.
It was priced quite high, but users loved it because it was fast and stable. We had studied a wide range of gateway protocols in depth. That’s also why, even back then, we already understood issues like head-of-line blocking in SSE under HTTP/1.1—most people ignore those details, but we went deep because we wanted to optimize latency to the extreme.
One day, I was sitting in the office with Hao Su, eating while looking at the revenue dashboard, and we just said: “Let’s go all-in after graduation.” At that point, we realized entrepreneurship wasn’t actually risky at all—even without a dime of funding, if we built a good product, we could support ourselves—and never have to take a job.
ZP: You’ve won several hackathon awards and even published SCI/SSCI papers. How have those experiences helped you identify white space in the Agent space?
Milton: I’d say the papers and awards themselves aren’t what matter—it’s what they demystify that’s valuable. For example, in one competition, participants were tasked with building an object detection model. Most teams followed the standard playbook: pre-processing on CPU, inference on GPU, and post-processing back on CPU. They focused heavily on boosting model accuracy—tweaking architectures or feeding in better datasets. Basically, they were “alchemy-ing” for small gains.
We approached it differently. Instead of focusing on the model itself, we optimized the asynchronous coordination between CPU and GPU to ensure neither sat idle. That led to significantly faster inference speeds than the other teams. This kind of counterintuitive thinking became our foundational logic for building products later on.
When it comes to Agents, people often ask us if we’re working on model training or reinforcement learning. But we don’t see that as the real bottleneck. Today’s large models are already powerful enough. The real question is: how do you use them well?
We’ve seen too many people force-fit AI into problems that don’t need it—just to make something look impressive. In the end, it becomes all form and no substance.
That’s why we stick to one core principle: only build things where we have a shot at a 10x improvement. Not things that just look technically intense. This mindset is how we identify opportunities and spot white space in the Agent ecosystem.
ZP: What inspired you to build CoreSpeed, the Agent-native PaaS?
Milton: The original spark came from two products we built in October 2024: Keting and Zhizhi—automated tools for podcast-style content generation. They weren’t Agents in the strict sense, but they served use cases like: regularly pulling documents from arXiv or PitchBook, or allowing users to upload files or links. The system would perform OCR, generate podcast scripts, assign roles, and then synthesize speech using different TTS (text-to-speech) voices, each with a preset prompt.
At the end of the day, it was a scripted workflow pipeline. There was no real-time editing or natural-language interaction from the user. The “roles” were just prompt wrappers pretending to be different characters. So it lacked true interactivity, which is core to what makes something an Agent.
That said, the product still gained traction. We actually launched features similar to NotebookLM even earlier—it was a case of “parallel discovery.” But it made us think critically about its true potential and limitations. Sure, it helped users absorb information faster—say, by summarizing a page of slides—but ultimately, it was still just a content consumption tool.
Then we asked: What if we gave those podcast roles personalities? What if they had their own knowledge bases, toolchains, and reasoning capabilities? What if they could interact with users mid-conversation—answer questions, receive corrections, even shift tone dynamically?
At that point, it would no longer be a passive listening experience. It would become something closer to consultation-grade output—a truly deliverable-level product. And that’s when the Agent-native vision for CoreSpeed started to form.
So we began experimenting with building character-based Agents—like investor Agents or professor Agents—shaped by reading habits, content consumed, and preferred tools. What we discovered was surprising: even without relying on RAG or LangGraph, large models alone were already capable of handling fairly complex reasoning and planning.
That’s when it hit us: building a “smart enough” Agent wasn’t the hard part anymore. The real challenge was getting it online—deploying it to the cloud in a robust, scalable, and user-friendly way.
In actual use cases, users were writing code through the Agent to invoke tools and making highly personalized requests. It became immediately clear: you can’t have all users share a single Agent instance—that introduces cross-talk, conflicts, and serious issues with isolation and security.
This realization became the foundation for building CoreSpeed.
We noticed that many so-called “Agent” products on the market weren’t really Agents at all. The litmus test is simple: does it give each user their own container? If not, it’s not a true Agent platform. Most “Agents” still treat the LLM as a factory-line worker, not an autonomous decision-maker.
But what we wanted to build was an executional brain—an Agent that can autonomously plan, reason, and invoke tools. Once this kind of architecture is in place, it unlocks 10x to 100x improvements in performance, and unleashes the full potential of large models. But to make that work, each user needs an independent container environment.
We reviewed every container solution at the time—like E2B. While it had both open-source and SaaS versions, the open-source deployment cost was sky-high (around $6,000/month per AWS cluster), which is out of reach for most startups. And the SaaS version was too limited—users still had to build their own orchestration layers.
That’s when we thought: if every Agent company has to deal with container lifecycle management, user-level routing, and orchestration, and if these tasks have nothing to do with Agent logic, and if Agent developers don’t even have the skillset for this infra work—why not build the “wheel” once?
Let one infra company turn everyone’s marginal cost into its fixed cost. That way, every Agent team can focus on their core business logic instead of reinventing the orchestration layer.
And we actually had the technical foundation to do it. Back when we built Speed, our virtual private network product, we developed deep expertise in network protocols, container orchestration, and isolation mechanisms. We knew how to build a high-performance, strongly isolated, and scalable Agent runtime platform.
Ultimately, our goal is to empower thousands of vertical-specific Agent developers to bring production-grade Agents online—without needing to know Kubernetes. And really, that vision ties back to what I’ve believed since I was a kid: find people who share the same drive, build things that are genuinely useful, and help everyone realize their full potential.
For me, this wasn’t a calculated startup strategy—it was simply the next step in a very natural progression.
02 | CoreSpeed’s Agent-Native PaaS: Building the System That Actually Gets Agents Online
ZP: Why do you believe 2025 is the right window of opportunity to launch CoreSpeed?
Milton: It really comes down to a natural inflection point in technological evolution.
By now, the context window is long enough, and Agent development has matured to the point where you no longer need frameworks like LangGraph to build something functional. Tool functions and invocation paradigms are stabilizing. Protocols like MCP and A2A have accelerated this process, and as a result, building an Agent locally has become much easier.
But while creating an Agent locally is now relatively straightforward, getting it online is still extremely difficult.
That’s why I believe 2025 is the eve of the vertical Agent explosion. Once a few companies like us step up to build Agent-native infrastructure, we’ll start to see vertical-specific Agents emerging en masse.
Take OpenManus, for example. As soon as Manus was released, GitHub was flooded with “OpenManus” clones. Developers could fork it locally and instantly get a functional copycat Manus running on their machines. There are countless Agent frameworks with thousands or even tens of thousands of GitHub stars.
But here’s the catch: why aren’t there 10,000 deployed Agents or 10,000 live CopyCat Manus tools out there?
The answer is simple: People can run Agents locally, but they can’t deploy them—let alone deploy them at scale or serve multiple users simultaneously.
That’s the opportunity we saw. Most people can build Agents, but they can’t deploy them, and certainly can’t scale them.The problem we’re solving is exactly that “last mile”—the gap between working prototype and production-ready deployment.
That’s why we launched CoreSpeed now—because the timing is right to unlock the next wave of Agent innovation.
ZP: I’d also love to hear your definition of an Agent-native PaaS. CoreSpeed describes itself as a PaaS platform—how is it fundamentally different from traditional PaaS?
Milton: What we emphasize most is the word “native.”
Traditional DevOps and PaaS platforms were built for conventional applications. They simply weren’t designed to handle the unique demands of deploying Agents. Most impose strict limits on the number of containers you can run, forcing today’s Agent developers to layer multiple orchestrators on top of legacy DevOps stacks—drastically increasing engineering complexity.
What’s more, Agents typically use SSE (Server-Sent Events) for communication. If your infrastructure doesn’t support HTTP/2 or higher, the connection becomes painfully sluggish. One prompt could trigger multiple back-and-forth rounds between the Agent and the LLM, and you’d be waiting minutes for a response.
That’s why you can’t deploy Agents using last-generation DevOps.
An Agent-native PaaS isn’t about “optimizing” or “stacking more orchestration layers.” It means abandoning legacy infrastructure components that bottleneck Agent performance and rebuilding everything from the ground up—infrastructure built specifically for Agents.
We call this paradigm Agent-Native Infra, Agent-Native PaaS, and AgentOps.
Agents represent a new computing paradigm.
They’re not just tools stacked together, nor are they simple aggregators of information. Agents are intelligent entities with the ability to reason, plan, and act autonomously.
And if Agents are a new species of software, then the infrastructure that serves them must be reimagined from scratch. You can’t just slap an “AI” label on old tools and call it a day.
CoreSpeed is the platform we’re building for that future—a runtime born for intelligent agents, from the infrastructure up.
ZP: Let’s talk about your two core products—Zypher Agent Framework and CoreSpeed.io. What specific problems do they solve? Can you share concrete use cases?
Milton: These two products address the two key stages of the Agent lifecycle:
Zypher is a development framework that helps developers build powerful Agents locally.
CoreSpeed is the deployment platform that helps you launch Agents at scale—securely, efficiently, and reliably—to serve thousands or even millions of users.
Let’s start with Zypher. It focuses on three core capabilities:Autonomous tool invocation
Zypher is a composable, autonomous tool-calling Agent development framework. Even without any modifications, Zypher can function as a fully general-purpose Agent out of the box. In fact, Zypher currently ranks #1 globally among open-source Agent frameworks on the GAIA Benchmark. Developers simply populate the tool list in Zypher—whether with their own tools or external APIs—and then guide orchestration via prompts, weightings, and other configuration methods. That’s where Agent developers should be spending their time: not reinventing infrastructure, but focusing on designing meaningful Agent behavior.
Indexing: Semantic Code Understanding and Precision Insertion
Zypher’s Indexing capability enables deep semantic understanding of the entire codebase and runtime context. It breaks down the codebase into meaningful semantic chunks, parses dependencies, and builds a fine-grained knowledge graph—mapping functions, classes, config files, and even visual elements.
When the LLM generates new code or content, Indexing doesn’t rely on line numbers or diffs. Instead, it uses semantic anchors to determine the most appropriate insertion points. This ensures that the new code:
Preserves logical dependencies
Maintains scope integrity
Avoids stylistic inconsistencies
It then automatically adds the necessary import statements, updates references, syncs test cases, and triggers minimal-impact regression testing via the CI pipeline. When a user wants to fine-tune a specific component, Zypher—via Indexing—locates all relevant code, context, and dependencies, passes only the affected subgraph to the LLM for modification, and patches the results back into the codebase. This process ensures:
Zero impact on unrelated modules
Full compliance with code style, linting rules, and commit conventions
In short: high-precision, localized edits with no collateral damage.
Take our showcase product, DeckSpeed (Slide Agent), for example. If a user says: “Change the bar chart in the upper-left corner of slide 4 to a line chart,” DeckSpeed will pinpoint the exact code tied to that chart, transform it into a line chart, maintain stylistic consistency across the slide, and leave every other element untouched.
Another recent use case: I met with a team (four times in five days!)—former developers from Activision Blizzard—who built a prototype using the Zypher framework. Their product is essentially “Cursor for Unity.” A user types a prompt like:
“Add light effects, shadows, sound, and textures to this scene.”
Zypher first uses Indexing to identify related GameObjects, materials, ShaderGraph files, and AudioSource configurations in the project. Then it guides the LLM to generate the lighting, shadows, textures, and audio code snippets. Indexing precisely inserts these into the correct Prefabs or scripts, while:
Auto-updating reference counts and asset paths
Adjusting Lightmap settings
Preserving unrelated logic (e.g., physics, UI, networking)
The result: the scene is instantly upgraded—without breaking collision logic, UI behavior, or multiplayer sync. And the developer doesn’t need to worry about merge conflicts or asset loss.
Checkpoint Management: Version Control for Agent-Generated Output
The third core capability of Zypher is Checkpoint Management—essentially bringing Git-style versioning to the Agent workflow.Here’s the typical scenario: after an Agent produces an initial result (from a one-shot prompt), the user is 80% satisfied. From there, they’ll likely enter an iterative loop—providing feedback, making incremental adjustments, and reviewing changes at each step. With Checkpoint Management, users can:
Accept the new version
Reject the change and roll back to a previous version
This process places the user firmly “in the loop”—a critical component of intelligent, controllable AI. It ensures that LLM-driven edits are transparent, reversible, and aligned with human intent.
Even as models continue to grow more powerful, users will remain the ultimate source of direction and quality control. That’s why version checkpoints aren’t a luxury—they’re a foundational feature for any serious Agent system.
This capability is already featured in a number of Agent products—like Cursor, Träe, and others. For instance, if you add a border to a slide and realize the result looks worse, you should be able to instantly roll it back.
But Zypher goes a step further: as a development framework, it provides native, built-in support for checkpoint management. This way, Agent developers don’t have to reinvent the wheel—they get version control as a first-class feature, right out of the box.
ZP: That’s very specific. Let’s talk about CoreSpeed.io. What exactly is the “wall” it’s breaking through?
Milton: To summarize CoreSpeed.io in one sentence: Agent products allow users to execute a large amount of untrusted code, so you must implement “per user per container.”
This brings up a whole set of new requirements: ensuring fast cold starts for containers, user-level container routing, and dynamic container lifecycle management (otherwise, if a container remains running after the user is done, your costs will explode exponentially). Traditional infra and DevOps systems were designed for traditional applications and cannot natively support the unique needs of deploying Agents. As a result, the threshold for getting an Agent deployed and online is very high. Developers not only need to write Agent logic, but also master DevOps, K8s, CI/CD, and other infrastructure skills in order to stitch together a functioning orchestration layer—none of which has anything to do with the Agent’s actual “intelligence” or ability to solve problems. That’s why we’ve seen many promising products fail to launch: a user sends a prompt and waits 20 minutes for the first response.
What CoreSpeed does is this: strip away all components that hinder Agent performance, and build an Agent-native PaaS using the container as the core unit. It ensures fast cold starts, supports auto-scaling, CI/CD, user-level container routing, and dynamic container lifecycle management. It’s a full-stack rearchitecture that ensures every Agent can be deployed efficiently and run smoothly. With native Agent infra, Agents run faster—and what users feel directly is that the Agent responds quicker.
In our comparative testing, an Agent that used to take 20 minutes to return a task result now takes only 3 minutes after migrating to CoreSpeed PaaS—and we’re aiming to bring that down to under 1 minute in the future. This will massively unlock Agent product performance.
03 | CoreSpeed Is Redefining the Agent Development Experience: From Months to One Week
ZP: Are there any successful user-facing Agent applications already launched on your platform?
Milton: Many people discovered us because the PPT Agent product DeckSpeed hit #1 on Product Hunt’s monthly leaderboard in May. But in reality, DeckSpeed was built by just two developers using the Zypher Agent Framework and CoreSpeed.io—in only two weeks.
The development team really only did a few things: they opened the Zypher project in Trae, wrote a system prompt for the Agent, then created a few core tools related to slide creation—a layout tool, an image generation tool, a rendering tool, a font styling tool, and a web scripting tool—and spent just 3 minutes putting together a UI. Through the combination of system prompts and tool orchestration, they constrained the Agent’s task boundaries (rather than its capability boundaries).
In Agent development, the hardest part isn’t writing the tools themselves—it’s figuring out how to translate human task execution paradigms into a tool invocation system that the Agent can follow. For example, DeckSpeed’s image generation tool only has a dozen lines of code, and one of them is simply an API call to image-1. Writing the tool isn’t the hard part. The challenge is orchestration: when to trigger which tool, how to define the activation rules, how to assign weights—this is the true core of Agent engineering.
ZP: What kind of positive feedback did DeckSpeed bring to CoreSpeed?
Milton: DeckSpeed sent a very strong signal: with the combination of Zypher + CoreSpeed, it’s possible to build and launch an Agent product in just two weeks—and then reach #1 on Product Hunt’s daily and monthly leaderboards. It wasn’t just a visibility win; DeckSpeed earned its top ranking purely through community votes, received endorsements from multiple top universities—including official backing from NYU and ETH Zurich, and enthusiastic support from professors at Peking University and Stanford. Most importantly, we validated a 27% trial-to-paid conversion rate within just one month.
ZP: To generate more success stories like DeckSpeed in the future, what strategies are you focusing on next?
Milton: We’re putting our focus on case-driven marketing, not rushing into flashy “repo marketing.” In other words, we’re not going to waste energy buying PR to make Zypher look like a cool GitHub project. Stars on GitHub are still a business metric, but in the short term, I want to go deep on a few high-value, fully-executed product cases—real ones that prove the entire flow from development to deployment to user conversion.
Take that Blizzard-origin team I mentioned earlier—we’re fully backing their Zypher for Unity project. The goal is to polish it into an industry hit, and then use their influence to fuel the platform’s growth and bring more developers into the ecosystem. That’s how we build a positive feedback loop.
Zypher Agent Framework is also now part of the Capstone curriculum at NYU’s School of Engineering, where students are using Zypher to build their own Agents as final projects. And together with NYU, NVIDIA, ByteDance, and others, we’ll be launching a series of hackathons to help more developers build practical Agent products using Zypher and CoreSpeed.
Earlier we mentioned Cursor for Unity as a use case built on Zypher, and I think it sets a great precedent. Taking that as inspiration, I’d love to see the emergence of interactive 3D content production Agents—for example, scene assistants for Blender or Unreal.
The challenge is very similar to Unity: building 3D environments involves constant back-and-forth across a dozen different panels for lighting, materials, particle effects, and animations. Iteration is extremely slow. But if you Agent-ify these workflows, you can achieve the same “one-prompt” complex transformations seen in Cursor for Unity.
Scene graphs in these tools are structured as hierarchical trees, making semantic targeting relatively easy. Both Blender and Unreal support Python APIs, which can be directly injected into CoreSpeed’s container sandbox. And once these Agents are live, the user base is naturally prosumer-heavy—high willingness and ability to pay, with above-average software spend per capita.
Blender’s community alone exceeds 4 million monthly active users, and the Unreal Marketplace sees over $200 million in annual transaction volume. Creators in these spaces heavily depend on plug-ins, so successful Agent-based tools would directly amplify the adoption of both the Zypher Framework and CoreSpeed.
Similarly, there are other domains ripe for Agent transformation—such as CAD and BIM in architecture, or post-production workflows in video and audio editing. The core criteria we’re looking for are: 1. High complexity;
2. High iteration frequency; 3. Rich asset ecosystems—ideal vertical tools that can be Agent-ified through Zypher.
ZP: How will your upcoming “Silicon Valley Hackathon” accelerate the developer ecosystem? What resources and support will you provide?
Milton: ByteDance’s Trae has incredibly strong product capabilities, and our team are heavy users of it. Trae and Zypher are natural partners—developers can clone Zypher, open the project in Trae, then use natural language coding via Trae to “give Zypher hands and feet” (i.e., add tools), and orchestrate these tools. Without a doubt, Trae + Zypher can build powerful Agents, and CoreSpeed enables those Agents to go online quickly. I believe that such an event will lead to the emergence of a large number of outstanding Agent products.
The combination of Trae + Zypher + CoreSpeed forms a complete toolchain—from building the interface, writing system prompts and tool orchestration, all the way to product deployment—everything connects seamlessly. The purpose of the hackathon is to help developers create deliverable products in the shortest possible time, experiment and iterate quickly through the platform’s built-in traffic, and explore commercialization opportunities. For us, this is what truly drives the ecosystem forward.
ZP: For CoreSpeed, what core user metrics will you focus on most over the next three years?
Milton: For an Agent-Native PaaS targeting prosumer and B2B Agent developers, the most telling metrics are at the container level. For example:
How many containers are launched daily?
What is the average usage time per container?
These are the metrics that truly measure the strength of our infrastructure and our commercialization potential. Simply looking at the number of Agents doesn’t tell you if they are online, actively used, or if they have retention. By focusing on container launches and usage duration, we can clearly see:
Are there real end-users?
Do these Agents have deliverable capabilities?
Is there ongoing retention and reuse?
These indicators determine the actual scale of platform operations, while commercial metrics (like total revenue or Agent income) are lagging variables built on top of this foundation. Sustained growth in these container-level metrics is what we care about the most.
ZP: You’ve made the transition from student to CEO. What technical or business challenges have you faced during that process? Were there any missteps along the way? And how did you overcome them?
Milton: Definitely—and to be honest, I encounter challenges every single day. It’s hard to recall all the details at once, but I can share one recent and very pivotal mindset shift.
We’ve been building things since our student days—that part hasn’t changed. But back then, our mentality was all about: how can we move something forward at zero or minimal cost? We did everything ourselves. If we could avoid spending, we would. Our biggest thrill was solving something for $200 that others spent $10,000 on.
But now, as a CEO, the responsibility is completely different.
After our last round of funding, we barely spent more than $10K–20K over a long stretch. We were being too frugal—honestly, a bit afraid to spend. We kept thinking, “let’s save where we can.” But now I realize: the CEO’s primary job isn’t to save money—it’s to drive the business forward.
If you have funding, you should have the courage to invest it—get the critical path unblocked first, then come back to optimize for cost. You can’t let caution around spending delay execution and drain your momentum. That shift—from a “student mindset” to a “CEO mindset”—was a major structural transformation for me.
We no longer chase “zero-cost hacks” for small wins. We’re now willing to invest real resources toward ambitious goals, and take on the responsibility of orchestrating larger-scale resource allocation.
Early on, when I led the team to secure partnerships or land some seemingly “magical” resources, I thought those at the top had it all figured out. But once we got to that higher platform, I realized—even the people on top are constantly hustling to unlock new resources. That’s when it clicked: no matter how many cards you’re holding, the game is always about building more leverage, unlocking more opportunities, and climbing higher. If you can clearly see the core of a deal, there’s almost nothing that can’t be negotiated.
And now that we’ve received funding from some very well-known institutions, we’re holding more chips—which means we hold ourselves to a higher standard. More leverage means a greater responsibility to convert it into even more meaningful outcomes.
ZP: Can you share a few AI startups that you personally find interesting?
Milton: One I’ve been really intrigued by lately is Cluely. Their founder is a Gen Z entrepreneur who was actually expelled from Columbia University. Their first product was called Interview Coder—basically a tool for cheating in interviews.
But what struck me was their level of insight. They realized that operating systems can use declarations and flags to prevent screenshots and screen recording. For example, when you try to screenshot an MV in Apple Music, the video area turns black—that’s a system-level restriction. They applied this concept to video interview scenarios: by flagging certain windows as non-recordable, the candidate could see them, but video conferencing software couldn’t capture them—so the interviewer couldn’t see what was going on.
Also, Cluely's task execution involves edge-side and cloud-side collaboration, which makes latency extremely low and the user experience very smooth.
I like them because they’re bold—and brutally independent.
They were building from Day 1, rejecting the prestige of big-name schools and tech giants from Day 1. Whether it’s product or growth, they operate with their own mental model. At the core, they’ve thought deeply about first principles (“the dao”), and that gives them a kind of wild energy in execution (“the tools and techniques”). That kind of spirit—I really admire.
Disclaimer
Please note that the content of this interview has been edited and approved by Milton Yan. It reflects the personal views of the interviewees. We encourage readers to engage by leaving comments and sharing their thoughts on this interview. For more information about CoreSpeed, please explore the official website: https://corespeed.io/zh.
Z Potentials will continue to feature interviews with entrepreneurs in fields such as artificial intelligence, robotics, and globalization. We warmly invite those of you who are hopeful for the future to join our community to share, learn, and grow with us.
Image source: Milton Yan