@grepr/cli 1.11.5-403bfd0 → 1.11.5-4c372c1

package/build/dist/docs-index/4ab1ec6c-5988-4d6e-81a8-a7ac8a63704a.txt

@@ -0,0 +1,124 @@
+Use the skills Grepr ships and write your own, so a Grepr AI agent loads the guidance and tools a task needs only when that task comes up.
+
+# Extend agents with skills
+
+A *skill* is a directory of instructions that an agent loads only when the task it covers comes up. Grepr ships a set of skills, and you can write your own for the procedures your organization follows.
+
+Skills exist because an agent's system prompt is read at the start of every investigation, so anything you put there costs tokens on every run whether it is relevant or not. Guidance that applies to one kind of task belongs in a skill. A skill can also carry the tools its task needs, which is why enabling one is often how you grant a capability rather than pinning the tool yourself.
+
+Skills are on the **Skills** page, which shares the left rail with **Agents**.
+
+## Skill scopes \[#scopes]
+
+| Scope | Where it comes from | Who can change it |
+| --- | --- | --- |
+| Platform | Maintained by Grepr and available to every agent. | Read only. |
+| Organization | Created and managed by you. | Anyone with the Edit permission on integrations. |
+
+The scope also changes how much a skill grants. To learn more, see [_](/ai-agents/capabilities#grant-scope).
+
+## Platform skills \[#platform]
+
+Grepr maintains a catalog of platform skills, available to every agent. Read the catalog on the **Skills** page, where each skill lists what it covers and which tools it grants. The catalog changes as Grepr adds skills, so treat the page as the authoritative list.
+
+The skills fall into three groups:
+
+* **Investigation approaches.** How to work through a kind of problem. Incident Response covers a log pattern the pipeline has just flagged, and Triage Security Pattern covers a first-seen pattern that might be security relevant.
+* **Pipeline changes.** How to change a pipeline safely. Test Pipeline Change is the safety procedure, which plans a change, reads the preview of the difference, and replays the investigation's own sample logs through the proposed pipeline before submitting it. Others cover a specific kind of change, such as tuning Grok parsing or authoring a SQL transform.
+* **Grepr reference and commands.** What an agent needs to know to use Grepr itself, such as the processing model, the operations reference, and how to query the data lake or read past investigations.
+
+Most agents want an investigation approach plus Test Pipeline Change. The approach gives the agent a way to work through its signals, and Test Pipeline Change stops it submitting a pipeline change it has not verified against real samples.
+
+> An agent proposes changes to a pipeline's Grok parsers and its SQL transforms. The catalog also holds skills for changes you make yourself with the Grepr CLI, such as masking and filtering, so a skill's presence does not by itself mean an agent will make that change. To learn more, see [_](/ai-agents/capabilities#tool-table).
+
+## Create an organization skill \[#create]
+
+1. On the **Skills** page, in the **Organization skills** section, click **Add New Skill**.
+2. Enter a **Display name**. Grepr derives the skill's identifier from this name, and the identifier must be unique across your organization's skills and the platform skills.
+3. Write the skill's files, starting with `SKILL.md` at the root. See [What SKILL.md must contain](#skill-md).
+4. Select the tools the skill needs under **Approved tools**. See [Approve the tools a skill needs](#approved-tools).
+5. Save the skill.
+
+Organize a skill the way you would a short runbook. Keep `SKILL.md` to the approach and put long reference material, such as a table of service names or an example payload, in separate files the agent reads when it needs them.
+
+### What SKILL.md must contain \[#skill-md]
+
+Every skill has a `SKILL.md` file at its root, and that file must begin with front matter containing a `description`:
+
+```markdown
+---
+description: How to respond to a checkout service latency alert - which dashboards to read, which dependencies to rule out, and when to page the on-call engineer. Use when a signal names the checkout service.
+---
+
+# Responding to checkout latency
+
+...
+```
+
+The description is the only part of a skill an agent reads before deciding whether the skill is relevant, so write it to answer two questions: what the skill covers, and when to use it. A description that only names the topic leaves the agent guessing, while one that ends with a sentence starting "Use when" tells it exactly when to load the skill. The description can be up to 1,024 characters.
+
+The body of `SKILL.md` is read after the agent loads the skill, so put the approach there.
+
+### Approve the tools a skill needs \[#approved-tools]
+
+The **Approved tools** field is what grants tools to an agent that enables this skill. Select only the tools the skill's procedure actually uses.
+
+> In an organization skill, the **Approved tools** field is what grants access. An `allowed-tools` entry in the front matter of your `SKILL.md` does not grant anything, so a skill whose front matter lists tools but whose **Approved tools** field is empty grants nothing.
+
+Each tool you approve grants its whole family to any agent that enables the skill, so approving a tool is a permission decision about the agent, not only about the skill. To keep the grant narrow, approve fewer tools. A skill that needs no tools at all grants none, and is safe to enable on any agent.
+
+## Enable a skill on an agent \[#enable]
+
+Enable skills on the agent's **Capabilities** step, where they are grouped into abilities, which carry tools, and reference skills, which carry only knowledge. To learn more, see [_](/ai-agents/capabilities#grepr-access).
+
+A skill takes effect on investigations that start after you save the agent.
+
+## Update a skill \[#update]
+
+Editing a skill replaces its whole directory, so the version you save is the version agents get. Grepr tracks a revision for each skill and refuses a save based on a revision that is no longer the latest, which stops one save overwriting another.
+
+Every agent with the skill enabled picks up the new revision on its next investigation, so a change to a widely enabled skill reaches many agents at once. Change a shared skill the way you would change shared code.
+
+## Delete a skill \[#delete]
+
+Grepr refuses to delete a skill that any active agent still has enabled. Remove it from each of those agents on their **Capabilities** step, then delete it.
+
+Deleting an organization skill archives it, and investigations that already ran keep their transcripts unchanged.
+
+An agent that loses a skill also loses the tools that skill granted, so before you remove a skill that carried tools, decide whether each agent still needs them and grant them another way if so. See [_](/ai-agents/capabilities#grepr-access).
+
+## Limits \[#constraints]
+
+| Limit | Value |
+| --- | --- |
+| Files in one skill | 25 |
+| Directories in one skill | 10 |
+| Directory levels below the root | 3 |
+| Characters in a file path | 240 |
+| Size of one file | 256 KiB |
+| Total size of one skill | 1 MiB |
+| Characters in a description | 1,024 |
+| Skills enabled on one agent | 20 |
+| Total size of the skills enabled on one agent | 8 MiB |
+
+## Frequently Asked Questions
+
+### What is a Grepr AI agent skill?
+
+A skill is a directory of instructions that an agent loads only when the task it covers comes up, and which can also grant the tools that task needs. Guidance that applies to one kind of task belongs in a skill rather than in the system prompt, which is read on every investigation.
+
+### What skills does Grepr provide?
+
+Grepr maintains a catalog of platform skills available to every agent, covering investigation approaches such as Incident Response, pipeline-change procedures such as Test Pipeline Change, and reference material about Grepr itself. Read the catalog on the Skills page, which is the authoritative list because it changes as Grepr adds skills.
+
+### How do I grant tools through my own skill?
+
+Select them in the Approved tools field on the skill. An allowed-tools entry in your SKILL.md front matter does not grant anything in an organization skill, so a skill whose front matter lists tools but whose Approved tools field is empty grants nothing.
+
+### What must a SKILL.md file contain?
+
+Front matter with a description of up to 1,024 characters. The description is the only part an agent reads before deciding whether the skill is relevant, so it should say what the skill covers and when to use it. The body holds the approach and is read after the agent loads the skill.
+
+### How many skills can one Grepr AI agent use?
+
+Up to 20 skills, with a combined size of 8 MiB. A single skill can hold 25 files across 10 directories, no more than 3 levels below the root, up to 256 KiB per file and 1 MiB in total.

package/build/dist/docs-index/{f0094c52-59f8-44e3-9659-b6d6956bfcef.txt → 4b07deb7-a55b-4e75-a5e9-3c5a8a61c9ea.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/5cd8fa97-fe51-4707-9659-62945ff66941.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/5fd814e6-8b13-4959-a9bc-a24a941e05e6.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/{747e273f-1ef8-4ebc-9a6d-f148d6f53fae.txt → 6ec31ecc-683a-486d-ac7a-db2770ab1f57.txt}

@@ -60,6 +60,15 @@ Grepr parses structured logs into an attribute document. Address a single attrib
 
 The shorthand reads one value out of the parsed document. The `attributes` column is the whole document, so use `@` when you want a field and `attributes` when you want the object itself.
 
+An attribute name is a dotted path of letters, digits, and underscores. A hyphen or a slash can join characters inside a segment, so `@trace-id` and `@app.kubernetes.io/name` are each one name. Because `-` and `/` are name characters, put whitespace around them when you mean subtraction or division: write `@bytes / 1024`, not `@bytes/1024` (which reads `bytes/1024` as one name). Every other character ends the name, so `@status=500` and `@duration_ms*2` work without spaces.
+
+To read a key that uses any other character, such as a space, comma, or bracket, reference it through the `attributes` column with a single-quoted key in brackets. The bracketed key can be any string, dots included, and names exactly one key; double a single quote to include one. Add one bracketed key per level of a nested path:
+
+```sql
+attributes['service.status']
+attributes['special outer key']['special inner key']
+```
+
 An attribute has no declared type, because two logs in the same dataset can carry different types under the same name. Grepr infers a type from how you use the value, so `SUM(@duration_ms)` reads it as a number and `LOWER(@user.email)` reads it as a string.
 
 Cast the attribute when you need a specific type or precision, and when you sort:
@@ -72,6 +81,8 @@ CAST(@duration_ms AS BIGINT)
 MIN(CAST(@duration_ms AS DOUBLE))
 ```
 
+Grepr reads a numeric attribute as a 64-bit floating point value, which represents whole numbers exactly only up to 9,007,199,254,740,992. Above that limit, two different whole numbers can compare as equal. Store large identifiers such as trace ids and 64-bit request ids as strings, which always match exactly. If an attribute already holds a large whole number, cast it to `BIGINT` to compare it exactly.
+
 > Sorting by an attribute you have not cast sorts it as text, so `100` sorts before `99`. Cast it to sort numerically.
 
 A path segment is a name or a number, and the segments are separated by dots.

package/build/dist/docs-index/710f7b65-8301-464e-b833-9ecba9d72887.txt

@@ -0,0 +1,78 @@
+Two ways to send logs to several vendor accounts, by creating a pipeline for each group or by grouping the reducer and filtering each sink.
+
+# Route logs to several vendor accounts
+
+Your logs do not all belong in the same place. Separate teams, environments, or business units each own an account in your observability platform, and a log has to reach the account that owns it. Each account you send to is its own Grepr integration.
+
+A Grepr pipeline is a free-form processing graph rather than a fixed shape, so you can arrange this in more than one way. Here are two examples, and you can combine them.
+
+## Create a pipeline for each group \[#pipeline-per-group]
+
+Create one pipeline for each group of logs that belongs together, filter its source to that group, and give it the sink for that group's account.
+
+Each pipeline summarizes only its own logs, so you can tune each one on its own. Choose this when the groups need different configurations, or when you want them isolated from each other.
+
+To create a pipeline, see [_](/tutorials/first-pipeline). To limit what one ingests, see [_](/transforms/filter-events).
+
+## Group the reducer and filter each sink \[#grouped-sinks]
+
+Run a single pipeline, add a sink for each account, and filter each sink to that account's logs. Choose this when the groups have the same configuration, and you would rather manage one pipeline than several.
+
+Routing rests on a *routing key*, which is a field whose value names the account a log belongs to, such as `account` or `team`. Two settings act on it: the reducer groups on the key, and each sink filters on it.
+
+Grouping is what makes the filtering correct. A summary carries the values of the fields it was grouped on, so grouping on the routing key gives every summary exactly one account, and each sink's filter then matches its own account and no other.
+
+> Configure the grouping before you add the sinks, because leaving it out fails quietly. Without the routing key in the group-by, logs bound for different accounts aggregate together. A tag then carries every value the merged messages had, so every account receives the same summary, reporting counts that include the other accounts' logs. An attribute is merged instead, and the default merge strategy replaces values that differ with a wildcard, so no filter matches and the summary reaches no account.
+
+### Step 1: Put the routing key on every log \[#step1-routing-key]
+
+The routing key has to be on each log before the reducer sees it, holding one value per account. If your collectors already tag logs with the owning team or environment, use that tag. If the value is inside the message, parse it into an attribute or a tag first with the Grok parser or the JSON parser. See [_](/transforms/grok) and [_](/transforms/json-parsing).
+
+A tag and an attribute both work as the routing key. Choose one whose values are few and stable, because each value aggregates separately. Decide what happens to logs carrying no value for the key, which match no filter and so reach no account: give them a default value when you parse, or add a sink that catches them.
+
+### Step 2: Group the reducer on the routing key \[#step2-group]
+
+1. On the pipeline's **Reducer** step, click **Edit** on the **Fields** card.
+2. If the routing key is listed, set its **Behaviour** to **Match or split**.
+3. If it is not listed, enter it in the **Add field** row, set the **Behaviour** to **Match or split**, and click **Add**.
+4. Click **Save**.
+
+The **Match or split** behavior keeps a field out of aggregation, so messages whose values differ are never merged into one pattern. Enter tag keys plainly, and prefix attribute paths with `@`. An attribute is merged as well as grouped, and the default merge strategy keeps the value that every message in the group agrees on. If you set a different merge strategy for the routing attribute, check that it preserves that value rather than combining or discarding it. See [_](/transforms/reducer/configuration#attribute-configuration).
+
+### Step 3: Create a Grepr integration for each account \[#step3-integrations]
+
+Create one Grepr integration for each account you send to. An integration authenticates to a single account, so its credential is what decides where its logs land. Name each integration after its account, because that name is what you select when you add the sink. See [_](/integrations).
+
+### Step 4: Add a filtered sink for each account \[#step4-sinks]
+
+Repeat for each account:
+
+1. On the pipeline's **Sinks** step, click **Add sink**.
+2. In the **Sink** menu, select the integration for the account. Grepr fills in a **Name**, which you can change.
+3. In the **Query language** menu, select the syntax you want to write the filter in.
+4. In the **Filter Query** field, enter a query that matches only that account's logs, such as `team:platform`.
+5. Click **Add**, then save the pipeline.
+
+A sink with an empty filter forwards everything, so give each sink a filter query that matches it to one account. A sink's card reports its filter and shows **All messages** when it has none, which is how you spot one you missed. The filter runs on everything the reducer emits, so summaries, samples, passthrough messages, and exceptions all follow the same routing. To learn about the filter syntax, see [_](/queries/datadog) and [_](/queries/new-relic).
+
+## Frequently Asked Questions
+
+### Can one Grepr pipeline send logs to several accounts of the same vendor?
+
+Yes. Add one sink for each account, each pointing at that account's integration, and give each sink a filter that matches only that account's logs. Group the reducer on the same routing key the filters use, so that each summary belongs to exactly one account.
+
+### Why does the reducer need to group on the routing key?
+
+Without it, logs for different accounts aggregate together and the summary no longer identifies one account. If the key is a tag, the summary carries every value the merged messages had, so each account's filter matches it and every account receives counts that include the other accounts' logs. If the key is an attribute, the default merge strategy replaces the differing values with a wildcard, so no filter matches and the summary reaches no account.
+
+### Should I create a pipeline for each account or filter the sinks of one pipeline?
+
+Create a pipeline for each group when the groups need different reduction settings or different exceptions, or when you want them isolated. Filter the sinks of one pipeline when the groups share one reduction policy and you would rather keep a single pipeline to change.
+
+### What happens to logs that have no value for the routing key?
+
+They match no sink's filter and reach no vendor account. Give them a default value when you parse the routing key, or add a sink whose filter matches them so they land somewhere you can see.
+
+### Does a sink filter apply to summarized logs as well as raw ones?
+
+Yes. The filter runs on everything the reducer emits, so summaries, samples, passthrough messages, and exceptions all follow the same routing.

package/build/dist/docs-index/717153a6-7050-4f51-bc38-a9b787da2088.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/{e88838f0-7430-4368-998d-a37e12cc7c99.txt → 71cc906f-e117-47c3-85f1-20fad36b16c9.txt}

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

package/build/dist/docs-index/{47b83d30-b872-47b1-9792-ebb73550f5e8.txt → 731c2e17-c94d-4672-bc43-391ccd656b4b.txt}

@@ -11,7 +11,7 @@
   type: `ReadOrgConstraints`
 
 - name: featureFlags (optional)
-  type: array of enum: `DATADOG_BROWSER_LOGS_INTEGRATION`, `METRICS_SOURCE`, `S3_LOGS_FILE_SOURCE`, `PIPELINE_TEMPLATES`, `AI_WORKFLOWS`, `SEARCH_ICEBERG_SOURCE`, `QUERY_JOBS`, `AUTH0_SSO_CONNECTION`, `TRINO_QUERY_ENGINE`, `UNKNOWN`
+  type: array of enum: `DATADOG_BROWSER_LOGS_INTEGRATION`, `METRICS_SOURCE`, `S3_LOGS_FILE_SOURCE`, `PIPELINE_TEMPLATES`, `AI_WORKFLOWS`, `SEARCH_ICEBERG_SOURCE`, `MULTI_GROK_PARSER`, `AUTH0_SSO_CONNECTION`, `TRINO_QUERY_ENGINE`, `UNKNOWN`
 
 - name: name (required)
   type: string

package/build/dist/docs-index/{831564aa-3555-4fd2-a3c9-3deaffe05408.txt → 73a86f15-ef41-4210-9cd7-cd7f86ebf47d.txt}

@@ -10,10 +10,13 @@ You can use the Grepr UI or the REST API to create and manage integrations. To u
 
 ## Integration types
 
-The Grepr platform includes two 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]
 
@@ -75,6 +78,34 @@ To configure the Grepr-hosted integration, you only need to assign a name to the
 
 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.