@grepr/cli 1.11.4-fa34897 → 1.11.5-03c23a0

package/build/dist/docs-index/561050bd-530a-485b-bada-7dca217d5ab3.txt

@@ -0,0 +1,248 @@
+Learn how to configure how Grepr integrates with observability platforms and storage systems to support data ingestion, processing, and output in your pipelines.
+
+# Configure how Grepr integrates with observability platforms and cloud storage
+
+To support data ingestion and data output for your Grepr pipelines, you connect Grepr to external observability platforms and storage systems. To support these connections, the Grepr platform uses *integrations*. A Grepr integration provides the configuration details to connect to an external system, enabling data exchange between Grepr and that system.
+
+After configuring an integration, you can use it in your Grepr pipelines to create *sources* to ingest data from agents and collectors, such as FluentD or the OpenTelemetry collector, and *sinks* to send data to an observability platform or storage.
+
+You can use the Grepr UI or the REST API to create and manage integrations. To use the UI, see [Manage integrations in the Grepr UI](#manage-integrations-in-ui). To use the API, see the documentation for each [supported integration](#supported-integrations).
+
+## Integration types
+
+The Grepr platform includes the following integration types:
+
+* Observability platform integrations: Connections to monitoring, logging, and APM platforms, such as Datadog, Splunk, New Relic, and Sumo Logic.
+* Cloud storage integrations: Connections to cloud storage. The Grepr data lake uses cloud storage to store your raw data and metadata.
+* AI integrations: Connections that Grepr AI agents use, covering the model providers they reason with, the MCP servers they call, the webhook endpoints that trigger them, and the vector indexes that store their memories. See [Supported AI integrations](#ai-integrations).
+
+Observability platform and cloud storage integrations become the sources and sinks of your pipelines. AI integrations are used by AI agents instead, so they are not selectable as a pipeline source or sink.
+
+## Supported platform and storage integrations \[#supported-integrations]
+
+The Grepr platform includes the following integrations. For details on configuring and using an integration, refer to the linked documentation page. For a complete list of supported integrations, supported functionality, and details on vendor-specific capabilities with some integrations, see [Grepr supported vendor and storage integrations](/integrations/support-matrix).
+
+### Datadog
+
+The Datadog integration connects to the Datadog observability platform and supports sourcing data from several Datadog-compatible collectors and sending processed data to Datadog.
+
+See [Configure Datadog connections with a Grepr integration](/integrations/datadog).
+
+### New Relic
+
+The New Relic integration connects to New Relic's observability platform. Use this integration to create sources that retrieve log data from New Relic collectors and sinks that send processed data to New Relic for monitoring and analysis.
+
+See [Configure New Relic connections with a Grepr integration](/integrations/new-relic).
+
+### Splunk
+
+The Splunk integration provides connectivity to Splunk through Splunk's HTTP Event Collector (HEC) or S2S over HTTP. This integration supports reading data from Splunk collectors and writing data to Splunk indexes.
+
+See [Configure Splunk connections with a Grepr integration](/integrations/splunk).
+
+### Sumo Logic
+
+The Sumo Logic integration connects to Sumo Logic's cloud-based log management and monitoring platform using a Sumo Logic HTTP Source. You can use the integration to create sources that ingest data from Sumo Logic collectors and sinks that send processed data to Sumo Logic.
+
+See [Configure Sumo Logic connections with a Grepr integration](/integrations/sumo-logic).
+
+### OpenTelemetry
+
+The Grepr OpenTelemetry integration lets you ingest logs and Application Performance Monitoring (APM) data into Grepr from a collector that supports the OpenTelemetry Protocol over HTTP, or OTLP/HTTP, process them with a Grepr pipeline, and then send the processed data to any observability vendor that accepts OTLP/HTTP requests.
+
+See [Configure connections to OpenTelemetry compatible platforms](/integrations/open-telemetry).
+
+### Grafana Cloud
+
+You can configure Grepr's OpenTelemetry integration to connect with Grafana Cloud using the OpenTelemetry Protocol (OTLP). Use an OpenTelemetry integration to create sources that ingest data from OTLP-compatible collectors and sinks that send processed log data to Grafana Cloud.
+
+See [Configure Grafana Cloud connections with a Grepr integration](/integrations/grafana).
+
+### Amazon CloudWatch
+
+You can configure Grepr's OpenTelemetry integration to connect with Amazon CloudWatch using the OpenTelemetry Protocol (OTLP). Use an OpenTelemetry integration to create sources that ingest data from OTLP-compatible collectors and sinks that send processed log data to a CloudWatch log group.
+
+See [Configure Amazon CloudWatch connections with a Grepr integration](/integrations/cloudwatch).
+
+### Google Cloud Platform (GCP)
+
+The GCP integration as a source enables you to stream logs from Google Cloud services to Grepr for processing and analysis, and then forward the processed logs to any sink created using a Grepr-supported integration, such as Datadog, Splunk, or New Relic.
+
+See [Google Cloud Platform observability with Grepr](/integrations/gcp).
+
+### Cloud storage
+
+The Grepr data lake uses Amazon S3 to store, manage, and support querying the raw data from your Grepr pipelines. Depending on your requirements, you can choose from two S3 integrations: a Grepr-hosted integration, which uses a Grepr-managed S3 bucket, and an integration that uses an S3 bucket in your account. Both integrations provide secure, managed, and efficient storage for your data, along with an optimized query interface.
+
+To configure the Grepr-hosted integration, you only need to assign a name to the integration. The Grepr platform manages the S3 bucket, including its deployment and configuration.
+
+Using the integration with your own S3 bucket requires that you deploy and configure an S3 bucket in your AWS account, but it provides more control over your data. See [Host a Grepr data lake with the Amazon S3 integration](/integrations/aws-s3).
+
+## Supported AI integrations \[#ai-integrations]
+
+The following integrations support Grepr AI agents. They appear on the **Integrations** page only when AI agents are enabled for your organization. To turn on AI agents, contact <support@grepr.ai>. To learn what AI agents do, see [_](/ai-agents).
+
+### LLM providers
+
+An LLM integration holds the credentials for a large language model provider. Grepr AI agents use generative models for reasoning and embedding models for memories.
+
+See [_](/integrations/llm).
+
+### MCP servers
+
+An MCP integration connects Grepr to a MCP server run by another system, so an agent can call that system's tools during an investigation. You set each integration's server URL, so you can point one at a self-hosted or regional endpoint.
+
+See [_](/integrations/mcp).
+
+### Grepr Agent webhooks
+
+A Grepr Agent integration is a webhook endpoint that turns events from another system, such as an alerting platform or a Kubernetes event forwarder, into AI agent investigations.
+
+See [_](/integrations/grepr-agent-webhooks).
+
+### Vector indexes
+
+A vector index integration stores the search index for agent memory, which is what lets an agent find past investigations that reached a similar conclusion. You create one in the **S3 Vector Index** section of the **Integrations** page.
+
+See [_](/ai-agents/memory#vector-index).
+
+## Manage integrations in the Grepr UI \[#manage-integrations-in-ui]
+
+The **Integrations** page displays your integrations as cards, organized by observability vendor integrations and storage integrations. In each section, cards are ordered by recent activity, with the most active integrations appearing first.
+
+In addition to the integration name and its type, for example, a Datadog integration, if the integration is assigned to one or more teams, the team names appear in the header of the card.
+
+You can get a visual overview of the health and usage of your integrations using the charts included on each integration card. If an integration has recent activity, such as requests received from agents by a vendor integration or the amount of data written to a storage integration, a time-series chart of that activity is shown on the card.
+
+* Observability vendor integrations display requests received from agents over the last 30 minutes, color-coded by HTTP status code.
+
+  * To view more detailed metrics or more details about a pipeline that uses the integration, select it from the **Pipelines** menu.
+
+* Storage integrations display data written to the integration over the last 24 hours, broken down by dataset.
+
+  * To view and query a dataset stored on a storage integration, select it from the **Datasets** menu.
+
+To view more details about the metrics in either chart type, hover over any point in the chart to see a tooltip with the value and timestamp for that point.
+
+### Add an integration
+
+To create an integration, click **Add new** next to the section heading for the type you want to add. To learn how to create and configure specific integrations, see the documentation for each [supported integration](#supported-integrations).
+
+### Edit an integration
+
+To edit an integration, click the three-dot menu on the integration card and select **Edit**. Update the fields in the dialog and click **Save**.
+
+### Delete an integration
+
+To delete an integration, click the three-dot menu on the integration card and select **Delete**. Confirm the deletion in the dialog that appears.
+
+### Identify log events that should bypass aggregation \[#passthrough-estimation]
+
+When you create an integration with an observability vendor that supports *exception parsing*, Grepr automatically parses queries used by monitors, dashboards, or alerts in your observability vendor platform. You can use this list of queries to identify log messages that should be treated as *exceptions* to log reduction in Grepr pipelines. In other words, messages that should bypass aggregation to ensure that critical alerts and dashboards continue to work as expected. To help with identifying exceptions, the Grepr UI displays a *passthrough percentage* estimate for each query. This estimate is the percentage of events, over a configurable time window, that would bypass aggregation.
+
+You can also choose to automatically add and remove exceptions by enabling **Auto-sync exceptions** when you add the integration to your pipelines. To learn more about enabling and using auto-sync when you create or edit a pipeline, see [Prevent aggregation of messages used in your observability platform](/transforms/reducer/exceptions#vendor-exceptions).
+
+If an integration does not support exception parsing, the **Parsed Alerts** button on the integration card is disabled. See [Supported integrations: observability platforms](/integrations/support-matrix#supported-observability-integrations).
+
+To view the log queries parsed from an integration and configure passthrough estimation:
+
+1. On the **Integrations** page, on the card for a vendor integration that supports query parsing, click **Parsed Alerts**.
+
+   The **Parsed alert queries** dialog displays a table with the following columns:
+
+   * **Id**: The unique identifier for this alert.
+   * **Name**: The alert or dashboard name from your vendor.
+   * **Exception Type**: The type of vendor resource the query came from, such as a monitor or dashboard widget.
+   * **Query**: The log query extracted from the alert or dashboard.
+   * **Passthrough %**: The percentage of raw logs in your configured dataset that match this query. This value is displayed only if you've configured passthrough estimation.
+   * **Last Updated**: When the passthrough percentage was last calculated. Hover over the value to see the exact date and time.
+
+   You can filter the table by name or query text and filter by exception type using the multi-select filter in the **Exception Type** column. To manage which columns are visible, click the **Manage columns** icon in the upper-right corner of the table.
+
+2. To configure passthrough estimation and view the percentage of logs that would bypass aggregation for each query, click **Configure Passthrough Estimation**.
+
+   The **Passthrough Estimation Configuration** dialog lists the datasets that pipelines using the integration write to. Each row shows whether passthrough estimation is configured for that dataset and which pipelines use it.
+
+   > When you configure passthrough estimation for a dataset, it applies to all integrations or pipelines that use that dataset as a sink.
+
+3. Expand the row for the dataset you want to configure.
+
+4. Under **Filter Query (Optional)**, select your preferred query syntax and enter a query to filter for logs to include in the estimation analysis. Use this field when your dataset contains logs from multiple sources, and you want Grepr to use only the logs relevant to this integration. Leave this field empty to include all logs in the dataset.
+
+5. In the **Lookback Duration** menu, select the time window for calculating percentages. Options range from 15 minutes to 24 hours. A shorter window scans less data, reducing costs, but may not be representative if your log patterns vary throughout the day. A longer window provides more representative results but increases the cost of the analysis queries.
+
+6. In the **Refresh Period** menu, select how often Grepr recomputes each estimation for this dataset. Options range from 1 hour to 30 days, with a default of 7 days. A shorter period uses more recent logs to calculate estimates, resulting in more up-to-date values, but increases query load on the data lake.
+
+7. In the **Log Limit** field, enter the maximum number of logs to scan per estimation run. The default is 10,000,000. Larger limits provide more representative results, but increase the cost of each estimation query.
+
+8. To save a new configuration, click **Enable**. To save edits to an existing configuration, click **Save changes**.
+
+Grepr's impact estimation cycle runs once an hour for any datasets due for refresh, based on each dataset's **Refresh Period**. New or recently changed queries are included in the next cycle. A first estimate typically appears within an hour, though it might take longer if a large number of queries are queued for processing.
+
+To stop estimating for a dataset, expand its row and click **Disable estimation**. The dataset remains in the list as **Not configured** so you can re-enable estimation later.
+
+### Interpret passthrough percentages
+
+> Although two queries might use the same log events, their estimates will be equal. Additionally, the passthrough rate remains constant and is not the sum of the estimates. For example, if you enable exceptions for two queries that use the same log events, the passthrough rate doesn't double, but remains equal to the rate when only one exception is enabled.
+
+The **Passthrough %** value for a query shows what fraction of your raw logs that alert would require to pass through without aggregation. Use these values to evaluate the impact of adding each alert as a pipeline exception:
+
+A percentage less than 1% is considered low, and an exception should have minimal impact on aggregation efficiency and storage.
+
+You should review carefully any percentage above 1% before creating an exception for the query.
+
+A dash (—) in the **Passthrough %** column indicates that no estimate is available yet, either because passthrough estimation is not configured, or because Grepr hasn't finished calculating the estimate. If passthrough estimation is configured, the first estimate typically appears within an hour, and later refreshes occur based on the dataset's **Refresh Period**.
+
+The **Passthrough Estimation Configuration** dialog also includes the **Recent Activity** table at the bottom. This section shows the most recent log events related to exception parsing, giving you visibility into recent integration activity without leaving the dialog. To view the complete log history for the integration, click **View all logs** to go to the **System Logs** page, pre-filtered to show all activity for the selected integration.
+
+### Configure passthrough estimation from a pipeline
+
+You can also configure passthrough estimation directly from a pipeline. On the pipeline details page, in the left-hand navigation menu, click **Exceptions**. In the **Actions** column for an **Avoid impacting dashboards/alerts** exception, click the **⋯** menu and select **Configure estimations** to open a dialog that includes all datasets configured as sinks for the pipeline. Any configuration changes you make to the dataset apply to every other integration or pipeline that populates that dataset.
+
+To have Grepr recompute impact percentages during the next impact estimation cycle, click the **⋯** menu and select **Reset estimations** to clear the cached impact percentages for the datasets configured as sinks for the pipeline. Use this when you've changed alert queries in your observability vendor and want updated estimates without waiting for the next scheduled refresh.
+
+## Limitations \[#limitations]
+
+Grepr might split log events over 900KB, causing them to lose their original structured format. Each split event includes a common `grepr.splitOriginId` attribute if you need to reconstruct the original message.
+
+## Frequently Asked Questions
+
+### What is a Grepr integration?
+
+A Grepr integration provides the configuration details needed to connect Grepr to an external system, such as an observability platform or cloud storage. Integrations enable data exchange between Grepr and external systems, allowing you to create sources for data ingestion and sinks for data output in your pipelines.
+
+### What types of integrations does Grepr support?
+
+Grepr supports two integration types: observability platform integrations (connections to monitoring, logging, and APM platforms like Datadog, Splunk, New Relic, and Sumo Logic) and cloud storage integrations (connections to cloud storage for the Grepr data lake).
+
+### What is a source in a Grepr pipeline?
+
+A source in a Grepr pipeline is an operator that ingests data from an external system or agent. Sources use integrations to connect to observability platforms or collectors like FluentD or OpenTelemetry to pull data into Grepr for processing.
+
+### What is a sink in a Grepr pipeline?
+
+A sink in a Grepr pipeline is an operator that outputs processed data to an external system. Sinks use integrations to send Grepr-processed logs to observability platforms, data lakes, or other storage systems based on your pipeline configuration.
+
+### Can I use multiple integrations in a single pipeline?
+
+Yes, you can configure pipelines with multiple sources to ingest data from different platforms and multiple sinks to send processed data to different destinations. This flexibility allows you to build complex multi-source, multi-destination data processing workflows.
+
+### Which observability platforms does Grepr support?
+
+Grepr supports integrations with Datadog, Splunk, New Relic, Sumo Logic, Grafana Cloud, and Google Cloud Platform (GCP). Each integration enables different source and sink capabilities depending on the platform's features and capabilities.
+
+### How do I configure a Grepr integration?
+
+To configure an integration, you need to provide connection details specific to your external system, such as API keys, tokens, endpoints, or credentials. The specific steps vary by integration type. Detailed instructions for each integration are available in the platform-specific documentation pages.
+
+### What is the Grepr data lake integration?
+
+The Grepr data lake uses Amazon S3 to store raw log data. You can configure either a Grepr-hosted integration (using a Grepr-managed S3 bucket) where you only provide a name, or an integration with your own AWS account (requiring you to configure and manage the S3 bucket yourself for more control).
+
+### What happens to logs older than 48 hours from external sources?
+
+Grepr might drop incoming data from external integration sources with timestamps older than 48 hours. This limitation helps optimize storage and processing while allowing you to retain raw logs in the data lake for longer-term analysis.
+
+### What happens when a log event is larger than 900KB?
+
+If a log event exceeds 900KB, Grepr might split it into smaller events, which can cause them to lose their original structured format. Each split event includes a common 'grepr.splitOriginId' attribute that you can use to reconstruct the original message from its component parts.

package/build/dist/docs-index/5e61b64c-42d6-44a6-b8a9-d2b89f119d6e.txt

@@ -0,0 +1,20 @@
+# Get a skill
+
+**GET** `/v1/skills/{id}`
+
+**Operation ID**: `get_3`
+**Summary**: Get a skill
+## Tags
+- Skills
+## Parameters
+
+- **id** (required) - path
+  - Type: string
+
+## Responses
+
+### 200
+
+Skill retrieved successfully
+
+- **Content-Type**: `application/json` / `SkillView`

package/build/dist/docs-index/6566a7db-9244-4936-a1da-ef750250b531.txt

@@ -0,0 +1,22 @@
+# List skills
+
+**GET** `/v1/skills`
+
+**Operation ID**: `list_3`
+**Summary**: List skills
+## Tags
+- Skills
+## Parameters
+
+- **query** (optional) - query
+  - Type: string
+- **scope** (optional) - query
+  - Type: string
+
+## Responses
+
+### 200
+
+Skills retrieved successfully
+
+- **Content-Type**: `application/json` / array of `SkillView`

package/build/dist/docs-index/7186be7f-0254-47e2-a3d6-384dbcaa48e2.txt

@@ -0,0 +1,15 @@
+# ExceptionUsage
+
+Usage the vendor reports for the source of one parsed query
+
+**Type**: `object`
+
+## Properties
+
+- name: lastViewedAt (optional)
+  type: string
+  description: When the source was last viewed. Null means the vendor reports it was never viewed.
+
+- name: totalViews (optional)
+  type: integer
+  description: How many times the source was viewed, as the vendor counts them. Datadog counts views since January 2025 and refreshes the count daily.

package/build/dist/docs-index/7362601f-f3d7-4a54-8ca0-c61a7102ca3b.txt

@@ -0,0 +1,65 @@
+# Variant
+
+**Type**: `object`
+
+## Properties
+
+- name: array (optional)
+  type: boolean
+
+- name: as (optional)
+  type: object
+
+- name: boolean (optional)
+  type: boolean
+
+- name: byte (optional)
+  type: string
+
+- name: bytes (optional)
+  type: string
+
+- name: date (optional)
+  type: string
+
+- name: dateTime (optional)
+  type: string
+
+- name: decimal (optional)
+  type: number
+
+- name: double (optional)
+  type: number
+
+- name: emptyObject (optional)
+  type: boolean
+
+- name: float (optional)
+  type: number
+
+- name: instant (optional)
+  type: string
+
+- name: int (optional)
+  type: integer
+
+- name: long (optional)
+  type: integer
+
+- name: null (optional)
+  type: boolean
+
+- name: object (optional)
+  type: boolean
+
+- name: primitive (optional)
+  type: boolean
+
+- name: short (optional)
+  type: integer
+
+- name: string (optional)
+  type: string
+
+- name: type (optional)
+  type: enum: `OBJECT`, `ARRAY`, `NULL`, `BOOLEAN`, `TINYINT`, `SMALLINT`, `INT`, `BIGINT`, `FLOAT`, `DOUBLE`, `DECIMAL`, `STRING`, `DATE`, `TIMESTAMP`, `TIMESTAMP_LTZ`, `BYTES`

package/build/dist/docs-index/77834068-99e0-4397-8515-a99b45337859.txt

@@ -0,0 +1,21 @@
+# ParsedQueryImportStatus
+
+**Type**: `object`
+
+## Properties
+
+- name: coveredIntegrationIds (required)
+  type: array of string
+  description: Every integration an import updates. Integrations that share a vendor account share one fetch, so importing for one imports for all of them.
+
+- name: hasCredential (required)
+  type: boolean
+  description: Whether the credential the import needs is saved. For Datadog this is the application key.
+
+- name: importing (required)
+  type: boolean
+  description: Whether an import covering this integration is already under way.
+
+- name: supported (required)
+  type: boolean
+  description: Whether this vendor's parsed queries can be imported at all. False for vendors Grepr cannot read alert queries from.

package/build/dist/docs-index/86460551-4259-4b4f-aa2a-4b108b0fee62.txt

@@ -0,0 +1,33 @@
+# Get integration exception impacts for a pipeline
+
+**GET** `/v1/pipelines/{pipelineId}/exceptions/integrations/{integrationId}/impacts`
+
+**Operation ID**: `getIntegrationExceptionImpacts`
+**Summary**: Get integration exception impacts for a pipeline
+Returns the per-exception impact percentages the runtime auto-sync threshold filter would compare against for this pipeline/integration pair, each with the time that estimate was measured. The pipeline's sink dataset scopes the lookup; exceptions without an estimation row are absent from the response rather than reported as zero.
+
+## Tags
+- Pipeline Exceptions
+## Parameters
+
+- **pipelineId** (required) - path
+  - Pipeline ID providing the dataset scope
+  - Type: string
+- **integrationId** (required) - path
+  - Integration whose exceptions to look up impacts for
+  - Type: string
+
+## Responses
+
+### 200
+
+Impact percentages retrieved
+
+- **Content-Type**: `application/json` / object
+### 401
+
+Unauthorized
+
+### 404
+
+Not Found - Pipeline not found.

package/build/dist/docs-index/873346c7-935a-4171-8d84-84c7193d3e46.txt

@@ -0,0 +1,168 @@
+Turn on Grepr AI agent memory so an agent records what it concluded, counts recurrences, and searches past investigations during a new one.
+
+# Remember past investigations
+
+Without memory, every investigation starts from nothing. An agent that diagnosed a problem last week reaches the same conclusion the same slow way this week, and nobody learns that the problem has now happened five times.
+
+*Memory* changes that. An agent with memory enabled records what it concluded when it reaches a diagnosis, recognizes when a later investigation reaches the same conclusion and counts the recurrence, and searches those records at the start of a new investigation to find out whether it has seen this before.
+
+Both halves show up in the investigation's tool calls. A memory search runs near the start, before the agent has looked at anything else, and the record is written at the end, when it has a diagnosis.
+
+The agent decides what to record and whether something is a recurrence. Grepr does not extract conclusions on its behalf or merge records by similarity, because the investigating agent is the only thing that saw the evidence.
+
+Memory is off until you turn it on and choose where the memories are stored.
+
+## What an agent records \[#what-recorded]
+
+An agent records at most one memory per investigation, written when it reaches a diagnosis rather than after the fact. Each memory holds:
+
+| Field | What it holds |
+| --- | --- |
+| Title | A short name for the problem. |
+| Symptoms | What was observed. |
+| Root cause | What the agent concluded was responsible. |
+| Root cause confidence | Whether the cause is **confirmed**, **suspected**, or **unknown**. |
+| Ruled out | Causes the agent checked and eliminated, so a later investigation does not repeat that work. |
+| Resolution | What resolved it, or what was attempted. |
+| Significance | How much the conclusion matters. See [Significance](#classification). |
+| Entity tags | The services, pipelines, and environments the memory is about. See [Entity tags](#tagging). |
+| Recurrence count | How many investigations reached this same conclusion. |
+
+An agent can correct its own memory for an investigation while that investigation is running, so an early diagnosis it later disproves does not stay on the record. Correcting a memory does not count as a new recurrence.
+
+### Significance \[#classification]
+
+Significance is how an agent classifies what it found, and it decides how the memory can be found later:
+
+| Significance | Meaning |
+| --- | --- |
+| Incident | A real problem was identified. |
+| Observation | Not a problem, but a conclusion worth keeping. |
+| Inconclusive | The agent could not determine whether there was a problem. |
+| Benign | Triaged as no problem. |
+
+Benign memories are recorded but not indexed for search by meaning or by text. They are reachable only by a timeline search over their entity tags. This keeps the large number of routine all-clear findings out of the way of searches for real problems, at the cost of making them harder to find. If you want an agent to notice that a given service has been triaged as benign many times, search the timeline for that service rather than searching by text.
+
+## Turn on memory \[#enable]
+
+Memory needs somewhere to store its search index and a model to build that index with, so there are three things to set up.
+
+### Step 1: Create a vector index integration \[#vector-index]
+
+1. On the **Integrations** page, next to the **S3 Vector Index** section heading, click **Add new**.
+2. In the **Add Vector Index** dialog, enter a **Name** and the number of **Dimensions** the embedding model you plan to use produces, then click **Create**.
+
+The dimensions must match the model's output, so choose the embedding model first and use its dimension count. An index's dimensions are fixed after creation.
+
+### Step 2: Create an embedding integration \[#embedding-integration]
+
+Memory embeds each record with a model from an LLM integration that provides embeddings. If you do not have one, create it before you continue. See [_](/integrations/llm).
+
+An agent's reasoning model and its embedding model are separate choices. An agent can reason with one integration and embed with another.
+
+### Step 3: Turn on memory for the agent \[#agent-memory]
+
+1. On the agent's page, go to the **Memory** step.
+2. Turn on **Remember past investigations**.
+3. Under **Storage**, select the **Vector index integration**, the **Embedding credentials**, and the **Embedding model**.
+4. Save the agent.
+
+Grepr creates the search index when you create the vector index integration in Step 1, and discards the integration if the index cannot be created. Saving the agent then checks that the embedding model actually works against that index, by embedding a test value with it. So a wrong model or an unusable credential stops the save rather than surfacing later as memories that were never indexed.
+
+### Choose an embedding model and keep it \[#embedding-model]
+
+A memory is embedded with the model the agent had when it was recorded, and a query can only be compared against embeddings from the same model. Changing an agent's embedding model therefore cuts its new memories off from the ones it already recorded, as far as searching by meaning is concerned. Treat the choice as long lived.
+
+Using the same model across several agents does not pool their memories into one semantic search. A search by meaning always targets one agent, as described next.
+
+## How an agent searches its memory \[#search-modes]
+
+A search runs in exactly one of three modes, and which mode fits depends on what the agent is trying to find:
+
+| Mode | What it finds | Use it to answer |
+| --- | --- | --- |
+| Semantic | Investigations whose conclusions mean something similar to the query. | Has a problem like this happened before? |
+| Text | Investigations mentioning specific words, using full-text search. | Has this exact error string or identifier come up before? |
+| Timeline | Investigations about given entities, ordered by time. | What has been happening to this service recently? |
+
+Semantic search finds a past incident described in different words, which text search misses. Text search finds a literal, such as an error code or a host name, which semantic search can rank poorly. Timeline search needs entity tags rather than a query, and it is the only mode that returns benign memories.
+
+The modes also differ in how much they cover, which matters when you read an empty result:
+
+* A semantic search covers one agent at a time, because a query is only comparable against embeddings made with that agent's model. An empty semantic result means nothing similar was found within what the search could reach. It is not evidence that the agent recorded nothing similar, and it is not evidence that your organization has not seen the problem. A memory embedded with a model the agent no longer uses is unreachable until it is embedded again, and a search that cannot reach the embedding provider returns empty as well. When an empty result matters, confirm it with a text or timeline search, which read the records directly.
+* A text or timeline search covers every agent in your organization by default, so it is the one to use when you want the organization's whole history.
+
+So to find out whether any agent has seen something, search by text or timeline, or repeat the semantic search against each agent you care about.
+
+A result carries the memory's content along with its recurrence count, how long ago it was recorded, when it was last seen, and whether it is active, recent, or historical. There is no relevance score, because the agent judges from the content and the provenance rather than a ranking number.
+
+Search returns at most 50 results and has no pagination, so a broad query can be incomplete. Narrowing by entity tags or by significance is more effective than raising the limit.
+
+## Entity tags \[#tagging]
+
+Entity tags are what make memories findable by the thing they are about, such as a service, a pipeline, or an environment. Each memory carries two kinds:
+
+* Tags Grepr derives from the triggering signal, which identify the source and the signal type.
+* Tags the agent adds, which name the entities it concluded the memory is about.
+
+Grepr derives its tags using a mapping per signal type, which extracts values from the signal payload by path. The shipped mappings cover the common cases:
+
+| Signal type | Tags derived from the signal |
+| --- | --- |
+| Log pattern | The pipeline, the pattern, and the service, environment, and Kubernetes namespace from the sample log event. |
+| Webhook | The integration, and the service and host from the payload. |
+| Manual | The signal type only. |
+
+The webhook mapping reads the service and host from field names Grepr expects. If your payloads name those fields differently, add a mapping so the tags resolve. On the agent's **Memory** step, under **Entity tags**, add a mapping for the signal type, then add each tag key with the paths to read it from. Grepr tries the paths in order and uses the first that resolves.
+
+Consistent tag values matter more than complete ones. A service tagged `checkout` in some memories and `checkout-svc` in others splits its history in two, and a timeline search finds only half. Grepr gives an agent the tag values already in use in your organization when it searches, so an agent that searches before recording reuses existing values rather than inventing new ones.
+
+## Who can read and write memories \[#scope]
+
+* Reads are organization-wide. Any agent can search any other agent's memories in your organization. Operational history is only useful shared, so an agent investigating a service finds what another agent concluded about the same service. Permission is uniform across the modes, but coverage is not: a semantic search still examines one agent at a time. See [How an agent searches its memory](#search-modes).
+* Writes are owner-only. A memory can be written or corrected only by the agent that ran the investigation, so one agent cannot overwrite another's conclusions.
+
+When an agent finds that a past memory describes what it is now seeing, it links its investigation to that memory, which raises the recurrence count rather than creating a near-duplicate record. Each contributing investigation counts once.
+
+Memories outlive the agent that wrote them. Deleting an agent leaves its memories searchable by your other agents.
+
+## Search memories from the CLI \[#cli]
+
+The Grepr CLI searches the same memories an agent does, which is how you read what your agents have concluded.
+
+```bash
+# Find investigations mentioning a literal string
+grepr investigation:memory:search --mode text --query "connection refused" --limit 5
+
+# Find investigations whose conclusions are similar in meaning
+grepr investigation:memory:search --mode semantic --agent-id <agent-id> --query "intermittent ingestion failures"
+
+# See what has been happening to one service lately
+grepr investigation:memory:search --mode timeline --entity-tag entity:service=checkout
+```
+
+A semantic search needs an agent id, because a query can only be compared inside the index that agent embeds into. Text and timeline searches cover every agent in your organization by default. Timeline searches need at least one entity tag.
+
+The CLI is how you read what your agents have concluded outside of an investigation. To learn more about the CLI, see [_](/cli).
+
+## Frequently Asked Questions
+
+### What does Grepr AI agent memory store?
+
+One memory per investigation, holding a title, the symptoms, the root cause and the agent's confidence in it, the causes it ruled out, the resolution, a significance classification, entity tags, and a count of how many investigations reached the same conclusion.
+
+### What do I need to turn on agent memory?
+
+Three things: a vector index integration whose dimensions match your embedding model, an LLM integration that supplies the embedding model, and the embedding model name. Grepr creates the search index when you create the vector index integration. Saving the agent then checks that the embedding model works against that index, so a wrong model stops the save.
+
+### How does an agent search its memory?
+
+In one of three modes. Semantic search finds conclusions that mean something similar to the query, and covers one agent at a time. Text search finds specific words, such as an error code. Timeline search finds memories about given entities ordered by time, and is the only mode that returns benign memories. Text and timeline searches cover every agent in the organization by default.
+
+### Can one Grepr AI agent read another agent's memories?
+
+Yes, permission is organization-wide, so any agent can search any other agent's memories in your organization. Coverage differs by mode: text and timeline searches span every agent by default, while a search by meaning targets one agent at a time, because a query is only comparable against embeddings made with that agent's model. Writes are owner-only.
+
+### How do I read what my agents have remembered?
+
+Search them with the grepr investigation:memory:search command, choosing text, semantic, or timeline mode, or read them in an investigation that searched them. The Memory step of an agent holds the settings rather than the records.

package/build/dist/docs-index/89a02511-f8a7-4f59-83bd-4d10d19d0a99.txt

@@ -0,0 +1,30 @@
+# Preview authorization scopes for keys not yet saved to any integration
+
+**POST** `/v1/integrations/datadog/app-key/scopes/preview`
+
+**Operation ID**: `previewNewDatadogAppKeyScopes`
+**Summary**: Preview authorization scopes for keys not yet saved to any integration
+Probes Datadog with the supplied site and keys and reports each authorization scope. For the create form, where there is no integration to take keys from, so every field is required. Nothing is written and nothing is stored.
+
+## Tags
+- Datadog Integration
+## Request Body
+
+**Content-Type**: `application/json`
+
+**Schema**: `CheckAppKeyScopesRequest`
+
+## Responses
+
+### 200
+
+Scopes checked successfully
+
+- **Content-Type**: `application/json` / array of `AppKeyScopeCheck`
+### 400
+
+The supplied site is not allowed for this organization.
+
+### 401
+
+Unauthorized