@grepr/cli 1.11.5-17c35fd → 1.11.5-2d36a92

package/build/dist/docs-index/{131160a2-a5a5-47b6-bf54-b58f4f3ae133.txt → 00421b75-4428-495d-adb7-cf254bddbee0.txt}

@@ -4,6 +4,8 @@
 
 **Operation ID**: `currentWindow`
 **Summary**: Get the current maxTokens window of one LLM integration
+## Tags
+- LLM Usage
 ## Parameters
 
 - **integrationId** (required) - path

package/build/dist/docs-index/{9750bbb0-a443-47df-9ab8-a96eccbc2ef1.txt → 071a4e66-96b8-43ea-84d6-a170c574d74a.txt}

@@ -4,6 +4,8 @@
 
 **Operation ID**: `archive`
 **Summary**: Archive an organization skill
+## Tags
+- Skills
 ## Parameters
 
 - **id** (required) - path

package/build/dist/docs-index/{3fb9a8c6-6a48-4531-bb3b-e606ea5cb956.txt → 08843848-20ba-44e4-97dd-03d5a7318175.txt}

@@ -4,7 +4,7 @@
 
 **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. The pipeline's sink dataset scopes the lookup; exceptions without an estimation row are absent from the response.
+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

package/build/dist/docs-index/15880500-9fb7-4496-9660-ca803cc11533.txt

@@ -0,0 +1,33 @@
+# Get parsed alert query impacts for an integration and dataset
+
+**GET** `/v1/integrations/{integrationId}/exceptions/impacts`
+
+**Operation ID**: `getIntegrationExceptionImpactsByDataset`
+**Summary**: Get parsed alert query impacts for an integration and dataset
+Returns the estimated percentage of the dataset's raw log volume each of the integration's parsed alert queries matches, with the time that estimate was measured. Queries that have not been estimated are absent from the response rather than reported as zero. The dataset must be one of those returned by the estimation-datasets endpoint for this integration.
+
+## Tags
+- Integration Exceptions
+## Parameters
+
+- **integrationId** (required) - path
+  - Integration id
+  - Type: string
+- **datasetId** (required) - query
+  - Dataset the estimates are scoped to
+  - Type: string
+
+## Responses
+
+### 200
+
+Impact estimates retrieved
+
+- **Content-Type**: `application/json` / object
+### 401
+
+Unauthorized
+
+### 404
+
+Not Found - Integration not found, or the dataset is not reachable from it.

package/build/dist/docs-index/18cd0ba8-bd11-40e7-8a84-b91605bffd0b.txt

@@ -0,0 +1,171 @@
+Start, follow, and read Grepr AI agent investigations, guide a running one, understand each state, and review the pipeline changes an agent proposes.
+
+# Run and review investigations
+
+An *investigation* is one run of an agent. It holds the signals that triggered it, every turn the agent took, every tool it called, the changes it made outside the sandbox that Grepr recognizes, and the summary it finished with. Investigations are listed on the agent's **Investigations** step.
+
+An investigation is a record, not a conversation. You can interrupt one to add guidance, but most investigations run to completion unattended and you read them afterwards.
+
+## Start an investigation manually \[#start-manual]
+
+Start one manually to try out an agent before subscribing it to anything, or to point an agent at something you already know about.
+
+1. On the agent's page, click **Run investigation**.
+2. Optionally enter **Context**, which is what the agent starts from, such as the service to look at or the symptom you saw.
+3. Click **Start investigation**.
+
+Context is the only instruction an investigation started manually receives beyond the agent's system prompt, so include the service, the time range, and the symptom. An investigation with no context relies entirely on the agent's prompt to decide what to examine.
+
+An investigation you start manually is not subject to the maximum queue wait, but it is subject to the concurrency limit and the token budgets. When a budget is exhausted, a manual investigation is discarded rather than queued, so you find out immediately instead of waiting. See [_](/ai-agents/create-an-agent#limits).
+
+## Investigation states \[#states]
+
+| State | What it means | What you can do |
+| --- | --- | --- |
+| Queued | Accepted and waiting for a free slot on the agent. No sandbox exists yet. | Cancel it. |
+| Running | The agent is working. | Stop it or cancel it. |
+| Stopping | A stop was requested and is being applied. | Cancel it. |
+| Cancelling | A cancel was requested and is being applied. | Wait for it to finish. |
+| Stopped | Either paused and waiting for instruction, or ended after waiting too long. | Resume a paused one, or continue a finished one in a new investigation. |
+| Completed | The agent finished and wrote a summary. | Continue it in a new investigation. |
+| Failed | The investigation ended with an error. | Read the reason, then continue it in a new investigation. |
+| Cancelled | You cancelled it. | Continue it in a new investigation. |
+| Discarded | Recorded but never ran. | Read why, then address the cause. |
+
+Stopped covers two situations, and the status icon tells them apart. A stopped investigation that is still waiting for instruction is paused and can be resumed, carrying on from where it left off while its sandbox is still there. If the sandbox is lost while the investigation is paused, the resumed agent restarts from the triggering signals and whatever you resume it with, so give it what it needs rather than assuming it still remembers. One that waited too long without instruction has ended, and the work it did is readable but no longer resumable. So resume a stopped investigation while you still want its context, rather than leaving it paused indefinitely.
+
+Completed, Failed, Cancelled, Discarded, and a timed-out Stopped are final. Nothing restarts them, though you can start a fresh investigation seeded with what one learned. See [Continue in a new investigation](#continue).
+
+## Read an investigation \[#read]
+
+Open an investigation from the agent's **Investigations** step. It reads top to bottom: what the agent concluded, what set it off, then how it got there.
+
+### The summary \[#summary]
+
+A finished investigation opens with the agent's own account of what it found. An investigation that failed or was discarded carries the reason it ended instead of a conclusion, which is the first thing to read when a run did not work.
+
+The summary is what the agent wrote for you to read, so it is the part to read when you want the conclusion. Read the timeline when you want to check the conclusion.
+
+### The triggering signal \[#trigger]
+
+The triggering signal is the event that started the run. A webhook signal shows the payload the sending system posted. A log pattern signal shows the pattern the reducer detected and a sample log line that matched it. An investigation you started manually shows the context you typed.
+
+Read the signal when a conclusion surprises you. An agent reasoning from a payload whose fields it cannot interpret often produces a plausible but wrong summary, and the fix is usually the integration's schema description rather than the agent's prompt. See [_](/integrations/grepr-agent-webhooks#schema-description).
+
+### The timeline \[#timeline]
+
+The timeline is every step in order: what the agent was told, what it said, each tool it called with the arguments it passed, and what each tool returned. Tool output is collapsed, so you can scan the shape of a run and expand only the calls that matter. Each call reports how long it took.
+
+Read the timeline to answer why an agent concluded what it did. Two patterns are worth recognizing:
+
+* Repeated similar tool calls usually mean the agent is missing a capability or some knowledge, and is working around the gap. Consider enabling a skill that covers the task or using a better model.
+* A run that ends without a conclusion usually means it reached its turn or token limit. The last turn shows where it was.
+
+### Recorded actions \[#actions]
+
+An *action* is a consequential change the agent made outside its own sandbox: a pipeline version it applied, a pipeline change it proposed for review, or a write it made through a connected MCP integration. Reads are not actions, and neither is everything an agent can do from a shell, so treat the count as a record of the changes Grepr recognizes rather than a complete audit. Actions appear beneath the tool call that made them and are counted in the **Actions** column of the list, so you can find the investigations that changed something without reading any transcripts.
+
+Actions record successful changes, not attempts. A tool call that failed appears in the timeline but produces no action.
+
+## Guide a running investigation \[#guide]
+
+### Stop and resume \[#stop-resume]
+
+Stopping ends the agent's session and pauses the investigation. Work already in flight is abandoned rather than finished, so a tool call that was running might not complete. Everything the investigation had recorded up to that point is kept, which is what a resume continues from.
+
+To continue it, click **Resume**. You can add a message to steer it, such as naming the service it should focus on, or resume with no message to let it carry on. Stop and resume when an agent is heading the wrong way but its work so far is worth keeping.
+
+### Cancel \[#end-for-good]
+
+Cancelling ends an investigation for good. Use it when the run is not worth finishing. The transcript remains readable.
+
+To cancel several at once, select them in the list and cancel the selection. This is how you clear a backlog that built up, such as from a misconfigured source. Cancelling is permanent, and an investigation that has already finished is left alone.
+
+### Continue in a new investigation \[#continue]
+
+A finished investigation cannot be resumed, but you can start a new one seeded from it. The new investigation begins with the earlier conversation, and you can add a message to direct it, such as asking it to verify that a change worked.
+
+The seed carries what the agent and you said to each other, not the tool calls it made or the results they returned, and a long conversation is trimmed to its most recent part. Put anything the new investigation must not lose into the message you start it with.
+
+Use this to carry an investigation forward after you have acted on it, rather than starting from nothing and paying for the same discovery twice.
+
+## Find investigations \[#find]
+
+The list holds one row per investigation, with its identifier, what triggered it, its summary, when it was created, how long it ran and how long it waited in the queue, its state, and how many actions it recorded.
+
+Three filters narrow it:
+
+* **Status** limits the list to the states you select.
+* **Actions** separates investigations that recorded a change from those that did not.
+* **Trigger** limits the list to investigations started manually, by a webhook, or by a log pattern.
+
+Filter on recorded actions when you want to review what an agent has changed, and on failed status when you are diagnosing an agent that is not working.
+
+## Why an investigation was discarded \[#discarded]
+
+A discarded investigation was recorded but never ran. There are three reasons, and each has a different fix:
+
+| Reason | What to do |
+| --- | --- |
+| The agent was at its concurrency limit and set to discard extra signals. | Raise the concurrency limit, switch to queueing, or reduce what the source emits. |
+| A queued investigation waited longer than the maximum queue wait. | Raise or remove the maximum queue wait, or raise the concurrency limit so the queue drains faster. |
+| A token budget was exhausted. | Raise the budget that blocked it, or wait for the window to reset. Check which budget it was on the agent's page. |
+
+A rise in discarded investigations usually means a source is emitting more than the agent can handle. Reducing what the source emits keeps the signal you want, whereas raising the limits keeps the volume and increases the cost. See [_](/ai-agents/subscriptions#volume).
+
+## Review the pipeline changes an agent proposes \[#suggestions]
+
+An agent set to require human approval records each pipeline change it proposes as a *suggestion* on that pipeline, and changes nothing until you apply it. Suggestions are on the pipeline's **Suggestions** step, not on the agent, because the decision is about the pipeline.
+
+Each suggestion lists when it was proposed, what it changes, and the investigation that produced it. To decide, review the proposed change as a difference against the pipeline's configuration, and read the investigation that produced it to see the evidence the agent based it on.
+
+Then either apply it or reject it:
+
+* Applying re-verifies the change against the pipeline's configuration as it is now, not as it was when the agent proposed it, and a running pipeline then restarts to pick it up. A suggestion whose assumptions no longer hold is refused rather than applied blindly, and it stays pending, so you can retry it after the pipeline settles.
+* Rejecting leaves the pipeline untouched and closes the suggestion.
+
+Reviewing a suggestion changes nothing on the live pipeline, so read as many as you like before deciding. Suggestions do not expire, but an old one is more likely to be refused on apply, because the pipeline's configuration has likely drifted. Review them while they still match the pipeline.
+
+To let an agent apply its own changes instead, see [_](/ai-agents/capabilities#change-approval).
+
+## Read investigations from the CLI \[#cli]
+
+The Grepr CLI reads investigations, which is useful for auditing many runs at once or feeding them into your own tooling.
+
+```bash
+# List an agent's failed investigations
+grepr investigation:list --agent-id <agent-id> --status FAILED --page-size 10
+
+# Read one investigation's metadata, summary, and recorded actions
+grepr investigation:get <investigation-id>
+
+# Read the turns, including tool calls and their results
+grepr investigation:turns <investigation-id> --page-size 10
+
+# Export a transcript to a file
+grepr investigation:transcript <investigation-id> --all --output investigation.json
+```
+
+To follow a running investigation as it progresses, add `--follow` to `investigation:turns`. To learn more about the CLI, see [_](/cli).
+
+## Frequently Asked Questions
+
+### How do I start a Grepr AI agent investigation manually?
+
+On the agent's page, click Run investigation, optionally enter the context the agent should start from, and click Start investigation. Context is the only instruction beyond the agent's system prompt, so include the service, the time range, and the symptom.
+
+### What does a stopped investigation mean in Grepr?
+
+Stopped covers two situations. An investigation that is still waiting for instruction is paused and can be resumed, carrying on from where it left off while its sandbox is still there. If the sandbox is lost while it is paused, the resumed agent restarts from the triggering signals and the message you resume it with. One that waited too long without instruction has ended, and remains readable but is no longer resumable. The status icon tells the two apart.
+
+### Can I resume a completed Grepr AI agent investigation?
+
+No. Completed, failed, cancelled, discarded, and timed-out stopped investigations are final. You can start a new investigation seeded from the finished one, and add a message to direct it, such as asking it to verify that a change worked.
+
+### Why was my investigation discarded?
+
+There are three reasons: the agent was at its concurrency limit and set to discard extra signals, a queued investigation waited longer than the maximum queue wait, or a token budget was exhausted. The agent's page reports which token budget blocked it and when the window resets.
+
+### How do I review a pipeline change proposed by a Grepr AI agent?
+
+Suggestions appear on the pipeline's Suggestions step. Review the proposed change as a difference against the current configuration and read the investigation that produced it, then apply or reject it. Applying re-verifies the change against the pipeline as it is now, and a running pipeline restarts to pick it up. A suggestion that no longer verifies is refused and stays pending, leaving the pipeline untouched.

package/build/dist/docs-index/{21a13434-66af-4ab8-8c42-5fec34637bd4.txt → 1aa8bf5c-97c6-4079-8c61-7e80f82b07ee.txt}

@@ -4,6 +4,8 @@
 
 **Operation ID**: `create_2`
 **Summary**: Create an organization skill
+## Tags
+- Skills
 ## Request Body
 
 **Content-Type**: `application/json`

package/build/dist/docs-index/{b702f0a4-5140-4267-ae9f-64563d70405b.txt → 1b47a47f-b2a0-49b9-9737-2eb1a6dc6e92.txt}

@@ -31,6 +31,9 @@
 - name: double (optional)
   type: number
 
+- name: emptyObject (optional)
+  type: boolean
+
 - name: float (optional)
   type: number
 

package/build/dist/docs-index/1d7f601e-b4fc-47f4-841c-1d1d9f3c853d.txt

@@ -0,0 +1,117 @@
+Connect another system's MCP server to Grepr so your AI agents can call the tools it publishes.
+
+# Configure MCP server connections with a Grepr integration
+
+An MCP integration connects Grepr to a Model Context Protocol server, or MCP server, run by another system. After you create one, you can let a Grepr AI agent call the tools that server publishes, so the agent gains capabilities, such as reading an incident, querying a dashboard, posting to a channel, or opening a pull request.
+
+> MCP integrations, along with the rest of the Grepr AI agent features, are in a closed beta. To request access, contact <support@grepr.ai>.
+
+> This page is about Grepr calling another system's MCP server. For the opposite direction, where an AI agent, such as Claude, calls Grepr's own MCP server, see [_](/apis/mcp).
+
+## Requirements
+
+To create an MCP integration, you need:
+
+* A credential for the system you are connecting. See [Create an MCP integration](#create) for where to get it.
+
+## What an agent can do through a connected server \[#server-tools]
+
+The tools an agent gains depend on the server you connect:
+
+| Type | What an agent can do with it |
+| --- | --- |
+| Datadog MCP | Read monitors, dashboards, logs, and metrics from your Datadog organization. |
+| GitHub MCP | Read and change repository content, issues, pull requests, and workflow runs. |
+| PagerDuty MCP | Read and act on incidents, services, and schedules. |
+| Slack MCP | Read and post messages in the channels the token can reach. |
+
+Each integration has a server URL you set, so you can point one at a self-hosted or regional endpoint rather than the vendor's.
+
+Don't see an MCP in the list? Send a request to <support@grepr.ai>.
+
+## Create an MCP integration \[#create]
+
+1. On the **Integrations** page, next to the **MCP Servers** section heading, click **Add new**.
+2. In the **Add MCP Server** dialog, select the server from the **Type** menu.
+3. Complete the remaining fields, which depend on the type you selected.
+4. Click **Create**.
+
+You cannot change an integration's type after you create it. You can change its other fields at any time, and each investigation picks up the change when it starts.
+
+Every type has a **Name** field, which identifies the integration when you configure an agent, and an **MCP Server URL** field. The remaining fields are the credential the server authenticates with.
+
+The credential decides what the agent can do through that MCP. Grepr passes it through as you supply it, so give the token minimal access for what the agent needs. Select the tab for the MCP you are connecting.
+
+| Field | Value |
+| --- | --- |
+| **MCP Server URL** | `https://mcp.datadoghq.com/v1/mcp`, or your regional Datadog MCP endpoint. |
+| **API Key (DD-API-KEY)** | A Datadog API key. |
+| **Application Key (DD-APPLICATION-KEY)** | A Datadog application key. |
+
+Create both keys in Datadog under **Organization Settings**. An application key carries the authorization scopes that decide what the agent can read, so scope it to the data you want the agent to reach, such as monitors, dashboards, and logs. To learn more, see [API and Application Keys](https://docs.datadoghq.com/account_management/api-app-keys/) and [Authorization Scopes](https://docs.datadoghq.com/api/latest/scopes/) in the Datadog documentation.
+
+If you already use Datadog as a Grepr source or sink, this is a separate integration. Reusing the same keys is fine. See [_](/integrations/datadog).
+
+| Field | Value |
+| --- | --- |
+| **MCP Server URL** | `https://api.githubcopilot.com/mcp/`, or your GitHub Enterprise MCP endpoint. |
+| **Personal access token** | A GitHub personal access token. |
+
+Create the token in GitHub under **Settings** > **Developer settings** > **Personal access tokens**. A fine-grained token is the better choice, because you can limit it to the repositories the agent works in.
+
+Grant the token access to the repository content, issues, pull requests, and workflow runs the agent needs. An agent that only reads code needs read access alone, and an agent that opens pull requests needs write access to contents and pull requests. To learn more, see [Managing your personal access tokens](https://docs.github.com/en/authentication/keeping-your-account-secure/managing-your-personal-access-tokens) in the GitHub documentation.
+
+| Field | Value |
+| --- | --- |
+| **MCP Server URL** | `https://mcp.pagerduty.com/mcp`, or your PagerDuty MCP endpoint. |
+| **Account URL** | Your PagerDuty account URL, such as `https://<your-org>.pagerduty.com`. Optional. |
+| **API Key** | A PagerDuty API key. |
+
+Create the key in PagerDuty under **Integrations** > **API Access Keys**. A read-only key lets an agent read incidents, services, and schedules, and a full-access key also lets it acknowledge or resolve incidents, so choose the one that matches what you want the agent to do. To learn more, see [API Access Keys](https://support.pagerduty.com/main/docs/api-access-keys) in the PagerDuty documentation.
+
+Grepr uses the **Account URL** to build links back to incidents in the actions an agent records, so set it if you want those links to resolve.
+
+| Field | Value |
+| --- | --- |
+| **MCP Server URL** | `https://mcp.slack.com/mcp`, or your Slack MCP endpoint. |
+| **User token** | A Slack user token, which begins with `xoxp-`. |
+
+Create a Slack app in your workspace, add the user token scopes the agent needs, then install the app to get the token. Grant `channels:read` and `channels:history` for an agent that reads channels, and add `chat:write` for one that posts. The agent reaches only the channels the token's user is in, so invite that user to the channels you want covered. To learn more, see [Access tokens](https://docs.slack.dev/authentication/tokens) in the Slack documentation.
+
+## Choose which tools an agent can call \[#allowed-tools]
+
+Creating an integration does not give any agent access to it. You enable an integration on each agent, and you choose which of the server's tools that agent can call. Two agents can therefore share one integration with different tool allowances.
+
+The tool allowance lives on the agent, not on the integration. To set it, go to the agent's **Capabilities** step, find the integration in the **MCP integrations** table, and edit its allowed tools. Grepr reads the tool list from the server, marks each tool as read only or writing, and lets you allow all tools or only the ones you select. To learn more, see [_](/ai-agents/capabilities#mcp-integrations).
+
+An agent can enable at most one GitHub MCP integration. The agent's `github_code` tool also requires an enabled GitHub MCP integration, because that is how it reaches source code.
+
+## Grant team access \[#team-access]
+
+When you have teams in your Grepr organization, you can grant access to the integration to one or more of those teams. To configure team access when you create or edit an integration:
+
+1. In the **Grant Team Access** section, click the plus sign icon (+).
+
+2. Select the team or teams that should be granted access to the integration.
+
+3. Click **Create**.
+
+To learn more, see [Manage teams in the Grepr platform](/admin/manage-teams) and [Permissions in the Grepr platform](/grepr-platform/permissions).
+
+## Frequently Asked Questions
+
+### Which MCP servers can Grepr AI agents connect to?
+
+You set each integration's server URL, so you can point one at a self-hosted or regional endpoint. Grepr adds integrations continuously, so contact support\@grepr.ai to get an agent connected to the server you use.
+
+### How do I limit which MCP tools a Grepr AI agent can call?
+
+The allowance is set on the agent, not on the integration. On the agent's Capabilities step, find the integration in the MCP integrations table and either allow all of the server's tools or select individual tools. Grepr reads the tool list from the server and marks each tool as read only or writing.
+
+### What is the difference between an MCP integration and the Grepr MCP server?
+
+An MCP integration lets a Grepr AI agent call another system's MCP server. The Grepr MCP server is the reverse: it lets an AI assistant such as Claude or Claude Code call Grepr to list pipelines, query logs, and propose pipeline changes.
+
+### How do I change an MCP integration after creating it?
+
+Edit it from the three-dot menu on the integration card. Investigations that start after the change use the new settings, and one already running keeps the settings it started with. An integration's type is fixed when you create it, so to move to a different server type, create a new integration.

package/build/dist/docs-index/{543bd3c3-253e-4b2e-871a-8d2604a00c01.txt → 2176793a-1953-4224-a0a1-03ef3e17d3ca.txt}

@@ -4,6 +4,8 @@
 
 **Operation ID**: `get_3`
 **Summary**: Get a skill
+## Tags
+- Skills
 ## Parameters
 
 - **id** (required) - path

package/build/dist/docs-index/{0744cf21-0407-4ef7-9d38-e82f3f7658ce.txt → 2b0504e4-45fb-41d8-82df-fa12e7f3f019.txt}

@@ -20,15 +20,19 @@ To modify the configuration settings in the UI, on the overview page for your pi
 
 ## Configure how messages are grouped \[#grouping-configuration]
 
-The **Grouping Configuration** section controls how incoming messages are partitioned into independent groups before pattern detection, and the level of similarity messages must meet to be considered part of the same pattern.
+Grouping controls how incoming messages are partitioned into independent groups before pattern detection, and the level of similarity messages must meet to be considered part of the same pattern.
 
-### Group-by values \[#group-by-configuration]
+### Group messages by a field \[#group-by-configuration]
 
-To control how the reducer partitions messages, enter a comma-separated list of tag keys and attribute paths in the **Group-by values** field. Messages are aggregated separately for each unique combination of values across the listed tags and attributes, so patterns from different services, hosts, or other dimensions are never merged. For example, the value `service, host, @http.url.path` aggregates messages independently for each unique combination of `service`, `host`, and the `http.url.path` attribute.
+Messages are aggregated separately for each unique combination of values across the fields you group on, so patterns from different services, hosts, or other dimensions are never merged. Grouping on `service`, `host`, and the `http.url.path` attribute aggregates messages independently for each unique combination of those three values.
 
-To specify attributes, prefix the attribute path with `@` and use dot notation for nested attributes. For example: `@http.url.path`. Enter tag keys using just the key name without any prefix.
+To group on a field, on the pipeline's **Reducer** step, click **Edit** on the **Fields** card, find the field, and set its behavior to **Match or split**. A field with this behavior is kept out of aggregation, so messages whose values for it differ are never merged into one pattern.
 
-Use this setting to retain the values of important fields by excluding them from aggregation. For example, to retain the values of high-cardinality identifiers, such as user IDs. To prevent a field from being aggregated, parse the field into an attribute using the **JSON Parser** or **Grok Parser** steps earlier in the pipeline, then add that attribute to the **Group-by values** field. See [Transform JSON strings into JSON objects](/transforms/json-parsing) and [Parse log messages to enrich log events with the Grok parser](/transforms/grok).
+Attribute paths are written with an `@` prefix and dot notation for nested attributes, such as `@http.url.path`. Tag keys are written as the key name alone.
+
+Use grouping to retain the values of important fields by excluding them from aggregation, such as high-cardinality identifiers like user IDs. To keep a field that is currently inside the message, parse it into an attribute or a tag with the **JSON Parser** or **Grok Parser** step earlier in the pipeline, then group on that field. See [Transform JSON strings into JSON objects](/transforms/json-parsing) and [Parse log messages to enrich log events with the Grok parser](/transforms/grok).
+
+Grouping also decides how a summary can be routed, because a summary carries the tag values of the fields it was grouped on. To use grouping to send each group's logs to a different destination, see [_](/solution-guides/route-logs-to-several-accounts).
 
 ### Similarity threshold (%)
 
@@ -165,6 +169,16 @@ The **Default Strategy** section defines the strategies that apply to every attr
 
 As with path-specific strategies, you can add multiple default strategies. When you add multiple default strategies, each strategy produces a suffixed attribute in the summary, and the first strategy also writes to the base attribute name.
 
+## Send new-pattern signals to AI agents \[#agent-signals]
+
+The reducer identifies the patterns in your logs, which also makes it the first place a pattern that has never occurred before becomes visible. You can have the pipeline report each new pattern to your Grepr AI agents, so an agent investigates behavior that is new in your systems without you writing an alert for it first.
+
+To turn this on, on the reducer step of your pipeline, open the **Advanced** settings and select **Emit new-pattern signals to AI agents**.
+
+Turning it on emits nothing by itself. A signal reaches an agent only when that agent is subscribed to the pipeline, and Grepr refuses a subscription to a pipeline that has this setting off. So turn it on first, then subscribe the agent.
+
+Each pattern signals an agent once rather than on every occurrence, for as long as the reducer keeps that pattern in its state, so a pattern that keeps matching does not keep starting investigations. To learn how signals reach an agent and how to bound the volume, see [_](/ai-agents/subscriptions).
+
 ## Frequently Asked Questions
 
 ### What is the aggregation window?

package/build/dist/docs-index/2bbb5667-d141-4575-a6cb-8ada2fe7845d.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/{c085c9f3-fc18-44c0-be7a-386542fafd1f.txt → 2d622e6d-940c-4972-b448-4d6ac58be5a3.txt}

@@ -10,6 +10,21 @@ This page provides an overview of the observability platform and cloud storage i
 
 Grepr supports Amazon S3 for storing, querying, and backfilling raw data. See [Host a Grepr data lake with the Amazon S3 integration](/integrations/aws-s3).
 
+## Supported integrations: AI agents \[#supported-ai-integrations]
+
+The following integrations support Grepr AI agents. None of them are a pipeline source or sink, so they do not appear in the source and sink tables on this page.
+
+| Integration | What it provides |
+| --- | --- |
+| LLM provider | The generative model an agent reasons with and the embedding model agent memory uses. |
+| MCP server | The tools of another system that an agent can call. |
+| Grepr Agent webhook | An endpoint that turns events from another system into investigations. |
+| Vector index | Storage for the agent memory search index. |
+
+To configure these, see [_](/integrations/llm), [_](/integrations/mcp), [_](/integrations/grepr-agent-webhooks), and [_](/ai-agents/memory#vector-index).
+
+Grepr adds integrations continuously. To get an agent connected to the provider you use, contact <support@grepr.ai>.
+
 ## Supported integrations: observability platforms \[#supported-observability-integrations]
 
 A Grepr integration provides the configuration details needed to connect to an external system, such as an observability platform. Integrations support moving data into Grepr and between Grepr and external systems by enabling the creation of sources and sinks in your Grepr pipelines.

package/build/dist/docs-index/{3e919530-12b0-4e4f-a02a-811ba33b9c03.txt → 32a6701f-727e-41ee-a148-1a1f49865270.txt}

@@ -38,6 +38,14 @@ API key is invalid
 
 No such webhook integration
 
+### 409
+
+The integration has no live target agent to start
+
 ### 413
 
 Body exceeds the size limit
+
+### 503
+
+At least one target agent could not be started for a transient reason; retry

package/build/dist/docs-index/3c77c3ff-1b75-482d-9315-1dc85ff731de.txt

@@ -0,0 +1,136 @@
+Control what a Grepr AI agent can reach with a service account, tools, skills, and MCP integrations, and whether its pipeline changes need approval.
+
+# Control what an AI agent can do
+
+An agent's reach is bounded in layers, and a capability has to be allowed by every layer to work:
+
+1. The **service account** the agent acts as. Its roles are the outer boundary and cap everything the agent can reach in Grepr.
+2. The **tools and skills** you enable. These narrow the agent to specific operations within what the service account permits.
+3. The **MCP integrations** you enable, and the tools you allow on each. These decide what the agent can reach in other systems.
+
+A fourth setting, the change approval mode, decides whether the agent can make automatic changes to your pipeline.
+
+These settings are on the agent's **Capabilities** step, and on the matching step of the create wizard.
+
+## Choose the service account an agent acts as \[#service-account]
+
+Every call an agent makes to Grepr authenticates as the service account you select in the **Service account** field. The service account's roles decide which pipelines, datasets, and integrations the agent can read and write to.
+
+The service account is the boundary that holds even if a tool grant is over-permissive. An agent with the pipeline editing tool but a service account that can only view jobs cannot change a pipeline. Grant the narrowest role that lets the agent finish its job. To create one, see [_](/admin/service-accounts).
+
+If the **Service account** menu is empty, create a service account before you continue.
+
+## What every agent can already do \[#sandbox-baseline]
+
+Each investigation runs in its own sandbox, and inside that sandbox an agent can:
+
+* Run shell commands.
+* Run Python for local analysis and scripting.
+* Query files it downloaded with DuckDB.
+* Read, create, and edit files in its own workspace.
+
+These are part of the sandbox and cannot be turned off. They act only on the sandbox, which is discarded when the investigation ends, so they do not reach your data or your pipelines. Everything that does reach Grepr is granted separately, as described next.
+
+## Grant access to Grepr with tools and skills \[#grepr-access]
+
+The **Grepr access** section is where you decide what the agent can do. You grant access in two ways, and most agents use both:
+
+* Enable a skill, which gives the agent guidance for a task and, when the skill needs them, the tools that task requires.
+* Pin an individual tool, which grants that tool with no accompanying guidance.
+
+Prefer skills. A skill tells the agent how to use what it grants, so an agent with a skill usually needs fewer turns than one holding the bare tool. Pin a tool when you want a capability that no skill attached covers.
+
+### Abilities and reference skills \[#skill-kinds]
+
+Skills are grouped by whether enabling one is a permission decision:
+
+* **Abilities** carry tools. Enabling one grants the agent the operations that skill needs, so treat it as granting access.
+* **Reference** skills carry only knowledge. Enabling one changes what the agent knows, never what it can do, so it is safe to enable freely.
+
+To read what a skill covers and what it grants before you enable it, open its detail from the selector. To learn what skills exist and how to write your own, see [_](/ai-agents/skills).
+
+### How much a skill grants \[#grant-scope]
+
+How wide a skill's grant is depends on its scope, and the difference matters when you are reasoning about least privilege:
+
+* A **platform skill**, which Grepr maintains, grants exactly the operations its definition lists. A skill that needs only to preview a pipeline change gets the preview operation and not the one that applies it.
+* An **organization skill**, which you create, grants the whole *tool family* behind each tool you approve on it, meaning every operation that tool covers rather than only the ones the skill uses. Approving the pipeline editing tool on your own skill grants everything that tool covers, not only the part your instructions use.
+
+So an organization skill is as broad as the tools you approve on it. To keep a grant narrow, approve fewer tools on the skill rather than relying on the skill's instructions to limit the agent.
+
+Enabling a tool directly always grants its whole family, the same way an organization skill does.
+
+### Tool reference \[#tool-table]
+
+| Tool | What it lets the agent do |
+| --- | --- |
+| `query_logs` | Query the logs in your Grepr datasets. |
+| `get_pipeline` | Read the configuration of your pipelines and templates. |
+| `edit_pipeline` | Propose a change to a pipeline's configuration, and preview a change before proposing it. |
+| `grok` | Build and test Grok parsers. |
+| `datasets` | List, read, and manage your Grepr datasets. |
+| `integrations` | List and read your Grepr integrations. |
+| `docs` | Search the Grepr documentation and validate SQL. |
+| `backfill` | Replay logs from the data lake to a vendor destination. |
+| `investigations` | Read agent configuration, past investigations, and their transcripts. |
+| `github_code` | Clone, edit, and publish source repositories. Requires an enabled GitHub MCP integration. |
+
+An agent's pipeline changes are scoped to a pipeline's Grok parsers and its SQL transforms, so granting the pipeline editing tool keeps the rest of the pipeline configuration out of the agent's reach. Both are add-only. An agent can add a Grok rule or add a SQL transform, and it cannot change or remove one that is already there, so its proposals accumulate alongside your configuration rather than rewriting it.
+
+A SQL transform an agent adds is a filter and nothing further. It reads the pipeline's logs and selects them unchanged against a single condition, so it cannot join, aggregate, read a dataset, register a function, or keep state. It routes the events it matches to the agent signal sink, which you configure yourself when you set the pipeline up. An agent can add routes to that sink, and it cannot create, change, or remove the sink. That limit is on what an agent adds by itself. A SQL output you route to the agent signal sink yourself carries no such restriction, so you can build the event an agent receives however you need. See [_](/ai-agents/subscriptions#agent-signal-sink).
+
+The tools an agent uses to record and search its memory are not in this list. They are granted by the agent's memory settings instead, so that turning memory on is the single decision that controls them. See [_](/ai-agents/memory).
+
+## Let an agent call an MCP server's tools \[#mcp-integrations]
+
+The **MCP integrations** section lists the MCP integrations in your organization and which of their tools the agent can use. Two agents can share one integration with different tool access enabled.
+
+Edit the integration's allowed tools and choose either every tool the server publishes or only the ones you select. Grepr reads the tool list from the server and marks each tool as read only or writing; for example, you can allow an agent to read incidents without allowing it to change them.
+
+Allowing every tool means the agent gains any tool the server adds later, which is convenient for a read-only server and worth avoiding for one that can make changes. Selecting individual tools keeps the enabled tools fixed until it is manually changed.
+
+Two rules apply to GitHub:
+
+* An agent can enable at most one GitHub MCP integration.
+* The `github_code` tool needs an enabled GitHub MCP integration, because that integration is how it reaches source code.
+
+To create an integration, see [_](/integrations/mcp).
+
+## Decide whether pipeline changes need approval \[#change-approval]
+
+An agent that decides a pipeline needs a configuration update does not edit it directly. It submits the change, and the **Pipeline changes** setting decides what happens next:
+
+| Mode | What happens when the agent proposes a change |
+| --- | --- |
+| **Require human approval** | Grepr records the change as a suggestion on the pipeline. Nothing changes until you review and apply it. |
+| **Auto-apply** | Grepr verifies the change and applies it. A running pipeline restarts to pick it up. No person is involved. |
+
+**Require human approval** is the default, and it is the right setting while you are learning how an agent behaves. Auto-apply an agent's changes only after its suggestions have consistently been ones you would have made yourself.
+
+Grepr enforces the mode at the operation level, so while an agent can always preview pipeline changes, it cannot bypass **Require human approval** to apply them.
+
+A change that lands on a running pipeline restarts it, which interrupts processing briefly.
+
+To review suggestions, see [_](/ai-agents/investigations#suggestions).
+
+## Frequently Asked Questions
+
+### How do I limit what a Grepr AI agent can reach?
+
+Reach is bounded in layers. The service account the agent acts as is the outer boundary and caps everything it can reach in Grepr. Within that, the tools and skills you enable narrow it to specific operations, and the MCP integrations you enable with their allowed tools decide what it can reach in other systems.
+
+### What can a Grepr AI agent do without any tools enabled?
+
+Inside its own sandbox it can always run shell commands and Python, query downloaded files with DuckDB, and read and write files in its workspace. These act only on the sandbox, which is discarded when the investigation ends, and they do not reach your data or pipelines.
+
+### What is the difference between an ability and a reference skill?
+
+An ability carries tools, so enabling one grants the agent the operations that skill needs and is a permission decision. A reference skill carries only knowledge, so enabling one changes what the agent knows but never what it can do.
+
+### Do platform skills and organization skills grant the same access?
+
+No. A platform skill grants exactly the operations its definition lists, which can be narrower than a whole tool. An organization skill grants the whole tool family behind each tool you approve on it, so keep its grant narrow by approving fewer tools.
+
+### Can a Grepr AI agent change my pipeline without approval?
+
+Only when you set its change approval mode to Auto-apply. The default, Require human approval, records every proposed change as a suggestion for you to review. Grepr enforces the mode server-side, so an agent has no route around it whatever its instructions say.