---
title: "How to choose an AI workspace: a criteria-based buyer guide"
excerpt: "Choosing an AI workspace comes down to five questions: does it hold live state, does work persist, can multiple actors collaborate with attribution, do agents have their own identity, and is it locked to one model vendor. This guide turns each into a test you can run on any tool."
author: mei
category: Use Cases
date: "2026-06-01"
---

**TL;DR:** Choose an AI workspace by running five tests on every vendor: does it hold live, agent-writable state instead of static files, does work survive after the session ends, can humans and multiple agents share one surface with attribution, do agents carry their own identity and credential, and is it open across model vendors. A tool that passes is built agent-first. A tool that fails is a familiar app with an assistant bolted on.

Most products marketed as an "AI workspace" are a tool you already know with a chat box added on the side. That is a reasonable product, but it is not the same category as a workspace built for agents to work in. This guide is a vendor-neutral way to tell the two apart.

## What is an AI workspace, actually?

An AI workspace is the persistent surface where humans and AI agents do work together, not a chat window that forgets. The distinction is whether the workspace is the system of record for what agents produce, or just a place to talk to a model. See [what is an AI workspace](/blog/what-is-an-ai-workspace) for the full definition.

The fastest way to sort the market is to stop reading feature lists and ask five questions. Each maps to one of the [five shifts from Cloud 1.0 to Cloud 2.0](/blog/five-shifts-cloud-1-to-cloud-2), and each carries a red flag when the answer is wrong.

## Does the workspace hold live state or static files?

Ask the vendor: can an agent read and write structured, queryable state, or does it only produce documents and attachments? A real workspace holds live state that humans and agents update in place. The red flag is every agent output being a static file you re-open, re-parse, and re-explain on the next run. Live state lets the next session pick up where the last one stopped; static files do not.

## Does the work survive when the session ends?

Ask: if I close the chat, what remains, and can a different agent read it tomorrow? Persistence means the work product, decisions, and context live in the workspace, not in a transcript that resets. The red flag is output that exists only inside one ephemeral session. If your team copies answers out of chat to keep them, chat was not the workspace.

## Can humans and multiple agents work the same surface?

Ask: can two agents and a person edit the same record, and can I see who did what? Multi-actor collaboration with attribution is the difference between a tool one person prompts and a workspace a team operates. The red flag is single-actor design, where the agent's work is invisible until shared manually. Attribution is what makes agent output reviewable. See [reviewing agent work](/blog/agent-audit-and-compliance).

## Do the agents have their own identity?

Ask: does each agent have its own identity and credential, or does it act as me, using my login? An agent that borrows a human's credential is indistinguishable from that human in every log, which makes review, revocation, and audit impossible. The red flag is agent actions appearing under a person's name. Agents should be [principals](/blog/agents-are-principals), as in [why agents need identities](/blog/why-agents-need-identities).

## Is the workspace locked to one model vendor?

Ask: can I run agents from more than one model provider against this workspace, or is it wired to a single vendor's models? Cross-vendor openness, usually delivered through the [Model Context Protocol](https://modelcontextprotocol.io/introduction), an open standard for connecting AI applications to external systems, keeps you from betting your workflows on one provider's roadmap. The red flag is a closed stack where switching models means switching tools.

## How do these five questions compare across the two kinds of tool?

The same five tests separate an assistant bolted onto a familiar app from a workspace built agent-first.

| Criterion (the test) | Assistant bolted onto a familiar tool | Agent-native workspace |
| --- | --- | --- |
| Storage to State | Produces static files you re-parse each run | Holds live, queryable, agent-writable state |
| Sessions to Persistence | Work lives in an ephemeral chat that resets | Work survives in the workspace as the record |
| Single to Multi-actor | One user prompts a private assistant | Humans + multiple agents share one surface with attribution |
| Implicit to First-class identity | Agent borrows the user's login | Each agent has its own identity and credential |
| Vertical to Cross-vendor | Locked to one model provider | Open across vendors via MCP |

A tool that scores on the left is not broken; for a single person doing single-session tasks it is often the right call. The scoring matters when a team and recurring work go behind it, because every left-column answer becomes a tax on every run.

## How Dock approaches this

Dock is the worked example of the right-column answers, because it started there. The workspace is the [system of record for agent output](/blog/what-is-an-ai-workspace): agents write to live state that persists past the session. Agents are named teammates with [signed agent identity](/blog/agent-identity), their own credential rather than a borrowed login, so every action is attributable. Sensitive actions pass through [consent gates and a two-key handshake](/blog/two-key-handshakes-irreversible), with the [dangerous-ops contract](/blog/dangerous-ops-contract) defining what needs a second key. Dock is MCP-canonical, so it stays open across vendors. The architecture is detailed in [Cloud 2.0 for engineering](/blog/cloud-2-0-for-engineering), [Cloud 2.0 for product](/blog/cloud-2-0-for-product), and [/cloud-2-0](/cloud-2-0).

Evaluating for a role? See [Dock for founders](/blog/dock-for-founders). For running agents specifically, start from [the best AI workspace for AI agents](/blog/best-ai-workspace-for-ai-agents) or the head-to-head in [AI workspace vs chat assistant](/blog/ai-workspace-vs-chat-assistant).

## What should I do with these five tests?

Run them in order on every vendor demo, and weight identity and persistence highest, because those are the two you cannot retrofit later. A tool can add a model provider next quarter. It cannot retroactively give an agent its own identity for work already done under your name.

Ready to test a workspace that answers right-column on all five? [Start with Dock](/signup).

## FAQ

**What is the single most important criterion when choosing an AI workspace?**

First-class agent identity. If agents borrow a human's credential, you lose attribution, audit, and the ability to revoke one agent without locking out a person. Other criteria can be added later, but identity must be designed in from the start. See [agents should be principals](/blog/agents-are-principals).

**Is an agent-native workspace overkill for a solo user?**

Often, yes. If you are one person doing single-session tasks, a chat assistant or a docs-and-notes tool with AI added is usually enough. The five tests matter most when a team and recurring work are involved.

**How do I tell live state from static files in a demo?**

Ask the agent to update a record, then close the session and reopen as a different user. If the change is there, queryable, and attributed, that is live state. If you have to re-upload or re-explain, it was storage.

**Why does cross-vendor support through MCP matter for a buyer?**

It prevents lock-in to one model provider's roadmap and pricing. MCP is an open standard for connecting AI applications to external systems, so a workspace that speaks it lets you swap or mix vendors freely.