@grepr/cli 1.11.5 → 1.11.6-674b35e

package/build/dist/docs-index/eef50b79-7277-4985-b92c-62813907231c.txt

@@ -0,0 +1,113 @@
+Process data in Grepr pipelines using built-in tools for parsing, filtering, enrichment, and transformation of log events.
+
+# Transform data in a Grepr pipeline
+
+A Grepr transform is a processing step that modifies, enriches, or restructures data as it flows through a pipeline. As records move through a pipeline, transforms allow you to parse structured and semi-structured data, filter records, and use a familiar SQL interface to perform more complex transformation of records as they move through a pipeline. Transforms are configured as pipeline steps that process data sequentially. Each transform receives input data, applies its logic, and passes the result to the next step in the pipeline.
+
+Most transforms are available in the Grepr pipelines UI. Some transforms are available only in the Grepr REST API or provide more capabilities when used with the API, such as [filters](#filter) and [branching the processing of records](#message-routing) based on query matches.
+
+The following sections describe the transforms available in Grepr pipelines.
+
+## Transform semi-structured records with the Grok parser \[#grok-parser]
+
+The Grok transform parses unstructured text using pattern matching with regular expressions and named capture groups. Use this transform to extract fields from log lines, error messages, and other text-based data where you need to identify specific patterns and convert them to structured fields.
+
+See [Grok parser](/transforms/grok).
+
+## Convert JSON messages into structured objects \[#json-parser]
+
+The JSON parser transforms JSON strings into structured JSON objects. This transform handles nested objects, arrays, and various data types, making it useful for processing API responses, configuration data, and structured log entries.
+
+See [Transform JSON strings into JSON objects](/transforms/json-parsing).
+
+## Restructure JSON objects with a remapper \[#remapper]
+
+The remapper transform moves or copies attributes to top-level fields or to tags in a JSON object. You can also use rename rules to move attribute values from one path to another within the same event. In the pipelines UI, a remapper with customizable default attributes is automatically added to a pipeline.
+
+See [Remap JSON attribute fields to top-level log event fields](/transforms/remapper).
+
+## Transform records with SQL \[#sql-transform]
+
+The SQL transform allows you to use ANSI standard SQL queries to filter, transform, and enrich data records. The SQL transform provides a familiar SQL interface to perform a number of data processing and transformation tasks.
+
+You can use the SQL transform in the Grepr UI or REST API. In the UI, the SQL transform is available when you configure filters.
+
+To learn about using the SQL transform in the Grepr API, see the [SQL Operation specification](/apis/api-spec#schema/SQLOperation).
+
+For a complete reference and examples, see [Transform events with SQL](/transforms/sql-transform).
+
+## Filter records based on conditions \[#filter]
+
+The Filter transform includes or excludes data records based on specified conditions. You can create filters using familiar query interfaces, such as SQL, as well as Datadog and New Relic log query-like syntaxes.
+
+In the Grepr pipelines UI, filters are located in predefined locations in the pipeline. To learn how to configure filters, see [Filter events in a Grepr pipeline](/transforms/filter-events).
+
+To have more flexibility for where filters are included in a pipeline, use the REST API. See [LogsFilter](/apis/api-spec#schema/LogsFilter).
+
+## Reduce log volumes with dynamic aggregation \[#reducer]
+
+The Grepr log reducer uses clustering algorithms to identify patterns in your log data and aggregate similar log messages. The output of this aggregation includes summaries and samples of similar messages. The log reducer is a core step in a log reduction pipeline, where it runs before processed log events are sent to your configured sinks. By sending summaries of similar messages rather than multiple events with redundant information, Grepr significantly reduces the volume of shipped logs and your observability costs. The log reduction pipeline also persists the complete set of raw logs to a low-cost data lake, enabling you to analyze and troubleshoot issues when necessary.
+
+To learn more about how Grepr reduces log volumes with dynamic aggregation, see [Reduce noise and improve the usability of your logs with the log reducer](/transforms/reducer).
+
+To learn how to create a log reduction pipeline, see [Tutorial: Build your first Grepr pipeline](/tutorials/first-pipeline).
+
+To learn how to use the resulting summarized log events in your observability platform along with raw logs stored in Grepr, see [Troubleshoot incidents with Grepr-processed data and your observability tool](/tutorials/troubleshooting-example).
+
+## Transform and enrich log messages with the REST API \[#log-transform-action]
+
+You can use the LogTransformAction in the REST API to specify actions that transform log messages, such as adding or removing attributes and tags. See [LogTransformAction](/apis/api-spec#schema/LogTransformAction).
+
+## Route the processing of messages based on query matches \[#message-routing]
+
+You can route log messages to be processed by different pipelines based on query matches. Because the pipelines UI doesn't support branching, Grepr recommends creating multiple pipelines that ingest data using the same source, and then use filters to route data to the correct pipeline.
+
+Sending logs to different destinations, rather than processing them differently, is a separate problem with its own approaches. See [_](/solution-guides/route-logs-to-several-accounts).
+
+You can also use the REST API to create more complex pipeline configurations. See [LogsBranch](/apis/api-spec#schema/LogsBranch).
+
+## Frequently Asked Questions
+
+### What transforms are available in Grepr pipelines?
+
+Grepr provides several transform types: Grok parser for parsing unstructured text with pattern matching, JSON parser for converting JSON strings into structured objects, remapper for restructuring JSON fields and attributes, SQL transform for complex filtering and enrichment using SQL queries, and Filter transform for conditional record processing. Most transforms are available in the UI, while some advanced options are available via REST API.
+
+### When should I use the Grok parser transform?
+
+Use the Grok parser when you need to extract structured data from unstructured text logs. It's ideal for parsing error messages, application logs, system logs, and other text-based data where you need to identify specific patterns and convert them into structured fields using regular expressions and named capture groups.
+
+### When should I use the JSON parser transform?
+
+Use the JSON parser when your log messages contain JSON strings that need to be converted into structured JSON objects. This is useful for processing API responses, configuration data, and structured log entries. The JSON parser handles nested objects, arrays, and various data types automatically.
+
+### What is the remapper transform and when is it used?
+
+The remapper transform moves or copies attributes to top-level fields or to tags in a JSON object. It's useful for standardizing log event structure by moving well-known fields like message, severity, and host from nested attributes to top-level fields. You can configure whether the source attribute is preserved or removed after remapping. The remapper also supports rename rules for moving attribute values from one path to another. The remapper is automatically added to pipelines in the UI with customizable default attributes.
+
+### When should I use the SQL transform?
+
+Use the SQL transform when you need complex filtering, transformation, or enrichment of log records. SQL provides a familiar interface for advanced operations like conditional logic, string manipulation, aggregations, and joining data. It's available in the UI for filters and via REST API for more flexibility.
+
+### Can I combine multiple transforms in a pipeline?
+
+Yes, transforms are configured as sequential pipeline steps. Each transform receives input from the previous step, applies its logic, and passes the result to the next step. This allows you to create complex data processing workflows by combining parsing (Grok), restructuring (remapper), and filtering/enrichment (SQL) transforms.
+
+### What is the Filter transform used for?
+
+The Filter transform includes or excludes data records based on specified conditions. You can use filters with SQL, Datadog, and New Relic-like query syntaxes. In the UI, filters are located in predefined pipeline positions, while the REST API provides more flexibility for filter placement.
+
+### Can I use the REST API for more advanced transform options?
+
+Yes, the REST API provides access to advanced transform options not available in the UI. For example, you can use LogTransformAction to add or remove attributes and tags, LogsBranch for complex message routing based on query matches, and more flexible filter placement. See the API specification for complete details on transform capabilities.
+
+### How do I choose between Grok and SQL transforms?
+
+Use Grok when you need pattern-based parsing of unstructured text to extract specific fields. Use SQL when you need complex conditional logic, calculations, string transformations, or filtering. Grok is specialized for text parsing, while SQL is more general-purpose for data manipulation and enrichment.
+
+### How does Grepr reduce log volumes and observability costs?
+
+Grepr uses clustering algorithms to identify patterns in log data and aggregates similar log messages. Instead of sending multiple redundant log events, Grepr sends summaries and samples of similar messages to your observability platform. This significantly reduces the volume of shipped logs while retaining the ability to analyze and troubleshoot issues. Raw logs are retained in a low-cost data lake for future reference.
+
+### What happens if a transform fails on a record?
+
+Transform behavior depends on the specific transform type and configuration. Parsing errors (like Grok or JSON parsing) typically skip records or add error attributes depending on your configuration. SQL transforms filter out records that don't match conditions. Review transform-specific documentation for error handling details.

package/build/dist/docs-index/eff4ffec-6a9f-4851-b169-b2cd51bdf0db.json

@@ -0,0 +1 @@
+{"docType":"doc"}

package/build/dist/docs-index/f15bed93-374c-4c7d-b956-588cd075b15d.json

@@ -0,0 +1 @@
+{"docType":"doc"}

package/build/dist/docs-index/f53841f8-7497-4f61-a1e7-aba23adb27b9.txt

@@ -0,0 +1,14 @@
+# PromotionPolicyAttributes
+
+**Type**: `object`
+
+## Properties
+
+- name: cap (required)
+  type: integer
+
+- name: exclude (optional)
+  type: array of `PromotionPolicyAttributeExclude`
+
+- name: include (optional)
+  type: array of `PromotionPolicyAttributeInclude`

package/build/dist/docs-index/f54e9254-31a4-45cc-99e5-6fb2aa5651f7.txt

@@ -0,0 +1,40 @@
+# Preview a vendor estimation run
+
+**POST** `/v1/integrations/{integrationId}/exceptions/vendor-estimation-runs/preview`
+
+**Operation ID**: `previewVendorEstimationRun`
+**Summary**: Preview a vendor estimation run
+Returns how many exceptions and distinct queries a run would cover, and which exceptions cannot be counted because their query never parsed. Writes nothing.
+
+## Tags
+- Integration Exceptions
+## Parameters
+
+- **integrationId** (required) - path
+  - Integration id
+  - Type: string
+
+## Request Body
+
+**Content-Type**: `application/json`
+
+**Schema**: `CreateVendorEstimationRunRequest`
+
+## Responses
+
+### 200
+
+Preview computed
+
+- **Content-Type**: `application/json` / `VendorEstimationRunPreview`
+### 400
+
+Bad Request - The window is inverted, starts or ends in the future, or is too long.
+
+### 401
+
+Unauthorized
+
+### 404
+
+Not Found - Integration not found.

package/build/dist/docs-index/f94f4c43-f0f2-4d13-88b9-8aa53bc4959f.json

@@ -0,0 +1 @@
+{"docType":"doc"}

package/build/dist/docs-index/f9755ca4-3eaa-4d97-9cb9-bd073bbd0674.json

@@ -0,0 +1 @@
+{"docType":"api"}

package/build/dist/docs-index/f9fc04d0-7b3e-40e6-986e-735d091fdd97.json

@@ -0,0 +1 @@
+{"docType":"doc"}

package/build/dist/docs-index/fa614e9b-2fc8-4d91-a227-25582b0c3f6c.json

@@ -0,0 +1 @@
+{"docType":"schema"}

package/build/dist/docs-index/fa9be527-f96f-4c5e-b3b4-8f5c98a39553.json

@@ -0,0 +1 @@
+{"docType":"doc"}

package/build/dist/docs-index/fa9be527-f96f-4c5e-b3b4-8f5c98a39553.txt

@@ -0,0 +1,103 @@
+Learn what Grepr AI agents are, how they investigate your telemetry, and what to configure before you create one.
+
+# Grepr AI agents
+
+A Grepr *AI agent* is a configured investigator that Grepr runs for you. You give it instructions, a model to reason with, an identity to act as, and a set of capabilities. It then runs *investigations*: in each one the agent works in an isolated sandbox, uses the capabilities you granted to examine your logs, pipelines, and connected systems, records the changes it made outside the sandbox that Grepr recognizes, and writes up what it found.
+
+You decide when an agent runs. Start an investigation yourself and give it the context to work from, or connect the agent to a source so it investigates on its own whenever that source reports something. When an investigation finishes, you can carry it forward into a new one that starts from the earlier conversation.
+
+An agent is not a chat assistant. It runs unattended and finishes with a written conclusion you read afterwards. If it concludes that a pipeline should change, what happens next depends on the agent's change approval mode: it either records the change as a suggestion for you to review, or applies it directly.
+
+> AI agents are enabled for each organization individually. To turn on AI agents for your organization, contact <support@grepr.ai>.
+
+## What an agent can do \[#capabilities-summary]
+
+Every agent works inside its own sandbox, where it can always run shell commands, Python, and DuckDB, and read and write its own files. What it can reach beyond that sandbox is entirely what you grant it:
+
+* Search the logs and spans in your data lake.
+* Read the configuration of your pipelines, datasets, templates, and integrations.
+* Propose and apply changes to a pipeline's Grok parsers and SQL transforms.
+* Call the tools published by an MCP server you connect.
+* Read its own past investigations and the conclusions it recorded from them.
+
+An agent acts as a Grepr service account that you choose. The roles on that service account cap what the agent can reach, whatever tools you enable, so the service account is the outer boundary and the tool grants narrow it further. To learn more, see [_](/ai-agents/capabilities).
+
+## The parts of an AI agent \[#parts]
+
+| Part | What it is |
+| --- | --- |
+| Agent | The configuration you create: a name, instructions, a model, a service account, the tools and skills it can use, and its limits. |
+| Signal source | A pipeline that detects new log patterns, or a Grepr Agent integration that receives events from another system. |
+| Subscription | The link between an agent and a signal source. A signal from that source starts an investigation on that agent. |
+| Investigation | One run of an agent, with its transcript, the actions it took, and its summary. |
+| Memory | What an agent recorded from past investigations, and can search during a new one. |
+| Skill | A directory of instructions an agent loads when it needs them. A skill can also grant tools. |
+| Suggestion | A pipeline change an agent proposed and is waiting for you to review. |
+
+## How an investigation runs \[#investigation-loop]
+
+1. An investigation is queued, either because you started one and gave it context, or because a source the agent is connected to reported something. If the agent is already running as many investigations as you allow, the new one waits or is dropped, depending on the agent's queueing setting.
+2. The agent starts in a fresh sandbox, reads its instructions and whatever it was given to start from, and searches its memory for investigations that reached a similar conclusion.
+3. The agent works through as many turns as you allow, calling the tools you granted. Grepr records each turn, each tool call, and each change it recognizes the agent making outside the sandbox.
+4. The agent writes a summary and, when it has one, records a conclusion in its memory. If it wants to change a pipeline, it submits the change as a suggestion, or applies it directly when you configured the agent to do so.
+
+An investigation ends on its own, or you can stop it to add guidance and resume it, cancel it outright, or continue it in a fresh investigation seeded from it. To learn more, see [_](/ai-agents/investigations).
+
+## What you need before you start \[#requirements]
+
+Before you create your first agent, you need:
+
+* An LLM integration that provides the model the agent reasons with. See [_](/integrations/llm).
+* A Grepr service account for the agent to act as. See [_](/admin/service-accounts).
+
+That is enough to create an agent and run investigations yourself. Three further capabilities each need their own setup:
+
+* To have an agent investigate on its own, connect it to a signal source, which is either a pipeline or a Grepr Agent integration. See [_](/ai-agents/subscriptions).
+* To let an agent call an external system's tools, create an MCP integration. See [_](/integrations/mcp).
+* To let an agent keep and search conclusions from past investigations, create a vector index integration and an embedding integration. See [_](/ai-agents/memory).
+
+## Create an agent
+
+Create an agent in a six-step wizard that collects its instructions, its model, its capabilities, its memory settings, and its subscriptions. The same settings are editable afterwards on the agent's page. See [_](/ai-agents/create-an-agent).
+
+## Control what an agent can do
+
+An agent's reach is set by the service account it acts as, the tools you enable, the skills you give it, and the MCP servers you connect. This also covers whether the pipeline changes it proposes need your approval. See [_](/ai-agents/capabilities).
+
+## Extend agents with skills
+
+A skill is a directory of instructions that an agent loads only when it is relevant, and which can grant the tools it needs. Grepr ships a set of skills, and you can write your own. See [_](/ai-agents/skills).
+
+## Have an agent investigate on its own
+
+Connect an agent to a pipeline or a Grepr Agent integration so that source's events start investigations without you. See [_](/ai-agents/subscriptions).
+
+## Run and review investigations
+
+Start an investigation yourself, follow the ones a source triggered, read their transcripts, guide one that is running, and review the pipeline changes an agent proposes. See [_](/ai-agents/investigations).
+
+## Remember past investigations
+
+With memory turned on, an agent records what it concluded, counts how often the same conclusion recurs, and searches those records during later investigations. See [_](/ai-agents/memory).
+
+## Frequently Asked Questions
+
+### What is a Grepr AI agent?
+
+A Grepr AI agent is a configured investigator that runs unattended in an isolated sandbox. You give it instructions, a model, a service account identity, and a set of capabilities, then run investigations with it. You can start an investigation yourself, connect the agent to a source so it investigates on its own, or continue a finished investigation in a new one. In each investigation the agent examines your telemetry, records the actions it took, and writes a summary.
+
+### How is an AI agent different from an agent sessions pipeline?
+
+An AI agent investigates your telemetry and can change your pipelines. An agent sessions pipeline does the opposite: it ingests the OpenTelemetry data that coding agents such as Claude Code, Codex, and OpenCode produce, and reassembles it into readable sessions so you can review transcripts and measure token usage and cost.
+
+### How does a Grepr AI agent investigation start?
+
+You can start one yourself from the agent's page and give it the context to work from, or continue a finished investigation in a new one. An agent connected to a source also investigates on its own: a pipeline reducer detecting a log pattern it has not seen before, a SQL output in a pipeline routed to the agent signal, or an event received by a Grepr Agent webhook integration.
+
+### Can a Grepr AI agent change my pipelines without approval?
+
+Only if you configure it that way. An agent's change approval mode is either Require human approval, which records every proposed change as a suggestion for you to review and apply, or Auto-apply, which applies verified changes directly. Require human approval is the default.
+
+### What limits how many investigations an agent runs?
+
+You set the maximum number of concurrent investigations for each agent and whether additional signals queue or are discarded at that limit. You can also cap the tokens a single investigation can consume and the tokens the agent can consume per time window. The LLM integration the agent shares carries its own token budget as well.

package/build/dist/docs-index/faacf226-23a8-46f4-a002-403761021e11.json

@@ -0,0 +1 @@
+{"docType":"api"}

package/build/dist/docs-index/fabf7e24-9769-4658-8921-dbe5b73eb143.json

@@ -0,0 +1 @@
+{"docType":"api"}

package/build/dist/docs-index/fad29b2f-63d1-4a37-b2ab-55329ed9fac4.json

@@ -0,0 +1 @@
+{"docType":"schema"}

package/build/dist/docs-index/faf0ea6d-1685-46d0-a99d-e628b1120ecf.json

@@ -0,0 +1 @@
+{"docType":"schema"}

package/build/dist/docs-index/fb31dda3-127d-4431-a86e-da690e5ea62d.json

@@ -0,0 +1 @@
+{"docType":"schema"}

package/build/dist/docs-index/fb31dda3-127d-4431-a86e-da690e5ea62d.txt

@@ -0,0 +1,15 @@
+# ExceptionImpact
+
+Estimated passthrough for one parsed alert query against one dataset
+
+**Type**: `object`
+
+## Properties
+
+- name: measuredAt (optional)
+  type: string
+  description: When the estimation run that produced this percentage completed. Absent when the age of the measurement is not known; that is not the same as freshly measured.
+
+- name: percentage (required)
+  type: number
+  description: Estimated percentage of the dataset's raw log volume this query matches. Honouring the query as a pipeline exception passes approximately this share of the data through without aggregation.

package/build/dist/docs-index/fb54f59e-f34b-4810-a7e2-86bd95b588d8.json

@@ -0,0 +1 @@
+{"docType":"schema"}

package/build/dist/docs-index/fb86db2c-24e8-46bd-8e59-ef70453cb5b5.json

@@ -0,0 +1 @@
+{"docType":"schema"}

package/build/dist/docs-index/fbfe4d61-d3d4-4bc3-95e2-a4807f2c7e14.json

@@ -0,0 +1 @@
+{"docType":"schema"}

package/build/dist/docs-index/fbfe4d61-d3d4-4bc3-95e2-a4807f2c7e14.txt

@@ -0,0 +1,19 @@
+# PreviewAppKeyScopesRequest
+
+Unsaved changes to check Datadog authorization scopes against
+
+**Type**: `object`
+
+## Properties
+
+- name: apiKey (optional)
+  type: string
+  description: API key to probe with instead of the stored one
+
+- name: appKey (optional)
+  type: string
+  description: Application key to check instead of the stored one
+
+- name: site (optional)
+  type: string
+  description: Site to probe instead of the stored one

package/build/dist/docs-index/fc183a1d-5191-4d27-a84b-916841a6ea18.json

@@ -0,0 +1 @@
+{"docType":"doc"}

package/build/dist/docs-index/fc183a1d-5191-4d27-a84b-916841a6ea18.txt

@@ -0,0 +1,148 @@
+Create a Grepr AI agent, write its instructions, choose its model, set the limits that bound what it spends, and edit or delete it later.
+
+# Create an AI agent
+
+You create an agent once and it runs from then on, so the settings you choose decide both what the agent is good at and what it costs. This page covers the settings that define the agent itself. Its capabilities, its memory, and its subscriptions each have their own page, and the wizard links to the same settings.
+
+## Requirements
+
+Before you create an agent, you need:
+
+* An LLM integration for the model the agent reasons with. See [_](/integrations/llm).
+* A Grepr service account for the agent to act as. See [_](/admin/service-accounts).
+
+## Create an agent \[#create]
+
+On the **Agents** page, click **Create agent**. The **Create agent** wizard collects the agent's settings in six steps, and you can move between steps with **Back** and **Continue** or by clicking a step in the stepper. The agent is created when you click **Create agent** on the last step, so you can revise any step before then.
+
+### Step 1: Name the agent and write its instructions \[#step1-instructions]
+
+Enter a **Name** that says what the agent is for, such as `prod-log-triage`. The name identifies the agent everywhere you subscribe it to a source or read its investigations, and you can change it later.
+
+In the **System prompt** field, write the instructions that frame every investigation this agent runs. To start from a working example rather than an empty field, click **Use a starter prompt** and edit what it gives you.
+
+### Step 2: Choose a model \[#step2-model]
+
+1. In the **Provider** menu, select the provider of the LLM integration you want the agent to use.
+2. In the **LLM integration** menu, select the integration that provides the credentials for that provider. If the menu is empty, create the integration first. See [_](/integrations/llm).
+3. In the **Model name** field, enter the model the agent reasons with. Grepr suggests the models your integration reports, but the field accepts any model identifier the provider serves, so a model missing from the list is still valid.
+4. Set the agent's limits under **Advanced configuration**. See [Set an agent's limits](#limits).
+
+Investigations are long-running and tool-heavy, so the model you choose changes how well the agent reasons across many turns, not just how fast it answers. Prefer a model that handles extended tool use.
+
+### Step 3: Grant capabilities \[#step3-capabilities]
+
+The **Capabilities** step is where you choose the service account the agent acts as, the tools and skills it can use, the MCP servers it can call, and whether the pipeline changes it proposes need your approval. To learn more, see [_](/ai-agents/capabilities).
+
+### Step 4: Configure memory \[#step4-memory]
+
+The **Memory** step is where you decide whether the agent keeps and searches conclusions from its past investigations. To learn more, see [_](/ai-agents/memory).
+
+### Step 5: Subscribe to signal sources \[#step5-subscriptions]
+
+The **Subscriptions** step is where you connect the agent to the pipelines and Grepr Agent integrations whose signals it investigates. You can leave it empty and subscribe later from the agent's page. To learn more, see [_](/ai-agents/subscriptions).
+
+### Step 6: Review and create \[#step6-review]
+
+The **Review** step lists every setting you chose. Check the system prompt, the model, the abilities and tools, and the subscriptions, then click **Create agent**.
+
+An agent with subscriptions starts investigating as soon as its sources produce signals. To review its behavior before it runs on live signals, create it without subscriptions, start an investigation manually, read the transcript, then subscribe it. See [_](/ai-agents/investigations#start-manual).
+
+## Set an agent's limits \[#limits]
+
+An agent's limits are under **Advanced configuration** on the **Model** step, and on the **Behavior** step after the agent exists. They are what bound the work and the cost of a single investigation and of the agent as a whole.
+
+### Limit a single investigation \[#run-limits]
+
+| Setting | What it does |
+| --- | --- |
+| **Max output tokens** | The largest response Grepr accepts from the model in one call. |
+| **Max turns per investigation** | How many turns an investigation can take before it ends. A turn is one model call and the tool calls that follow it. |
+| **Max tokens per investigation** | The total tokens one investigation can consume. The default is 3,000,000. |
+
+An investigation that reaches its turn or token limit ends where it is, keeping the transcript and the summary it had reached.
+
+### Limit the agent as a whole \[#window-limits]
+
+**Agent max tokens per window** caps the tokens this agent can consume across all its investigations in each budget window. Leave it empty to bound the agent only by the budget on its LLM integration.
+
+Grepr reserves an investigation's tokens before it starts and requires room in two budgets: this agent's window budget, and the budget on the LLM integration the agent shares with any other agent using it. When either is exhausted, new investigations stop starting, and the agent's page reports which budget blocked them and when the window resets. Raising this agent's limit does not help when the shared integration is the one that is full. To set the integration's budget, see [_](/integrations/llm#max-tokens).
+
+The two kinds of invocations, manual and signal triggered, end differently when a budget is exhausted. An investigation you start manually is discarded immediately, so you learn straight away. One triggered by a signal stays queued and runs when capacity returns, unless it waits longer than the maximum queue wait.
+
+### Control concurrency and queueing \[#concurrency]
+
+| Setting | What it does |
+| --- | --- |
+| **Max concurrent investigations** | How many of this agent's investigations run at the same time. The default is 3. |
+| **When at the limit** | Whether an additional signal waits or is dropped. **Queue** holds it until a slot frees. **Discard** drops it. |
+| **Max queue wait (minutes)** | How long a queued investigation waits before Grepr discards it. Leave empty for no limit. |
+
+The maximum queue wait applies only to investigations triggered by a signal, not to the ones you start manually. Set it when a stale signal is not worth investigating, such as a pattern that stopped occurring an hour ago. Leave it empty when you want every signal investigated eventually.
+
+An agent subscribed to a busy pipeline can produce more signals than it can investigate. **Discard** keeps the agent current at the cost of skipping signals, and **Queue** with a maximum wait keeps a bounded backlog. To reduce the signals instead of dropping them, narrow what the source emits. See [_](/ai-agents/subscriptions).
+
+## Write a system prompt \[#system-prompt]
+
+The system prompt is read at the start of every investigation this agent runs, so it should describe the agent's standing job rather than any one incident. A prompt that works well:
+
+* States what the agent is responsible for and what it should leave alone.
+* Names the systems and services it covers, using the same names that appear in your logs, so the agent can match a signal to a service.
+* Says what a finished investigation looks like, such as whether the agent should attempt a remediation or only diagnose.
+* Says when the agent should change a pipeline and when it should not.
+
+Keep behavior that only applies sometimes out of the prompt and put it in a skill, which the agent loads when it is relevant. This keeps the prompt short and lets several agents share the same guidance. See [_](/ai-agents/skills).
+
+You can revise the prompt at any time on the agent's **Behavior** step. A revised prompt applies to investigations that start afterwards, and running investigations keep the prompt they started with.
+
+## Monitor an agent \[#monitor]
+
+The agent's **Overview** step reports how the agent is doing over the time range you select, with its model, its last investigation, the share of its runs that failed, its run times, and how much of its token budget it has used. Three charts break down the investigations it started, how they ended, and the tokens they consumed.
+
+Read the failure rate together with the outcomes chart. Failures concentrated in time usually point at the model or a tool that became unavailable, while a failure rate that is steady across the range usually points at the agent's instructions or its limits.
+
+When a token budget is exhausted, new investigations stop starting and resume when the window resets. The agent's page shows which of the two budgets blocked them.
+
+## Edit an agent \[#edit]
+
+An agent's settings are spread across the steps on its page, which hold the same fields as the wizard:
+
+* **Behavior** holds the name, the system prompt, the model, and the limits.
+* **Capabilities** holds the service account, the tools, the skills, the MCP integrations, and the change approval mode.
+* **Memory** holds the memory settings.
+
+Changes on these three steps are held until you click **Save Changes**, so you can revise several steps in one pass. To abandon them, click **Discard Changes**. Subscriptions are not part of this and apply as soon as you make them.
+
+An investigation reads the agent's instructions, model, and limits when it starts, so correcting those mid-incident leaves the current run on the settings it began with and applies to the next one.
+
+The change approval mode is the exception. Grepr checks it when the agent submits a pipeline change, not when the investigation started, so switching an agent to **Auto-apply** lets an investigation that is already running apply its own changes.
+
+## Delete an agent \[#delete]
+
+To delete an agent, on its page, open the three-dot menu and select **Delete agent**. You can also delete it from the three-dot menu on its card on the **Agents** page.
+
+Grepr refuses to delete an agent while a pipeline is subscribed to it or a Grepr Agent integration names it, so detach it from both on its **Subscriptions** step first. A pipeline that names the agent directly in its agent signal sink is not covered by that check, so open the sink in each such pipeline and clear the agent from the **Agents** field yourself. A sink keeps at least one agent, so where the agent you are deleting is the only one named, either select another agent in its place or remove the sink along with the routes that feed it. A signal that arrives for a deleted agent is discarded. Investigations already running finish, and no new ones start.
+
+Deleting an agent does not delete its investigations or the memories it recorded, which stay readable and searchable by your other agents.
+
+## Frequently Asked Questions
+
+### What do I need before creating a Grepr AI agent?
+
+You need an LLM integration for the model, a Grepr service account for the agent to act as, and the Edit permission on integrations at the organization or team level.
+
+### How many investigations does a Grepr AI agent run at once?
+
+You set the maximum number of concurrent investigations, which defaults to 3, and choose whether an additional signal queues or is discarded at that limit. A queued investigation can also be given a maximum wait, after which Grepr discards it.
+
+### What happens when an agent reaches its token budget?
+
+New investigations stop starting, and the agent's page reports whether the agent's own window budget or the shared LLM integration's budget blocked them, and when the window resets. An investigation started manually is discarded immediately, while one triggered by a signal stays queued until capacity returns or its maximum queue wait elapses.
+
+### Do changes to an agent affect investigations that are already running?
+
+Mostly no. An investigation reads the instructions, model, and limits it started with, so changes to those apply to the next run. The change approval mode is the exception: Grepr checks it when the agent submits a pipeline change, so switching to Auto-apply lets an investigation that is already running apply its own changes.
+
+### Why can't I delete my Grepr AI agent?
+
+Grepr refuses to delete an agent while a pipeline is subscribed to it or a Grepr Agent integration names it. Detach it from both on its Subscriptions step, then delete it. Investigations already running finish, and its recorded memories remain searchable by your other agents.

package/build/dist/docs-index/fc3073bd-4c6d-4d04-a7a2-3f222225ac1b.json

@@ -0,0 +1 @@
+{"docType":"schema"}

package/build/dist/docs-index/fc406968-c036-4d32-b4cb-fed5c3f89f54.json

@@ -0,0 +1 @@
+{"docType":"schema"}

package/build/dist/docs-index/fc406968-c036-4d32-b4cb-fed5c3f89f54.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/fca123ad-91c5-4b2c-9893-2ff36523e4d8.json

@@ -0,0 +1 @@
+{"docType":"schema"}

package/build/dist/docs-index/fcce70a6-a27f-4194-8549-c8ee16c51b7a.json

@@ -0,0 +1 @@
+{"docType":"schema"}

package/build/dist/docs-index/fdd0f668-20da-4e5b-9342-5b2cb5f1c2fe.json

@@ -0,0 +1 @@
+{"docType":"api"}

package/build/dist/docs-index/fe468220-9148-4afa-97fe-d6187984b645.json

@@ -0,0 +1 @@
+{"docType":"api"}

package/build/dist/docs-index/fe506096-2e22-4863-8fcc-b2890ca923ff.json

@@ -0,0 +1 @@
+{"docType":"doc"}

package/build/dist/docs-index/fe60224b-6e08-49ab-9bc8-15fc238b7450.json

@@ -0,0 +1 @@
+{"docType":"schema"}

package/build/dist/docs-index/ff085d5a-e10d-4cae-9853-17f72b8140bc.json

@@ -0,0 +1 @@
+{"docType":"schema"}

package/build/dist/docs-index/ff0fa924-9233-4cdf-b40b-f2ce72b5e9b7.json

@@ -0,0 +1 @@
+{"docType":"api"}

package/build/dist/docs-index/ff0fa924-9233-4cdf-b40b-f2ce72b5e9b7.txt

@@ -0,0 +1,30 @@
+# Get the usage of an integration's parsed queries
+
+**GET** `/v1/integrations/{integrationId}/exceptions/usage`
+
+**Operation ID**: `getIntegrationExceptionUsage`
+**Summary**: Get the usage of an integration's parsed queries
+Returns the usage the observability vendor reports for the source of each parsed query, such as when a Datadog dashboard was last viewed and its total views, with whether the last attempt to read it worked. Queries the vendor reported nothing for are absent rather than reported as never viewed.
+
+## Tags
+- Integration Exceptions
+## Parameters
+
+- **integrationId** (required) - path
+  - Integration id
+  - Type: string
+
+## Responses
+
+### 200
+
+Usage retrieved
+
+- **Content-Type**: `application/json` / `ExceptionUsageResponse`
+### 401
+
+Unauthorized
+
+### 404
+
+Not Found - Integration not found.

package/build/dist/docs-index/ffa0360a-f951-4a00-b493-2caff25559ed.json

@@ -0,0 +1 @@
+{"docType":"api"}

package/build/dist/docs-index/ffab32ee-f0c7-46a5-9e75-9fd598cfb68f.json

@@ -0,0 +1 @@
+{"docType":"doc"}

package/build/dist/docs-index/ffc2c11c-b662-4153-adee-3d35ba944c94.json

@@ -0,0 +1 @@
+{"docType":"api"}

package/build/dist/docs-index/ffffb87b-88e2-404b-92e9-3db566abf0d5.json

@@ -0,0 +1 @@
+{"docType":"api"}