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

package/build/dist/docs-index/{bfde6912-7654-49da-a08e-eb27c8b31c91.txt → 413b7deb-a418-407c-b90d-8c02c247cd4c.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.

package/build/dist/docs-index/{839ba0a0-827d-46e6-8c16-14c67602ee5c.txt → 41ee7065-0199-4f5a-a8ed-9e2dabba2153.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/490302e4-2c5d-4a0b-93c4-0da862657989.txt

@@ -0,0 +1,15 @@
+# recordLogin
+
+**POST** `/v1/me/login`
+
+**Operation ID**: `recordLogin`
+**Summary**: No summary provided.
+## Tags
+- Users
+## Responses
+
+### default
+
+default response
+
+- **Content-Type**: `application/json` / No schema defined

package/build/dist/docs-index/5f2c46f5-1839-4f5a-8297-20ce7c9d67a8.txt

@@ -0,0 +1,30 @@
+# Get parsed-query import state
+
+**GET** `/v1/integrations/{integrationId}/parsed-queries/import`
+
+**Operation ID**: `getParsedQueryImportStatus`
+**Summary**: Get parsed-query import state
+Says whether this vendor's parsed queries can be imported, whether the credential the import needs is saved, whether an import is already under way, and which integrations an import covers. Poll this while an import is running; what it imported is reported in the integration's activity log.
+
+## Tags
+- Integrations
+## Parameters
+
+- **integrationId** (required) - path
+  - Integration id
+  - Type: string
+
+## Responses
+
+### 200
+
+State retrieved
+
+- **Content-Type**: `application/json` / `ParsedQueryImportStatus`
+### 401
+
+Unauthorized
+
+### 404
+
+Not Found - Integration not found.

package/build/dist/docs-index/79029c5c-bff2-400c-ad02-8806a75bbdb8.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/{d7ee44b8-4abd-4353-bd33-eb5e8f984dee.txt → 7bd696b8-b258-4068-badd-48accb93bb5f.txt}

@@ -4,6 +4,8 @@
 
 **Operation ID**: `list_3`
 **Summary**: List skills
+## Tags
+- Skills
 ## Parameters
 
 - **query** (optional) - query

package/build/dist/docs-index/81ed1d14-1aa3-4e22-bf0c-df3d8107ecde.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/919d92ad-4412-4076-a0af-f01221bee8f0.txt

@@ -0,0 +1,145 @@
+Create a Grepr Agent integration so any system that can send JSON over HTTP starts an AI agent investigation for each event it reports.
+
+# Send events to an AI agent with a Grepr Agent integration
+
+A Grepr Agent integration is a webhook endpoint that turns events from another system into AI agent investigations. Any system that can send a JSON body over HTTP can use it, such as an alerting platform, a Kubernetes event forwarder, or a script of your own. Each accepted event starts an investigation on every agent subscribed to the integration.
+
+The integration carries a description of the payload you send. The agent reads that description alongside every event, which is what lets one agent make sense of alerts from several different systems without you writing a parser for each.
+
+> Grepr Agent integrations, along with the rest of the Grepr AI agent features, are in a closed beta. To request access, contact <support@grepr.ai>.
+
+## Requirements
+
+To send events to an agent, you need:
+
+* A Grepr API key, which you generate on the **Developer** page. See [Authenticate your requests](#authentication).
+* At least one AI agent to subscribe to the integration. See [_](/ai-agents/create-an-agent).
+
+## Create a Grepr Agent integration \[#create]
+
+1. On the **Integrations** page, next to the **Grepr Agent** section heading, click **Add new**.
+
+2. In the **Add Grepr Agent** dialog, complete the following fields:
+
+   \| Field | Description | |---|---| | **Name** | A name for the integration, used to identify it when you subscribe an agent. | | **System type** | A short label for the sending system, such as `datadog-monitors` or `k8s-events`. The agent sees this label with every event. | | **Schema description** | An explanation of the payload's structure and the meaning of its fields. The agent reads this with every event from this source. |
+
+3. Click **Create**.
+
+Grepr then shows the ingest URL for the integration, which is where you send your events.
+
+### Write a schema description the agent can use \[#schema-description]
+
+The schema description is the only thing that tells the agent what the fields in your payload mean, so it decides how well the agent can reason about your events. An annotated example payload works better than prose, because it shows the structure and the meaning together:
+
+```text
+An alert from your Datadog monitors. Fields:
+{
+  "alert_id": "abc123",          // stable id for the monitor
+  "alert_title": "5xx rate high on checkout",
+  "priority": "P2",              // P1 is highest, P5 is lowest
+  "service": "checkout",         // the owning service, matches the service tag in your logs
+  "env": "prod",                 // prod, staging, or dev
+  "runbook": "https://wiki.example.com/runbooks/checkout-5xx",
+  "triggered_at": "2026-09-21T14:03:00Z"
+}
+```
+
+Describe the fields an agent would need to act: which field identifies the affected service, which indicates severity, and which values are expected in each. A description can be up to 16,384 characters.
+
+To change a description later, click the three-dot menu on the integration card, select **Edit**, and update the **Schema description** field. The next event the integration receives uses the new description.
+
+## Authenticate your requests \[#authentication]
+
+Requests to the ingest URL authenticate with a Grepr API key sent in the `GREPR-API-KEY` header. Grepr identifies your organization from the key and the integration from the URL, so the sender does not supply either.
+
+To generate a key, go to the **Developer** page, select **API Keys**, and under **External Triggers API Key**, click **Generate**. Copy the key when it appears and store it in your sending system's secret store.
+
+## Send an event \[#send]
+
+To find the ingest URL, on the integration card, click **Setup**. The URL has the following form, where `<integration-id>` identifies the integration you created:
+
+```bash
+https://<your-org>.app.grepr.ai/api/v1/integrations/webhooks/<integration-id>/events
+```
+
+Send the event as the request body. The body is your payload, with no Grepr envelope around it:
+
+```bash
+curl -X POST \
+  "https://<your-org>.app.grepr.ai/api/v1/integrations/webhooks/<integration-id>/events" \
+  -H "GREPR-API-KEY: <your-api-key>" \
+  -H "Content-Type: application/json" \
+  -d '{
+    "alert_id": "abc123",
+    "alert_title": "5xx rate high on checkout",
+    "priority": "P2",
+    "service": "checkout",
+    "env": "prod"
+  }'
+```
+
+Grepr returns `202 Accepted` after it submits the event to every subscribed agent without a failure. The responses are:
+
+| Status | Meaning |
+| --- | --- |
+| `202` | The event was submitted to every subscribed agent. The body lists the investigation identifiers. |
+| `400` | The body is not valid JSON. |
+| `401` | The API key is missing or not valid. |
+| `404` | No integration matches the id in the URL. |
+| `409` | The integration has no agent that can be started. Subscribe an agent. |
+| `413` | The body is larger than the 262,144 character limit. |
+| `503` | At least one agent could not be started, for a reason that might not persist. |
+
+A `202` can still include agents that were not investigated. An agent at its concurrency limit with a queueing policy of discard drops the event deliberately, which is a decision rather than a failure, so the event is not resubmitted.
+
+Subscribe an agent before you point a production system at the URL. An integration with no subscribed agents rejects every event with `409` rather than accepting it and doing nothing.
+
+### Retry safely \[#retries]
+
+Retry on `503` and nothing else. A `503` means at least one agent could not be started, so the event is lost for that agent if you drop it.
+
+Retrying a `503` can also duplicate work, because a `503` is returned even when some of the subscribed agents did start. Those agents are submitted again on the retry, and Grepr does not deduplicate events. There is no response that distinguishes the two cases, so weigh losing an event against investigating it twice, and prefer retrying when the agent's conclusions are cheap to read and the event matters.
+
+To clear duplicates, cancel them in bulk from the agent's **Investigations** step. See [_](/ai-agents/investigations#end-for-good).
+
+## Subscribe an agent \[#subscribe]
+
+An integration on its own does nothing. To have an agent investigate the events it receives, subscribe that agent to the integration from the agent's **Subscriptions** step. To learn more, see [_](/ai-agents/subscriptions#webhook-sources).
+
+## 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
+
+### What is a Grepr Agent integration?
+
+A Grepr Agent integration is a webhook endpoint that turns events from another system into AI agent investigations. Any system that can send a JSON body over HTTP can use it. Each accepted event starts an investigation on every agent subscribed to the integration.
+
+### How do I authenticate requests to a Grepr Agent webhook?
+
+Send a Grepr API key in the GREPR-API-KEY header. Generate the key on the Developer page under API Keys, in the External Triggers API Key section. Grepr identifies your organization from the key and the integration from the URL.
+
+### Why does the schema description matter?
+
+The agent reads the schema description alongside every event from that integration, and it is the only thing that tells the agent what your payload's fields mean. An annotated example payload works best, because it shows the structure and the meaning of each field together.
+
+### How large can a webhook event be?
+
+The request body is limited to 262,144 characters. A larger body is rejected with a 413 response.
+
+### Why does my Grepr Agent webhook return 409?
+
+The integration has no agent that can be started, which normally means no agent is subscribed to it. Subscribe an agent on that agent's Subscriptions step. Grepr returns 409 rather than accepting the event and silently doing nothing.
+
+### Can a webhook retry start duplicate investigations?
+
+Yes. A 503 is returned when at least one agent could not be started, even if others did start, and Grepr does not deduplicate events. Retrying that 503 resubmits the agents that already succeeded. Retry on 503 anyway when the event matters, because dropping it loses the event for the agent that failed, and cancel any duplicates in bulk from the agent's Investigations step.

package/build/dist/docs-index/95a02ab2-0594-4eee-b954-d231e09c50ff.txt

@@ -0,0 +1,116 @@
+Connect a model provider with a Grepr LLM integration, and cap how many tokens your agents consume per time window.
+
+# Configure LLM provider connections with a Grepr integration
+
+An LLM integration holds the credentials Grepr uses to call a large language model provider. Grepr AI agents can use LLM integrations for two purposes: a generative model used for reasoning, or an embedding model used for similarity analysis.
+
+An LLM integration can be assigned a token budget, which is a mechanism that caps the amount of tokens your agents can spend. When several agents share one integration, the budget applies to all of them together.
+
+> LLM integrations, along with the rest of the Grepr AI agent features, are in a closed beta. To request access, contact <support@grepr.ai>.
+
+## Requirements
+
+To create an LLM integration, you need:
+
+* The credential your provider requires, which is an API key for most providers, or a gateway URL and a key for the gateway.
+
+## Choose a provider \[#providers]
+
+An LLM integration serves one of two purposes, so create the one that matches what you need.
+
+For the model an agent reasons with, create an integration for your model provider. You can also create a gateway integration to route your agents through a gateway you run, which reaches whatever models you configure it with, so use one to choose the model yourself, apply your own routing rules, or keep model traffic inside your own infrastructure.
+
+For the embedding model that agent memory uses, create an integration for a provider that supplies embeddings. One integration can serve both purposes, so a single integration is often enough to run an agent with memory turned on.
+
+The **Type** menu in the **Add LLM** dialog lists the providers available to you.
+
+Don't see your provider in the list? Send a request to <support@grepr.ai>.
+
+## Create an LLM integration \[#create]
+
+1. On the **Integrations** page, next to the **LLMs** section heading, click **Add new**.
+2. In the **Add LLM** dialog, select the provider from the **Type** menu.
+3. Complete the remaining fields, which depend on the provider you selected.
+4. Click **Create**.
+
+You cannot change an integration's type after you create it. To move to a different provider, create a new integration and point your agents at it.
+
+Select the tab for your provider to see the fields it requires:
+
+| Field | Description |
+| --- | --- |
+| **Name** | A name for the integration, used to identify it when you configure an agent. |
+| **API Key** | Your Gemini API key. |
+| **Max tokens per window** | The total tokens that all agents using this integration can consume in each window. Leave empty for the default of 20,000,000. |
+| **Max tokens window (hours)** | The length of the budget window. Leave empty for the default of 1 hour. |
+
+A Gemini integration can serve as both an agent's model and the embedding model for agent memory.
+
+| Field | Description |
+| --- | --- |
+| **Name** | A name for the integration, used to identify it when you configure an agent. |
+| **Gateway URL** | The base URL of your LiteLLM proxy, such as `https://litellm.example.com/team-a`. Required. |
+| **Virtual key** | The LiteLLM virtual key Grepr authenticates with. |
+| **Validate virtual key when saving** | Turn this on to have Grepr verify the virtual key against the gateway before it saves the integration. |
+| **Max tokens per window** | The total tokens that all agents using this integration can consume in each window. Leave empty for the default of 20,000,000. |
+| **Max tokens window (hours)** | The length of the budget window. Leave empty for the default of 1 hour. |
+
+Grepr reaches whatever models your gateway exposes, so the model names available to an agent are the ones your LiteLLM configuration routes.
+
+| Field | Description |
+| --- | --- |
+| **Name** | A name for the integration, used to identify it when you configure an agent. |
+| **API Key** | Your OpenAI API key. |
+
+An OpenAI integration provides the embedding model that agent memory uses.
+
+## Cap token consumption with a budget window \[#max-tokens]
+
+An integration that serves an agent's model carries a token budget, which is what caps the spend of every agent sharing it. The budget has two settings:
+
+* **Max tokens per window** is the total tokens every agent sharing the integration can consume in one window.
+* **Max tokens window (hours)** is the length of that window. The value must divide 24 evenly, so the valid lengths are 1, 2, 3, 4, 6, 8, 12, and 24 hours. Windows are aligned to UTC.
+
+Before it starts an investigation, Grepr reserves the tokens that investigation is allowed to consume and checks the reservation against two budgets: the integration's budget, and the agent's per-window budget. Both must have room. An agent whose own budget is untouched still waits when the shared integration has none left, so when investigations stop starting, check which of the two is exhausted on the agent's page before you raise a limit. To learn more about the agent-level settings, see [_](/ai-agents/create-an-agent#limits).
+
+## Update an API key \[#update-key]
+
+To replace a key, click the three-dot menu on the integration card, select **Edit**, enter the new key, and click **Save**. Every agent using the integration picks up the new key automatically.
+
+## 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).
+
+## View token usage \[#usage]
+
+Each LLM integration card on the **Integrations** page charts the tokens its agents consumed, broken down by token type, and shows how much of the budget window remains. The card totals every agent sharing the integration and lists which agents those are, so to see how much one agent is spending, open that agent's page.
+
+## Frequently Asked Questions
+
+### Which LLM providers can a Grepr AI agent use as its model?
+
+Create an LLM integration for your model provider, or a gateway integration to route your agents through a gateway you run, which reaches whatever models you configure it with. Use a gateway to choose the model yourself, apply your own routing rules, or keep model traffic inside your own infrastructure. The Type menu in the Add LLM dialog lists the providers available to you, and Grepr adds integrations continuously, so contact support\@grepr.ai to get connected to the provider you use.
+
+### Which LLM providers can Grepr use for agent memory embeddings?
+
+Create an LLM integration for a provider that supplies embeddings. One integration can serve as both an agent's reasoning model and its embedding model, so a single integration is often enough to run an agent with memory turned on.
+
+### How does Grepr cap the tokens my AI agents consume?
+
+An LLM integration that serves an agent's model carries a max-tokens budget and a window length in hours that must divide 24 evenly. Grepr reserves an investigation's tokens up front and requires room in both the shared integration budget and the agent's own per-window budget before the investigation starts.
+
+### Can I change an LLM integration's provider after creating it?
+
+No. The type is fixed when you create the integration. To move to a different provider, create a new integration and point your agents at it.
+
+### Why have my agent's investigations stopped starting?
+
+The most common cause is an exhausted token budget. Because several agents can share one LLM integration, the shared budget can run out while the agent's own budget is untouched. The agent's page reports which of the two blocked the investigation and when the window resets.

package/build/dist/docs-index/{519c1c49-9942-48c2-96b9-db0830821559.txt → 986d99e3-faa5-45b9-a585-5566405bf3a8.txt}

@@ -43,6 +43,21 @@ This table lists all available permissions for organization and team-level roles
 | Edit | Datasets | Organization or Team |
 | View | Datasets | Organization or Team |
 
+## Permissions for AI agent resources \[#ai-agent-permissions]
+
+AI agents, skills, and agent memory do not have permissions of their own. They are governed by the permissions already in the table:
+
+| To do this | You need |
+| --- | --- |
+| View an agent, its investigations, or its skills | View on integrations |
+| Create, edit, or delete an agent or an organization skill | Edit on integrations |
+| Create or edit an LLM, MCP, or Grepr Agent integration | Edit on integrations |
+| Subscribe an agent to a pipeline, or unsubscribe it | Edit on jobs |
+| View the pipeline changes an agent proposed | View on jobs |
+| Apply or reject a pipeline change an agent proposed | Edit on jobs |
+
+An agent's own reach is separate from yours. An agent acts as the service account you assign it, and that account's roles cap what the agent can read and change, whatever tools it holds. To learn more, see [_](/ai-agents/capabilities#service-account).
+
 ## Permissions by role
 
 The following are the permissions granted to each role type in the Grepr platform:

package/build/dist/docs-index/{c76bd5b8-f5f9-4944-a6a9-d4cd5d225322.txt → a01b86b5-4a61-49f0-9203-be1bda4a3460.txt}

@@ -1,8 +1,8 @@
-# query_1
+# query
 
 **POST** `/v1/metrics/query`
 
-**Operation ID**: `query_1`
+**Operation ID**: `query`
 **Summary**: No summary provided.
 ## Tags
 - Status Metrics

package/build/dist/docs-index/a3fb5d0c-5a96-41b3-b8b3-44c91bdc305d.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.