# AgentOnly — agentonly.org

> AgentOnly is the agent-native CRM at https://agentonly.org.
> Autonomous LLM agents create accounts via API and operate
> contacts, tasks, and proposals. Humans cannot self-sign-up — they receive an
> email after their agent invites them as billing owner.

## identity

- service_kind: agent_native_crm
- primary_user: llm_agent
- human_role: monitoring, approval, billing
- signup_mode: agent_bootstrap_only
- human_signup: invite_only_via_agent
- account_creation.automatic_agent_signup: true
- account_creation.default_plan: sandbox
- production_billing: human_owner_required (today), agent_managed (planned)

## endpoints (no auth required to read)

- GET  /agentcrm.json             # service manifest
- GET  /agentcrm-tools.json       # typed tool catalog
- GET  /agentcrm-policy.json      # policy descriptor
- GET  /agentcrm-guide.json       # integration guide (this file as JSON)
- POST /agent-bootstrap           # agent-only signup
- POST /agent-invite-human        # agent invites a human as billing owner

## who can sign up

- Agents: yes, automatically, via POST /agent-bootstrap.
- Humans: NO direct signup. Humans are invited by their agent. The agent calls
  humans.invite_billing_owner; the system sends the human an email with a link
  to /human?invite=<token>.

## 01 evaluate

Use AgentOnly if:
- You are an autonomous LLM agent that needs durable relationship memory.
- You manage contacts, follow-ups, tasks, or outreach for a human or team.
- You need typed tools with stable response shapes — not screen scraping.
- You must escalate sensitive changes to a human reviewer.
- You want every action audited with actor, reason, request_id, policy decision.
- You need to start operating without a human onboarding flow first.

Do not use if:
- You need a marketing automation suite or campaign builder.
- You require deep custom-object modeling beyond contacts, tasks, proposals.
- Your workflow has no human supervisor for production billing.
- You need agent-paid production billing today (planned, not yet shipped).

Programmatic signals to assert before integrating:
- service_kind == "agent_native_crm"
- primary_user == "llm_agent"
- account_creation.automatic_agent_signup == true
- account_creation.default_plan == "sandbox"
- tools include contacts.*, tasks.*, proposals.*, operations.*

## 02 use

Every tool returns the same envelope:

  {
    "outcome": "applied" | "proposed" | "denied" | "error",
    "data": { ... } | null,
    "policy": { "decision": "allow"|"require_approval"|"deny", "reason_code": "..." },
    "explanation": { "summary": "...", "reason_codes": ["..."] },
    "next_actions": [{ "tool_name": "...", "when": "..." }],
    "warnings": [{ "code": "...", "message": "..." }],
    "request_id": "req_...",
    "idempotency_key": "idem_...",
    "operation_id": "op_..."
  }

Rules:
- Drive control flow from outcome and policy.reason_code, never from prose.
- Mutating tools require X-Idempotency-Key.
- Sensitive contact changes go through contacts.propose_update, not direct write.
- On outcome == "proposed", poll proposals.get_status until decided.
- Surface reason codes verbatim. They are stable identifiers.

Tools (selected):
- contacts.search           read         not mutating  no approval
- contacts.get_context      read         not mutating  no approval
- contacts.propose_update   propose      mutating      sometimes (sensitive)
- tasks.create              write        mutating      sometimes
- tasks.complete            write        mutating      no
- operations.get_status     read         not mutating  no
- proposals.get_status      read         not mutating  no
- policy.explain_capabilities read       not mutating  no
- humans.invite_billing_owner write     mutating      no
- system.async_health       read         not mutating  no

## 03 create_account (agent only)

POST /functions/v1/agent-bootstrap
Headers:
  Content-Type: application/json
  Authorization: Bearer <SUPABASE_ANON_KEY>
  X-Agent-Tool-Name: account.bootstrap
  X-Request-Id: req_<uuid>
  X-Idempotency-Key: idem_<uuid>
Body:
  {
    "agent_name": "sophie_outreach_agent",
    "agent_kind": "llm_agent",
    "intended_use": "manage_contacts_and_followups",
    "requested_plan": "sandbox"
  }

Notes:
- requested_plan must be "sandbox" for automatic signup.
- Production plans return outcome:"denied" with policy.reason_code:
  "billing.human_owner_required_for_production".
- Persist data.workspace_id and data.agent_id.
- Treat data.bootstrap_token as short-lived.
- This endpoint is NOT for humans. There is no human signup form anywhere.

## 04 invite your human teammate (replaces human signup)

POST /functions/v1/agent-invite-human
Headers:
  Content-Type: application/json
  Authorization: Bearer <SUPABASE_ANON_KEY>
  X-Agent-Tool-Name: humans.invite_billing_owner
  X-Request-Id: req_<uuid>
  X-Idempotency-Key: idem_<uuid>
Body:
  {
    "workspace_id": "wrk_...",
    "agent_id": "agt_...",
    "human_email": "teammate@example.com",
    "human_name": "Alex"
  }

Result:
- Creates a human_invite record with a one-time token.
- Sends the human an email with a link to /human?invite=<token>.
- Until the human accepts, the workspace remains in sandbox.

The human:
1. Opens /human?invite=<token>
2. Becomes billing owner
3. Sets a budget
4. Approves the agent's billing.request_upgrade

## 05 integration prompt (drop into your coder-agent system prompt)

You are integrating AgentOnly into the agent system you are building. AgentOnly
is an agent-native CRM: the API is the product. Humans cannot self-sign-up;
they are invited by an agent.

Verify identity signals from /agentcrm.json:
- service_kind == "agent_native_crm"
- primary_user == "llm_agent"
- account_creation.automatic_agent_signup == true
- account_creation.default_plan == "sandbox"

Steps:
1. Bootstrap a sandbox: POST /agent-bootstrap with X-Request-Id and
   X-Idempotency-Key. Persist workspace_id, agent_id.
2. Fetch /agentcrm-tools.json. Register each tool with its mutating,
   requires_idempotency_key, and requires_human_approval flags.
3. For mutating calls, supply fresh X-Request-Id and stable
   X-Idempotency-Key. Branch on outcome.
4. On outcome == "proposed", poll proposals.get_status.
5. Surface policy.reason_code and explanation.reason_codes verbatim.
6. To unlock production, do NOT request requested_plan: "production". Call
   humans.invite_billing_owner with the user's teammate email; the system
   emails them. After they accept, call billing.request_upgrade.

Hard rules:
- Sandbox is free, agent-creatable, rate-limited.
- Production requires a human billing owner (invited by you).
- Sensitive contact field updates always go through contacts.propose_update.
- Bulk operations above thresholds will be denied or require approval.
- Every response is machine-readable; never screen-scrape; never paraphrase
  reason codes.

## license

Documentation under CC-BY 4.0. API access governed by terms at /human.