Account

Account is where the app’s boundary model and operator controls come together.

Use it when the question is:

• which organization, workspace, or project am I actually working in?
• who can access this area?
• where do settings, chat models, secrets, billing, and user administration live?

Note

This is the context and control layer around the product surfaces. It is not the place where evaluations, analytics, or training jobs execute.

Context chain

Organization
  -> Workspace
     -> Project
        -> App workflow surfaces

Layer or control surface	Primary role
Organization	top-level ownership, membership, and billing boundary
Workspace	access boundary and collaboration area
Project	grouping context for runs, traces, evaluations, and related work
Settings	manage org-facing configuration pages in the app
Chat Models	manage user-scoped assistant model preferences
Secrets	store user-owned credentials for compute injection
Credits	manage SaaS usage and billing controls
User Administration	manage deployment-wide users and platform admin state

Where control actually lives

Not every admin-looking surface lives in the same place.

Surface family	Scope	Typical examples
Settings shell	current organization plus current user	General, Members, Workspaces, Secrets, Chat Models, Billing
Platform Admin	whole deployment	Organizations, Users, and admin Billing under the /admin area

That split matters because the same person may be an org owner without being a deployment-wide platform admin.

Common workflows

• confirm the correct org, workspace, and project before launching work
• update access boundaries and sharing rules
• manage provider credentials, model preferences, and billing controls
• answer “why can this person see this?” or “why did this workload run here?”
• leave the org-scoped settings shell and move to /admin when the question is deployment-wide rather than tenant-specific

What agents should assume

• organization, workspace, and project materially change what artifacts and runs are visible
• projects are context, not permission boundaries
• settings is a shell that groups several operator surfaces rather than one API object
• deployment admin is a separate surface from org settings, even if both feel administrative

For the individual control surfaces, use Settings, Chat Models, Organizations, Workspaces, Projects, Secrets, Credits, and User Administration.