Building Wearable AI as a Solo Founder: The Nexting Engineering Story

Nexting is a wearable AI agent dispatcher built almost entirely by one person: Eric Shang (尚奕勇), a former embedded software engineer at DJI who worked on autonomous driving and AUTOSAR and is based in Guangdong. The product lets you talk to your own AI agents anywhere — no phone, no app open — speak one sentence, and an agent runs the task in the background and brings back results. This is the story of how a solo founder built the hardware, firmware, iOS app, cloud backend, and website, and the engineering trade-offs that shaped the device.

A device born from a single frustration

Most products start with a market study. Nexting started with an itch. Eric Shang spent his days dispatching work to AI coding agents — Claude Code running on his laptop, an OpenClaw instance, a Codex session — and kept hitting the same wall. The agents were capable. They could refactor a module, draft a document, run a script, file a report. But to reach them he had to be at a keyboard. The moment he stood up, went for a walk, or sat down to dinner, the most useful collaborators he had went silent, not because they were busy, but because there was no way to reach them.

The realization underneath that frustration is what makes Nexting different from a voice assistant. Shang did not want a chatbot in his ear narrating tokens. He wanted to hand off a task and get on with his life.

“I just want results. I don't need real-time interaction. I need a tool to dispatch tasks anytime, anywhere.”

That single sentence is the entire product thesis compressed into one breath. The phone, the laptop, the chat window — all of them assume you want to sit and watch. Nexting assumes the opposite. You raise your hand, you say the thing, and you walk away. The work happens somewhere else, on your own agents, and the answer finds you when it is done.

It is a subtle reframing, but it changes everything downstream. Once you accept that the user does not want to watch, you stop optimizing for a beautiful live token stream and start optimizing for reliable hand-off and reliable return. You stop building a companion and start building a courier. Almost every difference between Nexting and the assistant wearables that came before it traces back to this one choice about what the person actually wants, which is not company — it is leverage over their own time.

Who is Eric Shang?

Before Nexting, Eric Shang was an embedded software engineer at DJI — the Shenzhen drone giant that, over the last several years, expanded into automotive and now supplies autonomous driving technology to carmakers as a Tier 1 supplier. Inside that world, Shang worked on autonomous driving and on AUTOSAR, the automotive software architecture standard that governs how safety-critical embedded code is structured and certified.

What that background actually teaches you

It is hard to overstate how formative automotive embedded work is. AUTOSAR is not a place for cowboys. It is a discipline built around the assumption that the code you write will run, unattended, in a moving vehicle, and that a single unhandled edge case is not a bug report — it is a hazard. Engineers who come up through that environment internalize a particular mindset: handle errors explicitly, never trust an input, design for the case where the network drops, the sensor lies, or the power browns out.

DJI itself is famous for an unusually demanding engineering culture — a difficult hiring bar and intense internal competition where teams are pitted against each other to ship the better design. That environment produces engineers who are comfortable owning a problem end to end and who expect their work to be measured against something real, not a slide.

All of that matters because a wearable agent dispatcher is, at its core, an embedded systems problem wearing a consumer-product costume. The thing has to capture audio reliably on a tiny power budget, survive flaky connectivity, and never lose your task. A founder who spent years making code behave inside a car is exactly the kind of person who treats “the phone is locked and you walked out of Wi-Fi range” as a requirement, not an excuse.

Dispatch, don't chat

To understand the engineering, you first have to understand the interaction model, because every technical decision flows from it. Nexting is not an assistant you converse with. It is a dispatcher. The difference is the difference between a walkie-talkie and a telephone call.

• One sentence out. You press, you speak, you release. “Pull the latest sales numbers and summarize the trend.” “Refactor the auth module and open a pull request.” “Remind me to call the supplier at three.”
• The agent runs in the background. Not a hosted black box — your agent. Claude Code on your machine, OpenClaw, Codex. The same tools you already trust, now reachable from your collar.
• Results come back when ready. The answer arrives even while your phone is locked or in your pocket and you are moving. You do not babysit a token stream.

This fire-and-forget posture is liberating for the user and brutal for the engineer, because it removes the one crutch most AI products lean on: the assumption that a human is sitting there, watching, ready to retry. When the interaction is asynchronous and the user has already walked away, the system has to be honest about state. Did the task land? Is it running? Did it fail silently? A dispatcher that loses your task is worse than no dispatcher at all.

A day with a dispatcher on your collar

Abstractions are easy to nod along to and hard to feel, so it helps to walk through an ordinary day. You wake up, clip the PIN to your shirt, and forget about it. On the walk to the kitchen you press it and say, “Check overnight error logs and tell me if anything is on fire.” You do not stop walking. By the time the coffee is poured, a short summary is waiting — not a wall of tokens, a verdict.

Mid-morning you are away from the desk, in a meeting, and a decision lands that needs a code change. You press and say, “On the billing branch, add the retry logic we discussed and open a pull request.” Your Claude Code session, running on the laptop back at your desk, picks it up and starts working. You are still in the meeting. The work is happening somewhere you are not. When it finishes, the PIN does not interrupt you; the result is simply there when you look.

In the afternoon you remember something on the train. “Remind me to email the supplier about the enclosure tolerance at four.” That one does not even need an agent — it touches your phone's own Reminders. The point of the day is not any single task. It is that the friction of reaching your tools collapsed to one sentence, and the requirement that you sit still and watch disappeared entirely. That is the feeling the entire stack exists to produce, and almost every hard engineering decision below is in service of making that feeling reliable.

What “solo full-stack” really means

When people say someone is building a startup alone, they usually mean one person wrote the app and outsourced the rest. Nexting is more literal than that. The same person is responsible for the physical device, the code that runs on it, the phone apps, the servers, and the marketing site. Each of those is, by itself, a career. Stacked together they are five careers running in parallel, with no one to hand the hard parts to.

The data backs up how unusual this is. Solo founders are on the rise — roughly a third of new startups now launch with a single founder — but they are conspicuously underrepresented in hardware and deep tech, precisely because those categories demand space, equipment, capital, and specialized expertise that one person rarely carries across every discipline at once. Building a consumer electronics device alone is not the easy path. It is one of the hardest paths there is.

The hardware layer: a shape you forget you are wearing

The first hard problem of any wearable is not electronics. It is the human body. A device only works if you keep it on, and you only keep it on if you forget it is there. That constraint — be invisible — collides head-on with everything the hardware needs to do: hear you clearly, last through the day, and hold a radio link to your phone.

Nexting's answer for the shipping product is the PIN — a small device that clips to your collar, where a microphone has the best shot at your voice and where a button is reachable without fishing in a pocket. The collar position is not an accident; it is the quietest place to put a thing that has to listen. The flagship Ring, still in private beta, pushes invisibility further: the most discreet possible way to raise your hand and dispatch an agent.

Why specs are not the headline

It would be easy to lead with part numbers and radio versions. Nexting deliberately does not. Specs are table stakes, and quoting numbers you have not stress-tested across thousands of real wearing hours is how hardware startups lose trust. What matters at this stage is the behavior: does it capture your sentence cleanly when you are walking down a noisy street, and does the battery get you through the parts of the day you actually use it. Those are claims that have to be earned in the field, not printed on a box.

The firmware layer: where the embedded discipline pays off

This is the layer where Shang's background stops being a biography line and starts being a competitive advantage. Firmware is the code that runs directly on the wearable, with no operating system to catch its mistakes. It has to wake on a button press, capture audio, encode it, hand it to the radio, and do all of that within a power envelope measured in milliwatts — then go back to sleep so the battery survives.

The skills that make this tractable are exactly the ones automotive embedded work drills into you: deterministic real-time behavior, ruthless power management, and the habit of treating every external event as something that can fail. A dropped radio packet, a half-captured utterance, a brownout mid-transmission — in a car these are hazards you design around; in a wearable they are the difference between “it just works” and a device people quietly stop wearing.

“A dispatcher that loses your task is worse than no dispatcher at all. The firmware's only real job is to never be the reason a sentence disappears.”

Crucially, the firmware is on GitHub. That is a deliberate choice with two motives. The first is trust: a device that listens to your life should let you read the code that does the listening. The second is leverage — an early-adopter community that can inspect, build, and improve the firmware is a force multiplier a solo founder cannot otherwise buy.

The voice-capture problem, up close

Of all the firmware's jobs, capturing your voice well is the one users feel most directly and engineers underestimate most often. A microphone on your collar is not in a recording studio. It is in the wind, near a rustling jacket, on a street with traffic, in a cafe with a dozen other conversations. The same hardware has to get a clean enough signal that downstream speech-to-text turns your sentence into the right text, the first time, because in a dispatcher there is no screen you are staring at to catch a mistranscription before it becomes a wrong task.

That is a genuine engineering tension. Better capture — more processing, higher sample rates, more aggressive noise handling — costs power, and power is the budget that decides whether the device lasts the day. Every milliwatt spent cleaning audio is a milliwatt not available to keep the radio alive or the battery lasting. Resolving that tension is exactly the kind of constrained optimization embedded engineers do for a living: find the cheapest processing that still produces a transcript good enough to act on, and push everything else off the device.

Why transcription lives off the wearable

Nexting does not try to run heavy speech recognition on the wearable itself. The device captures and encodes; the phone and cloud do the linguistic heavy lifting, with a speech-to-text pipeline tuned for the kind of clipped, imperative sentences a dispatcher receives. Even small details matter here — getting punctuation right, for instance, depends on prompting the transcription model with the right examples, the sort of unglamorous tuning that separates a transcript you can act on from one that quietly mangles a command. Pushing that work upstream keeps the wearable simple, cheap, and power-frugal, which is the right place for the complexity to live.

The app layer: the bridge that lives on your body

The wearable does not talk to the internet directly. It talks to your phone, and your phone — through the Nexting app — is the bridge between a button on your collar and an agent running on your laptop. That bridge does a surprising amount of work: pairing and ownership, turning speech into text, routing the request to the right agent, and rendering whatever comes back in a way you can actually read on a small screen.

Two apps, kept honest against each other

There is an iOS app and an Android app, and they are built to mirror each other feature for feature. The iOS app uses UIKit for the chat surfaces — where keyboard handling and fast scrolling have to be flawless — and SwiftUI for settings. The Android app is a deliberate one-to-one port in Kotlin and Jetpack Compose. Maintaining parity across two native platforms is, again, normally a team sport. Doing it solo forces a discipline of checking one implementation against the other constantly, so the two surfaces do not drift into subtly different products.

The app is also where Nexting earns its “works with your real life” claim. It integrates with the iPhone's own world — Calendar, Reminders, Contacts, HealthKit, Location, HomeKit — so an agent can schedule, remind, and act on context instead of living in a sandbox. There is a Feishu and Lark voice bridge for teams, and a skills ecosystem that flows through ClawHub and GitHub. None of that is glamorous to build. All of it is what separates a demo from a tool you reach for daily.

The cloud layer: delivering results when nobody is watching

If the firmware's job is to never lose a sentence, the cloud's job is to never lose an answer. This is the part of an agent dispatcher that is genuinely hard, and it is where a lot of would-be competitors quietly fall back to “keep the app open and wait.” Nexting's whole premise is that you have already walked away, so the backend has to deliver to a phone that is locked, asleep, or out of the app entirely.

That means a real backend — a Node service, a PostgreSQL database, Redis, all running in containers — that queues tasks, tracks their state, relays messages, and pushes results down when they are ready. It means handling the case where your phone is briefly offline by holding the result and delivering it on reconnect, and the case where the agent finishes an hour later by waking the phone with a notification rather than hoping you happen to be looking.

Strict isolation between modes

Nexting connects to several different agent worlds — its own managed mode, your self-hosted OpenClaw, a Hermes connection, a Feishu bridge, plus the dedicated Claude Code and Codex surfaces. The architectural rule is that these never share code paths. Each mode has its own handler, its own data tagging, its own routing. That isolation is unglamorous and easy to skip when you are moving fast alone — and it is exactly the kind of corner that, when cut, leaks one user's data into another's session. Keeping the modes hermetically separate is a deliberate, repeatedly enforced discipline, not an accident.

The offline-delivery problem, in detail

It is worth dwelling on offline delivery, because it is the single hardest promise the product makes and the one most likely to break quietly. The pitch is “results come back even while your phone is locked and you are moving.” That sentence hides a thicket of failure modes that an embedded engineer recognizes instantly, because they are the same ones that haunt any system where the client is not reliably present.

Consider what can go wrong between “you said the sentence” and “you got the answer.” The phone's live connection can drop while you walk into an elevator. The agent can take a minute or an hour to finish. The app can be killed by the operating system to save memory. You can switch networks. Any one of those, handled naively, ends with a task that vanished and a user who learns not to trust the device. So the backend cannot assume the phone is there. It has to assume the phone is usually gone.

The shape of the solution is a system that holds state on the user's behalf and reaches out when the moment is right:

• Queue, don't assume. A task and its eventual result are durable records, not transient messages that evaporate if no one is listening.
• Deliver on reconnect. When the phone comes back — out of the elevator, onto Wi-Fi — the system reconciles what it missed and hands it over, without duplicating what already arrived.
• Wake the phone when needed. If the result lands while the app is closed, a push notification brings it back, with the content shaped so the alert is useful on its own, not a cryptic ping.
• Know who is actually connected. Deciding whether a user is “online” comes down to whether there is a live connection — and getting that judgment wrong is how you either spam someone with redundant pushes or fail to deliver at all.

None of this is visible in a demo, and all of it is the actual product. A flashy thirty-second video can be faked with the app open and the agent primed. A dispatcher you trust with a real task while you walk out the door cannot. That gap — between the demo and the daily-driver — is precisely where the embedded-systems instinct to engineer for the failure case becomes the whole ballgame.

Remote-controlling a running session from your pocket

Dispatching a fresh task is the headline feature, but there is a subtler capability that long-time agent users tend to fall in love with: you can reach into a Claude Code session that is already running and steer it from your body. The agent asks a clarifying question; you answer by voice from the hallway. It is partway through a long job; you check on it from your pocket without opening the laptop. The session keeps working while you move.

Mechanically, this is harder than it sounds, because a live coding session is a stateful, long-lived thing, and the wearable is a thin, intermittent client to it. The system has to keep a faithful picture of what the session is doing — is it running, is it waiting on you, did it finish, did it die — and stream just enough of that state down to a phone without flooding it. It has to survive the session going briefly quiet without falsely declaring it dead, and it has to let you inject an instruction mid-flight without corrupting the agent's turn. Getting liveness right — knowing the true difference between “thinking” and “stuck” — is one of those problems that looks trivial in a demo and takes real engineering to make trustworthy in the field.

This is also where the dispatcher model and the “own your AI” principle reinforce each other. Because the agent is yours, running on your machine, remote-controlling it is just a secure channel to software you already control — not a request to a vendor's opaque service. The wearable is the remote; the brains stay where you put them.

The skills ecosystem, and why one person needs it

No single founder can build every integration a useful agent platform needs. The way out of that trap is to make the platform extensible and let other people add the long tail. That is what the OpenClaw plugin standard is for: an open protocol that lets developers write skills — from smart-home control to health tracking to bespoke workflows — and have them work with the device without Nexting hand-coding each one.

For the user, skills flow through familiar channels: a ClawHub catalog and GitHub, with the app syncing your chosen skills down to your agent. For a solo founder, this is leverage in its purest form. The core team of one builds the seams — the protocol, the sync, the safety boundaries — and the ecosystem fills the surface area. It is the same logic that makes open firmware and an open plugin standard not just ideological choices but survival strategy: a single person cannot out-build a community, so the right move is to invite one in.

• Open protocol. OpenClaw is a standard, not a walled garden, so skills are not hostage to one vendor's roadmap.
• Distribution you already know. Skills live where developers already are — GitHub and a public catalog — instead of behind a proprietary store.
• Agent-installable. Adding a new capability can be as simple as telling your agent to go set itself up — the dispatcher model applied to its own extensibility.

Privacy as an architecture, not a promise

An always-on device that hears your life only deserves to exist if privacy is real. Plenty of products say the right words. Nexting tries to make the words structurally true. In the bring-your-own-agent modes — where you connect Claude Code, OpenClaw, or Codex — the design is end-to-end encrypted by default: the agent runs on your device, the keys stay with you, and the cloud relays only ciphertext it cannot read.

That is a meaningfully different posture from the assistant wearables that route everything through a vendor's servers in the clear. The cloud still does real work — queuing, delivery, push — but in BYOA mode it is a courier carrying a sealed envelope, not a reader of your mail.

Being honest about the limits

Honesty cuts both ways. The managed Nexting Pro tier — which gives you hosted access to models like Claude, GPT-4o, and Gemini for a monthly fee — necessarily involves the cloud, because the model runs there. Nexting does not pretend otherwise. The commitment that holds across both worlds is the plain one: it does not train on, sell, or share your data, and you can delete it at any time. A privacy claim is only worth anything if it survives contact with the cases where it is inconvenient.

“The cloud is a courier carrying a sealed envelope, not a reader of your mail.”

The Co-Builder Edition: open hardware, on purpose

Here is the part most companies would hide, and Nexting puts on the label. The units shipping today are 3D-printed and user-assembled. That is not a polished injection-molded gadget off a finished production line. It is, frankly, early hardware — and Nexting reframes that reality honestly as the Co-Builder Edition: open hardware in the hands of early adopters who are helping shape the product.

This is not spin trying to dress up a limitation. It is a recognized strategy with a real track record. In open hardware, the earliest adopters tend to be people who genuinely believe in the open-source ethos — they want to inspect, modify, and improve the thing, and they are often influential voices who carry a small project further than any ad budget could. For a solo founder without a factory or a marketing department, turning your first customers into co-builders is not just a nice narrative; it is how hardware actually gets refined before it scales.

• It is honest. Calling a 3D-printed unit a co-builder edition tells you exactly what you are buying, instead of overselling a polished consumer product that does not exist yet.
• It is open. The firmware is on GitHub and the plugin standard is open, so the people who buy in early can genuinely change the product.
• It builds the right community. Early backers are not just buyers — they are the most valuable source of feedback a hardware project can have before it commits to tooling and scale.

There is a long lineage here, from the open-source hardware movement to companies that treat openness as a decade-long commitment rather than a launch gimmick. Nexting is choosing to start on that side of the line.

Building in public, and the open-source line

The other half of the strategy is building in public. Sharing how the product is being made — the trade-offs, the rough edges, the roadmap — is how a one-person project earns attention and trust it could never buy. Build-in-public is a well-worn path for exactly this reason: it grows a community of people who feel like participants rather than targets, and it surfaces the early adopters who will carry the product forward.

Core and partial open source — said precisely

It is worth being exact about what “open” means here, because the word gets abused. Nexting is core and partial open source — not fully open source. The firmware is on GitHub. The OpenClaw plugin standard is an open protocol that lets developers extend the device with their own skills. But not every line of the stack is public, and Nexting does not claim it is. Overclaiming openness is its own kind of dishonesty, and a project asking you to trust it with your voice cannot afford that.

That openness has a practical payoff for a solo founder. An open plugin standard means the skills ecosystem can grow without Shang writing every integration. Open firmware means bugs can be found by more eyes than one. The model is leverage: do the irreducible core yourself, and design the seams so other people can extend it.

How Nexting differs from the wearables that came before

It is fair to be skeptical of AI wearables. The category has a graveyard. The most-hyped entrant, the Humane AI Pin, launched at $499 plus a $24-a-month subscription and was discontinued, taking a lot of the category's credibility with it. Any new device in this space inherits that skepticism and has to answer it directly.

Nexting's answer is that those devices tried to be a new phone — a standalone assistant meant to replace the computer in your pocket. That is a brutal bar to clear, and most missed it. Nexting is not trying to replace your phone or your agents. It is the shortest path to the agents you already own and trust. It does not need its own foundation model or its own cellular plan, because the intelligence already lives on your machines. It just needs to be the most reliable way to reach it from your body.

The economics follow from the philosophy. The PIN is $129 with free worldwide shipping from Shenzhen, and bring-your-own-agent is free — you only pay if you want the managed Pro tier at $29 a month or $279 a year. There is no $24 toll just to keep the lights on.

The roadmap, told honestly

The fastest way to lose trust in hardware is to promise dates and specs you cannot keep. So here is the roadmap stated plainly, with no invented numbers.

• Nexting PIN — shipping now. $129, free worldwide shipping from Shenzhen, currently in Co-Builder Edition form: 3D-printed and user-assembled, openly framed as early hardware for people who want to shape it.
• Nexting Ring — private beta. The flagship form factor, the most invisible way to dispatch an agent. Price and ship date are not public yet, and Nexting will not invent them. When the numbers are real, they will be published.
• The software keeps shipping. Deeper integration with Claude Code, OpenClaw, and Codex; a growing skills ecosystem; the ability to remote-control a running Claude Code session from your pocket; and continued parity work across iOS and Android.

Notice what is missing: no untested battery-life figure, no weight spec presented as final, no latency promise. Those claims have to be earned across real wearing hours before they belong in a sentence. That restraint is itself a product decision — the kind an embedded engineer who has shipped safety-critical code tends to make by reflex.

What building this solo actually costs

It would be dishonest to tell this story as a clean triumph. The research on solo founders is unambiguous about the toll: burnout is the single biggest predictor of failure, decision fatigue is constant, and there is no co-founder to share the weight or argue you out of a bad call. Hardware sharpens every one of those edges, because the feedback loops are slow and the mistakes are physical. You cannot hot-patch an enclosure.

The honest reason to do it anyway is the one Shang started with: he wanted the tool to exist, for himself, badly enough to build every layer of it. That is a different motivation than chasing a market, and it tends to produce different products — ones where the hard, invisible parts (offline delivery, mode isolation, real encryption) get the care they need, because the person building them is also the person who will be annoyed when they fail.

“I just want results. I don't need real-time interaction. I need a tool to dispatch tasks anytime, anywhere.”

A solo founder cannot out-resource a Humane or a Meta. What one person can do is make a sharper bet, hold a clearer point of view, and refuse the corners that big teams cut by committee. Nexting is that bet: not a smarter assistant, but the most reliable way to hand work to the agents you already have, and then get on with your day.

Why one person can sometimes move faster

The solo-founder story is usually told as a tale of limitation, and the limitations are real. But there is a counter-current worth being honest about. A single engineer who holds the whole stack in one head pays no coordination tax. There are no integration meetings between the firmware team and the app team, because they are the same person. A decision that touches hardware, protocol, and UI at once — the kind that gets stuck in committee at a larger company — can be made and shipped in an afternoon.

That coherence shows up in the product. The reason the firmware, the radio protocol, the app, and the backend agree with each other is that one mind designed all of them to agree. When the dispatcher model demanded that a task never be lost, the person who decided that is the same person writing the firmware that captures it, the backend that queues it, and the app that displays it. End-to-end ownership is the rare luxury that lets a solo founder build something genuinely integrated rather than a federation of compromises.

The discipline that makes it survivable is borrowed straight from embedded engineering: a tight verification loop. Make a change, build it, run the tests, review it adversarially, and only then ship it. When you are the entire QA department, the only protection against your own mistakes is process, applied without exception. It is not glamorous, but it is the difference between a one-person project that ships reliably and one that ships chaos.

Nexting review: the honest verdict

If you came looking for a review, here is the fair summary, strengths and caveats together. Nexting is the clearest expression yet of the agent-dispatcher idea: own your AI, dispatch by voice, get results while you live your life, and keep your data yours. The pricing is honest — a $129 device and free bring-your-own-agent, with an optional managed tier — which stands in sharp contrast to the expensive, subscription-gated wearables that preceded it.

The caveats are equally plain. The shipping unit is a Co-Builder Edition: 3D-printed, user-assembled, early. The flagship Ring is in private beta with no public price or date. And the most demanding specs — battery life, weight, latency under load — are the kind of claims a serious builder declines to publish until they are earned. None of that is hidden; all of it is stated up front, which is itself a signal about how the project intends to treat the people who buy in.

“A solo founder cannot out-resource the giants. What one person can do is make a sharper bet and refuse the corners big teams cut by committee.”

Frequently asked, answered plainly

• Who is the Nexting founder? Eric Shang (尚奕勇), a former embedded software engineer at DJI who worked on autonomous driving and AUTOSAR, based in Guangdong. He builds the hardware, firmware, iOS app, cloud backend, and website himself.
• Do I need a subscription? No. Bring-your-own-agent is free; you only pay $29/month or $279/year if you want the managed Nexting Pro tier with hosted models.
• Is it private? In BYOA modes it is end-to-end encrypted by default — the agent runs on your device, the keys stay with you, and the cloud relays ciphertext. Managed Pro uses the cloud by necessity. Either way, your data is never trained on, sold, or shared, and you can delete it anytime.
• Is it open source? Core and partial — not fully. The firmware is on GitHub and OpenClaw is an open plugin standard, but not every layer is public, and Nexting does not claim otherwise.
• What can I buy today? The Nexting PIN at $129, shipping now with free worldwide shipping from Shenzhen, in Co-Builder Edition form. The Ring is in private beta.

Should you try it?

Be clear-eyed about what you are buying. If you want a finished, shrink-wrapped consumer gadget with guaranteed specs, the Co-Builder Edition is not that yet, and Nexting will be the first to tell you so. But if you already live in the world of AI agents — if you run Claude Code, OpenClaw, or Codex and you have felt the same itch of leaving your most capable collaborators chained to a desk — then this is the most direct attempt yet to set them free, built by someone who felt that itch first and decided to fix it the hard way: completely, and mostly alone.

There is a quiet bet underneath all of this about where AI is going. If the future is a small number of giant assistants you rent, then a dispatcher for your own agents is a niche. But if the future is the one already taking shape — everyone running their own capable agents, on their own machines, doing real work — then the missing piece is not another model. It is a humane, reliable, private way to reach those agents from anywhere, with your hands free and your attention on your life. That is the bet Nexting is making, and it is why the device is a dispatcher and not an oracle.

That is the whole story. One former DJI embedded engineer, in Guangdong, building hardware, firmware, two apps, a backend, and a website, in public, so that you can say one sentence and walk away while your own agents do the rest.