Skip to main content
ModelHub and AgentHub are two deployments of the same application, reading the same database. What makes ModelHub a chat-only product is the deployment, enforced on the server. What decides whether someone can also use AgentHub is their role.

​
Chat-only is enforced by the deployment

ModelHub is built as the employee variant of the platform. On that build:
  • The sidebar carries exactly two pages, Chat and AI Usage, plus New chat, conversation history and (for admins) Settings.
  • The logo links to the chat.
  • Every other project page is redirected to the chat by middleware before the page renders. That includes Overview, Model Manager, Cost Calculator, Evaluation, Simulations, Traces and Reports. Typing the URL does not work; you get the chat of the same organization and project instead.
This is server-side enforcement, not a hidden menu item. A redirect happens before anything renders, so there is no blank page or partial content. On the AgentHub build, the same slot that is the chat on ModelHub is the organization-wide AI Usage dashboard, and the chat is not offered.

​
Hub roles

Each person has a hub role derived from their organization role:
  • The hub role is shown as a badge under each person’s name in the sidebar.
  • Super admins act with the full Owner permission set in every organization they can reach, whatever their database role there.
  • The super admin list is deliberately kept outside the database. It is the root of the access system: if it lived in the tables it governs, a bad write or an unreachable database could lock every administrator out.
  • People without settings tabs have no Settings link, and opening a settings URL directly sends them back to the organization’s first project (the chat, on ModelHub).
  • In User Management, admins can assign Editor and Viewer; only super admins can add, change or remove Admins.
Full permission lists per role are in Roles and permissions.

​
The AgentHub gate for Users

When a User (Viewer) signs in to AgentHub and opens any project page, they see a full-screen notice instead:
Your account has ModelHub access only AgentHub is available to admins and AI Builders. You can keep using ModelHub to chat with models. Ask an admin if you need AgentHub access.
with a Go to ModelHub button and a Sign out link. Organization-wide usage is gated separately: on both hubs, the organization view of AI Usage (cost per person, the log of removed personal data with its values) loads only for Owners, Admins and super admins. The check runs before the query, so the data is never fetched for anyone else.

​
The per-organization caveat

Membership is per organization, not per deployment. Both hubs read the same database, so a person you add to an organization is a member on both. The URL you hand out decides where they usually go; the role decides what they can do if they reach the other hub. In practice:
  • A User who opens AgentHub sees the gate above.
  • An AI Builder or Admin has the full platform on AgentHub. Do not use those roles for people who should only chat.
  • Anyone who can reach an organization’s settings or usage can do so from either hub.
If you need a harder boundary, put chat-only staff in a separate organization. They are then not members of the organization whose data AgentHub reports on, and there is nothing for them to see there whatever their role. The cost is a second set of model configurations and keys.

​
Removing someone

Do both of these when someone leaves:
  1. Remove the membership. In Settings → User Management, delete their email from every box and click Save changes. A dialog titled Remove this person? lists who will lose access (“Saving will remove their access to this organization (or revoke their pending invite).”) Click Remove and save. The save summary shows “Removed from the organization.” or “Pending invite revoked.”
  2. Block sign-in. In Settings → Platform access (super admins), Remove their address from the Allowlist if it is listed there.
Removing the membership alone still lets them sign in with an email code. If they sign in with Okta, also unassign them from the CorePillar app in Okta.
The current Platform access screen only offers Deny on Pending requests. There is no button to revoke an address that was approved from a request, or to deny one person whose whole @domain is on the allowlist. An explicit denial would beat the domain rule, but it cannot be set for an already-approved address from the UI today. For those people, removing the membership is the effective control: they can still sign in, but they belong to no organization of yours. Removing the domain entry blocks everyone on that domain who was not approved individually.
Limits on removal: Their past chat turns stay in the organization’s usage records, masked, so spend and privacy history remain accurate.

​
Checking a deployment

If anyone on ModelHub ever sees platform pages such as Traces or Model Manager, the deployment was built with the wrong variant. ModelHub must be built with NEXT_PUBLIC_APP_VARIANT=user. The value is fixed at build time, so one deployment cannot serve two different products.