{"slug": "i-tested-the-new-opensearch-agent-toolkit-skill-here-s-what-it-actually-does", "title": "I tested the new OpenSearch Agent Toolkit skill. Here's what it actually does.", "summary": "AWS announced the amazon-opensearch-service skill for the Agent Toolkit on July 15, 2026, enabling AI coding agents to build, manage, and query OpenSearch via natural language. A developer tested the skill by building a RAG search backend on Amazon OpenSearch Serverless NextGen, finding it provides structured knowledge packages for migration, provisioning, search, log analytics, and trace analytics. The skill is part of the aws-data-analytics plugin, which includes eight skills covering the full data lifecycle.", "body_md": "AWS [announced](https://aws.amazon.com/about-aws/whats-new/2026/07/amazon-opensearch-service-agent/) the `amazon-opensearch-service`\n\nskill for the Agent Toolkit for AWS on July 15, 2026. The marketing says it lets AI coding agents \"build, manage, and query OpenSearch directly from natural language.\" I installed it and ran it through a real task: building a RAG search backend on Amazon OpenSearch Serverless NextGen from scratch.\n\nHere's what the skill actually does, where it saved me time, and the one area where skipping it entirely would have been faster.\n\nThe skill is not a chatbot wrapper over AWS APIs. It's a **structured knowledge package** that loads into your coding agent's context when you ask an OpenSearch-related question. Think of it as a senior engineer's notebook: sizing formulas, engine selection logic, migration checklists, query DSL recipes. It covers both managed Amazon OpenSearch Service domains and OpenSearch Serverless collections ([full source on GitHub](https://github.com/aws/agent-toolkit-for-aws/tree/main/skills/specialized-skills/analytics-skills/amazon-opensearch-service)).\n\nIt routes every request to one of five capabilities:\n\n| Capability | What it knows |\n|---|---|\n| Migration | Schema translation from Solr/ES, compatibility assessment, cutover planning |\n| Provisioning | Instance sizing math, shard calculations, storage tier selection, policy setup |\n| Search | k-NN engine selection (FAISS vs Lucene), hybrid search patterns, Amazon Bedrock connectors |\n| Log analytics | PPL queries, Ingestion pipelines, anomaly detection, dashboard patterns |\n| Trace analytics | OpenTelemetry spans, service maps, Data Prepper configuration |\n\nThe provisioning capability works for both managed domains (instance families, JVM heap, OR1 trade-offs) and Serverless (collection groups, OCU limits, NextGen vs Classic). The search capability includes sizing math that differs between deployments: shard count formulas for managed domains, OCU memory rules for Serverless. See the [official documentation](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/amazon-opensearch-service-skill.html) for the full capability description.\n\nThe skill comes as part of the [ aws-data-analytics plugin](https://github.com/aws/agent-toolkit-for-aws/tree/main/plugins/aws-data-analytics), which bundles 8 skills covering the full data lifecycle:\n\n| # | Skill | What it does |\n|---|---|---|\n| 1 | `creating-data-lake-table` |\nManaged Iceberg tables on Amazon S3 Tables |\n| 2 | `ingesting-into-data-lake` |\nImport from S3, JDBC, Snowflake, BigQuery, DynamoDB |\n| 3 | `querying-data-lake` |\nAthena SQL across default and federated catalogs |\n| 4 | `finding-data-lake-assets` |\nResolve data references by name, keyword, column |\n| 5 | `exploring-data-catalog` |\nAWS Glue Data Catalog inventory and audit |\n| 6 | `storing-and-querying-vectors` |\nAmazon S3 Vectors for semantic search and RAG |\n| 7 | `connecting-to-data-source` |\nAWS Glue connections to JDBC, Redshift, Snowflake |\n| 8 | `amazon-opensearch-service` |\nMigration, provisioning, search, logs, traces |\n\nNote skill #6: the plugin includes an Amazon S3 Vectors skill too. It covers vector bucket creation, index setup, and query patterns for RAG workloads.\n\nInstall in one step (full setup guide in the [Agent Toolkit docs](https://docs.aws.amazon.com/agent-toolkit/latest/userguide/quick-start.html)):\n\n```\n# Claude Code\n/plugin install aws-data-analytics@claude-plugins-official\n/reload-plugins\n\n# Codex\ncodex plugin marketplace add aws/agent-toolkit-for-aws\n\n# Kiro — MCP config + skills\n# Add to ~/.kiro/settings/mcp.json:\n{\n  \"mcpServers\": {\n    \"aws-mcp\": {\n      \"command\": \"uvx\",\n      \"args\": [\"mcp-proxy-for-aws@1.6.3\",\n               \"https://aws-mcp.us-east-1.api.aws/mcp\",\n               \"--metadata\", \"AWS_REGION=eu-central-1\"]\n    }\n  }\n}\n# Then install skills:\nnpx skills add aws/agent-toolkit-for-aws/skills\n\n# Or let AWS CLI detect your agent and configure everything:\naws configure agent-toolkit\n```\n\nI asked my agent: *\"Create an OpenSearch Serverless vector search collection with scale-to-zero, set up a hybrid search index for 1024-dimension Amazon Titan Embeddings G2, ingest 5 sample documents, and run a query.\"*\n\nHere's what happened step by step.\n\nThe skill detected capability: **provisioning**, and recommended a NextGen collection group with zero minimum OCUs. It produced the correct sequence:\n\n```\n# 1. Collection group (NextGen, scale-to-zero)\naws opensearchserverless create-collection-group \\\n  --name agent-toolkit-demo \\\n  --generation NEXTGEN \\\n  --standby-replicas ENABLED \\\n  --capacity-limits '{\n    \"maxIndexingCapacityInOCU\": 8,\n    \"maxSearchCapacityInOCU\": 8,\n    \"minIndexingCapacityInOCU\": 0,\n    \"minSearchCapacityInOCU\": 0\n  }'\n\n# 2. Three mandatory policies (encryption, network, data access)\n# 3. Collection in the group\naws opensearchserverless create-collection \\\n  --name agent-demo \\\n  --type VECTORSEARCH \\\n  --collection-group-name agent-toolkit-demo\n```\n\n**What it got right:** The full policy chain (encryption → network → data access → collection), the NextGen generation flag, the `VECTORSEARCH`\n\ntype, and the scale-to-zero capacity limits. Without the skill, agents often create Classic collections (no scale-to-zero) or forget the encryption policy (which silently blocks collection creation).\n\n**What it didn't do:** Create the collection for me. The skill produces the commands and explains the sequence, but execution still requires you (or the agent via the MCP Server's `call_aws`\n\ntool) to run them. It took about 4 minutes for the collection to become ACTIVE.\n\nWhen I asked for a hybrid search index, the skill detected capability: **search** and recommended this mapping:\n\n```\nindex_body = {\n    \"settings\": {\n        \"index\": {\"knn\": True, \"knn.algo_param.ef_search\": 512}\n    },\n    \"mappings\": {\n        \"properties\": {\n            \"title\": {\"type\": \"text\"},\n            \"content\": {\"type\": \"text\"},\n            \"category\": {\"type\": \"keyword\"},\n            \"embedding\": {\n                \"type\": \"knn_vector\",\n                \"dimension\": 1024,\n                \"method\": {\n                    \"engine\": \"faiss\",\n                    \"name\": \"hnsw\",\n                    \"space_type\": \"l2\",\n                    \"parameters\": {\"ef_construction\": 512, \"m\": 16}\n                }\n            }\n        }\n    }\n}\n```\n\n**This fails on NextGen Serverless** with `illegal_argument_exception: Field parameter 'engine' is not supported`\n\n. NextGen collections use their own managed vector acceleration (automatically enabled at collection creation as `ServerlessVectorAcceleration: ENABLED`\n\n). You can't specify the engine.\n\nThe correct mapping for NextGen:\n\n```\nindex_body = {\n    \"settings\": {\"index\": {\"knn\": True}},\n    \"mappings\": {\n        \"properties\": {\n            \"title\": {\"type\": \"text\"},\n            \"content\": {\"type\": \"text\"},\n            \"category\": {\"type\": \"keyword\"},\n            \"embedding\": {\n                \"type\": \"knn_vector\",\n                \"dimension\": 1024,\n                \"space_type\": \"cosinesimil\"\n            }\n        }\n    }\n}\n```\n\n**This is the skill's biggest gap right now.** It knows about Classic Serverless and managed domains (where FAISS/Lucene engine selection matters), but NextGen's simplified vector API isn't in the reference files yet. The skill was released the same week as the NextGen announcement, so this is likely a timing issue.\n\nThe skill warned about two Serverless limitations:\n\n```\n# The skill correctly omitted the 'id' parameter\nclient.index(index=\"articles\", body={\n    \"title\": \"Building RAG applications that actually work\",\n    \"content\": \"The retrieval step matters more than the generation step...\",\n    \"category\": \"ai\",\n    \"embedding\": embedding  # 1024d from Titan G2\n})\n```\n\nOn Classic Serverless, documents took 30-60 seconds to become searchable. On NextGen, **my documents were searchable in 2 seconds**. This is a massive improvement that AWS hasn't highlighted enough. The decoupled compute-storage architecture of NextGen means writes commit to the shared storage layer instantly and become queryable almost immediately.\n\nVector search, keyword search, and filtered search all returned correct results. The skill produced working query DSL for each mode.\n\nFor hybrid search (BM25 + vector), the skill noted that OpenSearch Serverless requires a **search pipeline with a normalization processor** for native hybrid queries, or you can implement client-side Reciprocal Rank Fusion (RRF). It recommended client-side RRF for simplicity:\n\n``` python\ndef hybrid_search(query_text, k=3):\n    query_embedding = generate_embedding(query_text)\n\n    # Vector results\n    vec = client.search(index=\"articles\", body={\n        \"size\": k,\n        \"query\": {\"knn\": {\"embedding\": {\"vector\": query_embedding, \"k\": k}}}\n    })[\"hits\"][\"hits\"]\n\n    # BM25 results\n    kw = client.search(index=\"articles\", body={\n        \"size\": k,\n        \"query\": {\"multi_match\": {\"query\": query_text, \"fields\": [\"title^2\", \"content\"]}}\n    })[\"hits\"][\"hits\"]\n\n    # Reciprocal Rank Fusion\n    rrf_k, scores, docs = 60, {}, {}\n    for rank, hit in enumerate(vec):\n        scores[hit[\"_id\"]] = scores.get(hit[\"_id\"], 0) + 1.0 / (rrf_k + rank + 1)\n        docs[hit[\"_id\"]] = hit\n    for rank, hit in enumerate(kw):\n        scores[hit[\"_id\"]] = scores.get(hit[\"_id\"], 0) + 1.0 / (rrf_k + rank + 1)\n        docs[hit[\"_id\"]] = hit\n\n    return sorted(scores.items(), key=lambda x: x[1], reverse=True)[:k]\n```\n\n**Policy sequencing.** Three policies must exist before the collection. The skill knows the order and the exact permission set (including `aoss:DeleteIndex`\n\n, which you'll hit a 403 without during development).\n\n**Serverless-specific warnings.** No custom IDs, auth service name `\"aoss\"`\n\n, and the collection group requirement for NextGen. Each of these cost me 5-10 minutes to debug in my first attempt without the skill.\n\n**NextGen awareness.** The skill knew about collection groups, the `--generation NEXTGEN`\n\nflag, and scale-to-zero capacity limits. This is May 2026 knowledge that most agents don't have in their training data.\n\n**Engine selection for NextGen.** The skill recommended `\"engine\": \"faiss\"`\n\nwhich fails on NextGen with `illegal_argument_exception`\n\n. NextGen manages vector acceleration internally, you just specify `dimension`\n\nand `space_type`\n\n. This is the skill's biggest gap: the most recommended deployment target rejects the skill's default mapping.\n\n**Write latency expectations.** The skill warned about \"30-60 second eventual consistency\" which is true for Classic but wrong for NextGen (2 seconds in my test). NextGen's decoupled architecture makes writes visible almost immediately.\n\nThe skill covers both Serverless and managed domains. I tested two questions against my existing managed domain (t3.small, single-node, OpenSearch 2.19).\n\n**Simple question: \"Is my domain healthy? Should I upgrade?\"**\n\nThe skill detected capability: **provisioning** and produced a checklist:\n\nThis was useful. The skill read the domain configuration and produced actionable recommendations, not generic advice.\n\n**Harder question: \"I want to add vector search to this domain for a RAG use case with 500K documents. What do I need to change?\"**\n\nThe skill detected capability: **search** and routed to the vector/k-NN reference. It recommended:\n\n`m=16`\n\n, `ef_construction=256`\n\nfor 500K vectors at 1024 dimensions.The skill then produced the correct index mapping (with `\"engine\": \"faiss\"`\n\n, which is valid for managed domains, just not for NextGen) and a Bedrock connector configuration for embedding generation at ingestion time.\n\n**Verdict on managed domain coverage:** the skill is more helpful for managed domains than for NextGen Serverless, because managed domains have more knobs to tune (instance types, shard math, JVM heap, storage sizing). The provisioning reference files were clearly written with managed domains as the primary target.\n\nI installed the `aws-cdk`\n\nand `aws-cloudformation`\n\nskills alongside the OpenSearch skill to test IaC output. Here's what each provides:\n\n`aws-cdk`\n\n`aws-cloudformation`\n\n`amazon-opensearch-service`\n\nIn practice, your agent combines knowledge from multiple skills: the OpenSearch skill provides the *what* (r7g.large, 3 shards, FAISS HNSW, ef_construction=256), and the CDK skill provides the *how* (construct patterns, proper scoping, safe refactoring). But there's no pre-built bridge between them. You still ask \"now write that as CDK\" as a separate step.\n\n**Terraform is not covered at all.** No skill in the Agent Toolkit produces HCL. For Terraform users, the OpenSearch skill's sizing recommendations are still valuable, but you translate to HCL using the agent's general training data.\n\n**Writing the application code.** The skill produces query DSL snippets and CLI commands, but it doesn't generate a complete Python application. You still write the Bedrock embedding calls, the opensearch-py client setup, the ingestion loop, and the search logic yourself.\n\n**Cost estimation.** The skill explicitly refuses to produce dollar figures. If you ask \"how much will this cost?\", it points you to the AWS Pricing Calculator and stops. This is by design: pricing changes monthly and account-specific discounts make generic estimates misleading.\n\n**Choosing between OpenSearch and alternatives.** The skill is scoped to OpenSearch. It won't tell you \"actually, Amazon S3 Vectors would be 15x cheaper for your workload.\" That's your architecture decision.\n\nNextGen Serverless scales to zero after 10 minutes of inactivity. The first request after idle takes 10-30 seconds while compute provisions. For agentic workloads (burst of queries, then hours idle), this is the right trade-off: pay nothing during idle, accept the wake-up penalty.\n\nFor workloads where cold starts are unacceptable:\n\n| Alternative | Cold start | Idle cost | Hybrid search |\n|---|---|---|---|\nNextGen with min 1 OCU |\nNone | ~$175/month | Yes |\nManaged domain (t3.medium) |\nNone | ~$53/month | Yes |\nS3 Vectors |\nNone (always ready) | ~$0 | No (vector + filter only) |\n\nS3 Vectors deserves a separate mention: for pure vector retrieval without BM25 or complex filters, it's both faster (89ms p50 in my tests vs 109ms for the managed domain) and cheaper ($11/month for 10M vectors vs $175+ for Serverless). No cold start, no policies to configure. The `aws-data-analytics`\n\nplugin includes a `storing-and-querying-vectors`\n\nskill for S3 Vectors too, covering bucket creation, index setup, and query patterns. The trade-off: no hybrid search, 100 results max per query, flat metadata only (2 KB filterable).\n\nThe combination that makes the most sense for production: **S3 Vectors for the primary vector store** (cheap, fast, scales to billions) **+ a small OpenSearch domain for the hybrid re-ranking step** when you need keyword precision on top of semantic recall.\n\nThe full sequence from zero to working RAG search on NextGen Serverless:\n\n```\n# Prerequisites\npip install opensearch-py boto3 requests-aws4auth\n\n# 1. Collection group (NextGen, scale-to-zero)\naws opensearchserverless create-collection-group \\\n  --name my-rag-demo --generation NEXTGEN \\\n  --standby-replicas ENABLED \\\n  --capacity-limits '{\"maxIndexingCapacityInOCU\":8,\"maxSearchCapacityInOCU\":8,\n                      \"minIndexingCapacityInOCU\":0,\"minSearchCapacityInOCU\":0}'\n\n# 2. Policies (all three required before collection)\naws opensearchserverless create-security-policy --name my-enc --type encryption \\\n  --policy '{\"Rules\":[{\"ResourceType\":\"collection\",\"Resource\":[\"collection/my-rag\"]}],\"AWSOwnedKey\":true}'\n\naws opensearchserverless create-security-policy --name my-net --type network \\\n  --policy '[{\"Rules\":[{\"ResourceType\":\"collection\",\"Resource\":[\"collection/my-rag\"]},\n             {\"ResourceType\":\"dashboard\",\"Resource\":[\"collection/my-rag\"]}],\"AllowFromPublic\":true}]'\n\naws opensearchserverless create-access-policy --name my-access --type data \\\n  --policy '[{\"Rules\":[\n    {\"ResourceType\":\"collection\",\"Resource\":[\"collection/my-rag\"],\n     \"Permission\":[\"aoss:*\"]},\n    {\"ResourceType\":\"index\",\"Resource\":[\"index/my-rag/*\"],\n     \"Permission\":[\"aoss:*\"]}],\n  \"Principal\":[\"arn:aws:iam::YOUR_ACCOUNT:role/YOUR_ROLE\"]}]'\n\n# 3. Collection\naws opensearchserverless create-collection \\\n  --name my-rag --type VECTORSEARCH \\\n  --collection-group-name my-rag-demo\n\n# 4. Wait for ACTIVE (~4 minutes), then create index + ingest via Python\n```\n\n**Yes, if** you're working with OpenSearch regularly and want your agent to produce correct configurations on the first try. The policy sequencing, engine selection, and Serverless-specific gotchas alone save 30+ minutes of debugging per project.\n\n**No, if** you're doing pure vector search without hybrid/BM25 needs. In that case, Amazon S3 Vectors is simpler, cheaper, faster, and has its own lightweight skill (`storing-and-querying-vectors`\n\n) that covers the basics.\n\nThe broader pattern: **Agent Toolkit skills are most valuable where the service has high configuration complexity.** OpenSearch has dozens of knobs (instance types, shard counts, engines, storage tiers, three policy types, collection groups). The OpenSearch skill reflects that complexity with 5 capabilities and a library of reference files. The S3 Vectors skill is simpler because the service is simpler.\n\nNextGen scales to zero, so leaving it idle costs only storage. To fully remove:\n\n```\naws opensearchserverless delete-collection --id YOUR_COLLECTION_ID\naws opensearchserverless delete-collection-group --id YOUR_GROUP_ID\naws opensearchserverless delete-security-policy --name my-enc --type encryption\naws opensearchserverless delete-security-policy --name my-net --type network\naws opensearchserverless delete-access-policy --name my-access --type data\n```\n\n**Links:**\n\n*Tested July 2026 in eu-central-1 with OpenSearch Serverless NextGen, Amazon Titan Embeddings G2, and the Agent Toolkit for AWS (aws-data-analytics plugin). Cold-start measurement based on AWS documentation (10-30 seconds from zero). S3 Vectors latency measured from Python client in the same region.*", "url": "https://wpnews.pro/news/i-tested-the-new-opensearch-agent-toolkit-skill-here-s-what-it-actually-does", "canonical_source": "https://dev.to/vidanov/i-tested-the-new-opensearch-agent-toolkit-skill-heres-what-it-actually-does-31d8", "published_at": "2026-07-17 05:50:22+00:00", "updated_at": "2026-07-17 06:00:27.432211+00:00", "lang": "en", "topics": ["artificial-intelligence", "developer-tools", "ai-tools", "ai-infrastructure", "ai-agents"], "entities": ["AWS", "Amazon OpenSearch Service", "Agent Toolkit for AWS", "Amazon OpenSearch Serverless NextGen", "GitHub", "Amazon S3 Vectors", "Claude Code", "Codex"], "alternates": {"html": "https://wpnews.pro/news/i-tested-the-new-opensearch-agent-toolkit-skill-here-s-what-it-actually-does", "markdown": "https://wpnews.pro/news/i-tested-the-new-opensearch-agent-toolkit-skill-here-s-what-it-actually-does.md", "text": "https://wpnews.pro/news/i-tested-the-new-opensearch-agent-toolkit-skill-here-s-what-it-actually-does.txt", "jsonld": "https://wpnews.pro/news/i-tested-the-new-opensearch-agent-toolkit-skill-here-s-what-it-actually-does.jsonld"}}