Organisation world

What a world is

A world belongs to an organisation. It holds a company (name, email domain, industry, country), its employees with titles and departments, its teams, and its customers: companies with their own domains and contacts. There is one world per organisation, and every save is a new version.

• Employees become the internal people of every simulation: users, members, assignees, reporters, owners, authors and workers.
• Customers become the external side: CRM companies, accounts, contacts, deals and tickets, and payment customers.
• Vendor ids stay vendor-specific (a Jira accountId, a Slack user id, a Workday worker id). Names, emails, titles, departments and companies match everywhere.

Create it from a brief

Write a short brief: what the company does, how big it is, which teams it has and who its customers are. The model designs the cast once, from the brief, and the result is stored. Serving requests never calls a model. Designing a cast uses a few cents of your AI allowance; with useModel: false, or with no brief, Slurry builds a cast deterministically instead.

curl -X PUT https://api.slurry.io/v1/world -H "Authorization: Bearer $SLURRY_ACCOUNT_KEY" -H "Content-Type: application/json" -d '{
  "brief": "Northwind Logistics is a 250-person UK freight company in Leeds. Operations, fleet, engineering, sales, customer success and finance teams. Customers are UK retailers, wholesalers and manufacturers.",
  "domain": "northwind.example"
}'

curl https://api.slurry.io/v1/world -H "Authorization: Bearer $SLURRY_ACCOUNT_KEY"

{
  "exists": true, "version": 1, "source": "model",
  "company": { "name": "Northwind Logistics", "domain": "northwind.example", "industry": "Logistics", "country": "GB" },
  "cast": {
    "employees": [
      { "name": "Priya Shah", "email": "priya.shah@northwind.example", "title": "Head of Operations", "department": "Operations" }
    ],
    "customers": [
      { "name": "Kestrel Retail", "domain": "kestrelretail.co.uk",
        "contacts": [{ "name": "Tom Hale", "email": "tom.hale@kestrelretail.co.uk", "title": "Head of Procurement" }] }
    ],
    "teams": [{ "name": "Operations", "department": "Operations" }]
  }
}

In the app, open World in the sidebar. Owners, admins and developers can create and edit it; viewers can read it. You can also change the company name, email domain and industry, or edit the people and customers directly. Emails are always made from the person's name and the domain (priya.shah@northwind.example), so every field style a vendor uses agrees.

The same people everywhere

Within a record, every person field comes from one identity: name, first and last name, display name, username or login, email, initials and avatar URL. References agree with the record they point at: a Jira issue's assignee carries the same accountId, name and email as that user, a Slack message's author is a member of the workspace, and a HubSpot contact's owner is one of the owners.

# Slack
GET /users.list      -> { "name": "priya.shah", "real_name": "Priya Shah", "profile": { "email": "priya.shah@northwind.example" } }
# Jira
GET /rest/api/3/search -> "assignee": { "accountId": "...", "displayName": "Priya Shah", "emailAddress": "priya.shah@northwind.example" }
# Workday
GET /workers         -> { "descriptor": "Priya Shah", "primaryWorkEmail": "priya.shah@northwind.example", "businessTitle": "Head of Operations" }
# HubSpot and Salesforce
GET /crm/v3/objects/companies    -> { "properties": { "name": "Kestrel Retail", "domain": "kestrelretail.co.uk" } }
SELECT Name, Website FROM Account -> { "Name": "Kestrel Retail", "Website": "https://www.kestrelretail.co.uk" }

Account owners in HubSpot and Salesforce come from your customer-facing teams. In Salesforce, SOQL relationship fields resolve them: SELECT Name, Owner.Name, Owner.Email, Account.Name FROM Opportunity.

Using it in simulations

New simulations use the world by default once your organisation has one; the wizard has a Use your organisation's world switch, and the API and MCP take useWorld. Each simulation keeps the version it was seeded with, so a reset brings back the same people. Rebuild a simulation to adopt the latest version.

# create: on by default when your organisation has a world
curl -X POST https://api.slurry.io/v1/simulations -H "Authorization: Bearer $SLURRY_ACCOUNT_KEY" -H "Content-Type: application/json" -d '{ "library": "jira", "useWorld": true }'

# an existing simulation adopts the latest world (records are re-seeded)
curl -X POST https://api.slurry.io/v1/simulations/acme-jira/rebuild -H "Authorization: Bearer $SLURRY_ACCOUNT_KEY" -H "Content-Type: application/json" -d '{ "useWorld": true }'

Record limits still apply. A collection bigger than the cast (say 150 Okta users for a 40-person cast) is filled with further people derived from the same world, so they too agree across simulations.

Privacy

The brief, company details and any people you type in are customer content. They are reviewed for the acceptable use policy before they are saved, and when AI is on they are sent to our model provider to design the cast (the brief is not used for training). If review cannot run, nothing is saved and you can try again shortly. See the privacy policy.

Endpoints and tools

MCP

get_world reads the world; update_world sets the brief or edits the cast; create_simulation and rebuild_simulation take useWorld.