AdministrationWorkspace, orgs & projects

Workspace, orgs & agents

Your Neens workspace is a three-level hierarchy — the company (your whole workspace) contains organizations, and each organization contains agents. Everything you send, score, and diagnose lives in an agent; orgs group related agents; the company is the isolation boundary that keeps your data physically separate from every other tenant.

At a glance

WhereAgents page in the left nav; workspace naming in Getting started
Key API routesGET/POST /orgs, PATCH /orgs/{id}, GET/POST/PATCH/DELETE /projects/{id}, GET /onboarding/tenant
Who can createAdmins and members create orgs and agents; viewers are read-only
Who can deleteAdmins only — deletion cascades to all agent data
VisibilityAdmins see the whole company; members and viewers see only the orgs/agents they belong to
Company (your workspace)
└── Organization
    └── Agent  ← traces, scores, judges, datasets, annotations

Create an org or agent

Open Agents in the left nav:

  • New org — creates an organization inside your company. Admins and members can create orgs (POST /orgs); viewers cannot. The creator automatically becomes an admin of the new org, so it appears in their workspace immediately.
  • New agent — creates an agent inside an org (POST /projects). A brand-new agent starts empty — no traces, scores, or API keys yet — but the Neens default judges are available to it right away.

Your plan caps how many orgs and agents the company can hold. Creating one past the cap is rejected with a clear error — contact your operator to raise the limit.

Click any agent card to make it the active agent; most pages (Traces, Scores, Datasets, …) show the active agent’s data. Star a card to favorite it — favorites are personal to you and float to the top of the Agents page.

Rename, move, and delete

Each agent card has a ⋮ (more) menu:

ActionWhat it doesWho
RenameChange the agent’s display name (PATCH /projects/{id}).Admins & members
Move to orgMove the agent to another org in your own company — the target org must exist in your workspace, so an agent can never move across tenants.Admins & members
DeletePermanently remove the agent and every trace, score, dataset, annotation, and API key scoped to it.Admins only

Orgs can be renamed the same way (PATCH /orgs/{id}) — renaming your org and first agent is also the first step of the Getting started checklist, which is how you “rename the workspace” after provisioning.

⚠️

Deleting an agent can’t be undone. The delete cascades through every data-plane table scoped to the agent. The workspace’s original Default agent is protected and cannot be deleted (the API returns 409).

Who sees what

Visibility inside a company is membership-based:

  • Admins see every org and agent in the company — no membership filter applies.
  • Members and viewers see only the orgs and agents they hold a membership grant for:
    • an org grant makes the org visible and every agent inside it accessible;
    • an agent grant makes that agent accessible and shows its org as a container (only the granted agents inside it appear).
  • A member invited with no organizations lands on an empty workspace (the “zero state”) and is prompted to create their first org — they become its admin, so it appears for them immediately.

Org assignment happens when a teammate is invited — see Members & roles. Enforcement is hard: list endpoints filter to the caller’s grants, and requesting an agent you have no grant for is denied.

Narrower always means less, never more. Every read — a session list, a dashboard tile, a spend or token roll-up, the filter dropdowns, an API or MCP call made with a agent API key — is resolved against the caller’s accessible agent set, and a caller whose set is empty sees nothing. That is worth stating plainly because the alternative is the dangerous one: an unscoped aggregate would quietly return every agent in the company. A viewer opening a shared dashboard pinned to agents they hold no grant for gets empty charts, not someone else’s numbers.

The Getting started checklist

The first time a newly provisioned company’s admin signs in, Neens shows a Getting started checklist (also reachable from the left nav; members and viewers never see it — tenant setup is the admin’s job). It has five steps, in order:

Name your workspace

Rename the seeded default org and agent to names your team will recognize. The step completes on its own once you’ve added a second org or agent, or when you acknowledge it.

Invite your team

Send activation links to teammates (Members & roles). Completes once the company has more than one member.

Connect an LLM

Confirm or add an LLM connection so judges can score your traces. The step shows ready as soon as any connection is visible to your default agent.

Assign views

Give teammates a default view (persona lens) so each lands on the right home page. Completes once any member has an explicit lens assigned — or acknowledge it to keep the role-based defaults.

Set up your first agent

Hands off to the agent onboarding wizard, which mints your ingestion API key and sets up automatic evaluation. Completes once the agent is provisioned or has received traces.

Each step completes from a live signal (the checklist re-checks your workspace on every load) or from an explicit acknowledgement — so a step you completed out-of-band (say, you invited someone from Settings) still lights up. Skip for now dismisses the tracker; Finish marks it complete. Progress is per-company and admins share it.

How it works

  • Every data row in Neens carries a project_id, stamped at write time, and each company’s data lives in physically isolated storage — so org/agent scoping is enforced inside your company on top of hard cross-tenant isolation.
  • Step state for the checklist is computed live (GET /onboarding/tenant) from your orgs, agents, members, connections, and view assignments, merged with any explicit acknowledgements (POST /onboarding/tenant/ack).
  • Org and agent mutations are recorded to the audit log (org.create, project.delete, …).