Core concepts

Seven concepts carry most of the meaning in PRESHos Platform. Learn these and the rest of the wiki reads clearly.

Tenant

A tenant is one isolated customer footprint on the platform: its users, environments, sessions, approvals, connectors, and audit history.

Tenants are provisioned by invitation. There is no public self-serve.
Each tenant gets its own hostname (below).
Data and governance do not leak across tenants. Approvals, sessions, and audit trails belong to exactly one tenant.

Hostname

A tenant is reached at its hostname, usually slug.preshos.com (for example, acme.preshos.com).

Your invite points you at your tenant hostname. Bookmark it. That is your front door.
My tenants: hostname wins. If you belong to more than one tenant, the hostname in your address bar determines which tenant you are acting in. Same identity, different tenant, different session scope. When in doubt, check the hostname.
Some tenants use a custom domain. The rule is the same: the hostname decides the tenant.

org_id vs company_id

Two identifiers that are easy to confuse. They answer different questions:

Identifier	Answers	Example
`org_id`	Which organization’s context is this session operating on? The customer organization whose systems and data are in scope.	The MSP’s end customer, the business unit, the department whose tickets the agent is working.
`company_id`	Which operating company record does this belong to? The internal/operational grouping used for tenancy, billing, or hierarchy.	The provider company, the parent entity, the internal partition.

Rules of thumb:

org_id scopes work: sessions, approvals, and audit entries are tied to the org whose context is being acted on.
company_id scopes ownership: which company footprint the record rolls up to.
They can coincide for single-company tenants and diverge for multi-org setups (for example, a provider operating PRESHos across several end-customer orgs). Never assume they are interchangeable. Check which one a screen, API, or audit entry is filtering on.

Agent Environments

An Agent Environment is the isolated, pre-configured workspace an agent session runs inside. It bundles:

Context: which systems and data the session can see.
Tools: which actions the agent may attempt (read, search, draft, execute, change).
Policy: which actions need approval, and who can grant it.

Environments are the unit of governance reuse: define once, run many sessions. Admins and builders shape environments; sessions inherit their guardrails. A session outside an environment is not a governed session.

Sessions

A session is one bounded run of agent work inside an environment: a goal, a scope, a transcript of actions, and an outcome.

Sessions are the unit of first value: a new tenant’s onboarding ends with one real governed session, not a dashboard tour.
Every session carries its environment’s policy with it. Isolation and approval rules travel with the work.
Sessions end with a recorded outcome: what was attempted, what was approved or denied, and what changed.

Approvals

Approvals are the human gate between proposing an action and performing it.

Actions above a risk threshold pause and request approval instead of executing.
Approvers see the proposed action, its target, and its justification, then allow or deny.
Denials are first-class outcomes, recorded like approvals. A healthy tenant has both.
Approval policy lives on the environment (what needs approval) and resolves per session (who decides, what happened).

Connectors (code is not connected)

A connector links PRESHos to an external application (ticketing, RMM, identity, docs, and similar).

The critical distinction:

Connector code existing is not the same as a connector being live and connected for a tenant.

Code in a repository means an integration can be built or enabled. It says nothing about your tenant.
A connector is connected only when it has been provisioned, credentialed, and enabled for your tenant’s environment, and shows up as available in session scope.
Never promise a stakeholder that a system is “integrated” because the code exists. Check the tenant’s environment: is the connector listed, credentialed, and within session scope?

This wiki deliberately avoids claiming a fixed connector catalog or fixed navigation, since what is live varies by tenant and over time. The environment’s tool list is the source of truth.

How they fit together

The chain runs: hostname, then tenant, then environment (context, tools, policy), then session (goal, actions, outcome), then approvals (human gates on risky actions), then audit (the record of all of it). Connectors plug external apps into environments, but only when provisioned for that tenant. org_id scopes the work; company_id scopes the ownership.

Next: Day-0 for customer admins walks the invite-to-first-session flow that makes these concepts concrete.