DEV Community: yoko / Naoki Yokomachi

Building an AWS Cost Visualization Workflow with Strands Agents Skills and AgentCore Code Interpreter

yoko / Naoki Yokomachi — Fri, 03 Apr 2026 01:26:25 +0000

Introduction

I'm currently developing a personal AI agent called TONaRi. It also has an X (Twitter) account where it posts tech news and more.
https://x.com/tonari_with

The agent's core architecture is built on Strands Agents + Amazon Bedrock AgentCore.

In this article, I combined AgentCore Code Interpreter with Strands Agents' Agent Skills to implement a workflow that retrieves AWS cost data and generates chart images using code. Check out the video demo below:

https://x.com/_cityside/status/2035339843014987845

Although this was an addition to an existing web application codebase, I hope it also serves as a useful reference for building something similar from scratch.

Here are the main technologies used:

AgentCore Code Interpreter: One of Amazon Bedrock AgentCore's building blocks that executes code in a sandboxed environment
Agent Skills (SKILL.md): Externalized prompts that are loaded on demand
Cost Explorer API: An API for retrieving AWS cost data, called from an agent tool
S3: Stores chart images generated by Code Interpreter, served to the frontend via Presigned URLs

Amazon Bedrock AgentCore Code Interpreter

Amazon Bedrock AgentCore Code Interpreter (hereafter "Code Interpreter") is one of the building blocks that allows agents hosted on AgentCore Runtime to safely execute code in a sandboxed environment.
https://aws.amazon.com/blogs/machine-learning/introducing-the-amazon-bedrock-agentcore-code-interpreter/

Key features include:

Code execution in a sandboxed environment
Pre-installed libraries such as pandas, numpy, and matplotlib
In addition to the default access-restricted environment, you can create user-defined environments with public internet access or VPC connectivity

In this project, I use Code Interpreter to have the agent dynamically generate chart images from data using matplotlib.

Strands Agents Skills

Agent Skills is a mechanism originally proposed by Anthropic. In a nutshell, it works like this: you define procedures you want the agent to execute in Markdown files (similar to system prompts), then inject only the metadata into the system prompt. The agent dynamically loads the Skill files based on the metadata and executes the procedures. This approach helps reduce token consumption and prevents context pollution.

As of March 2026, Agent Skills are now available in Strands Agents as well:
https://strandsagents.com/docs/user-guide/concepts/plugins/skills/

For this project, I defined the following workflow as a Skill:

Call the Cost Explorer API tool to retrieve cost data for the user-specified period
Call the cost visualization tool
- 2-1. Convert cost data into a chart image using Code Interpreter
- 2-2. Upload the image to S3
- 2-3. Return the S3 presigned URL

Processing Flow

Here's a simplified overview of the processing flow:

User: "Show me this month's AWS costs"
  ↓
Main Agent
  ├─ ① skills tool: Load skill
  ├─ ② get_aws_cost tool: Call Cost Explorer API
  └─ ③ execute_python tool
     └─ ③-1 Generate matplotlib chart via Code Interpreter
        ③-2 Upload to S3
        ③-3 Return presigned URL
  ↓
Frontend: Detect S3 image URL in text → Display inline in chat

Implementation

get_aws_cost: Cost Data Retrieval Tool

The AWS cost retrieval tool is defined as an agent tool using the @tool decorator. The logic is separated from the Code Interpreter chart image generation.

import boto3
from strands import tool

_ce_client = boto3.client("ce", region_name="ap-northeast-1")

@tool
def get_aws_cost(
    period: str = "monthly",
    months: int = 1,
    group_by_service: bool = True,
) -> str:
    """Retrieve AWS cost data from Cost Explorer.

    Use this tool to fetch cost data. Then pass the result to execute_python
    to create matplotlib charts for visualization.

    Args:
        period: Granularity - "monthly" or "daily".
        months: Number of months to look back (default: 1, max: 6).
        group_by_service: If True, break down costs by AWS service.

    Returns:
        JSON string with cost data.
    """
    ce = _ce_client
    # ...
    response = ce.get_cost_and_usage(
        TimePeriod={"Start": start, "End": end},
        Granularity="MONTHLY",
        Metrics=["UnblendedCost"],
        GroupBy=[{"Type": "DIMENSION", "Key": "SERVICE"}],
    )
    return json.dumps({"data": data})

execute_python: Code Execution Tool

Similarly, Code Interpreter code execution is defined as an agent tool using the @tool decorator. To reliably capture matplotlib figures, the tool automatically injects capture code before and after the agent-generated code.

from bedrock_agentcore.tools.code_interpreter_client import code_session

CODE_INTERPRETER_REGION = os.getenv("CODE_INTERPRETER_REGION", "ap-northeast-1")
OUTPUT_BUCKET = os.getenv("CODE_INTERPRETER_OUTPUT_BUCKET", "ap-northeast-1")
_s3_client = boto3.client("s3", region_name=os.getenv("AWS_REGION", "ap-northeast-1"))

@tool
def execute_python(code: str, description: str = "") -> str:
    """Execute Python code in a sandboxed environment. Use this to run data analysis,
    generate charts with matplotlib, or perform calculations.

    Available libraries: pandas, numpy, matplotlib, json, datetime.
    Use ONLY matplotlib for plotting (not seaborn).
    Use English for all chart labels and titles (Japanese fonts are not available).

    IMPORTANT for chart generation:
    - Do NOT call plt.savefig() — images are auto-captured from open figures.
    - Do NOT call plt.close() — closing figures prevents image capture.
    - Just create figures with plt.subplots() and leave them open.
    - Do NOT use boto3 — the sandbox has no AWS credentials.

    Args:
        code: Python code to execute.
        description: Optional description of what the code does.

    Returns:
        JSON string with execution results including stdout, stderr, and image URLs.
    """
    # Automatically inject matplotlib image capture code
    img_code = f"""
import matplotlib
matplotlib.use('Agg')
{code}
import matplotlib.pyplot as plt, base64, io, json as _json
_imgs = []
for _i in plt.get_fignums():
    _b = io.BytesIO()
    plt.figure(_i).savefig(_b, format='png', bbox_inches='tight', dpi=100)
    _b.seek(0)
    _imgs.append({{'i': _i, 'd': base64.b64encode(_b.read()).decode()}})
if _imgs:
    print('_IMG_' + _json.dumps(_imgs) + '_END_')
plt.close('all')
"""
    with code_session(CODE_INTERPRETER_REGION) as code_client:
        response = code_client.invoke("executeCode", {
            "code": img_code,
            "language": "python",
            "clearContext": False,
        })
        # Extract images from stdout using _IMG_..._END_ markers
        # Upload to S3 and return presigned URLs

Creating the SKILL.md

Now that the tools are defined, we create the Agent Skill that defines how to call them. The directory structure looks like this:

agentcore/
├── skills/
│   └── aws-cost/
│       └── SKILL.md
├── app.py
└── ...

The SKILL.md file contains YAML frontmatter and a Markdown-formatted prompt:

---
name: aws-cost
description: "Analyze and visualize AWS cost data using get_aws_cost"
  for data retrieval and execute_python for matplotlib chart generation
allowed-tools: get_aws_cost execute_python
---

# AWS Cost Analysis Skill

Two-step process: fetch data with `get_aws_cost`,
then visualize with `execute_python`.

## Critical Rules

- **NEVER call plt.savefig()** — images are auto-captured from open figures.
- **NEVER call plt.close()** — closing figures prevents image capture.
- **Use English for ALL text** in charts — Japanese fonts are unavailable.

## Step 1: Fetch Data
(How to call get_aws_cost)

## Step 2: Visualize
(matplotlib code template)

Integrating with the Agent

The tools are passed via the tools parameter, and the Skill is initialized with the AgentSkills plugin and passed to the agent.

from strands import Agent, AgentSkills
from src.agent.code_interpreter import execute_python
from src.agent.aws_cost import get_aws_cost

# Initialize the Skills plugin
skills_plugin = AgentSkills(skills="./skills/")

# Create the agent
agent = Agent(
    tools=[*other_tools, execute_python, get_aws_cost],
    plugins=[skills_plugin],
    system_prompt=system_prompt,
)

I'll skip the frontend implementation details, but essentially it detects image URLs in the agent's response and automatically fetches and displays them inline.

Demo

Here's what it looks like when the skill is actually running. Since the chart-generating code is dynamically created by the agent, the output varies depending on how you phrase your instructions.

Here's the video demo again from the beginning of the article:

https://x.com/_cityside/status/2035339843014987845

Wrapping Up

That's how I implemented an AWS cost charting feature using Agent Skills + Code Interpreter. (Admittedly, you could just look at the Cost Explorer console for the same information, but this was more of a proof of concept...)

In this implementation, I used the default Code Interpreter tool, which restricts public internet access. However, by using a user-defined Code Interpreter tool, you could enable more flexible code execution. I'd love to explore the possibilities further.

Using OpenRouter's OpenAI-Compatible Models (Grok 4.1 Fast) with Strands Agents

yoko / Naoki Yokomachi — Sun, 15 Mar 2026 02:05:39 +0000

This article is an AI-assisted translation of a Japanese technical article.

Introduction

I'm building a personal AI agent called TONaRi ("tonari" means "next to" in Japanese — named with the idea of an AI that stands next to you and supports your daily life). It's built with Strands Agents + Amazon Bedrock AgentCore, with a VRM-powered 3D avatar frontend using AITuberKit.

In a previous article, I wrote about cost reduction through sub-agent splitting.
https://dev.to/yokomachi/28-tool-definitions-cutting-ai-agent-costs-with-sub-agent-splitting-4dbp

This time, I took cost reduction a step further by making it possible to switch the LLM itself to Grok 4.1 Fast via OpenRouter.

Cost Comparison

Let's compare the costs between Claude Haiku 4.5 (Amazon Bedrock), which I had been using as the main model, and Grok 4.1 Fast (OpenRouter), the new alternative.

	Claude Haiku 4.5 (Bedrock)	Grok 4.1 Fast (OpenRouter)
Input	$1.10 / 1M tokens	$0.20 / 1M tokens
Output	$5.50 / 1M tokens	$0.50 / 1M tokens

That's a significant difference. As I mentioned in the previous article, LLM per-token pricing is by far the biggest cost driver, so reducing the unit price — while maintaining an acceptable quality balance — has the greatest impact.

Switching Models in Strands Agents

Strands Agents is an open-source agent SDK provided by AWS, and it supports models beyond Bedrock. Using the OpenAIModel class, you can directly use models from any service that provides an OpenAI-compatible API, such as OpenRouter. If you need broader provider support, LiteLLMModel is also an option. Since Grok 4.1 Fast is OpenAI-compatible, we use the OpenAIModel class directly.

Creating an OpenAIModel

First, add the openai dependency.

dependencies = [
    "strands-agents>=1.23.0",
    "openai>=1.0.0",
    # ...
]

Then create the model instance via OpenRouter.

from strands.models.openai import OpenAIModel

model = OpenAIModel(
    client_args={
        "api_key": "your-openrouter-api-key",
        "base_url": "https://openrouter.ai/api/v1",
    },
    model_id="x-ai/grok-4.1-fast",
)

The created model can be passed to an Agent with the exact same interface as a Bedrock model.

from strands import Agent

agent = Agent(
    model=model,  # Works the same whether BedrockModel or OpenAIModel
    system_prompt="You are a personal AI assistant.",
    tools=my_tools,
)

Wrap Up

So I switched the model used for everyday conversations to Grok 4.1 Fast, and my impression is that quality isn't a major issue for casual conversation. However, application-specific conversation tags (this AI agent uses tags like [happy] or [bow] to trigger facial expressions and motions) sometimes get ignored or misinterpreted by the model, so that still needs tuning.

I also had concerns about tool calling via AgentCore Gateway, but it's been working surprisingly well without any major adjustments.

I'll continue monitoring and consider trying other models or implementing model-specific routing if needed.

28 TOOL DEFINITIONS! — Cutting AI Agent Costs with Sub-Agent Splitting

yoko / Naoki Yokomachi — Sat, 07 Mar 2026 12:53:02 +0000

This article is an AI-assisted translation of a Japanese technical article.

Introduction

As I kept adding tools to make my personal AI agent more useful for daily tasks, the input tokens per API call ballooned — and so did the cost.

It's lower now, but the projection was heading toward $120/month

In this article, I'll walk through the input token bloat problem caused by too many tools and how I tackled it by splitting into sub-agents.

Architecture Overview

Here's a high-level look at TONaRi's architecture:

Frontend (Next.js + VRM 3D Avatar)
  → Next.js API Route
    → AgentCore Runtime (Strands Agent)
      → AgentCore Gateway → Lambda functions (tools)
      → AgentCore Memory (STM/LTM)

The agent runs as a container deployed on Bedrock AgentCore Runtime. External tools are implemented as Lambda functions accessed through AgentCore Gateway. Adding a new tool is as simple as writing a Lambda function and registering it as a Gateway target.

All the Tools

AgentCore Gateway lets you expose Lambda functions as agent tools.

from strands.tools.mcp import MCPClient
from mcp_proxy_for_aws.client import aws_iam_streamablehttp_client

def create_mcp_client(gateway_url: str, region: str) -> MCPClient:
    def create_transport():
        return aws_iam_streamablehttp_client(
            endpoint=gateway_url,
            aws_region=region,
            aws_service="bedrock-agentcore",
        )
    return MCPClient(create_transport)

Here are all the tools I've connected:

Domain	Tools	Count
Task Management	List, Add, Complete, Update	4
Calendar	List events, Check availability, Create, Update, Delete, Suggest schedule	6
Gmail	Search, Get, Create draft, Archive	4
Notion	Search pages, Get page, Create, Update, Query DB, Get DB	6
Twitter	Get today's tweets, Post	2
Diary	Save, Get	2
Date Utils	Get current datetime, Calculate date, List date range	3
Web Search	Web search	1
Total		28

Each tool can be called individually, but the real power is chaining. For example, saying "Search for a recipe, save the bookmark to Notion, create a shopping list, and add grocery shopping to my tasks" triggers:

Web search tool finds a recipe
Saves the URL to a Notion bookmark page
Creates a shopping list from the recipe and saves it to a Notion memo page
Adds a grocery shopping task to TONaRi's task list

The AI agent sits between tools and interprets vague user requests to orchestrate across them — this is the most useful aspect of using an AI agent day-to-day.

The Input Token Explosion

Behind the convenience, costs were quietly piling up. When calling the Bedrock API, input tokens consist of four main components:

System prompt: Agent character settings, behavior rules
Tool definitions: Name, description, and JSON schema for every tool
Long-term memory (LTM): Episodes and facts extracted from past conversations
Conversation history (STM): Current session content

The biggest culprit was tool definitions. I had Claude Code calculate it — the 28 tools directly connected to the agent consumed about 5,000 tokens.

Breaking Down the Numbers

Here's a rough breakdown of input tokens per call for the monolithic agent:

Component	Estimated Tokens
System prompt (character + all domain rules)	~3,500
Tool definitions (28 tools × schema)	~5,000
LTM search results	~1,500
Conversation history (10 turns)	Variable (~5,000–30,000)

The system prompt, tools, and LTM are essentially fixed costs sent with every message — that's 10,000 tokens per call. With about 100 calls per day, the monthly fixed cost alone is:

10,000 tokens × 100 calls/day × 30 days = 30,000,000 tokens/month

At Claude Haiku 4.5's Bedrock input token rate ($1.10/1M tokens for Japan cross-region inference), that's $33/month in fixed costs alone. As a solo developer, having ~$33/month go toward tool definitions that might not even be used on a given call was painful.

Splitting into Sub-Agents

To reduce the number of tool definitions the main agent loads, I created domain-specific sub-agents and had the main agent call them via the @tool decorator.

[Before: Monolithic]
Main Agent
├── System prompt (all domain rules)
└── 28 tools ← sent every single call

[After: Sub-agent split]
Main Agent
├── System prompt (generic rules only)
├── DateTool (3 tools)      ← frequently used, kept in main
├── TavilySearch (1 tool)   ← same
├── task_agent      ← defined as @tool (4 tools)
├── calendar_agent  ← defined as @tool (6 tools)
├── gmail_agent     ← defined as @tool (4 tools)
├── notion_agent    ← defined as @tool (6 tools)
├── diary_agent     ← defined as @tool (2 tools)
├── briefing_agent  ← defined as @tool (multi-domain tools)
└── twitter_agent   ← defined as @tool (2 tools)

Sub-Agent Implementation

With Strands Agents' @tool decorator, you can define a sub-agent as a tool for the main agent:

@tool
def calendar_agent(request: str) -> str:
    """Google Calendar sub-agent. Handles listing, availability checks, creating, updating, and deleting events.

    Args:
        request: A request related to the owner's calendar
    """
    try:
        agent = Agent(
            model=BedrockModel(
                model_id="jp.anthropic.claude-haiku-4-5-20251001-v1:0",
                region_name="ap-northeast-1",
                streaming=True,
            ),
            system_prompt="You are a Google Calendar specialist assistant...",
            tools=_calendar_tools,  # calendar tools only
            callback_handler=None,
        )
        result = agent(request)
        return str(result)
    except Exception as e:
        return f"Calendar operation error: {e}"

System Prompt Reduction

By splitting sub-agents by domain, domain-specific rules moved from the main system prompt to each sub-agent's prompt.

Before: Main prompt contained all domain rules

- Calendar rules (duplicate checks, deletion confirmation, etc.)
- Gmail rules (draft only, date search caveats, etc.)
- Notion rules (property formats, database mappings, etc.)
- Briefing procedure (5 detailed sections)
- Diary creation flow (interview → generate → save)
- ...

After: Main prompt only has sub-agent list and delegation rules

## Sub-agent Coordination
- task_agent: Task management (list, add, complete, update)
- calendar_agent: Google Calendar (get, create, update, delete events)
- gmail_agent: Gmail (search, get, create drafts)
- ...

### Delegation Rules
- Describe requests to sub-agents in detail
- Rephrase sub-agent results in your own words

This reduced the system prompt from ~7,400 characters to ~3,800 characters.

Cost Reduction

Comparing the main agent's fixed cost per call:

Component	Before (Monolithic)	After (Sub-agent split)
System prompt	~3,500 tokens	~2,000 tokens
Tool definitions	28 tools (~5,000 tokens)	12 tools (~2,500 tokens)
LTM search results	~1,500 tokens	~1,500 tokens
Fixed cost total	~10,000 tokens	~6,000 tokens

Those 4,000 tokens weren't deleted — they moved to the sub-agents. Here's the per-call input token cost for each sub-agent:

Sub-agent	Prompt	Tool Defs	Request Message	Total
task_agent	~400	~400	~100	~900
calendar_agent	~400	~850	~100	~1,350
gmail_agent	~400	~400	~100	~900
notion_agent	~400	~700	~100	~1,200
briefing_agent	~500	~2,500	~100	~3,100
diary_agent	~400	~200	~100	~700
twitter_agent	~400	~150	~100	~650

If you just add everything up, the "After" total is actually higher. But the key insight is reducing tokens sent on every call. For example, the briefing_agent loads Gmail, Calendar, and task tools all at once and has complex rules — it's expensive, but it only runs once a day. Before, all those definitions were loaded on every single call. Now they only load when needed.

Monthly Cost Impact

Estimating with ~100 calls per day:

[Main agent fixed cost reduction (every call)]
  4,000 tokens/call × 100 calls/day × 30 days = 12,000,000 tokens/month

[Sub-agent additional cost (only when invoked)]
  Assuming ~60% of calls (60/day) trigger one sub-agent
  Average 900 tokens/call × 60 calls/day × 30 days = 1,620,000 tokens/month
  *briefing_agent (~3,100 tokens) runs once/day, calculated separately
  briefing: 3,100 tokens × 30 days = 93,000 tokens/month

[Net savings]
  12,000,000 - 1,620,000 - 93,000 = 10,287,000 tokens/month

At Claude Haiku 4.5's Bedrock input token rate ($1.10/1M tokens, Japan cross-region inference), that's roughly $11/month in input token savings.

Other Optimizations

I also made several complementary changes:

Conversation Window Reduction

Changed SlidingWindowConversationManager's window_size from 15 to 10.
Savings: $3–5/month

LTM Search Result Reduction

Reduced top_k across LTM strategies (total 18 → 10 results).
Savings: $2–3/month

Lightweight Pipeline Agents

For automated tasks like scheduled tweets and news collection, I was using the full main agent. I replaced these with lightweight dedicated agents that share memory but carry only minimal tools.
Savings: $2–3/month

Total Savings

Optimization	Est. Monthly Savings
Sub-agent splitting	$11
Conversation window reduction	$3–5
LTM result reduction	$2–3
Lightweight pipeline agents	$2–3
Total	$18–22

Wrapping Up

So I managed to cut costs to some degree, but it's still expensive...!
If you have any clever cost reduction ideas, I'd love to hear them.

(Fortunately I was recently selected as an AWS Community Builder, so I'm hoping for some AWS credits!)

Controlling VRM Character Motions for an AI Agent on the Web

yoko / Naoki Yokomachi — Sat, 21 Feb 2026 13:00:22 +0000

This article is an AI-assisted translation of a Japanese technical article.
https://zenn.dev/yokomachi/articles/202602_vrm-motion-control-on-web

Introduction

I'm currently working on a personal AI agent project and decided to use a 3D model as the user interface.
Since I didn't have the knowledge to build everything from scratch, I leveraged AITuberKit, an OSS project I'd been aware of for a while, to quickly set up the frontend.

Tech Stack

VRM model creation: VRoid Studio
Web frontend: Next.js, TypeScript
VRM rendering & control: three-vrm (v3.0.0), Three.js
Base kit: AITuberKit
Agent implementation: Strands Agents, Amazon Bedrock AgentCore Not covered in detail in this article

VRM and VRoid Studio

VRM is a file format designed for 3D avatars.
With VRoid Studio, you can create characters and export them in VRM format without any 3D modeling knowledge.
In my case, my only prior experience was creating characters in video games, but I was able to create two models (male and female) in about an hour — that's how easy it is.

https://x.com/_cityside/status/2019742015617994773

What AITuberKit Can Do

AITuberKit is an OSS that displays VRM models in a web browser and bundles features like LLM-powered chat, facial expression control, and speech synthesis.

Here are some of the key features AITuberKit provides:

VRM model display, facial expression control, and lip-sync
LLM-powered chatbot functionality
Speech synthesis API integration
YouTube streaming integration
Multimodal input
etc.

For my project, since I'm building it as a personal AI agent, I'm using AITuberKit's base features like VRM display control and chatbot functionality while adding heavy customizations on top.

Implementing Motion Control

Here's where we get to the main topic.
AITuberKit supports switching facial expressions (smile, angry face, etc.) out of the box, so I decided to implement additional body motions (bowing, extending a hand, etc.).

https://x.com/_cityside/status/2016874430056845502

Architecture Overview

Here's the overall picture of the motion control system:

LLM Response
  ↓ Streaming parser
  ├─ [emotion] Emotion tag → ExpressionController → Facial expression control
  └─ [bow/present] Motion tag → GestureController → Bone control
                                         ↑
                                    EmoteController (conflict resolution)

The EmoteController sits between facial expressions and motions to handle conflicts between them.

Motion Definitions

Motions are implemented by defining bone rotations as keyframes.

Here's an example definition for a bow:

// src/features/emoteController/gestureController.ts
interface BoneRotation {
  bone: VRMHumanBoneName
  rotation: THREE.Quaternion
}

interface GestureKeyframe {
  duration: number
  bones: BoneRotation[]
}

interface GestureDefinition {
  keyframes: GestureKeyframe[]
  holdDuration: number
  closeEyes?: boolean
}

For the bow motion, three bones — spine, chest, and neck — are each rotated forward to create a more natural-looking bow rather than simply bending at the waist.
The arm bones are also adjusted to achieve a natural posture.

// src/features/emoteController/gestureController.ts
this._gestures.set('bow', {
  keyframes: [
    {
      duration: 1.0,
      bones: [
        {
          bone: 'spine',
          rotation: new THREE.Quaternion().setFromEuler(
            new THREE.Euler(0.25, 0, 0)
          ),
        },
        {
          bone: 'chest',
          rotation: new THREE.Quaternion().setFromEuler(
            new THREE.Euler(0.15, 0, 0)
          ),
        },
        {
          bone: 'neck',
          rotation: new THREE.Quaternion().setFromEuler(
            new THREE.Euler(0.12, 0, 0)
          ),
        },
        // Arm bones are also adjusted (omitted)
      ],
    },
  ],
  holdDuration: 1.0,
  closeEyes: true, // Close eyes during the bow
})

Triggering Motions from LLM Responses

The character's expressions are controlled by having the LLM output emotion and motion tags in its responses.

Emotion tags are implemented by default in AITuberKit. The LLM response looks like this:

[happy]Thank you so much!

Motion tags are a custom addition. They appear in the response just like emotion tags:

Welcome! [bow]What kind of fragrance are you looking for today?

When both emotion and motion tags appear simultaneously, both are triggered.
For example, [happy][bow] results in the character bowing with a smile.

The system prompt includes the following instructions:

`
## Emotional Expression
The format for conversation text is as follows. Choose the single most appropriate emotion for the entire response and prepend the emotion tag at the beginning.
[{neutral|happy|angry|sad|relaxed|surprised}]{conversation text}
`

Handling Conflicts Between Expressions and Motions

Simply applying both facial expressions and motions at the same time can cause unexpected behavior, so I've added the following controls.
For example, having the eyes open during a bow looked unnatural, so I set closeEyes: true to close the eyes on the motion control side.

The EmoteController manages this by passing flags between controllers:

// src/features/emoteController/emoteController.ts
public updateExpression(delta: number) {
  const isEmotionActive = this._expressionController.isEmotionActive
  // Skip auto-blink if the motion is closing eyes and expression is neutral
  const skipAutoBlink =
    this._gestureController.isClosingEyes && !isEmotionActive
  this._expressionController.update(delta, skipAutoBlink)
}

public updateGesture(delta: number) {
  const isEmotionActive = this._expressionController.isEmotionActive
  // Skip motion eye-close if an emotion expression is active
  this._gestureController.update(delta, isEmotionActive)
}

The emotion expressions and the motion's eye-close feature are mutually exclusive.
When the emotion is neutral, the motion side closes the eyes. When an emotion is active, the motion's eye-close is disabled and control is handed to the expression side.

Wrapping Up

Using a chat UI as the frontend for an AI agent is a very common approach, but even a simple model like this feels lively just by having it move around, which makes it really fun.
That said, controlling motions can be quite tricky — figuring out which bones to rotate and by how much is surprisingly difficult.
For more complex motions, you could look into purchasing motion packs, which might be a good option.