Agents

An agent in ThinkWork is a named entity that receives messages in a thread and produces responses. Agents come in two flavors: managed (ThinkWork runs the runtime inside your AWS account) and connected (you bring your own runtime).

The role of agents in the system

Agents are the decision-making layer of ThinkWork. They sit on top of threads, use memory and document knowledge for context, and call tools through skill packs or connectors.

If you’re new to the model, a good reading order is:

1. Threads
2. Agents
3. Memory
4. Connectors

Managed agents

Managed agents are the default ThinkWork runtime. ThinkWork runs them on AgentCore in your AWS account and wires them into the rest of the platform.

That means ThinkWork gives you managed execution without forcing you into a vendor-hosted control plane.

Every managed agent has:

• A model selected through an agent template
• A system prompt stored on the agent record
• Optional skill packs
• Optional document knowledge access
• Optional memory behavior

Read Managed Agents for the runtime model and Templates and Skills for the reuse model.

Creating a managed agent

Use the admin app or the GraphQL API:

mutation CreateAgent {
  createAgent(input: {
    name: "Support Bot"
    description: "Handles tier-1 customer support questions"
    systemPrompt: "You are a helpful support agent for Acme Corp. Be concise and accurate."
    templateId: "tpl-claude-sonnet"
    skillPackIds: ["sp-jira", "sp-confluence"]
    knowledgeBaseId: "kb-support-docs"
  }) {
    id
    name
    status
  }
}

Connected agents

Connected agents let you plug an existing runtime, such as your own Python service, LangChain app, or custom container, into the ThinkWork thread and control plane. ThinkWork handles auth, thread persistence, real-time updates, and the admin UI while you provide the inference logic.

Connected agents register a webhook endpoint. When a message arrives in a thread assigned to a connected agent, ThinkWork POSTs the thread context to your endpoint and expects a response in the standard message format.

Note

Connected agents are useful when you already have agent infrastructure and want ThinkWork’s thread system, connectors, and admin app on top of it without migrating your runtime.

Agent Templates

Agent Templates define fleet-wide defaults for model selection, guardrails, and tool configuration. Rather than setting these per-agent, you set them once on a template and assign agents to that template.

A template specifies:

Field	Description
modelId	Bedrock model ID (e.g. anthropic.claude-3-5-sonnet-20241022-v2:0)
guardrailId	Bedrock Guardrail ID to apply on every invoke
maxTokens	Maximum output tokens per turn
temperature	Sampling temperature (0.0–1.0)
toolConfig	Which tool categories are enabled (SQL, S3, web, and connector-provided tools such as MCP)
memoryConfig	Memory engine settings (retain/recall/reflect intervals)

Example template

mutation CreateTemplate {
  createAgentTemplate(input: {
    name: "Claude Sonnet — Standard"
    modelId: "anthropic.claude-3-5-sonnet-20241022-v2:0"
    maxTokens: 8192
    temperature: 0.3
    guardrailId: "gr-default-safe"
    toolConfig: {
      sqlEnabled: true
      s3Enabled: true
      mcpEnabled: false
      webEnabled: false
    }
  }) {
    id
    name
  }
}

When you update a template, every agent assigned to it picks up the change on the next invoke. This is the primary mechanism for rotating models and runtime defaults across your fleet.

Skill packs

Skill packs are the primary extension mechanism for managed agents. A skill pack is a SKILL.md file stored in your S3 skill catalog bucket. At invoke time, AgentCore downloads the skill packs assigned to the agent, parses them, and injects their capabilities into the runtime.

Managed agents can also receive external tools through connectors, including MCP-based tool connectors configured at the tenant and template level. Use skill packs when you want to package logic inside ThinkWork, and use connector-managed tool systems when you want agents to call out to existing external services.

See Templates and Skills for the fuller operating model and Authoring Guide: Skill Packs for the SKILL.md format.

Model selection

ThinkWork uses Amazon Bedrock for managed agent inference. Any model available in your region through Bedrock can be used, but you must request model access in the AWS console first.

Recommended starting models:

Use case	Model ID
General purpose (recommended)	anthropic.claude-3-5-sonnet-20241022-v2:0
High throughput / lower cost	anthropic.claude-3-haiku-20240307-v1:0
Complex reasoning	anthropic.claude-3-5-sonnet-20241022-v2:0 with extended thinking
Long context	anthropic.claude-3-5-sonnet-20241022-v2:0 (200k context)

Model IDs are usually set at the Agent Template level rather than per-agent.

Memory and document knowledge

Agents use memory and document knowledge, but they do not own those concepts.

• Use Memory for the umbrella model
• Use Document Knowledge for Bedrock Knowledge Bases
• Use Long-term Memory for retained context across work

Over time, ThinkWork should expose that memory through a ThinkWork-owned contract so portability is defined at the harness layer, not by raw backend endpoints.

Tip

Start with the default AgentCore LongTerm memory and a single focused knowledge base. Expand from there once the agent’s job and retrieval needs are clear.

Agent lifecycle

created → active → suspended → archived

• created — Agent exists but has never been invoked
• active — Agent is accepting messages
• suspended — Agent is paused (for example, budget limit hit)
• archived — Agent is retired and read-only