Amazon OpenSearch Agentic AI: Investigation Agent Guide

Amazon OpenSearch Service is turning observability search into an agent workflow. The important change is not "chat over logs" by itself. It is the combination of natural-language query generation, multi-step investigation, memory across the OpenSearch UI, and ranked root-cause hypotheses that developers can inspect.

AWS announced agentic AI for log analytics in Amazon OpenSearch Service on March 31, 2026. The launch introduced Agentic Chat, Investigation Agent, and Agentic Memory for engineering and support teams working inside OpenSearch UI. AWS says Investigation Agent can plan an investigation, execute queries, reflect on results, and return structured root-cause hypotheses ranked by likelihood. Agentic Memory keeps investigation context available as a user moves through feature pages or web sessions, with limits around separate conversation threads.

Effloow Lab ran a local sandbox PoC for this article. The PoC did not call AWS, run OpenSearch, use OpenSearch Dashboards, or execute a real LLM agent. It simulated the documented workflow shape with synthetic logs: plan, query-like analysis, baseline comparison, working memory, long-term findings, audit history, and ranked hypotheses. The lab note is saved at data/lab-runs/amazon-opensearch-agentic-ai-investigation-agent-guide-2026.md.

Why This Matters

Incident investigation is usually a context problem before it is an AI problem. A developer starts with a vague symptom: checkout 500s, p95 latency, increased timeout errors, or a dashboard that looks wrong. The next steps require switching between logs, traces, metrics, deployment history, shard state, query syntax, and prior debugging notes.

Amazon OpenSearch already sits close to that workflow for teams using it as a search, log analytics, vector, or observability backend. The new agentic layer matters because it tries to move the interface from "write the right query" to "state the goal, inspect the agent's steps, and verify the evidence."

That shift is useful only if the agent remains auditable. The best version of this feature is not a black-box incident oracle. It is a structured assistant that shows the plan, runs bounded analysis tools, preserves context, and gives humans evidence they can accept, reject, or rerun.

What Amazon Added

There are four separate but related pieces to understand.

First, Agentic Chat is embedded in OpenSearch UI. AWS documentation says it can answer questions about the data, generate PPL queries in Discover, refine generated queries through follow-up instructions, analyze visualizations, and start investigations through a /investigate command or UI action.

Second, Investigation Agent is the deeper incident-analysis workflow. The official docs describe it as a goal-driven research agent that plans from the stated goal and available data, executes queries and analysis, reflects through multiple steps, and returns ranked hypotheses with supporting evidence. The result page includes a primary hypothesis, alternative hypotheses, investigation steps, relevant findings, and user controls to accept or rule out a conclusion.

Third, Agentic Memory is the continuity layer. AWS says it powers both Agentic Chat and Investigation Agent, persists context across page navigation and browser refreshes, isolates memory by user ID, and stores memory in a service-managed OpenSearch Serverless collection. AWS also states that Agentic Memory cannot retain context across different conversation threads.

Fourth, the broader OpenSearch ecosystem is moving in the same direction. OpenSearch 3.5 added agentic conversation memory, context management, and a redesigned no-code agent interface with MCP integration. The open source OpenSearch documentation describes agentic memory containers with sessions, working, long-term, and history memory types. AWS also published OpenSearch Agent Skills for agentic IDE workflows around search, logs, trace analytics, and migrations.

What We Simulated Locally

The Effloow Lab sandbox used Python 3.12.8 on macOS and synthetic service logs. The script generated 1,358 log rows across checkout, payments, catalog, and auth. It injected a checkout 5xx incident window and a payments timeout window, then ran a deterministic investigation loop:

1. Create a four-step investigation plan.
2. Group incident status codes by service.
3. Compare p95 latency in the incident window against a baseline window.
4. Store working memory, long-term hypotheses, and history records.
5. Rank root-cause hypotheses with evidence.

The top simulated hypothesis was: "Payments timeout cascade drove checkout 5xx responses." The evidence was specific: payments returned 72 HTTP 504 events during the incident window, payments p95 latency increased by 1,330.1 ms over baseline, and the checkout 5xx spike overlapped the payments timeout window.

This is not a benchmark and not a managed OpenSearch test. It is a small reproducibility check for the mental model. The simulation showed that the documented pattern is coherent: if an agent can preserve the plan, intermediate analysis, evidence, and hypothesis history, a human reviewer gets a better artifact than a one-shot chat answer.

The Architecture Pattern

The practical architecture is a loop:

incident goal
  -> plan
  -> bounded data tools
  -> intermediate findings
  -> memory update
  -> reflection
  -> ranked hypotheses
  -> human accept / rule out / reinvestigate

The "bounded data tools" part is critical. Agentic Chat documentation lists tools such as execute_ppl_query, create_investigation, SearchIndexTool, MsearchTool, CountTool, ExplainTool, IndexMappingTool, ClusterHealthTool, LogPatternAnalysisTool, MetricChangeAnalysisTool, and DataDistributionTool. That tool list makes the agent less magical and more operational: it is valuable because it can call specific analysis functions over OpenSearch data.

For production teams, this means the agent should not replace existing observability hygiene. It depends on it. Clean index mappings, useful service labels, trace IDs, consistent timestamps, field-level security, and retention policies become more important when an agent is allowed to chain analysis steps.

Where Agentic Memory Helps

Memory is useful in incident work because the first question is rarely the final question.

A developer may start with "why did checkout error rate increase?" then ask "only show us-west-2," then "compare against the previous hour," then "include payments traces," then "rerun after excluding synthetic traffic." If every turn loses context, the agent becomes a query generator. If the session preserves working state, the workflow becomes an investigation.

OpenSearch's open source memory docs are a helpful model here:

• sessions hold the interaction context.
• working memory holds recent messages, agent state, execution traces, and temporary investigation data.
• long-term memory stores extracted knowledge or durable findings.
• history tracks memory operations for auditability.

Our local PoC mirrored those categories. It stored one session, three working records, one long-term hypothesis record, and four history events. That structure made the final hypothesis easier to inspect because the conclusion was tied to the plan and intermediate results.

The caveat is equally important: memory can preserve mistakes. If the agent stores a weak assumption, a stale field meaning, or a misleading intermediate result, later steps may inherit that error. Teams should treat memory as evidence context, not ground truth.

Security And Governance Notes

AWS's managed Agentic Memory docs state that memory storage is isolated by user ID and encrypted with a service-managed key, or with a customer managed key if CMK encryption is enabled for the OpenSearch UI application. The docs also say Agentic Memory is free to use, though the March launch notes token-based usage limits for agentic AI features.

The open source OpenSearch memory docs put more responsibility on implementers. Administrators or memory-container owners are responsible for data access controls, index-level permissions, document-level security, and custom prompt behavior. That distinction matters: managed Amazon OpenSearch Service and self-managed OpenSearch memory are not the same governance surface.

For a production rollout, review these controls before treating agentic observability as safe:

• Which users can start investigations?
• Which indices, fields, and documents can each user query?
• Are memory records isolated by user, team, tenant, or incident?
• Can investigation traces reveal restricted fields?
• Does memory retain sensitive payloads longer than log retention policy?
• Can a human see the exact query, finding, and evidence chain behind a hypothesis?

This pairs naturally with the broader observability stack. If your LLM gateway is already traced through tools like LiteLLM or Langfuse, OpenSearch investigation traces should be treated as another high-value audit artifact, not just UI state.

When Developers Should Use It

Amazon OpenSearch Agentic AI is most relevant for teams that already keep operational data in OpenSearch Service or are evaluating OpenSearch for observability and AI search.

Use it when:

• Engineers already use OpenSearch UI during incidents.
• PPL or DSL query expertise is a bottleneck.
• Incident work requires correlating logs, metrics, traces, and index metadata.
• You need ranked hypotheses with evidence, not just a generated summary.
• Your team can review agent steps and reject weak conclusions.

Be cautious when:

• Log fields are inconsistent or poorly mapped.
• Sensitive data appears in logs without masking.
• Access control depends on informal team norms rather than enforceable policy.
• Teams expect the agent to perform remediation automatically.
• You cannot audit the investigation steps after the incident.

The best early use case is investigation assistance, not autonomous repair. Let the agent propose likely causes, show evidence, and help narrow the search. Keep remediation behind explicit human approval and existing change-control paths.

Common Mistakes

Mistake 1: treating natural language as a permission model. An agent that can understand a request still needs hard access boundaries. Field-level and document-level restrictions matter more when queries are generated dynamically.

Mistake 2: skipping schema quality. Agentic analysis is only as useful as the fields it can reason over. Service names, trace IDs, deployment IDs, status codes, regions, and error classes should be consistently indexed.

Mistake 3: ignoring memory lifecycle. Memory improves continuity, but it also creates state. Decide what should be stored, who can retrieve it, how long it should live, and how it aligns with incident-retention policy.

Mistake 4: accepting the top hypothesis without reviewing alternatives. AWS's Investigation Agent UI supports accepting, ruling out, and reviewing alternative hypotheses. Use that review flow. The most useful output is often the evidence trail, not the first answer.

Mistake 5: calling a simulation a production test. Our PoC proved only that the workflow shape is easy to reproduce locally. It did not validate AWS latency, accuracy, pricing, region behavior, security isolation, or real OpenSearch query generation.

FAQ

Q: What is Amazon OpenSearch Investigation Agent?

It is an agentic root-cause analysis feature in OpenSearch UI. AWS documentation says it plans from a stated goal, executes queries and analysis, reflects through a multi-step workflow, and returns ranked hypotheses with evidence. It can be started from supported feature pages or from Agentic Chat with /investigate.

Q: Does Agentic Memory work across every conversation?

No. AWS documentation says Agentic Memory preserves context for Agentic Chat and Investigation Agent across feature pages, browser tabs, and page refreshes, but it cannot retain context across different conversation threads.

Q: Is Agentic Memory the same as self-managed OpenSearch memory containers?

Not exactly. Amazon OpenSearch Service Agentic Memory is a managed memory layer for OpenSearch UI features. OpenSearch's agentic memory framework exposes memory containers and APIs that self-managed implementers configure themselves. The governance responsibility differs.

Q: Did Effloow Lab test Amazon OpenSearch Service?

No. Effloow Lab ran a local Python simulation using synthetic logs. It did not use AWS credentials, Amazon OpenSearch Service, OpenSearch Dashboards, OpenSearch Serverless, PPL execution, or a live LLM.

Q: Is there an extra price for these agentic features?

AWS's March 31 launch post says the three log-analytics agentic capabilities are available at no additional cost, with token-based usage limits. AWS's Agentic Memory docs say Agentic Memory is free to use. For broader OpenSearch Serverless or cluster costs, use current AWS pricing pages rather than assuming this makes the full deployment free.

Sources Checked

• AWS What's New: Amazon OpenSearch Service introduces agentic AI for log analytics
• AWS docs: Investigation Agent in Amazon OpenSearch Service
• AWS docs: Agentic Memory in Amazon OpenSearch Service
• AWS docs: Agentic Chat in Amazon OpenSearch Service
• AWS What's New: Amazon OpenSearch Service supports OpenSearch 3.5
• OpenSearch docs: Agentic memory
• AWS News Blog: next generation Amazon OpenSearch Serverless
• AWS Big Data Blog: OpenSearch Agent Skills

Key Takeaways

Amazon OpenSearch Agentic AI is a practical sign of where observability tools are heading: from query builders to auditable investigation assistants. The interesting part is not just natural-language search. It is the combination of query tools, investigation planning, memory, ranked hypotheses, and human review.

For developers, the right adoption posture is measured. Use it to reduce query friction and preserve investigation context. Keep hard permissions, schema quality, evidence review, and remediation controls outside the agent's discretion.