Skip to content
ThinkWork ThinkWork

Spaces

A Space is the workroom around a piece of work. It tells the tenant platform agent where the work is happening, who can participate, what local context matters, which capabilities are available, and which runtime policy applies.

Spaces keep the tenant model small. Operators configure one Tenant Agent as the baseline, then create Spaces for teams, customers, projects, workflows, inboxes, or channels that need their own context and controls. A thread still records the work, and the agent still acts, but the Space explains why that turn had a specific workspace, trigger, knowledge set, tool set, and access boundary.

For a practical walkthrough, see the Spaces Guide. This page is the concept reference.

ComponentResponsibility
AgentsThe runtime actor that reads, reasons, calls tools, and responds
SpacesThe workroom context, access boundary, channel, and local policy
ThreadsThe durable record of what happened in that workroom
GoalsThe promoted outcome contract when a Thread becomes accountable workflow

What a Space contains

Section titled “What a Space contains”

A Space can supply several kinds of local behavior:

  • Workspace files for the project, customer, team, workflow, or channel.
  • Space-owned Goal templates for repeatable workflows.
  • Public or private access and membership.
  • Triggers that start or wake work in that Space.
  • Tool and capability availability for work in that context.
  • Knowledge bases and Space-scoped memory.
  • Runtime policy such as inherited or local model, guardrail, budget, and sandbox settings when the UI exposes those controls.

The tenant platform agent provides the broad baseline. The Space narrows it for the current workroom.

Read this section

Section titled “Read this section”

Start with Workspace Context and Access and Membership. Then read Triggers and Channels if work enters the Space from email, schedules, or webhooks. Read Tools, Knowledge and Memory, and Runtime Policy when you are deciding what the agent can use inside a Space.

Workspace Context How Space files give the tenant platform agent local procedures, runbooks, customer notes, and project context.
Access and Membership Public and Private Spaces, who can open them, and how membership changes what work can enter the Space.
Triggers and Channels How chat, email, schedules, webhooks, and integrations create or wake work inside a Space.
Tools How Spaces participate in capability availability without replacing tenant MCP and built-in tool registration.
Knowledge and Memory How Space knowledge bases and scoped memory affect what the agent can know for a workroom.
Runtime Policy How Space policy relates to tenant-agent defaults for model, guardrail, budget, paused state, and sandbox behavior.
Spaces and Threads How Spaces shape the durable Threads that chat, email, automations, and integrations create.
Goals How selected Threads become accountable, folder-native workflows with outcome, owner, progress, and review.

Spaces and Goals

Section titled “Spaces and Goals”

Use a Space for the workroom. Use a Goal when a Thread in that workroom should have an explicit outcome, owner, mode, progress model, completion rule, and review policy.

In practice, the Space owns the reusable operating pattern. Customer Onboarding, for example, keeps its Goal template under the Space source folder as markdown files. When the workflow starts, ThinkWork creates a Thread, a Goal row, structured task rows, and a Thread Goal folder. The Thread remains the trace; the Goal explains what completion means.

The sharp rule is:

ObjectUse it for
SpaceContext, access, membership, triggers, knowledge, tools, and local policy
ThreadMessages, turns, audit trail, channel metadata, and collaboration history
GoalOutcome, owner, Delegate/Collaborate mode, progress, completion, and review
Goal folderPortable workflow context: GOAL.md, PROGRESS.md, decisions, artifacts, and handoffs

Spaces vs. folder specialists

Section titled “Spaces vs. folder specialists”

Spaces and folder specialists solve different problems.

Use a Space when the difference is about the workroom: project context, customer context, access, membership, channels, triggers, knowledge, memory, tool availability, or local policy.

Use a folder specialist when the difference is reusable delegated behavior: research, triage, QA, drafting, finance review, onboarding, or another durable specialty under workspaces/<slug>/.

The distinction is practical. A Finance Space can make the tenant platform agent work inside a finance context. A finance folder specialist can give the same platform agent reusable finance-review behavior that it may delegate to from multiple Spaces.

Section titled “Related pages”