Back

Working on Supermatter - Agent Swarm Now Runs Your Compute Cluster & SSH | Build Log #2

·4 min read
Working on Supermatter - Agent Swarm Now Runs Your Compute Cluster & SSH | Build Log #2

Supermatter is an AI material science and structural engineering agent that helps engineering teams design, simulate and discover better materials — faster. Parallel local-first swarm agents for serious engineering teams.

The goal is superhuman-level performance in material science and structural engineering — a full agent team that can reason, simulate and iterate at a level no single engineer can match. Supermatter is in heavy development and early stage, but already producing strong results. I'm building this solo and sharing the process openly — targeting enterprises, university research labs, individual engineers and national research centers.

What changed

Supermatter agents could only run commands locally. Fine for prototyping, but the whole point is to target real GPU clusters — and those are remote. So I added SSH remote execution.

Agents can now connect to any remote machine over SSH and work on it as naturally as they work locally. Set up a connection, point a swarm at it, and the agents handle the rest.


What it can do

Persistent remote sessions. Agents don't run isolated one-off commands. They get a real, stateful shell session on the remote machine. cd into a directory, it stays. Activate a virtual environment, it persists. An agent can work in a remote cluster for an entire run without losing context.

Dedicated SSH specialist. When you add SSH targets to a swarm, a specialist agent is automatically spawned alongside the regular agents. Regular agents handle local computation. The specialist handles remote. It reads the other agents' strategies and figures out what remote work to run — setting up environments, launching training jobs, checking GPU utilization.

Your credentials stay on your machine. SSH profiles are stored locally with strict permissions and the platform only sees opaque identifiers — no hostnames, no usernames, no keys ever leave your machine.

Clean by design. One agent owns the remote shell, so there are no state collisions or environment bleed between agents. Commands are serialized — ordered, predictable, reproducible.


How it works

  1. Add SSH connections in the Supermatter UI (host, key, etc.)
  2. Test the connection from the UI
  3. Select SSH targets when launching a swarm
  4. The swarm spawns regular agents for local work + an SSH specialist for remote work
  5. The specialist reads the swarm's plan and runs what's needed on the remote machine
  6. When the swarm ends, all remote sessions are closed cleanly

Nothing to configure on the remote side, no agent framework to install on the cluster — it's just SSH.


What this unlocks

The swarm can now split work across local and remote. Regular agents handle research, analysis, and local computation while the SSH specialist targets the GPU cluster — all running in parallel.

Some things that become possible:

  • Remote training runs. Point the specialist at a multi-GPU node, have it set up the environment and launch a training job while other agents prepare data or analyze previous results locally.
  • GPU cluster monitoring. The specialist can check utilization, manage running jobs, and iterate on configurations without manual SSH sessions.
  • Large-scale simulations. Scientific computing workloads that need real hardware. The specialist manages the remote execution, the rest of the swarm handles everything around it.
  • Multi-cluster workflows. Target different clusters for different parts of the work. One for training, one for inference benchmarking, one for data preprocessing.

The specialist agent pattern generalizes beyond SSH. Any tool that needs exclusive state — database connections, instrument control, cloud APIs — can follow the same model. Separate the tool, dedicate an agent, give it context about what the swarm needs.


What's next

Multi-target support is next — one specialist managing multiple clusters, or multiple specialists each owning a different target. After that, long-running job management and extending the specialist pattern to other exclusive-state tools beyond SSH.