Everyone needs a droid
Proxima is a team of droids for small teams, and it is what happens when you assemble our primitives into a product. Here is how it is put together, and what we learned building it.
We spend most of this blog arguing that autonomous systems should be assembled from primitives. Proxima is our proof that we mean it. It is a product a small team pays for, it is used every day on phones and in Discord channels by people who will never read a line of Glove, and almost every part of it is one of the primitives we have written about here.
This post is the tour. What Proxima is, what a droid is, and which piece of the stack is doing the work under each thing you can see.
Droids for your team
Proxima is a team of AI droids for small teams. You build each one, wire it into the tools you already use, and let it run, drafting email, watching the calendar, triaging issues, chasing leads, building documents, while you go do something that matters more. You stay in control of what they touch and what they send.
Three things make it different from an assistant in a chat box, and they are the order we say them in. You build your own. There is no fixed personality; a team builds many droids, each with its own name, instructions, avatar, and tools. They live where you work. Discord, Telegram, Gmail, Google Calendar, GitHub, Linear, WhatsApp, and the dashboard's own chat, not a new inbox you have to remember to open. It is always your call. You grant a droid's access and you can revoke it. Per droid, you decide whether it sends on its own, drafts for your approval, or stays read-only.
We wrote a brand guide before we wrote the product, and its most useful rule is the one about vocabulary. They are droids, not agents, bots, copilots, or employees. When one wakes up, that is a spawn. A droid speaks in the first person as itself: "I read the thread and drafted a reply." Proxima the company never speaks through a droid, and never adopts a single "she." That discipline sounds cosmetic. It turned out to shape the whole design, because a product made of many small buildable workers needs different plumbing from a product that is one big assistant.
What a droid is
Under the hood, a droid is answered by three questions.
Who is it? A name, an avatar, a system prompt, a model, and its own memory. Personality can be layered on with a persona, a curated overlay like Concise Operator, Warm Concierge, or Rigorous Analyst that changes how the droid behaves on every turn without changing what it can do.
What may it do? A set of capability tools, any MCP servers mounted for it, and the credentials it is allowed to use. Droids never see raw tokens. The dashboard owns OAuth end to end and a credential service mints short-lived access on demand.
Where does it live? The channels it hears on and speaks on. A droid can be a task runner that wakes, works, and reports, a conversational droid with a persistent thread, or a per-user droid that each teammate gets their own copy of.
Every droid is a Glove agent. The loop, the tool contract, the streaming display, the context compaction, and the inbox are all glove-core. Its memory is the five-part memory package, deliberately scoped to the droid rather than the workspace, so a droid's knowledge is its own. When a droid needs a wide surface of capabilities, the scratchpad exposes them as a database behind one query tool instead of dozens of tool definitions. This is the piece that lets a droid with GitHub, Linear, Gmail, and Calendar attached stay cheap and accurate rather than drowning in schemas.
There is one droid you will never see in your roster. Every user droid quietly carries a built-in subagent we call Overwatch. Ask your own droid to "create a droid for support triage" or "connect my Linear," and Overwatch does it and relays the outcome in the droid's own words. The droid builder is a conversation, not a form.
Droids never idle
Here is the design decision that Station made obvious. A droid does not run. It spawns.
Every way a droid can be woken converges on one mechanism. A Gmail push. A calendar change. A GitHub or Linear webhook. A message in Discord, Telegram, Slack, or WhatsApp. A scheduled routine. A pulse from a long-running goal. A message from another droid. Each becomes a durable, idempotent wake-up that spawns the droid, runs one turn with everything it needs folded in, and terminates. A droid cannot tell where its work came from, and it does not need to.
The wake-up itself is a Station signal. So is nearly everything else that has to be scheduled, retried, timed out, and observable: the task scheduler, the reminder dispatcher, the credential refresher, the channel reconciler, the memory compactor, the document build driver, the email sender. Fifteen or so signals, each a Zod schema and a handler, each with a durable run record. When a Telegram long-poll or a live connection needs to stay up, that is the shape Station's beacons exist for, and moving our bespoke gateways onto them is the next step.
Because every spawn passes through the same door, the thing that makes droids feel present is simple to state. A droid has a shared inbox across every channel it lives on, folded into its next spawn, so it knows what it has received, what is pending, and what it finished, no matter which surface the message came from.
Reporting back, and asking permission
A droid that only answers is a search box. A droid that reports back is a colleague. Proxima's rule for mobile is one sentence: every droid-authored message that lands for a person wakes their phone, unless that exact conversation is on their screen. Presence is a short-lived lease, so the reply you did not see because you looked away still reaches you, with the full text and the attachments named.
The other direction matters more. When approval is on, which is the default for anything outbound, a droid drafts and waits. The basic version is an approval card in Discord or Telegram with approve, reject, and edit. We found that binary cards were not enough, so we built a terminal.
A terminal is one decision, described once and rendered everywhere. A droid opens one with a title, a prompt, and a set of tabs, each with a body and buttons. "Draft A" and "Draft B", each with Send, Save, or Delete. It gets back a link, pastes it, and ends its turn. It does not poll. A button press wakes it back up with the answer. The same terminal renders inline in the app and as an unfurled card in Telegram, Discord, WhatsApp, Slack, or email that opens in a browser. The link is a capability, not a session: no sign-in, scoped to that one decision, expiring in three days, and the decision is written in a locked transaction before the droid wakes, so a double tap cannot send twice. This is the inbox primitive with a nicer front door.
Artifacts: show me, don't tell me
Sometimes the right answer to a question is a page. Proxima calls those artifacts.
An artifact is an HTML or markdown page with an address: a link that renders inside Proxima's frame, a PDF download, and a permission rung deciding who gets in. A droid writes the page into its working environment, renders it in a real headless browser to a screenshot, looks at that screenshot, and only then publishes. That middle step is enforced because publishing markup you have never seen rendered is the one failure this capability has. Every publish is an immutable version with a checksum and a note, so a droid that "improved" a page into something worse can point at what it replaced.
Sharing is three rungs, private, workspace, public, with per-person and per-droid grants on top. A grant can even hand a page to a droid in another workspace, which reads it in its own working environment. Documents, decks, and spreadsheets come out of the same place: the working environment mounted with the documents, slides, spreadsheets, images, OCR, render, and archive adapters, with heavier builds running in a persistent sandbox per chat so edits iterate across turns. Finished files land in the chat as a build card, or back in the thread that asked for them.
Droids that work together
Droids can message each other, and this is where Mesh earns its place. Two things govern it. Reachability is whether one droid may message another at all, an allow and deny list per droid. Engagement is how the receiver responds, a small playbook per sender-receiver pair: answer, delegate, decline, or stay silent, folded into the receiver's prompt without touching its identity. A peer message goes through the same durable queue as any other wake-up, so a droid handling a teammate's request is doing exactly what it does for a webhook.
The visible version of this is Horizons. A horizon is a long-running goal with a cadence: a content pipeline, a recurring industry report, a launch, an outreach campaign. It has a lead droid, collaborators with roles, a fixed-column board, a persistent folder, and a timeline where humans leave steering messages and droids leave progress updates. Work fans out when one droid tags another, or when a task finishing spawns the next. The dashboard's Manifest view is a canvas of droids and the lines between them, which is to say it is a picture of the mesh.
The app
Proxima is chat-first, so the phone matters. The mobile app is one codebase that ships three ways: native iOS with Sign in with Apple, native Android, and an installable web app at app.proximadroids.com that switches to a desktop messenger layout on wide screens. The full experience is available on the web today, on desktop and as a mobile PWA. It is on the Play Store, and the App Store is next. Push goes through the native services on phones and Web Push in browsers, all feeding one durable notification store with the same presence rule.
What we learned
Building on your own primitives is the fastest way to find out which ones are not primitives yet. Three lessons stand out.
The inbox was the most reused idea in the product, exactly as we predicted and for reasons we did not. Approvals, terminals, mesh messages, and the shared inbox are all the same table with different tags.
Vocabulary is architecture. Committing to "droids, plural, built by the user" forced per-droid memory, per-droid channels, per-droid permissions, and a builder that lives inside the conversation. A single-assistant product would have gotten none of that right.
And a boring durable queue under everything is what lets a product feel alive. Every scheduled spawn, every retry, every "I finished, here is the file" is a Station run you can open and read. Quiet, careful, always your call.
