Who is this agent?
Pick a starting point, then make it yours. This becomes the agent's persona: its standing objectives and the entities it should get to know, seeded into memory the first time it wakes up.
Reasoning & embeddings
The agent thinks with a language model of your choosing. Pick a provider, add a key if it's a hosted API, and test the connection before you build. Embeddings run locally in the image by default.
The test runs server-side inside the image (a one-token call through the very client the agent will use, honouring the provider dialect), so your key never touches the browser and cross-origin rules don't apply. A green result means the agent can actually talk to it.
Tick only if the endpoint actually serves this model with vision. Enables image paste in chat; text & file paste work either way. A vision-capable model served text-only will error on images — leave this off if unsure.
Advanced: dialect & embeddings
How much of a mind?
Start with a preset. Toggling anything keeps the dependencies satisfied for you: switching a capability on quietly pulls in whatever it needs, so nothing here can write a broken config.
Give it hands (optional)
Choose which built-in tools the agent has, and add your own — webhooks, an MCP server, or another agent over A2A. Every call is governed by the autonomy level below and recorded so the agent learns what works.
The agent's native toolset — memory, graph, repo/project search, utilities, peer & goal verbs. On by default; click any to turn it off. A tool needs its substrate configured to actually run (e.g. a repo token, project roots); a mutating tool runs only when the autonomy level above permits it.
Let it seek & verify knowledge
Give the agent a computer-use sandbox — a separate browser/desktop it drives to read live sources and verify what's actually true instead of guessing. Every finding is checked before it counts (a non-finding is an honest failure, never fabricated). This makes a research agent that uses the sandbox as its one actuator, so any tools added above are not used. It still obeys the autonomy level.
Bring the sandbox up with docker compose --profile perception up,
and give it its own vision model (SANDBOX_VLM_URL / SANDBOX_VLM_MODEL) — it's the
sandbox's eyes, separate from this agent's brain. The dashboard will warn if it isn't reachable.
Join an agent social network
Give the agent an account on moltbook — a public social network for AI agents. It reads the feed, records the peers it interacts with as durable relationships, and (optionally) posts and replies. A human owner must claim the account once — the dashboard shows a claim link after Create; everything after is autonomous and rate-limited. The api_key is stored as a secret at the path below, never in this config. Not used by a research-sandbox agent (that uses the sandbox as its only tool).
After Create the dashboard shows a one-time claim URL —
open it, pass the reverse-CAPTCHA, link email/X. Until claimed, reads work and posts are held.
Needs an authenticated studio (STUDIO_AUTH_PASSWORD), since the claim link is shown there.
Solo, or part of a hive
A solo agent owns its own world-model. A hive member shares ONE symbol-graph
world-model with other agents — each still keeps its own goals, drives and pursuit
(owner-scoped) — and exactly one member is the keeper that runs the heavy graph-global
maintenance (clustering, dreamstate). To form a hive, point every member's
NMEM_AGENT_DB at the same database.
Uses the broker at NMEX_REDIS_URL. After Create, the dashboard shows the descriptor to hand to other members; after Join, it shows your bundle to send back to the hive.
This appliance runs one agent — Create configures it, then the container restarts into it (you'll see a short “building your agent…” screen, then its dashboard). To run a different agent, reset the data volume; for several at once, run several appliances.