What is Atoms Agent Crews SDK?
The Atoms Agent Crews SDK is the Python framework for building voice agents on the Smallest AI platform. Your code owns the LLM turn and any application logic. The platform owns speech-to-text, text-to-speech, telephony, and turn-taking. The SDK handles streaming audio, conversation state, and tool coordination in between.
This page walks the whole picture. What each piece is called, how the lifecycle runs from create to live call, the two independent versioning axes, and a working sample you can drop in.
What agent-crew is
Agent-crew lets you run the agent’s brain (the LLM turn plus your logic) as your own code, in real time over a WebSocket. Smallest handles speech-to-text, text-to-speech, telephony, and turn-taking around it. Your code owns the words. The platform owns everything around them.
Runtime boundary. Smallest handles STT and TTS. Your crew node handles the LLM turn.
Crew, node, and crew code
-
Crew. The framework that runs a set of nodes collaborating in one real-time WebSocket session. Even a single agent is a crew of one node. In code,
AtomsCrewAppis the WebSocket server that hosts crews.CrewSessionis the crew instance for one live call, which the platform connects to when a call comes in. -
Node. A unit of logic inside a session. There are two kinds.
OutputCrewNodeproduces user-facing output. Itsgenerate_response()yields text that the platform speaks. This is the “agent” most people mean.BackgroundCrewNodeobserves events silently, no audio. Use it for live sentiment, compliance, or logging. Output nodes can read its state mid-call.
Multiple nodes can run in parallel in one session.
-
Crew code. Your Python project (
server.py+ node files +requirements.txt) that defines the crew and wires its nodes in thesetup_handler. It’s the deployable artifact.agent-crew deployzips it into a build.
One agent runs one live crew build. A CrewSession hosts your nodes per call.
One agent = one platform agent (config, versioned) + one live crew build (your code, one or more nodes).
The two versioning axes
They’re independent. Deploying crew code never creates a config revision. Publishing a config revision never changes which crew build is live. Two axes, two rollback controls.
What the crew node owns
A crew node produces text. generate_response() yields text, and speak(text) emits a text event. It has no voice, language, STT, or TTS setting. Those live on the agent config. At call time the platform voices your node’s text using the agent’s active config revision, so the node always uses the latest activated voice and language. You change them by editing the config, not the node.
Full lifecycle
Create the agent (platform)
Dashboard, CLI, or SDK.
agent-crew does not create the agent. It links your local code to an existing agent. Create the agent first.
Or from the terminal:
A new agent starts with a main branch at revision 1, live.
Set the config
Voice, language, STT model, TTS voice, first message, prompt. Dashboard, or the versioning API. Each publish is a tracked revision.
Write the crew code
A project with server.py (an AtomsCrewApp) and one or more nodes. Include a requirements.txt or a pyproject.toml. See the working sample below.
Deploy (upload)
The CLI zips the directory, base64-encodes it, and sends it to the backend. The backend stores it in S3. An orchestrator builds a container image (BUILDING), deploys it (DEPLOYING), assigns a websocketUrl, and marks the build SUCCEEDED (or BUILD_FAILED / DEPLOY_FAILED).
Secrets aren’t injected yet, so ship a .env next to server.py. It rides in the zip, and load_dotenv() reads it in the cloud.
Updating config or crew code
- Update config (voice, language, prompt, and so on). Edit and publish. This creates a new revision. The next call uses it. Roll back by restoring an earlier revision.
- Update crew code. Edit and
agent-crew deploy. This creates a new build. Make it live. Roll back by making an older build live.
Config versioning
Everything on the config side works normally. Create, edit, publish, view history, diff, restore.
Eventual consistency. After a publish, get_agent and the branch head read-back lag ~1-3s. A call started right after publishing may still use the previous revision. Poll or re-fetch.
Crew-code versioning
agent-crew deployproduces a new build (deploy history).agent-crew buildslists builds. You can Make Live, Take Down, or roll back to an older build.
Deploying doesn’t touch config revisions. The two axes roll back independently.
Working sample
assistant.py is the node. Bring your own LLM by pointing base_url at your runtime, drop it for OpenAI, or use Smallest’s Electron.
server.py is the WebSocket app. It greets on join.
requirements.txt:
Run and test.
FAQ
Does agent-crew create the agent?
No. Create the agent on the platform first (dashboard, smallestai agents create, or client.atoms.agents.create_agent). Then agent-crew init links your code to it.
Where do voice, language, and STT/TTS come from?
The agent config, which is versioned. Not the crew code. The node emits text. The platform voices it with the active revision.
If I deploy new crew code, does my config, prompt, or voice change?
No. Crew code and config are independent axes.
Can I version and roll back a crew agent?
Yes on both axes.
- Config. Branches and revisions. Restore an earlier revision.
- Crew code. Builds. Make Live an older build.
Roll them back separately.
How do I change the voice?
Edit the agent config (dashboard or edit_and_publish on the synthesizer field). Publish. It becomes a tracked revision and applies on the next call.
Can I run multiple agents or nodes per call?
Yes. Multiple OutputCrewNodes and BackgroundCrewNodes in one CrewSession.
Get Started
Build your first agent in minutes.
Create, inspect, and call agents from the terminal.
Nodes, Sessions, Events.
~15 ready-to-run voice-agent crews on GitHub.

