Skip to content
ThinkWork ThinkWork

Admin — Tenant Agent

The Tenant Agent page is the operator surface for the one platform agent every tenant runs through. It replaces the older per-agent roster as the day-to-day managed-agent control plane.

Route: /tenant-agent Legacy routes: /agents/* routes are retired or redirect to the current platform-agent model.

Use this page to set the tenant-wide agent baseline. Use Spaces to give that baseline different workrooms, workspace context, knowledge, triggers, access, and local policy.

What the tenant agent controls

Section titled “What the tenant agent controls”

The tenant agent is the default runtime identity for the tenant. Its configuration supplies the fallback values a Space inherits when the Space has not set an override.

The Config tab exposes:

FieldWhat it changes
NameThe display name used in operator surfaces and thread context
RoleThe default job description for the tenant platform agent
ModelThe fallback Bedrock model for Spaces that inherit from the tenant agent
Monthly budget centsThe fallback monthly budget cap
SandboxThe fallback code-sandbox mode
System promptThe baseline instructions loaded before Space context

Changes apply to new turns. An in-flight turn finishes with the configuration it loaded when the turn started.

Tabs

Section titled “Tabs”

Config

Section titled “Config”

The Config tab is where operators tune the tenant-wide defaults. Keep this layer broad: it should describe what the platform agent is for across the tenant, not the details of a single project, customer, workflow, or channel.

Good tenant-agent settings answer questions such as:

  • What role should the platform agent play for this company?
  • Which default model should normal Spaces inherit?
  • What broad safety and budget defaults should apply before a Space narrows them?
  • What instructions should every Space receive before local context is added?

Project-specific context belongs in a Space. Specialty behaviors belong in workspaces/<slug>/ folder specialists or Space workspace files.

Workspace

Section titled “Workspace”

The Workspace tab shows files the tenant platform agent reads as part of its baseline context. These files are the tenant layer of the runtime workspace. Use them for shared operating principles, standing instructions, and reusable context that should apply across Spaces.

During a turn, these Agent files hydrate at the root of /workspace. User context is merged into that root, and the active Space mounts separately as Space/.

Do not put Space-specific procedures here if they only apply to one workroom. Put those files on the Space workspace instead so other Spaces do not inherit irrelevant instructions.

Folder specialists

Section titled “Folder specialists”

The folder-specialist authoring surface edits workspaces/<slug>/ folders. Specialists are authored as files under the tenant agent instead of as separate top-level agent records.

A specialist folder should carry the focused context a specialty needs: role, instructions, memory notes, skills, and supporting files. The tenant platform agent can delegate to those specialties at runtime while preserving a single platform-agent identity for the tenant.

How Spaces use the tenant agent

Section titled “How Spaces use the tenant agent”

Spaces are contextual workrooms. A Space supplies:

  • Membership and access mode.
  • Workspace files for that context.
  • Tools, MCP servers, knowledge bases, memory, and triggers.
  • Local policy for the workroom when the current Admin UI exposes it.
  • A Space email address for inbound work.

When a Space leaves a runtime override empty, it inherits from the tenant agent. This keeps common defaults in one place while still letting high-risk or high-volume Spaces tighten their own settings.

Email behavior

Section titled “Email behavior”

Per-agent vanity addresses have been retired. Inbound cold-contact email starts at the Space layer.

Space email addresses use this format:

<space-slug>@<tenant-slug>.thinkwork.ai

Cold-contact delivery is accepted only when the Email trigger is enabled for that Space and the sender email matches a registered tenant user. Private Spaces additionally require that user to be a Space member. Token-bearing replies to agent-initiated emails continue to work even when the Email trigger is disabled or deleted so existing conversations can continue.

Known limits

Section titled “Known limits”
  • The old agent roster is no longer the primary managed-agent workflow. Use /tenant-agent and /spaces.
  • Historical thread records may still carry an agent_id, but after migration that id points at the tenant platform agent. It no longer distinguishes separate top-level managed agents.
  • If the page says no tenant agent is available, the tenant has not completed the platform-agent migration or the current user cannot read the tenant agent.
Section titled “Related pages”