@grepr/cli 1.11.4-fa34897 → 1.11.5-03c23a0

package/build/dist/docs-index/24801afd-0feb-48a4-aab8-8743f74572f7.txt

@@ -0,0 +1,229 @@
+Aggregate logs in the Grepr data lake with Analyze mode, using Grepr SQL expressions over log fields, tags, and parsed attributes.
+
+# Aggregate logs with Analyze mode
+
+Log Explorer's Analyze mode groups and aggregates the logs your search returns instead of listing them. You describe the analysis as a set of Grepr SQL expressions, and Grepr runs it against the logs in the data lake.
+
+## Create an analysis
+
+1. Go to Log Explorer and select a dataset and a time range.
+2. Enter a search query to filter the logs you want to analyze. Analyze mode accepts the same [Datadog-like syntax](/queries/datadog) and [New Relic log query-like syntax](/queries/new-relic) as searching.
+3. Open the **Analyze...** drawer under the search controls.
+4. Under **SELECT**, enter one expression per result column, and name it in the **Alias** field beside it. An alias is optional; a column you leave unnamed is named for you, after the field or function it computes.
+5. Under **GROUP BY**, add the expressions whose distinct combinations you want as rows. Each grouping expression also becomes a result column, so the rows show the values they are grouped on. Without a grouping expression, an analysis made only of aggregates returns a single row.
+6. Under **HAVING**, enter a condition over the aggregates to keep only some of the groups. Leave it empty to keep every group.
+7. Under **ORDER BY**, add the expressions to sort by and pick ascending or descending for each one.
+8. Set **Row limit**, the maximum number of rows to return. An analysis returns 2,500 rows by default, up to the largest limit your deployment allows.
+9. Set **Scan budget** to cap how much of the lake the query may read, then run the analysis.
+
+The drawer's clauses are the SQL ones, so an analysis reads the way the query does: SELECT computes, GROUP BY collapses, HAVING filters the groups, ORDER BY and the row limit choose which of them you see. GROUP BY, HAVING and ORDER BY can refer to a result by its alias.
+
+Every SELECT column is either an aggregate or one of the grouping expressions. To count events by a field, add the field under SELECT and group by it.
+
+## Log fields
+
+Expressions address the stored log columns by the following names:
+
+| Field | Type | Description |
+| --- | --- | --- |
+| `message` | VARCHAR | The log line. |
+| `severity` | INTEGER | The numeric severity level, where a higher number is more severe. |
+| `event_timestamp` | TIMESTAMP | When the event happened. |
+| `received_timestamp` | TIMESTAMP | When Grepr received the event. |
+| `id` | VARCHAR | The identifier of the event. |
+| `tags` | MAP | The tag values, keyed by tag name. |
+| `attributes` | VARIANT | The whole parsed attribute document. |
+
+> These are the Grepr SQL column names, which use `snake_case`. They are not the camelCase field names of the log event JSON that the search and export APIs return.
+
+A tag holds an array of values, so picking a tag key from the suggestions groups by the sorted, comma-joined set of its values — two events tagged with the same values in a different order land in one group:
+
+```sql
+ARRAY_TO_STRING(SORT_ARRAY(tags['service']), ',')
+```
+
+Index a single value with `[1]` when you want only the first:
+
+```sql
+tags['service'][1]
+```
+
+## Attribute values
+
+Grepr parses structured logs into an attribute document. Address a single attribute with the `@` form, which takes a dotted path through that document:
+
+```sql
+@duration_ms
+@http.status_code
+@kubernetes.labels.app
+```
+
+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:
+
+```sql
+-- Read the attribute as a whole number
+CAST(@duration_ms AS BIGINT)
+
+-- Or aggregate the cast value
+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.
+
+## Expressions
+
+Expressions are Grepr SQL, so aggregates, `CASE`, `CAST` and scalar functions are all available.
+
+Every function an analysis can call is listed in the [Analyze function reference](/queries/analyze/functions), with its arguments and a worked example. Focus an expression box or start typing to find fields, functions, sampled tag and attribute keys, and result aliases.
+
+> The [SQL transform function reference](/transforms/sql-transform/sql-functions) does **not** describe Analyze. A SQL transform runs inside a pipeline on Flink SQL; an analysis runs on the query engine over the data lake. The two support different functions, so a function listed there may not exist here, and the autocomplete offers functions that page does not list.
+
+```sql
+-- Log count by service: the first line goes under SELECT, the second under GROUP BY
+COUNT(*)
+ARRAY_TO_STRING(SORT_ARRAY(tags['service']), ',')
+
+-- 95th percentile request duration by endpoint, the same way
+APPROX_PERCENTILE(@duration_ms, 0.95)
+@http.route
+
+-- A SELECT column that buckets rather than aggregates
+CASE WHEN severity >= 4 THEN 'error' ELSE 'ok' END
+```
+
+`SEVERITY_TEXT` names the OpenTelemetry severity bucket a severity number falls in: `TRACE`, `DEBUG`, `INFO`, `WARN`, `ERROR` or `FATAL`, and nothing for a log with no severity. It takes a whole number, so cast an attribute before passing it. Grouping by it is the usual way to count logs per level:
+
+```sql
+-- Under SELECT
+COUNT(*)
+
+-- Under GROUP BY
+SEVERITY_TEXT(severity)
+```
+
+## Name the results
+
+Every SELECT column takes an optional alias, entered in the **Alias** field beside the expression. The alias becomes the result column's name. Leave it empty and Grepr names the column after the expression itself:
+
+| Expression | Alias | Result column |
+| --- | --- | --- |
+| `COUNT(*)` | empty | `count0` |
+| `APPROX_PERCENTILE(@duration_ms, 0.95)` | `p95` | `p95` |
+| `ARRAY_TO_STRING(SORT_ARRAY(tags['service']), ',')` | `service`, filled in for you | `service` |
+| `severity` | empty | `severity` |
+| `@http.route` | `route` | `route` |
+
+An alias can then be referred to under GROUP BY, HAVING or ORDER BY, anywhere inside that expression rather than only as the whole of it:
+
+```sql
+-- Under HAVING
+count0 > 100
+
+-- Under ORDER BY
+p95 / 1000
+```
+
+Aliases are lowercase, made of letters, digits and underscores, up to 128 characters, and a reference has to match exactly.
+
+> Enter the alias in its own field, not in the expression: `AS p95` inside an expression is not valid. An alias is available to GROUP BY, HAVING and ORDER BY, and to the SELECT columns after the one that defines it.
+
+Reserved SQL words cannot be aliases, because the query engine would read them as syntax. That is why the default first column is `count0` rather than `count`, and why a name Grepr derives for you gains a `0` when it lands on a reserved word.
+
+> `count`, `max`, `min`, `sum`, `value`, `date` and `year` are reserved. Ordinary field names such as `level`, `name`, `type`, `path`, `service`, `host` and `user` are not.
+
+## Window by time
+
+To see how an aggregate changes over time, add a time window under the grouping expressions. Every result row then carries a `window_start` and a `window_end` column, and the other grouping keys and aggregates are computed per window. The analysis is sorted by `window_start` descending, so the newest window leads.
+
+| Kind | Meaning |
+| --- | --- |
+| Tumbling | Fixed windows that do not overlap. A 5 minute window puts each log in exactly one bucket. |
+| Sliding | Windows of one size that start every *slide*. A 5 minute window sliding every 1 minute counts each log in five overlapping windows. The size must be a whole multiple of the slide, and a window can cover at most 100 slides. |
+
+Each duration is a whole number of milliseconds, seconds, minutes, hours, or days. Windows bucket by event time by default; choose receive time to bucket by when Grepr received each log instead. The time range you searched selects logs by event time either way.
+
+Windows are aligned to the clock rather than to the start of your time range, so the first and last windows of a range can be partial.
+
+In the API, the window is the `window` object of the structured analytics query, with ISO-8601 durations:
+
+```json
+{ "kind": "SLIDING", "timestamp": "EVENT_TIMESTAMP", "size": "PT5M", "slide": "PT1M" }
+```
+
+## Read the results table
+
+Click a column header to sort the rows you already have. No second run happens and no scan budget is spent; Shift-click adds a second sort instead of replacing the first.
+
+When an analysis comes back at its row limit, the rows you have are only the top of the ranking, so sorting them on the page can put the wrong rows first. **Sort on the server** puts the sort into ORDER BY and runs the analysis again, so the engine ranks every matching row.
+
+## Share an analysis
+
+The whole analysis lives in the page URL, so copying the link from the address bar is enough to share it. The link carries the dataset, the time range, the search query, every SELECT expression and its alias, every GROUP BY expression, the HAVING condition, the ORDER BY, the time window, the row limit, the scan budget, and the way you arranged the results table — its column order, column widths and sort.
+
+Opening such a link seats every control and runs the analysis once, so the recipient sees the rows rather than a filled-in form waiting for a click. Back and Forward move between analyses you have already run, restoring the controls without re-running and spending scan budget again.
+
+## Result values
+
+Each result row is a JSON object keyed by column name, so a column holds whatever the underlying attribute held, such as a number, a string, a boolean, or a nested object. Timestamps are returned as UTC ISO 8601 strings.
+
+## Limitations
+
+* An analysis reads one dataset at a time. Joins across datasets are not supported.
+* Sorting by an attribute that you have not cast sorts it by its stored text, so `100` sorts before `99`. Cast the attribute to sort numerically, as in `CAST(@http.status_code AS BIGINT)`.
+* A result alias cannot be a reserved SQL word, and a reference to one has to match its lowercase spelling exactly.
+* A sort you set from the result headers sorts the rows already on the page. When the analysis returned its row limit, use **Sort on the server** to rank every matching row instead.
+* An analysis too long to fit in the address bar cannot be shared as a link.
+* An analysis can compute at most 128 values, group by at most 64 expressions, and sort by at most 64 expressions. Each expression can be at most 4,096 characters long.
+* A time window's size and slide are whole milliseconds, and a sliding window covers at most 100 slides. `window_start` and `window_end` cannot be used as result aliases while a window is set.
+* Row, array, and map values are converted to nested JSON automatically. A value whose type has no JSON representation at all, or a constructed row with two fields of the same name, cannot be returned.
+
+## Frequently Asked Questions
+
+### How do I aggregate logs in Grepr?
+
+Go to Log Explorer, select a dataset and time range, enter a search query, then open the Analyze... drawer under the search controls. Enter Grepr SQL expressions under SELECT for the result columns, under GROUP BY for the grouping keys, and under ORDER BY for the sort.
+
+### What are the log field names in Grepr SQL?
+
+message, severity, event_timestamp, received_timestamp, id, tags, and attributes. Read the whole set of a tag's values as ARRAY_TO_STRING(SORT_ARRAY(tags\['service']), ','), index a single value as tags\['service']\[1], and address an attribute as @http.status_code.
+
+### How do I bucket an analysis by time?
+
+Add a time window under the grouping expressions in Analyze mode. Choose tumbling or sliding, a size, and for sliding windows a slide. Results gain window_start and window_end columns.
+
+### How many rows can an analysis return?
+
+An analysis returns 2,500 rows by default. The largest limit you can ask for is set by your deployment.
+
+### How do I share a Grepr analysis?
+
+Copy the page URL. The link carries the dataset, time range, query, every expression and alias, the window, the row limit, the scan budget and the column order, widths and sort, and opening it runs the analysis once.
+
+### Why can't I name a result column count?
+
+count is a reserved SQL word, so the query engine would read it as syntax rather than as an alias. Name the column count0 or anything else that is not reserved; that is why the default first column is named count0.
+
+### How do I turn severity numbers into names in Grepr?
+
+Use SEVERITY_TEXT(severity), which names the OpenTelemetry bucket: TRACE, DEBUG, INFO, WARN, ERROR or FATAL. It takes a whole number, so cast an attribute before passing it.
+
+### How do I sort an analysis by a result column?
+
+Click the column header in the results table. The rows on the page reorder immediately, without a second run. If the analysis returned its row limit, use Sort on the server, which puts the sort into ORDER BY and runs the analysis again.

package/build/dist/docs-index/25fc8256-b70e-415c-92b0-4b0d3ce08caf.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/31dcefa0-3b67-4590-96bd-4941e67bd9bc.txt

@@ -0,0 +1,22 @@
+# Archive an organization skill
+
+**DELETE** `/v1/skills/{id}`
+
+**Operation ID**: `archive`
+**Summary**: Archive an organization skill
+## Tags
+- Skills
+## Parameters
+
+- **id** (required) - path
+  - Type: string
+- **expectedRevision** (required) - query
+  - Type: integer
+
+## Responses
+
+### default
+
+default response
+
+- **Content-Type**: `application/json` / No schema defined

package/build/dist/docs-index/3266b32b-21bb-4042-bbaa-58c298cde36f.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/3766d65b-eae5-4fc1-8bd7-4ed929d8a417.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/427e48cb-a285-4e41-b671-6d13d5579328.txt

@@ -0,0 +1,20 @@
+# Get the current maxTokens window of one LLM integration
+
+**GET** `/v1/llm-usage/{integrationId}`
+
+**Operation ID**: `currentWindow`
+**Summary**: Get the current maxTokens window of one LLM integration
+## Tags
+- LLM Usage
+## Parameters
+
+- **integrationId** (required) - path
+  - Type: string
+
+## Responses
+
+### 200
+
+Current window retrieved
+
+- **Content-Type**: `application/json` / `LlmUsageWindow`

package/build/dist/docs-index/46c932a2-fac6-4ca4-89f6-2709a488c0d5.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/4a50d4b9-4b73-4b38-a4ac-4d99857dda26.txt

@@ -0,0 +1,55 @@
+# Datadog
+
+The payload containing integration data.
+
+**Type**: `object`
+
+## Properties
+
+- name: additionalTags (required)
+  type: array of string
+  description: Tags to add when writing data to Datadog
+
+- name: apiKey (optional)
+  type: string
+  description: Masked API key for Datadog
+
+- name: apiKeys (optional)
+  type: array of `IngestKeyView`
+  description: The API keys configured for this integration (masked).
+
+- name: appKey (optional)
+  type: string
+  description: Masked App key for Datadog
+
+- name: clientToken (optional)
+  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.
+
+- name: filterQuery (required)
+  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.
+
+- name: site (required)
+  type: string
+  description: Datadog site URL
+
+- name: validateKeysOnSave (optional)
+  type: boolean
+  description: Indicates whether to validate the API and App keys when saving the keys.

package/build/dist/docs-index/51debd7d-3bf4-44bc-b4ac-d37a476028a7.txt

@@ -0,0 +1,30 @@
+# Get the usage of an integration's parsed queries
+
+**GET** `/v1/integrations/{integrationId}/exceptions/usage`
+
+**Operation ID**: `getIntegrationExceptionUsage`
+**Summary**: Get the usage of an integration's parsed queries
+Returns the usage the observability vendor reports for the source of each parsed query, such as when a Datadog dashboard was last viewed and its total views, with whether the last attempt to read it worked. Queries the vendor reported nothing for are absent rather than reported as never viewed.
+
+## Tags
+- Integration Exceptions
+## Parameters
+
+- **integrationId** (required) - path
+  - Integration id
+  - Type: string
+
+## Responses
+
+### 200
+
+Usage retrieved
+
+- **Content-Type**: `application/json` / `ExceptionUsageResponse`
+### 401
+
+Unauthorized
+
+### 404
+
+Not Found - Integration not found.