No central registry
Each machine announces itself every few seconds with its CPU, memory, GPU and what it can do. Adding one is starting the process; one can also be spun up in the cloud when more muscle is needed.
Under the hood
From your voice to the machine doing the work
AMSET is not a model with a website in front of it. It is a work queue, a fleet of machines emptying it and an agent with real tools on each one. This is the full path of a request.
- 1. You askWeb, phone or watch. Typed, or spoken: “Hey AMSET”, shaking the phone or tapping the orb.
- 2. The API decidesChecks permissions, answers trivia instantly and picks machine and project by capability and load.
- 3. Into the queueThe task is stored and meanwhile you get a short spoken acknowledgement instead of silence.
- 4. A machine claims and runs itAn agent with shell, files and tools, inside the folders that machine allows.
- 5. Back to youLive activity, a spoken summary with emotion, option buttons and the generated files.
Turns from the same conversation run in order, never at the same time.
The fleet
Machines that sign themselves up for work
Routing by capability and load
The conversation goes to a machine that can actually do it: the one with WhatsApp linked, the one with a GPU, the one that owns that project. If they are all busy the task waits in the queue instead of failing.
In parallel, without clashing
Several tasks per machine at once. If two touch the same repository, the second one works on an isolated copy. And two turns of the same chat never run together.
They hand work to each other
One machine can ask another for something, and the result comes back on its own to the conversation that asked — whether it succeeded or failed.
It heals itself
A supervisor that restarts, automatic updates that never cut a running task, cleanup of orphaned tasks, account rotation when one runs out of quota and a daily check of the integrations that warns if something stops working.
Cancel means cancel
When you cancel, the process and all its children die on the machine. It is not a button that only changes what you see.
What AI is underneath
Several models, each doing what it is good at
No model is best at everything, and some data should not leave the building. That is why several coexist.
- A coding agent in headless mode for the heavy lifting: read, write, run and deploy.
- The engine is chosen per task: Claude, ChatGPT (Codex), Gemini, OpenRouter or the local model, each with its model. The Claude accounts take turns on their own when one hits its limit.
- A local model on a GPU machine for classifying, chatting and orchestrating, with no per-query cost and without the text leaving the network.
- Cloud models as a fallback, for web search with cited sources and for image generation.
- Voice and vision locally too, on the GPU machine: transcribe, speak and understand images. The cloned, emotional voice of the replies goes through the cloud.
- And a council of AIs: the same question to Claude, ChatGPT and Gemini, and a single plan built from what each one said.
- Our own vector memory, kept separate between project knowledge and each user’s personal notes.
While it works
You see everything it is doing
Every step the agent takes is stored and streamed instantly: which tool it uses, what it returns, when it is thinking and when it fails. The app panel also shows the connected machines with their load and which task each one is running.
This is the kind of thing we build
The same architecture (queues, agents, real time, automatic deployment) can be applied to your product, not just ours.