@grepr/cli 1.11.5-5ff5132 → 1.11.5-69ac4ea

package/build/dist/docs-index/035ce8ff-b34d-4703-b8a5-d52d4ebdd66e.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/{e578c0b1-740e-46b8-8a2a-626a431515d3.txt → 0558ef94-4fdd-4b4b-a479-c21e23dde6a3.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/081788ed-4144-4964-9e8d-6e3fde1816da.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/{a0170c7a-a8d6-4b2b-80b4-bbc65124c387.txt → 08a7d5bd-835c-40bf-aa41-5d16022b35de.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/{e5a46469-53f4-4ea7-ab60-0f41a7bbfcf0.txt → 0fb83efa-f765-4815-a20e-ef2688cb2859.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/1ac1e4b2-4f41-461e-a78a-d8b7bc595bea.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/{0a31039a-fbc1-41ce-aaba-e7f6472f95b5.txt → 294bd73c-a34c-4315-8f64-ad502459dc55.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/{e8bff44d-e1cc-47e5-bd29-cc76aff15037.txt → 57e7def4-ec52-490d-a071-da5c4789d184.txt}

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

package/build/dist/docs-index/6126611d-4864-4c25-af02-984a10e5c1e5.txt

@@ -0,0 +1,19 @@
+# UsageStatus
+
+The outcome of the last attempt to read the integration's usage
+
+**Type**: `object`
+
+## Properties
+
+- name: collectedAt (optional)
+  type: string
+  description: When usage was last read successfully. The usage returned is as of this time; absent when it was never read.
+
+- name: detail (optional)
+  type: string
+  description: Why the last attempt failed, in words fit to show. Absent when it worked.
+
+- name: state (required)
+  type: enum: `OK`, `PENDING`, `PERMISSION_DENIED`, `NO_VIEWS`, `ERROR`
+  description: Whether the usage of the integration's parsed queries could be read

package/build/dist/docs-index/6fc62b75-1262-4fa2-87de-f73b699fc40c.txt

@@ -0,0 +1,15 @@
+# ExceptionUsage
+
+Usage the vendor reports for the source of one parsed query
+
+**Type**: `object`
+
+## Properties
+
+- name: lastViewedAt (optional)
+  type: string
+  description: When the source was last viewed. Null means the vendor reports it was never viewed.
+
+- name: totalViews (optional)
+  type: integer
+  description: How many times the source was viewed, as the vendor counts them. Datadog counts views since January 2025 and refreshes the count daily.

package/build/dist/docs-index/{68c110d3-f6e6-41f8-94fa-60c1c2b4f830.txt → 787441aa-55fd-4f72-b3a9-26d34a1fc0ff.txt}

@@ -26,6 +26,10 @@ The payload containing integration data.
   type: string
   description: Client token for Datadog
 
+- name: dashboardFreshnessWindow (optional)
+  type: string
+  description: The active dashboard threshold: only dashboards viewed within it are imported as parsed queries. When unset, every dashboard is imported. Minimum one day.
+
 - name: exceptions (optional)
   type: object
   description: The imported exceptions from Datadog. This is a map from the vendor resource Id to the exception.
@@ -34,6 +38,10 @@ The payload containing integration data.
   type: string
   description: Filter to apply when reading any data from the Datadog API
 
+- name: includeNeverViewedDashboards (optional)
+  type: boolean
+  description: When the active dashboard threshold is set, whether dashboards that were never viewed are still imported. Unset means they are.
+
 - name: sendKeyId (optional)
   type: string
   description: Identifier of the API key used to send data back to Datadog. Defaults to the only key when unset.

package/build/dist/docs-index/7c084a9f-dcf0-4884-a96d-9c82b4113504.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/7ee1eb6f-c2e9-4790-a3f5-e67fd8f3fada.txt

@@ -0,0 +1,18 @@
+# ExceptionUsageResponse
+
+Usage the vendor reports for an integration's parsed queries
+
+**Type**: `object`
+
+## Properties
+
+- name: reportedTypes (required)
+  type: array of string
+  description: The parsed query exception types (values of a parsed query's exceptionType) the vendor reports usage for. Empty when the vendor reports none; a query of any other type has no usage to show.
+
+- name: status (required)
+  type: `UsageStatus`
+
+- name: usage (required)
+  type: object
+  description: Usage keyed by composite exception id (integrationId:vendorResourceId:exceptionType), the key the impacts endpoint uses. A query the vendor reported nothing for is absent, which is not the same as never viewed.