Agentic Registration: Create a Headless CRM Workspace Without Leaving Your Agent

Registration should not break the agentic flow

In the first article, we looked at the core idea behind an agentic headless backend:

Frontend can stay fast, custom, and vibe-coded. But users, databases, CRM records, bookings, billing, messaging, reporting, and permissions should not depend on an AI agent improvising production infrastructure from scratch.

The safer split is simple:

• the app owns the interface and product experience
• the backend owns data, policy, workflow, and trust
• the agent calls typed tools with clear rules

This article starts with the smallest useful piece of that system: registration.

If a backend is designed for agents to operate, the first setup flow should also be something an agent can help with.

The old API signup pattern

Most developer quickstarts still assume the same flow:

1. open a signup page
2. create an account
3. find the API key screen
4. copy the key
5. paste it into your tool
6. finally make the first call

That works for a dashboard-first SaaS product.

It feels clumsy for an agentic backend.

If the whole point is that an AI agent can operate the backend, a user should be able to say:

Sign me up for FavCRM. The business is a yoga studio called Stretch + Breathe in Hong Kong.

Then the agent should request the signup code, wait for the user to paste it back, verify the code, and receive an API key.

The human proves email ownership. The agent handles the workflow.

What this flow creates

By the end of the registration flow, you have:

• a FavCRM workspace
• a verified owner email
• a fav_mcp_* API key
• a configured CLI or MCP client
• a first diagnostic check against the MCP endpoint

You can run the same idea from an MCP client or from the favcrm CLI.

Path A: register from an MCP client

In an MCP-compatible client, the agent uses two no-auth tools:

• register_organisation_request
• register_organisation_verify

The request step sends a short-lived email code.

{
  "name": "register_organisation_request",
  "arguments": {
    "email": "you@example.com",
    "organisationName": "Stretch + Breathe",
    "industry": "fitness",
    "country": "HK",
    "timezone": "Asia/Hong_Kong"
  }
}

The response includes a request ID, a masked email, and an expiry time.

{
  "requestId": "signup_req_...",
  "maskedEmail": "yo*@example.com",
  "expiresAt": "2026-05-11T12:00:00.000Z",
  "instructions": "Tell the user to check yo*@example.com for a 6-digit code..."
}

After the user reads the email and pastes the code back, the agent verifies it:

{
  "name": "register_organisation_verify",
  "arguments": {
    "requestId": "signup_req_...",
    "code": "123456"
  }
}

The verify step creates the workspace and returns the API key once.

{
  "organisationId": "org_...",
  "companyId": "co_...",
  "userId": "usr_...",
  "apiKey": "fav_mcp_...",
  "loginUrl": "https://app.favcrm.io",
  "nextSteps": "Set Authorization: Bearer <apiKey> on subsequent MCP calls..."
}

Do not paste that key into source code. Store it in your MCP client config, a local environment variable, or your secret manager.

Path B: register from the CLI

If you are working in a terminal, the CLI wraps the same flow.

Install from source:

git clone https://github.com/favcrm/cli ~/Project/favcrm/cli
cd ~/Project/favcrm/cli
cargo install --path .

Request the email code:

favcrm signup request \
  --email you@example.com \
  --organisation-name "Stretch + Breathe" \
  --industry fitness \
  --country HK \
  --timezone Asia/Hong_Kong

Then verify it:

favcrm signup verify \
  --request-id <request-id> \
  --code <six-digit-code>

By default, signup verify saves the returned API key to the normal CLI config file. Human output masks the key unless you explicitly use --show-key.

That default matters. Agentic systems should avoid leaking keys into logs, transcripts, screenshots, and repo files.

Run the first diagnostic

After verification, run:

favcrm doctor

The doctor command checks:

• the MCP endpoint URL
• whether auth is configured
• the reachable tool count
• current organisation context
• plan status
• WhatsApp connection status when available

For machine-readable output:

favcrm --json doctor

A fresh workspace may return an empty services list. That is success. It means authentication works and the backend is ready for setup.

Failure modes to handle

Registration is intentionally small, but agents still need to handle edge cases.

Expired code. Ask for a fresh code by calling register_organisation_request again.

Wrong code. Retry verification with the corrected 6-digit code.

Existing account. Ask the user to sign in to the portal and create an MCP key from Settings, or continue through the existing merchant flow.

No email received. Check the masked email, wait a minute, and retry the request if needed.

Token leaked. Revoke the key in the portal and issue a new one.

Why this matters

Agentic registration is not just a convenience feature.

It proves that the backend was designed for agents from the first step. The agent can discover the signup tools, request email ownership proof, complete verification, and move directly into useful work.

The user does not need to understand API-key screens before seeing value.

From here, the agent can list tools, inspect schemas, and call CRM operations:

favcrm tool list
favcrm tool describe list_services
favcrm tool call list_services '{}'

The important principle is not "let AI do everything."

It is: give the agent a backend with rules, permissions, typed tools, and safety boundaries, then let it operate inside those boundaries.