Pazi workspaces now allow team access. An owner can grant another Pazi user view-and-run access to their workspace, and that teammate signs in, sees it in their list, and uses the agents inside it.
Until today, a Pazi workspace was bounded to one account. If you wanted a colleague to run something you had built, there was no read-only path for them to sign in under their own login and use it. They either borrowed your credentials or rebuilt the whole setup from scratch. Sharing closes that gap.
| What's new | What it means for you |
|---|---|
| Workspace sharing | A teammate can sign in and find your workspace in their list. |
| Read-only viewers | They can run what you own; they can't edit your agents or settings. |
| Owner-billed compute | Their LLM calls bill to you. |
| Agent-level sharing | Grant access to a single agent instead of the whole workspace. |
| User-to-user grants | v1 grants are person-to-person between Pazi users. |
How it works
A grant lets a teammate log into their own Pazi account, find your workspace next to the ones they already own, open it, and put the agents to work. From the viewer's side, the workspace looks like any other one in their list, and nothing about how it runs changes for the owner. Viewers are read-only on everything they didn't author themselves, so they can execute, but they cannot modify your agents, your skills, or your settings.
Invite teammates into your workspace as read-only viewers; their work runs on your owner-billed infrastructure.
Before this release, an agent's LLM call was billed to whichever user triggered it. Now the owner pays for every model call a viewer makes, regardless of which person on the team sent the prompt. The guest-pass analogy fits: a visitor gets to use the equipment, and the owner still covers the membership.
A related primitive sits alongside this one. A workspace owner can also grant a viewer access to a single agent independent of the surrounding environment, for cases where the right scope is one tool rather than the whole workspace. The same read-only rule applies: a guest can talk with that agent and run it, but cannot change it.
Both primitives share the same boundary: viewers operate inside the surface its owner built, and the owner keeps full control of it.
Get started
Workspace sharing ships today. Owners who want to invite a teammate can request access through Pazi.
In v1 the scope is deliberately narrow. Viewers are read-only; there's no editor role yet. Grants are person-to-person between Pazi users; team-level and organization-level subjects aren't supported yet. Granting goes through Pazi.
Workspace sharing is where the workspace you build in Pazi stops being bounded to one account and becomes something a team can run together.
If you've already been using workspace redesign and multiple workspaces, this is the next beat: where having multiple workspaces gave you separate environments for different jobs, sharing lets a colleague join one of them. It sits next to agents can now create agents, which lets a senior teammate spawn a specialist inside the same space. And it pairs with agent goals, which gives any agent a measurable target to track.
