Run Memnox for your customers

Most Memnox accounts are a company using Memnox for itself. This page is for the other kind: a company whose product is AI that works inside other companies.

Your agents already know how to reach their tools. What they cannot know is the company they have been dropped into — who owns this system, what leadership already decided, who authorizes a change this size, and how much of the evidence this particular agent is entitled to see. Building that once, per customer, in your own product is the work this replaces.

Priced on what you deploy, not on who works for you

There are two ladders here, and they are not five rungs of one.

A company with a hundred staff and ten thousand AI workers does not buy a per-seat plan, and pricing it per worker would charge it for the wrong side of its own business. Seats price people; governedActionsPerMonth prices what the AI does. They are separate meters because they are separate things.

What makes an account a platform is a number, not a flag. Every self-serve plan has customerOrganizations: 0, and zero is not a restriction — an ordinary customer runs its own organization and has no others to run. A non-zero ceiling is written into your contract, and the account's own number always wins over the plan matrix.

Provisioning a customer

There is no separate endpoint. You create an organization with your own org-scoped credential, and it is stamped with the platform that created it.

1. 1

   Create the organization

   bash

   curl -XPOST $MEMNOX/v1/orgs \
     -H "Authorization: Bearer $PLATFORM_TOKEN" \
     -d '{"name":"Acme Logistics"}'

   The response is an ordinary organization, carrying platformOrgId set to yours. It counts against your contracted ceiling.

2. 2

   Provision the customer's own admin

   bash

   curl -XPOST $MEMNOX/v1/orgs/$CUSTOMER/users \
     -d '{"name":"Nia","email":"nia@acme.test","role":"admin"}'

   The mnxc_ token comes back once. From here the customer runs their own tenant: their connectors, their policies, their members.

3. 3

   Mint an ask grant for each agent you deploy there

   One credential per agent, each with its own ceiling, its own principal and its own stated restrictions. Revoking one takes effect on that agent's next question. See Evaluate.

A child is a tenant in its own right

This is the part worth reading twice, because it is what makes the arrangement sellable to the customer at the other end.

You see the organizations you provisioned, and your own, and nothing else. That is deliberate on both sides: your customer is not exposed to you by the act of being provisioned, and you are not made responsible for governing them.

What your agents integrate against

One call, whatever built them.

import { MemnoxOrganization, mayProceed } from "@memnox/organization";
 
const org = new MemnoxOrganization({
  token: grantForThisAgent,
  workspace: customerWorkspace,
});
 
const answer = await org.evaluate({
  action: "invoice.approve",
  resource: { type: "invoice", id: "inv_2214" },
  principal: "ops@acme.test",
  amount: 12000,
  reads: factIds,
});
 
if (!mayProceed(answer)) {
  // answer.approvers names who can authorize it, and why they can.
}

The package is Apache-2.0 and deliberately thin — the protocol and nothing else. It does not need your connectors, does not execute anything, and never fails open: a call that cannot reach Memnox throws rather than returning a permissive default.

The same answers are available over MCP at POST /v1/workspaces/:ws/mcp, which is usually the faster path for an AI-native agent: point it there and it gains the organizational tools without anybody writing an integration.