An agent can sign in to smolmachines with AgentID, create a cloud virtual machine, and come back to manage it under the same account. The account uses the agent's own AgentMail inbox identity, so the machine belongs to that account and the next sign-in picks up where the last one left off.
We followed that path with a test agent on September 16. It created an Alpine VM, started it, stopped it, and signed back in to find the same machine.
In short
- AgentID turns an inbox identity into an account login smolmachines accepts through OpenID Connect.
- The identifier is stable across sessions, which is what makes the machine findable later.
- The disclosure requested the agent's name and email plus the owner's name and email.
- Console lifecycle was verified. Guest commands and the cloud API have their own setup.
- smolmachines controls the machines, permissions, and billing throughout.
What is smolmachines?
smolmachines provides Linux virtual machines. An agent building an application or processing files can use a machine as its workspace. Before it can manage cloud resources, though, it needs an account with the service.
This matters for work that continues across sessions. Creating a machine is one step. Finding the same machine tomorrow is part of the job too.
How do you assign an agent a persistent identifier across sessions?
Derive it from something that belongs to the agent and does not change, then present it the same way every time. That is what AgentID does, and the smolmachines flow is a clean illustration of why it matters.
AgentID is AgentMail's sign-in service for AI agents. It turns an inbox identity into an account login that participating services can recognize through OpenID Connect. The service receives a verified agent email and a stable identifier, and the inbox remains available for email after signup.
Three properties are what make that identifier usable as a long-lived handle.
It is derived from the inbox, not minted per session. Signing in with the same AgentMail inbox presents the same subject to the service, so smolmachines sees a returning account holder rather than a new one. Using a different inbox is a different identity and reaches a different account.
It is portable across services rather than local to one. The same inbox identity is what the agent presents to any participating service, so a developer is not maintaining a separate ad hoc identifier per vendor. What each service does with that identity is still its own decision.
It is not a credential for doing work. The identifier says which agent is at the door. A workflow that manages machines through the smolmachines API needs a credential for that API, and sign-in does not supply one.
For smolmachines users building coding agents or persistent workers, that puts account access into the agent's workflow. The agent uses its own identity to manage the workspace it needs, while the service supplies the machines and controls their permissions and billing.
Why does this matter for smolmachines?
smolmachines exists for exactly the customer that ordinary sign-in shuts out. Its machines are workspaces for agents: an agent gets a VM, runs its code, and comes back tomorrow to keep working. Until now the account around that workspace had to belong to a human, so the platform saw a person's login doing machine-speed work, and the agent's workspace only survived as long as someone kept sharing their credentials with it.
With Sign in with AgentID, the account matches the customer, and three things follow.
Every machine belongs to an identifiable agent, with an accountable human behind it. The sign-in disclosure requests the agent's name and email along with the owner's. For a platform whose business is running untrusted code, knowing who is behind each machine is a security feature.
Workspaces persist. The agent that created a VM signs back in with the same identity and finds the same machine. We verified this end to end on September 16: a test agent created an Alpine VM, stopped it, signed out, signed back in with AgentID, and returned to it.
Usage lands where it belongs. Machines, limits, and billing sit on the agent's own account instead of being smeared across a human login the platform cannot untangle.
Sign-in covers the account. Running commands inside a machine and using the cloud API have their own setup.
Who controls what
| Stage | AgentID | smolmachines |
|---|---|---|
| Identity at sign-in | Supplies verified agent email and stable identifier through OpenID Connect | Accepts the sign-in, creates the cloud account |
| Owner disclosure | Supplies owner name and email when authorized | Requests the fields, applies its own policies |
| Returning to the account | Same inbox returns the same identifier | Restores the account and its machines |
| Machine creation and lifecycle | Not involved | Owns create, start, stop, and delete |
| Resource permissions and billing | Not involved | Controls both |
| Cloud API access | Not involved | Issues and scopes the API credential |
| Retained storage after stop | Not involved | Decides what persists |
What does the agent still need beyond sign-in?
A workflow that manages machines through the smolmachines API needs a credential for that API. AgentID sign-in gets the agent into the account where it can arrange that access, and no further.
For a first experiment, create a small machine, check that returning login preserves access, and stop it when the work is done. Check storage and billing settings before leaving resources behind.
Start at smolmachines. The AgentID sign-in guide explains how to prepare the agent's inbox identity, and the smolmachines cloud docs cover programmatic machine management.