No. Most teams start with one team or one workflow, keep the rest of their stack, and connect it. GitHub issues can mirror into projects, and MCP connections reach systems you already run. Adoption grows piece by piece; nothing forces a big-bang migration.

It covers those jobs, including projects, chat, docs, meetings, and files, in one workspace. The task, thread, and doc share context that agents can use too. Coming from that stack, you can move gradually rather than all at once.

No. Volobox is a complete workspace on its own: projects, chat, docs, meetings, and files. Many teams enable agents gradually, starting with read-only Ask mode.

Teams begin with a guided setup around a real workflow. After sign-in, members land in the Workbench with Projects, Docs, Files, Code, Workflows, side panels, Spotlight search, and the Volobox Guide. There is no forced big-bang rollout or self-serve setup wizard.

Yes, through the responsive web app and its installable PWA experience. Mobile layouts include compact navigation and push notifications. Volobox does not currently publish a native iOS or Android app.

Agents can take assigned tasks and report back, draft docs and replies, run coding sessions that end in pull requests, help fill forms, analyze data in a sandbox, and answer questions with citations from workspace knowledge. Permissions and the authorization mode you choose govern what each agent can do.

Your personal assistant belongs to you and works with your permissions and private context. Shared agents belong to the workspace: they have a handle, persona, skills, and memberships. Teammates can mention them or assign them work, and a designated manager approves their escalations.

Yes. Create shared agents with their own handle, persona, skills, and memberships, with no code required. Package what works as Library packs to reuse across teams, or pull packs from your own registry.

The default defense is prevention: write actions appear as approval cards that you can inspect and reject. After an action, project activity, content version history, auto-approval history, agent history, and the organization audit log show what happened. Docs pages and task descriptions support version restore, but Volobox does not claim a universal undo for every agent action.

Yes, through Workflows. A governed agent can run a playbook manually, on a schedule, from a supported system event, or from an item such as a task or meeting. Runs keep their decisions, artifacts, and trace. Volobox does not claim broader proactive behavior outside configured workflow triggers.

Interactive agent turns use the access of the person who invoked them, and outbound messages still require approval. Autonomous shared agents cannot open or post in direct messages. Shared agents in team contexts cannot read personal Docs, My Drive, Inbox, or private Agenda; use your personal assistant in a one-to-one chat for personal context.

GitHub is integrated deeply: connect repositories, mirror issues into projects, and receive agent pull requests. Deployments can run through Azure DevOps pipelines. Other systems can connect over MCP.

Each coding session runs in an isolated remote VM with an admin-managed template. Teams can pause a VM while keeping its files, destroy it when finished, and use preview and terminal controls inside the session.

The coding room is part of the team workspace. The agent starts from a task and its context, while teammates can watch the terminal, diffs, plans, questions, and cost. The resulting branch, preview, pull request, and discussion stay connected to the work that started them.

GitHub is the native repository integration today. Volobox does not currently claim native GitLab or Bitbucket repository support. MCP can connect other systems for agent tool use, but it is not a substitute for the built-in GitHub coding and pull-request flow.

A Workflow is a markdown playbook executed by an agent, with typed inputs, manual, scheduled, event, or item-based triggers, and human decision points. Personal workflows belong to their owner. Shared workflows use Viewer, Runner, Editor, and Admin roles, with separate permissions to create them.

You can publish database-backed internal apps inside Volobox, including grids, kanban boards, calendars, galleries, dashboards, and conditional forms. Agent-assisted changes use approval cards, and the app inherits the workspace identity, permissions, audit, and deployment foundation. Teams can continue into JavaScript or full C# when the runtime model is not enough.

Every write action goes through the authorization model. By default the agent proposes and a human approves with an approval card. Manager escalation covers permission gaps, and self-authorized agents operate only inside explicit memberships under hard rate limits. Everything is logged.

No. In interactive use, the agent runs with the permissions of the person who invoked it. Shared agents never access personal data in team contexts. Self-authorized agents see only what their own explicit memberships grant.

The person who triggered the agent approves its proposals, using their own permissions. Teammates see requester approval cards as read-only. Manager escalations go to the agent manager through the Inbox.

Yes. The organization audit log records curated work, security, authorization, and durable agent events. Auditors can filter it, export CSV, or collect cursor-paginated JSONL through an authenticated API for SIEM ingestion. Conversation audit events record that a message changed, not its body.

Volobox uses OpenID Connect authentication with role- and permission-based access control today. We do not currently publish SAML or enterprise SSO as a standard capability. Bring your identity-provider requirements to the security review and we will assess them with your team.

We do not currently claim SOC 2 or ISO 27001 certification. The product has role- and permission-based access, an exportable audit log, encrypted secrets, isolated execution, and on-premise deployment. Bring your compliance requirements to the security review and we will share the current roadmap and evidence.

Data location follows the deployment you choose. On-premise or private-cloud deployments let you keep Volobox and model endpoints in infrastructure you control. For managed-cloud regions, retention, and backup requirements, bring your policy to the security review so we can confirm the available deployment shape.

Volobox sends only the context needed for a request to the model endpoints your workspace uses. Whether a provider retains requests or uses them for training depends on the agreement covering that provider, which is ours on a managed cloud workspace and yours when you connect your own keys. Self-hosted model endpoints can remain inside your network.

Knowledge search can index team Docs, task and request text, meeting notes, and pull requests. Official Volobox Help is indexed separately. Search combines semantic and full-text retrieval, and answers identify retrieved guide or workspace snippets so people can verify the source.

Volobox supports configured models from providers such as OpenAI, Anthropic, Google, and Moonshot AI, plus OpenRouter and OpenAI-compatible endpoints, including open-source models you host. On a cloud workspace, model access comes set up, so your team can work on day one without a provider account. Admins choose which models are allowed where, and can connect their own provider keys instead.

No. A cloud workspace arrives with model access we manage, so nothing needs configuring before your team starts working. If you would rather run on your own provider account, an admin can connect it and choose which models are allowed where. Which plans include that is part of the packaging conversation.

Yes. Volobox can deploy on-premise or in private-cloud infrastructure, including with model endpoints inside your network. The deployment shape is reviewed with your infrastructure and security teams.

The current packaging has three parts: a seat-based Volobox license, model usage, and sandbox compute for coding or data-analysis sessions. Capacity scales with seats; concurrent agent work (workflow runs and coding assignments) is metered per plan. Each plan includes a monthly model-usage allowance; you can also connect your own provider account and be billed by that provider instead. Exact license numbers are being finalized with early design partners.

Not as a self-serve flow today. We currently onboard teams through guided demos and pilots so a real workflow, its permissions, and the deployment shape are configured deliberately from the start.

Yes. A focused pilot is the recommended starting point. Pick one team or recurring process, begin read-only where appropriate, add approvals, and expand autonomy and adoption only after the workflow earns trust.

GitHub issues can mirror into Volobox projects out of the box. Volobox does not currently claim a general Jira or Notion importer. For broader tracker, wiki, or drive migrations, the services team plans and executes the move with you.