@grepr/cli 1.11.5-733ab4d → 1.11.5-9b6e525

package/build/dist/docs-index/02e5963d-c649-40fc-bf20-dce961d4b818.txt

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

package/build/dist/docs-index/0baf9947-ec7c-4439-a85e-4b8cf03b934e.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/{4ab5b068-5815-4e16-a622-8adb464ff9e2.txt → 1258d355-6c90-4eb2-bd1e-cb2e34ff5916.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/171d213c-9a9e-4753-bac3-c1278fcd00a0.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/{9a3f392b-9958-4fae-ae19-b8333948c290.txt → 179fa22a-280d-4c4e-96bd-e203dc5bb83a.txt}

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

package/build/dist/docs-index/{0ef35089-3d0b-4f32-835c-e1d4de5447af.txt → 264741c0-eb1e-454f-b9b2-4b9a53d72b2b.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/{81d823f5-42ed-44f5-88d9-dff19a8cd5cc.txt → 31c4b38e-c0a7-49d6-8bc0-ef6367233953.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/4095d037-91a8-4912-9690-56e64d07a9fc.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/{950526b9-691e-4776-ab20-263d754f9e50.txt → 48a92db8-08e7-4792-bdad-fe04e80bb7f3.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/{946c4789-cb73-42c4-bee6-7dcc84a12c60.txt → 4a42b0f8-2c35-4e47-9637-19116375df69.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/54fb96c4-1703-4b6f-a8a8-5449e2db7c9e.txt

@@ -0,0 +1,21 @@
+Guides that work through common Grepr situations end to end, showing the ways you can configure a pipeline to solve each one.
+
+# Solution guides
+
+A solution guide works through a situation you are likely to meet in production, rather than a single feature. A Grepr pipeline is a free-form processing graph, so most situations have more than one good shape. Each guide states the problem, then walks through the ways you can configure Grepr for it.
+
+Use these guides when you know what you want to achieve but not yet how to shape your pipelines around it. To learn a feature on its own, see the reference documentation for [pipelines](/pipelines), [transforms](/transforms), and [integrations](/integrations). To work through the product step by step, see [_](/tutorials).
+
+## Route logs to several vendor accounts
+
+Your logs belong to more than one account in your observability platform, because separate teams, environments, or business units each own their own. This guide shows two ways to get each log, and each summary of those logs, to the account that owns it: a pipeline for each group, or one pipeline whose reducer groups on a routing key and whose sinks each filter on it. See [_](/solution-guides/route-logs-to-several-accounts).
+
+## Frequently Asked Questions
+
+### What is a Grepr solution guide?
+
+A solution guide works through a situation you are likely to meet in production rather than a single feature. A Grepr pipeline is a free-form processing graph, so most situations have more than one good shape. Each guide states the problem, then walks through the ways you can configure Grepr for it.
+
+### How is a solution guide different from a tutorial?
+
+A tutorial teaches the product step by step, starting from nothing. A solution guide assumes you know what you want to achieve and shows you the ways you can shape your pipelines around it.

package/build/dist/docs-index/{efc71658-61a8-4dd0-893c-ee0c9352f8f6.txt → 5a01f797-d04b-45e9-a18a-7baa846120a8.txt}

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