Publish to the Portal

The Portal is the surface your clients and colleagues use. Read-only members see only the agents you published: no builder controls, datasets or metric editor. Owners and collaborators can also preview the agent version currently being edited in the workspace.

There are two publish steps, and you need both:

Publish the portal — turns on your workspace's outward address, the one link you hand a client. Done once, on the Portal page.
Publish an agent — puts that agent inside the portal, as a frozen snapshot. Done per agent, from its readiness panel.

Switch between your studio and the client view any time with the Build | Portal toggle at the top of the screen.

The Portal page

Everything about your portal lives on one page: Portal in the workspace sidebar (owner and collaborators only). It holds

the portal link name and the resulting address, with copy and preview;
the Publish / Take offline switch;
the list of agents in the portal, flagged when they have unpublished changes, with Republish and Remove;
your client list and the invite links.

While the portal is offline its address shows a plain "not available" page — it does not reveal that the workspace exists. Your published agents are untouched; publishing again restores exactly what clients had.

What publishing actually does

Publishing takes a frozen snapshot of the agent's client-facing configuration — its identity, scope, skills, pipeline, data selection, tool bindings and capability card — and serves that snapshot to clients in the Portal. Owners and collaborators preview the live workspace version.

The practical consequence: after you publish, you can keep editing the agent in the studio without your clients seeing a half-finished change. The published version keeps running as it was. When you are happy, Republish to push the new snapshot; the panel tells you when there are unpublished changes waiting.

The snapshot is not a copy of the data. These things are resolved at run time:

Data. Clients always get current numbers, not a snapshot of them.
Tool specifications, connection scope and credentials. The published tool bindings and approval mode are fixed in the snapshot, but tool specifications, connection availability, scope checks and rotated connection secrets are checked against current settings. Changes to workspace tool settings normally require republishing to become the client's binding configuration.
Gates. Suspending an agent, or losing its live data source, stops the published agent too.

Unpublish immediately removes the agent from the client Portal and portal access links. Public result snapshots are separate, read-only shares and are not deleted; revoke those shares separately if needed. Nothing else is deleted — the agent and its history stay in your studio.

Before you can publish

The agent must be Tested or already Published. Draft, Paused and Deprecated agents cannot be published. A successful run moves a draft to Tested.
When moving an agent to Published, the readiness checks for scope, documented metrics and reviewed refusals must be complete. Evaluations are quality guidance, not a separate hard gate. See Verify and evaluate.
You must be the workspace owner or a collaborator (the admin workspace role).
To publish the Portal, set a link name and have available account workspace/Portal capacity. Publishing an agent does not consume a separate per-agent quota.

Publishing works on every plan, including Free. The account's structural capacity determines how many workspaces and Portals it can have, with one Portal per workspace; check the current limits in Plans and credits and the in-app usage page. Putting more agents into an existing Portal does not consume another Portal allowance.

If your account later moves to a smaller plan, existing workspaces, data, scheduled jobs and Portals are not deleted. The account may temporarily exceed the new plan's structural limits; existing published Portals will generally continue serving existing clients, while creating resources or starting new refreshes may require capacity or an upgrade. Taking a Portal or agent offline is always free.

Your Portal address

Every workspace can set a portal link name — lowercase letters, numbers and hyphens. That gives you one address:

https://luxiva.ai/app/<your-link-name>

This is the Luxiva-hosted link to put in an email or proposal. The domain is provided by Luxiva and cannot currently be replaced with a custom domain. Copy the exact address shown on the Portal page.

Every plan can set a link name and publish. How many Portals you may have live at once depends on your account's workspace and Portal capacity — see Plans and credits.

What clients see

The list of agents published to their workspace (unpublished agents do not appear).
A chat surface per agent, with conversation history.
The files an agent produced for them, and the ability to share a read-only snapshot of a result.
Pinned facts and starter questions, so they know what to ask.

They cannot edit an agent, see your datasets or metric definitions, or reach any builder page. Clients are workspace members with a read-only, consume-only role; they are not owners or collaborators.

Managing published agents

The Portal page lists everything currently live, flags agents with unpublished changes, and gives you Republish and Remove per agent. The client roster is managed at workspace level — it is shared across every agent you publish, so a client you invite once can be given access to your next agent without a second invitation.

Each agent's readiness panel keeps its own publish button, and tells you the portal address once your portal is live.

Tool settings and live data

Before publishing, confirm the enabled tools, approval modes and connections in the agent and workspace tool settings. Publishing fixes those bindings in the snapshot; later changes to workspace defaults do not rewrite a client's snapshot. Tool catalog specifications, connection scope and credentials are still checked at run time, so disabling a tool, revoking a connection or losing the data source can prevent clients from using it even while the snapshot remains published.