@grepr/cli 1.11.3 → 1.11.5-00bed08

package/build/dist/docs-index/66f5eaf5-82ba-4a3c-8d66-3d20bb88d56e.txt

@@ -0,0 +1,118 @@
+Connect a Grepr AI agent to the pipelines and Grepr Agent integrations whose signals it investigates, and control how many signals reach it.
+
+# Subscribe an agent to signal sources
+
+A *signal* is an event that starts an investigation. A *subscription* connects an agent to a source of signals, so that source's events are investigated automatically rather than only when you start an investigation manually.
+
+A subscription carries no filters or conditions of its own. What an agent investigates is decided by what the source emits, so you narrow an agent's work by changing the source rather than the subscription.
+
+## Signal sources \[#sources]
+
+Signals reach an agent in four ways:
+
+| Signal | Where it comes from | How the agent is chosen |
+| --- | --- | --- |
+| Log pattern | A pipeline reducer detected a log pattern it has not seen before. | By subscription. |
+| Pipeline signal | A SQL output in a pipeline is routed to the agent signal and matched an event. | Named in the pipeline's agent signal sink. |
+| Webhook | A Grepr Agent integration received an event. | By subscription. |
+| Manual | You started the investigation. | You chose the agent. |
+
+The log pattern and webhook signals use subscriptions, which you manage on the agent's **Subscriptions** step. The pipeline signal names its agents in the pipeline itself instead, and is described in [_](#agent-signal-sink).
+
+## Subscribe an agent to a pipeline \[#pipeline-sources]
+
+A pipeline can tell your agents when its reducer detects a log pattern it has not seen before, which is how an agent learns about behavior that is new in your systems rather than behavior you already knew to alert on.
+
+### Step 1: Turn on new-pattern signal emission \[#emit-signals]
+
+A pipeline emits nothing to agents until you turn it on, and Grepr refuses a subscription to a pipeline that has it off. Turning it on changes the pipeline's configuration, so Grepr redeploys the pipeline before signals start flowing. Subscribing and unsubscribing afterwards take effect without a restart. A pipeline needs a log reducer or a pattern matcher to emit these signals at all.
+
+To turn it on, go to the pipeline's reducer configuration, open the advanced settings, and select **Emit new-pattern signals to AI agents**.
+
+To learn more about the reducer, see [_](/transforms/reducer/configuration).
+
+### Step 2: Subscribe the agent \[#subscribe-pipeline]
+
+1. On the agent's page, go to the **Subscriptions** step.
+2. In the **Subscribe to a signal source** menu, select the pipeline under **Pipelines**.
+3. Click **Subscribe**.
+
+Subscriptions apply as soon as you make them and are not held by the agent's save bar. A running pipeline picks up a new subscriber without restarting, so you can subscribe an agent to a live pipeline at any time.
+
+### When a pattern produces a signal \[#pattern-emission]
+
+A pattern signals an agent only if the agent subscribed after that pattern last emitted a signal. This has two consequences worth knowing before you rely on it:
+
+* An agent is notified about each pattern once, for as long as the reducer keeps that pattern in its state. A pattern that keeps occurring does not keep starting investigations, so a pattern that matches a high volume of logs does not flood an agent. A pattern the reducer drops from its state and later meets again counts as new, and signals its subscribers a second time.
+* Subscribing gives you no backlog. An agent you subscribe today is never notified about occurrences that already happened. It is notified the next time any pattern matches, including a pattern the pipeline flagged before you subscribed, because that agent is newer than the pattern's last emission.
+
+So subscribing an agent to an established pipeline can produce a burst of investigations, one for each of its recurring patterns as that pattern next matches, and then settle down to one per newly detected pattern. Expect that burst on a busy pipeline and set the agent's concurrency limit before you subscribe. See [Control how many signals reach an agent](#volume).
+
+## Send specific events with an agent signal sink \[#agent-signal-sink]
+
+New-pattern signals tell an agent about behavior that is new. When you want an agent to investigate behavior you can describe instead, route a SQL output in the pipeline to the agent signal. Every event that output emits becomes a signal, so you decide exactly what reaches the agent by writing the SQL.
+
+This mechanism does not use subscriptions. The pipeline names the agents directly, so an agent can receive these signals without appearing in its own **Subscriptions** step.
+
+To configure it:
+
+1. In the pipeline, add a SQL transform whose output is routed to the agent signal. The routed output must produce log events.
+2. In the pipeline's sinks, edit the agent signal sink and select the agents in the **Agents** field.
+3. Optionally enter **Context**, which is guidance sent with every signal from this pipeline, such as which team owns the service or what an acceptable remediation is. A context can be up to 4,096 characters.
+
+The sink and the route are two halves of one configuration, and Grepr saves the pipeline only when both are present. A pipeline with a routed output needs a sink naming at least one agent, and a sink cannot remain after you remove its last route. When you stop sending signals from a pipeline, remove the route and the sink together.
+
+Because every matching event becomes a signal, a SQL output that matches broadly can produce far more investigations than an agent can run. Write the output to match the events you would want to look at yourself, then check the agent's queue after the change. See [Control how many signals reach an agent](#volume).
+
+To learn more about SQL transforms, see [_](/transforms/sql-transform).
+
+## Subscribe an agent to a Grepr Agent integration \[#webhook-sources]
+
+A Grepr Agent integration turns events from another system into investigations. Every event it accepts starts an investigation on each subscribed agent, with no pattern detection or deduplication in between.
+
+1. On the agent's page, go to the **Subscriptions** step.
+2. In the **Subscribe to a signal source** menu, select the integration under **Grepr Agent**.
+3. Click **Subscribe**.
+
+Subscribe more than one agent to an integration when you want different agents to examine the same event differently, such as one that diagnoses and one that checks for a security concern. Each subscribed agent gets its own investigation of the event.
+
+To create an integration and send events to it, see [_](/integrations/grepr-agent-webhooks).
+
+## Unsubscribe an agent \[#unsubscribe]
+
+On the agent's **Subscriptions** step, remove the source from the table and confirm. The agent stops investigating that source's signals. Investigations already running finish.
+
+Detach an agent from its pipelines and from the Grepr Agent integrations that name it before you delete it, because Grepr refuses to delete an agent either one still targets. A pipeline that names the agent in its agent signal sink is not covered by that check, so clear the agent from the sink's **Agents** field yourself. Because a sink keeps at least one agent, name another in its place or remove the sink with the routes that feed it. See [_](/ai-agents/create-an-agent#delete).
+
+## Control how many signals reach an agent \[#volume]
+
+Because subscriptions carry no filters, the number of investigations an agent runs is set by the sources you subscribe it to and the limits on the agent itself:
+
+* Narrow what the source emits. For a pipeline signal, make the SQL output match fewer events. For a webhook, send fewer events from the system at the other end. This is the only way to reduce signals rather than drop them.
+* Cap the agent's concurrency. Choose how many investigations run at once and whether extra signals queue or are discarded. See [_](/ai-agents/create-an-agent#concurrency).
+* Expire stale queued signals. Set a maximum queue wait so a signal that has waited too long is dropped rather than investigated late.
+* Cap the tokens. A per-window token budget on the agent bounds its spend whatever the signal volume. See [_](/ai-agents/create-an-agent#window-limits).
+
+New-pattern signals need less of this than the other sources, because a pattern notifies an agent once rather than on every occurrence.
+
+## Frequently Asked Questions
+
+### How do I make a Grepr pipeline trigger AI agent investigations?
+
+Select Emit new-pattern signals to AI agents in the pipeline reducer's advanced configuration, then subscribe the agent to that pipeline on the agent's Subscriptions step. Grepr refuses a subscription to a pipeline that has the option off, and a pipeline needs a log reducer or a pattern matcher to emit these signals at all.
+
+### Why didn't my agent investigate a log pattern again?
+
+A pattern signals an agent only if the agent subscribed after that pattern last emitted a signal, so a pattern that keeps occurring does not keep starting investigations for an agent that has already seen it. A newly subscribed agent is different: it is newer than every previous emission, so it is notified the next time each pattern matches, which can produce a burst of investigations when you subscribe to an established pipeline.
+
+### Can I filter which signals reach a Grepr AI agent?
+
+Not on the subscription, which carries no filters or conditions. You narrow what an agent investigates by changing the source: make a routed SQL output match fewer events, or send fewer webhook events. You can also cap the agent's concurrency, expire stale queued signals, and cap its token budget.
+
+### What is the difference between a new-pattern signal and an agent signal sink?
+
+A new-pattern signal fires when the reducer detects a log pattern it has not seen before, and the agent is chosen by subscription. An agent signal sink sends every event matched by a SQL output you routed to the agent signal, and the pipeline names the agents directly rather than using subscriptions.
+
+### Do I need to restart a pipeline after subscribing an agent?
+
+No. A running pipeline picks up a new subscriber without restarting, and subscriptions apply as soon as you make them.

package/build/dist/docs-index/6ca111e5-3331-4e22-8416-e21ddd466bd9.txt

@@ -0,0 +1,21 @@
+# query
+
+**POST** `/v1/metrics/query`
+
+**Operation ID**: `query`
+**Summary**: No summary provided.
+## Tags
+- Status Metrics
+## Request Body
+
+**Content-Type**: `application/x-www-form-urlencoded`
+
+**Schema**: object
+
+## Responses
+
+### default
+
+default response
+
+- **Content-Type**: `application/json` / `QueryResult`

package/build/dist/docs-index/6ddf45bc-a6a8-417b-8438-625edfd9a832.txt

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

package/build/dist/docs-index/7833b406-f19e-458c-9fd3-42f0ff01afff.txt

@@ -0,0 +1,171 @@
+Start, follow, and read Grepr AI agent investigations, guide a running one, understand each state, and review the pipeline changes an agent proposes.
+
+# Run and review investigations
+
+An *investigation* is one run of an agent. It holds the signals that triggered it, every turn the agent took, every tool it called, the changes it made outside the sandbox that Grepr recognizes, and the summary it finished with. Investigations are listed on the agent's **Investigations** step.
+
+An investigation is a record, not a conversation. You can interrupt one to add guidance, but most investigations run to completion unattended and you read them afterwards.
+
+## Start an investigation manually \[#start-manual]
+
+Start one manually to try out an agent before subscribing it to anything, or to point an agent at something you already know about.
+
+1. On the agent's page, click **Run investigation**.
+2. Optionally enter **Context**, which is what the agent starts from, such as the service to look at or the symptom you saw.
+3. Click **Start investigation**.
+
+Context is the only instruction an investigation started manually receives beyond the agent's system prompt, so include the service, the time range, and the symptom. An investigation with no context relies entirely on the agent's prompt to decide what to examine.
+
+An investigation you start manually is not subject to the maximum queue wait, but it is subject to the concurrency limit and the token budgets. When a budget is exhausted, a manual investigation is discarded rather than queued, so you find out immediately instead of waiting. See [_](/ai-agents/create-an-agent#limits).
+
+## Investigation states \[#states]
+
+| State | What it means | What you can do |
+| --- | --- | --- |
+| Queued | Accepted and waiting for a free slot on the agent. No sandbox exists yet. | Cancel it. |
+| Running | The agent is working. | Stop it or cancel it. |
+| Stopping | A stop was requested and is being applied. | Cancel it. |
+| Cancelling | A cancel was requested and is being applied. | Wait for it to finish. |
+| Stopped | Either paused and waiting for instruction, or ended after waiting too long. | Resume a paused one, or continue a finished one in a new investigation. |
+| Completed | The agent finished and wrote a summary. | Continue it in a new investigation. |
+| Failed | The investigation ended with an error. | Read the reason, then continue it in a new investigation. |
+| Cancelled | You cancelled it. | Continue it in a new investigation. |
+| Discarded | Recorded but never ran. | Read why, then address the cause. |
+
+Stopped covers two situations, and the status icon tells them apart. A stopped investigation that is still waiting for instruction is paused and can be resumed, carrying on from where it left off while its sandbox is still there. If the sandbox is lost while the investigation is paused, the resumed agent restarts from the triggering signals and whatever you resume it with, so give it what it needs rather than assuming it still remembers. One that waited too long without instruction has ended, and the work it did is readable but no longer resumable. So resume a stopped investigation while you still want its context, rather than leaving it paused indefinitely.
+
+Completed, Failed, Cancelled, Discarded, and a timed-out Stopped are final. Nothing restarts them, though you can start a fresh investigation seeded with what one learned. See [Continue in a new investigation](#continue).
+
+## Read an investigation \[#read]
+
+Open an investigation from the agent's **Investigations** step. It reads top to bottom: what the agent concluded, what set it off, then how it got there.
+
+### The summary \[#summary]
+
+A finished investigation opens with the agent's own account of what it found. An investigation that failed or was discarded carries the reason it ended instead of a conclusion, which is the first thing to read when a run did not work.
+
+The summary is what the agent wrote for you to read, so it is the part to read when you want the conclusion. Read the timeline when you want to check the conclusion.
+
+### The triggering signal \[#trigger]
+
+The triggering signal is the event that started the run. A webhook signal shows the payload the sending system posted. A log pattern signal shows the pattern the reducer detected and a sample log line that matched it. An investigation you started manually shows the context you typed.
+
+Read the signal when a conclusion surprises you. An agent reasoning from a payload whose fields it cannot interpret often produces a plausible but wrong summary, and the fix is usually the integration's schema description rather than the agent's prompt. See [_](/integrations/grepr-agent-webhooks#schema-description).
+
+### The timeline \[#timeline]
+
+The timeline is every step in order: what the agent was told, what it said, each tool it called with the arguments it passed, and what each tool returned. Tool output is collapsed, so you can scan the shape of a run and expand only the calls that matter. Each call reports how long it took.
+
+Read the timeline to answer why an agent concluded what it did. Two patterns are worth recognizing:
+
+* Repeated similar tool calls usually mean the agent is missing a capability or some knowledge, and is working around the gap. Consider enabling a skill that covers the task or using a better model.
+* A run that ends without a conclusion usually means it reached its turn or token limit. The last turn shows where it was.
+
+### Recorded actions \[#actions]
+
+An *action* is a consequential change the agent made outside its own sandbox: a pipeline version it applied, a pipeline change it proposed for review, or a write it made through a connected MCP integration. Reads are not actions, and neither is everything an agent can do from a shell, so treat the count as a record of the changes Grepr recognizes rather than a complete audit. Actions appear beneath the tool call that made them and are counted in the **Actions** column of the list, so you can find the investigations that changed something without reading any transcripts.
+
+Actions record successful changes, not attempts. A tool call that failed appears in the timeline but produces no action.
+
+## Guide a running investigation \[#guide]
+
+### Stop and resume \[#stop-resume]
+
+Stopping ends the agent's session and pauses the investigation. Work already in flight is abandoned rather than finished, so a tool call that was running might not complete. Everything the investigation had recorded up to that point is kept, which is what a resume continues from.
+
+To continue it, click **Resume**. You can add a message to steer it, such as naming the service it should focus on, or resume with no message to let it carry on. Stop and resume when an agent is heading the wrong way but its work so far is worth keeping.
+
+### Cancel \[#end-for-good]
+
+Cancelling ends an investigation for good. Use it when the run is not worth finishing. The transcript remains readable.
+
+To cancel several at once, select them in the list and cancel the selection. This is how you clear a backlog that built up, such as from a misconfigured source. Cancelling is permanent, and an investigation that has already finished is left alone.
+
+### Continue in a new investigation \[#continue]
+
+A finished investigation cannot be resumed, but you can start a new one seeded from it. The new investigation begins with the earlier conversation, and you can add a message to direct it, such as asking it to verify that a change worked.
+
+The seed carries what the agent and you said to each other, not the tool calls it made or the results they returned, and a long conversation is trimmed to its most recent part. Put anything the new investigation must not lose into the message you start it with.
+
+Use this to carry an investigation forward after you have acted on it, rather than starting from nothing and paying for the same discovery twice.
+
+## Find investigations \[#find]
+
+The list holds one row per investigation, with its identifier, what triggered it, its summary, when it was created, how long it ran and how long it waited in the queue, its state, and how many actions it recorded.
+
+Three filters narrow it:
+
+* **Status** limits the list to the states you select.
+* **Actions** separates investigations that recorded a change from those that did not.
+* **Trigger** limits the list to investigations started manually, by a webhook, or by a log pattern.
+
+Filter on recorded actions when you want to review what an agent has changed, and on failed status when you are diagnosing an agent that is not working.
+
+## Why an investigation was discarded \[#discarded]
+
+A discarded investigation was recorded but never ran. There are three reasons, and each has a different fix:
+
+| Reason | What to do |
+| --- | --- |
+| The agent was at its concurrency limit and set to discard extra signals. | Raise the concurrency limit, switch to queueing, or reduce what the source emits. |
+| A queued investigation waited longer than the maximum queue wait. | Raise or remove the maximum queue wait, or raise the concurrency limit so the queue drains faster. |
+| A token budget was exhausted. | Raise the budget that blocked it, or wait for the window to reset. Check which budget it was on the agent's page. |
+
+A rise in discarded investigations usually means a source is emitting more than the agent can handle. Reducing what the source emits keeps the signal you want, whereas raising the limits keeps the volume and increases the cost. See [_](/ai-agents/subscriptions#volume).
+
+## Review the pipeline changes an agent proposes \[#suggestions]
+
+An agent set to require human approval records each pipeline change it proposes as a *suggestion* on that pipeline, and changes nothing until you apply it. Suggestions are on the pipeline's **Suggestions** step, not on the agent, because the decision is about the pipeline.
+
+Each suggestion lists when it was proposed, what it changes, and the investigation that produced it. To decide, review the proposed change as a difference against the pipeline's configuration, and read the investigation that produced it to see the evidence the agent based it on.
+
+Then either apply it or reject it:
+
+* Applying re-verifies the change against the pipeline's configuration as it is now, not as it was when the agent proposed it, and a running pipeline then restarts to pick it up. A suggestion whose assumptions no longer hold is refused rather than applied blindly, and it stays pending, so you can retry it after the pipeline settles.
+* Rejecting leaves the pipeline untouched and closes the suggestion.
+
+Reviewing a suggestion changes nothing on the live pipeline, so read as many as you like before deciding. Suggestions do not expire, but an old one is more likely to be refused on apply, because the pipeline's configuration has likely drifted. Review them while they still match the pipeline.
+
+To let an agent apply its own changes instead, see [_](/ai-agents/capabilities#change-approval).
+
+## Read investigations from the CLI \[#cli]
+
+The Grepr CLI reads investigations, which is useful for auditing many runs at once or feeding them into your own tooling.
+
+```bash
+# List an agent's failed investigations
+grepr investigation:list --agent-id <agent-id> --status FAILED --page-size 10
+
+# Read one investigation's metadata, summary, and recorded actions
+grepr investigation:get <investigation-id>
+
+# Read the turns, including tool calls and their results
+grepr investigation:turns <investigation-id> --page-size 10
+
+# Export a transcript to a file
+grepr investigation:transcript <investigation-id> --all --output investigation.json
+```
+
+To follow a running investigation as it progresses, add `--follow` to `investigation:turns`. To learn more about the CLI, see [_](/cli).
+
+## Frequently Asked Questions
+
+### How do I start a Grepr AI agent investigation manually?
+
+On the agent's page, click Run investigation, optionally enter the context the agent should start from, and click Start investigation. Context is the only instruction beyond the agent's system prompt, so include the service, the time range, and the symptom.
+
+### What does a stopped investigation mean in Grepr?
+
+Stopped covers two situations. An investigation that is still waiting for instruction is paused and can be resumed, carrying on from where it left off while its sandbox is still there. If the sandbox is lost while it is paused, the resumed agent restarts from the triggering signals and the message you resume it with. One that waited too long without instruction has ended, and remains readable but is no longer resumable. The status icon tells the two apart.
+
+### Can I resume a completed Grepr AI agent investigation?
+
+No. Completed, failed, cancelled, discarded, and timed-out stopped investigations are final. You can start a new investigation seeded from the finished one, and add a message to direct it, such as asking it to verify that a change worked.
+
+### Why was my investigation discarded?
+
+There are three reasons: the agent was at its concurrency limit and set to discard extra signals, a queued investigation waited longer than the maximum queue wait, or a token budget was exhausted. The agent's page reports which token budget blocked it and when the window resets.
+
+### How do I review a pipeline change proposed by a Grepr AI agent?
+
+Suggestions appear on the pipeline's Suggestions step. Review the proposed change as a difference against the current configuration and read the investigation that produced it, then apply or reject it. Applying re-verifies the change against the pipeline as it is now, and a running pipeline restarts to pick it up. A suggestion that no longer verifies is refused and stays pending, leaving the pipeline untouched.

package/build/dist/docs-index/78ea24e3-ec7a-4360-bd35-66fd215dbfa3.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/79ca0e6e-3720-482a-9f98-3039c024c610.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.