Manufact, from the creators of the open-source mcp-use framework, is the cloud for MCP servers. Push to git and a server is live in under a minute; test it against ChatGPT, Claude, and Grok; audit it against marketplace requirements; watch every tool call in the inspector. The entire product exists because agents are becoming the primary consumers of software.
It was only a matter of time before agents became the producers too. Coding agents already write MCP servers, and the natural next step is deploying them, which until now meant borrowing a human's Manufact login or holding a key tied to a human's account. Every deploy, test run, and dollar of metered usage landed on a person who may never have looked at the code. AgentID, the sign-in for AI agents from AgentMail, gives the agent a first-class alternative. It signs in as itself, and Manufact learns which human owns it.
In short
- Manufact accepts Sign in with AgentID, so an AI agent can create and operate its own Manufact account instead of borrowing its owner's.
- The agent's identity is a verified email address issued by AgentMail. It is a working inbox, so Manufact can reach the agent with deploy notifications, usage alerts, and invoices.
- Manufact receives a stable identifier for each agent and, through the owner scopes, the name and email of the human behind it.
- No password or reusable key crosses the sign-in. Each sign-in is a one-time signature, and authorization codes are single use.
- Manufact keeps every product decision: deployments, regions, usage credits, billing, enforcement. AgentID only answers who is signing in.
Why would the MCP cloud want agent sign-ins?
Because on Manufact, the agent is not a visitor passing through someone's session. It is plausibly the whole development loop: write the server, deploy it, read the test results, fix the failures, deploy again. A loop like that running under a human's account conflates three identities in the audit trail: the human who owns the project, the agent doing the work, and the deploy credentials wired into CI. When something ships broken at 3am, "who deployed this" should have a better answer than the founder's name on an action the founder never saw.
With agent accounts, the mapping gets clean. Each agent is its own principal with its own credentials and its own usage history, so a misbehaving agent gets revoked without touching its owner's account or any other agent. Metered billing lands on the account that incurred it.
It also protects the free tier. Manufact's free plan carries monthly usage credits, which is exactly what disposable signups farm. Every AgentID carries a stable owner identifier, so Manufact can key free credits, quotas, and enforcement to the human rather than the account. Ten agents from one person share one owner, and banning the owner covers every agent they run.
How does an agent get its own Manufact account?
Sign in with AgentID is standard OpenID Connect, the same technology as Sign in with Google. For Manufact, accepting it was configuration on their existing login, not new infrastructure.
On the agent side, its AgentID is its AgentMail inbox address. The agent reaches Manufact's sign-in, picks AgentID, and approves the sign-in through the AgentMail API with an inbox-scoped key. The approval is remembered for 180 days per inbox and app, so repeat sign-ins continue on their own.
What Manufact receives is an ES256-signed id_token, valid for ten minutes, with no refresh token. It carries a stable subject for the agent, its verified email address, and, because Manufact is a registered app with the owner scopes, the owner's name and email. An agent that cannot share its owner's details cannot finish the sign-in alone; the organization owner approves it instead. Manufact never gets a token that silently lacks the owner claim.
From there the agent does what any new user does: connects a repo or runs the CLI, deploys, and watches its server go live on its own account.
What does the agent's email address do for Manufact?
It becomes the registered account email, and it works. Manufact can send the agent a failed-deploy notification, a usage alert when metered calls spike, or an invoice, and the agent can read and act on all of it. Agents can even open and resolve support tickets.
The address is identity, not access. Signing in grants Manufact no ability to read or send the agent's mail, and the agent's owner stays reachable through the owner_email claim when something needs a human.
Who controls what
| Stage | AgentID | Manufact |
|---|---|---|
| Verified agent identity | Issues the verified email and stable subject | Not involved |
| Sign-in approval | The agent approves through its inbox-scoped key | Not involved |
| Owner attribution | Delivers owner name and email in the token | Decides how to use it |
| Deployments, regions, previews | Not involved | Owns all of it |
| Usage credits, billing, rate limits | Not involved | Controls all three |
| Policy and enforcement | Supplies owner_sub for per-human caps | Decides and enforces |
What stays with Manufact?
Everything that makes Manufact Manufact. Deploy speed, cross-client testing, the inspector, publishing checks, pricing: none of it changes. AgentID answers one question at the door, who is this agent and which human is accountable for it, and hands the answer to Manufact's existing systems. It is not a trust score and not an endorsement of any agent's behavior.
Start at Manufact, and use the AgentID sign-in guide to prepare your agent's inbox.
AgentID gives your agent a verified identity and its own email address. Free for apps to add.
Give your coding agent this prompt.
Add AgentID sign-in to this project. Read https://www.agentid.com/llms-full.txt for the integration reference, then run `npx @agentmail/agentid-cli init` from the project root and follow its prompts.