Skip to content
ThinkWork ThinkWork

Agents

An agent in ThinkWork is the runtime actor that reads a thread, chooses the next step, calls tools, and writes the result back. In the current managed model, a tenant does not operate a roster of separate top-level managed agents. It operates one tenant platform agent whose behavior is shaped by the Space and folder context for the current work.

The useful mental model is:

Tenant platform agent
  + Space context
  + folder-specialist context
  + tools, memory, and guardrails
  = the agent behavior for this turn

The database row gives ThinkWork something stable to bill, audit, pause, and invoke. The folder tree gives the model its instructions, routing map, memory notes, skills, and specialist workrooms.

The current model

Section titled “The current model”

ThinkWork separates agent behavior into three layers:

LayerPurposeOperator surface
Tenant platform agentTenant-wide baseline identity, model, budget, sandbox, and foldersAdmin - Tenant Agent
SpaceLocal workroom: context, access, tools, memory, channels, overridesAdmin - Spaces
Folder specialistDelegated behavior stored as files under workspaces/<slug>/Tenant Agent workspace authoring flows

This keeps operations small. Configure the platform agent once, create Spaces for real business contexts, and add folder specialists only where the platform agent needs a durable specialty.

What the tenant platform agent owns

Section titled “What the tenant platform agent owns”

The tenant platform agent owns defaults that should be true across the tenant:

  • Display name and broad role.
  • Default Bedrock model.
  • Default monthly budget.
  • Default sandbox behavior.
  • Baseline workspace files.
  • Root AGENTS.md routing and specialist folders.

These are tenant defaults, not project details. If a Space needs a different model, guardrail, budget, paused state, sandbox mode, tool set, email channel, or memory scope, configure the Space instead.

What Spaces own

Section titled “What Spaces own”

A Space gives the platform agent the current workroom. It can carry:

  • Workspace files for a project, customer, team, workflow, or channel.
  • Public or private membership.
  • Built-in tools and MCP server availability.
  • Knowledge bases and Space-scoped memory.
  • Triggers and channels.
  • Runtime policy.

When a thread starts in a Space, ThinkWork invokes the tenant platform agent with that Space context rendered into the runtime workspace. The turn still has one managed-agent identity for audit and cost accounting, but its behavior is shaped by the Space.

Folder specialists

Section titled “Folder specialists”

Folder specialists are authored under workspaces/<slug>/. A specialist can be as small as one CONTEXT.md file, or it can carry its own AGENTS.md, memory/, skills/, and nested workspaces/ children.

Use a folder specialist when the platform agent needs a durable specialty such as research, triage, QA, drafting, finance review, or customer onboarding. Use a Space when the difference is access, audience, project context, channel, memory, or runtime policy.

The root AGENTS.md is the routing map. A row such as this makes the specialist available:

| Task                     | Go to                | Read                           | Skills            |
| ------------------------ | -------------------- | ------------------------------ | ----------------- |
| Expense policy questions | workspaces/expenses/ | workspaces/expenses/CONTEXT.md | finance-audit-xls |

The folder path is the specialist boundary. The runtime can load only the files relevant to that boundary instead of handing every prompt, skill, and note to every turn.

Managed and connected runtimes

Section titled “Managed and connected runtimes”

Most tenants use the managed runtime path: ThinkWork runs the tenant platform agent on Bedrock AgentCore inside your AWS account. The harness, state, memory, guardrails, audit, and data stay inside your deployment boundary.

Connected agents still exist for bring-your-own-runtime integrations. Use them when you already operate an external agent service and want ThinkWork’s threads, auth, audit, and control plane around it. Connected agents are registered through Agent Invites, not through the tenant platform-agent page.

How a turn runs

Section titled “How a turn runs”

When a user message, email, automation, or integration event creates work:

Thread event
  -> resolve tenant and Space
  -> load tenant platform agent
  -> apply Space runtime policy or inherit tenant defaults
  -> render root folder + Space context + specialist folder context
  -> invoke managed runtime
  -> run tools or skills if requested
  -> write messages, turns, cost, audit, and tool events back to the thread
  -> publish updates to admin and mobile clients

Every new turn resolves current configuration. In-flight turns keep the files and settings they loaded when they started.

What belongs where

Section titled “What belongs where”
Put it hereWhen it is about
Tenant Agent configTenant-wide model, budget, sandbox, and broad role
Root AGENTS.mdRouting, identity, folder map, and specialist ownership
Root CONTEXT.mdGeneral responsibilities that apply before a specialist or Space narrows context
workspaces/<slug>/Durable specialist instructions and resources
Space workspaceProject, team, customer, channel, or workflow context
skills/<slug>/SKILL.mdReusable capability packages
memory/*.mdEditable workspace notes, not long-term transcript retention
Tenant MCP / credential UISecrets, OAuth, and external service configuration
Section titled “Related pages”