+++
title = "What an AI agent can do with Bonsai"
description = "The cluster tasks an agent can take on, with example prompts: create and connect, monitor, analyze search queries, resize and clean up."
weight = 23
updated = 2026-11-11

[extra]
nav_title = "What agents can do"
weight = 50
+++

Once an agent is [connected](@/docs/agents/overview/index.md), you manage clusters by asking. These are the tasks it can take on, with prompts to try and what happens behind them.

## Create a cluster and wire it into your app

> Add search to this app. Create a sandbox OpenSearch cluster and put its URL in `.env`.

The agent lists the plans and regions your account can use, tells you which it picked, and asks before creating. It waits for the cluster to be ready, then writes `BONSAI_URL` into your `.env`. It never sees the password, and the file has to be ignored by git.

From there it can go on with the work you actually wanted: add a client library, create an index, and load your data, as in the [connecting guides](@/docs/connecting/_index.md).

## See what you have

> What Bonsai clusters do I have? Which are close to their limits?

The agent lists your clusters and reads each one's documents, shards and disk size against its plan's limits.

## Check on a cluster

> How has `search-prod` been doing in the last 24 hours?

The agent reads request rates, 4xx and 5xx error rates, traffic, and p50, p95 and p99 latency, and tells you what stands out. Ask it to compare against last week, or to find when a spike started.

## Learn what your users search for

> What are the top search terms on `search-prod` this week? Which are slow, and which return almost nothing?

The agent reads the cluster's most frequent search terms, with their volume, average time and average hits. Terms with few hits point at missing content or synonyms, and slow ones at queries worth tuning.

This needs a token with the `query_logs:read` scope. See [Query Logs](@/docs/features/query-logs/index.md).

## Plan capacity and resize

> `search-prod` is at 90% of its documents. What would fit it, and what would it cost?

The agent compares the cluster's usage with the plans your account can use, and their prices. If you say go, it changes the plan and follows the change until it's done. See [Capacity planning](@/docs/cluster-management/capacity-planning/index.md).

## A cluster per branch or CI run

> Write a CI job that creates a sandbox cluster for the tests and destroys it afterwards.

The agent knows the CLI's `--json` output and exit codes, so it can write the script as well as run it. See [Scripting and CI](@/docs/cli/scripting/index.md).

## Clean up

> Which of my clusters haven't had a request this month?

The agent reads each cluster's metrics and lists the idle ones. To destroy one, it asks you to type the cluster's name. A destroyed cluster can't be brought back.

## Find out what happened

> Why did creating `search-staging` fail?

The agent reads the cluster's history of Actions and the failed Action's steps and error. If a payment method is needed, it tells you, with the link to add one.

## What an agent can't do

- **Read or show a cluster's password.** It can only write the connection URL to a git-ignored file.
- **Log in for you.** You run `bonsai login` in your own terminal.
- **Go beyond your token.** A token without `clusters:write` can't create, resize or destroy, whatever the agent is asked.
- **Manage what the CLI doesn't cover**, such as billing, team members and account settings. Those stay in the dashboard.

See [Keeping agents safe](@/docs/agents/safety/index.md).