Skip to content
ThinkWork ThinkWork

Managed Agents

Managed agents are the default ThinkWork runtime path — the harness’s Planning + Action layer in PPAF. ThinkWork runs the tenant platform agent inside your AWS account on Bedrock AgentCore, then applies the current Space context for each turn.

The important distinction is that managed does not mean vendor-hosted. The runtime container is in your account, thread state is in your Aurora cluster, model invocation goes to your Bedrock endpoint, and audit logs live in your S3 bucket.

A walking tour of one invocation

Section titled “A walking tour of one invocation”

1 — The trigger

Section titled “1 — The trigger”

A new message lands in a Space-scoped thread. It could be a mobile chat message, inbound Space email, Slack event, GitHub webhook, or scheduled automation. The message is persisted and an invocation is queued for the tenant platform agent.

2 — Configuration resolution

Section titled “2 — Configuration resolution”

The dispatcher resolves:

  • Tenant id and caller context.
  • The thread and Space.
  • The tenant platform agent.
  • Space runtime policy.
  • Tenant agent defaults for any unset override.

See Runtime Configuration for the resolution model.

3 — Container invocation

Section titled “3 — Container invocation”

The managed runtime receives the invocation. If the container is cold, it initializes clients and runtime libraries. Warm invocations start faster.

The runtime is preloaded with the ThinkWork runtime library for:

  • Tool registration.
  • MCP and built-in tool access.
  • Memory and Memory context assembly.
  • Workspace file loading.
  • Bedrock invocation.
  • OpenTelemetry instrumentation.
  • Thread message and audit writes.

4 — Space context assembly

Section titled “4 — Space context assembly”

Before calling the model, the runtime assembles context from:

  • Thread history — recent messages and turns from the current thread.
  • Tenant agent workspace — baseline instructions and shared files.
  • Space workspace — local runbooks, procedures, customer or project context, and Space-specific instructions.
  • Knowledge and memory — Space-scoped and tenant-approved sources.
  • Channel metadata — Slack, GitHub, email, task, automation, or chat context.

The system prompt comes from the tenant platform agent baseline plus the rendered Space context.

5 — Bedrock invocation

Section titled “5 — Bedrock invocation”

The runtime calls Bedrock with the resolved model and guardrail settings. Guardrails attach at the model invocation boundary rather than as a prompt-only wrapper.

The model returns either a direct response or a tool-use request.

6 — Tool loop

Section titled “6 — Tool loop”

If the model requests a tool:

  1. The runtime looks up the tool in the registry available to the Space.
  2. The tool runs as a built-in tool, skill-backed tool, or MCP call.
  3. The tool result is added to the turn.
  4. The model continues until it produces a final response or hits a configured stop condition.

Space tool availability matters here: a tool registered at the tenant level is only useful in a turn when the current Space allows it.

7 — Response and streaming

Section titled “7 — Response and streaming”

When the model produces a response, the runtime:

  1. Writes an assistant message.
  2. Writes the turn record with tool calls, memory reads, cost, and duration.
  3. Publishes updates through AppSync.
  4. Streams partial text to connected clients when streaming is active.

8 — Post-turn side effects

Section titled “8 — Post-turn side effects”

After the turn completes:

  • Memory retention can record useful facts.
  • Memory compile work can be queued.
  • Audit records are written.
  • Cost spans are reduced into cost rows.

Why this shape matters

Section titled “Why this shape matters”
  • One platform-agent identity. Operators do not need to manage a fleet of top-level managed-agent records.
  • Space-local behavior. Context, tools, memory, triggers, and runtime policy live where the work happens.
  • Every turn resolves fresh config. Tenant-agent changes and Space override changes apply to new turns without a redeploy.
  • Audit stays unified. Threads, turns, tool calls, cost, and channel metadata all attach to the same durable thread model.

When to use managed agents

Section titled “When to use managed agents”

Managed agents are the best fit when you want:

  • Bedrock-native deployment in your own AWS account.
  • A standard runtime path across Spaces.
  • Tight integration with threads, memory, automations, and controls.
  • Tenant-wide defaults with Space-specific overrides.
  • Per-turn cost, audit, streaming, and guardrail integration.

Use connected agents when you already run an external agent service and want ThinkWork’s threads, auth, audit, and control plane around it.

Configuration layers

Section titled “Configuration layers”
LayerExamples
Tenant AgentName, role, default model, budget, sandbox, system prompt, baseline workspace
SpaceWorkspace files, tools, memory, triggers, email channel, runtime policy
DeploymentRuntime image, memory, networking, environment variables, Bedrock access

Templates and older per-agent records can still appear in migration, authoring, or audit flows. For normal operation, start with Tenant Agent and Spaces.

Known limits

Section titled “Known limits”
  • In-flight turns keep the configuration they loaded at start.
  • Space runtime fields only override the fields they set; empty fields inherit from the tenant agent.
  • Long-running tool-heavy turns still obey the runtime’s execution ceiling.
  • If a model or guardrail referenced by the tenant agent or Space is unavailable in the deployment, the turn fails with a configuration error rather than silently changing policy.
Section titled “Related pages”