Skip to main content

Agents

Agents are autonomous AI entities that can execute tasks and use tools. Each agent belongs to an organization and, optionally, to an AgentTemplate that seeds its initial configuration.

Agent Properties

Creating an Agent

Usually you create an agent from a template — the agent snapshots the template’s system_prompt, default_model, adapter set, and per-adapter config at creation.
You can override any field at creation time (e.g., specify a custom model, system_prompt, or adapters array). Ad-hoc agents without a template are allowed too — pass template: null and provide model + system_prompt + adapters explicitly.
If model or system_prompt are blank at creation and a template is attached, the template’s values are copied in. Template edits after that don’t retroactively change the agent.

Tagging Agents

Tags are free-form string labels. Useful for filtering in the portal — e.g., git-ref:feature/x on eval agents, or cohort:beta on production agents.
Both endpoints are idempotent — the POST returns 200 if the tag already existed, 201 if it was created.

Running an Agent

Wake an agent to start execution:

What Happens During a Run

Every run_agent invocation spawns an isolated bedrock-harness subprocess (pinned to the template’s harness_git_ref, or latest main if unset). The harness drives the loop and streams spans back to Bedrock over HTTP; a HarnessRun row links the subprocess to the resulting Trace.
  1. Status Change: Agent transitions to RUNNING
  2. Runtime Loop (up to max_turns iterations):
    • Build prompt with system instructions and adapter state
    • Call LLM with available tools
    • Process any tool calls
  3. Sleep: Agent calls sleep tool or hits max turns

The Runtime Loop

  1. Build prompt with tools and adapter state
  2. Call LLM
  3. Process tool calls
  4. Check if should continue — if yes, go back to step 1; if no (sleep called), exit

Built-in Default Tools

Every agent has access to these tools regardless of adapters:

Sleep Tool

Agents must call sleep to end their run gracefully. Before sleeping, the agent must verify a checklist of conditions:
Sleeping to wait on the user is usually an indication that more work should be done. Agents should only sleep when they MUST wait on something external, not when they simply need user input.
If any checklist item is false, the sleep will be rejected and the agent must address the issue before sleeping. If an agent doesn’t call sleep and hits max_turns, it’s automatically put to sleep for 1 hour.

Stopping an Agent

Force-stop a running agent:
This immediately transitions the agent to SLEEPING status.

Agent State

Agents using built-in adapters have persistent state: This state persists across runs and is private to each agent.

Supported Models

Bedrock supports models from: Anthropic (Claude):
  • claude-sonnet-4-5
  • claude-opus-4
  • claude-haiku-4-5
OpenAI:
  • gpt-4o
  • gpt-4o-mini
  • gpt-4-turbo
Claude models get automatic access to web search capabilities.

Usage Tracking

Get usage statistics for an agent:
Response:

Wakeup Message

When an agent wakes up, it receives this instruction:
You are being woken up from sleep. Gather information from your tools to determine what to do next. Check every tool that stores information (like any tool with ‘list’ in the name) to re-ground yourself.
This prompts agents to check for new messages, tasks, etc. before taking action.

Example: Complete Agent Lifecycle