@grepr/cli 1.11.5-a603268 → 1.11.5-b97c32b

package/build/dist/docs-index/1206c19d-6eb3-4c60-99e7-37a3d6f369f0.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.

package/build/dist/docs-index/152b94df-8f83-43f0-8a0d-7ba78d3c2e15.txt

@@ -0,0 +1,17 @@
+# CreateVendorEstimationRunRequest
+
+**Type**: `object`
+
+## Properties
+
+- name: scopeQuery (optional)
+  type: string
+  description: Vendor query limiting the estimate to part of the customer's traffic. Applied to both the matched count and the total. Leave empty for all logs.
+
+- name: windowEnd (required)
+  type: string
+  description: Absolute end of the window to count over; must be after the start and not in the future
+
+- name: windowStart (required)
+  type: string
+  description: Absolute start of the window to count over

package/build/dist/docs-index/1533d7bd-5726-42ea-9e61-ddcd4d3b4a98.txt

@@ -0,0 +1,136 @@
+Control what a Grepr AI agent can reach with a service account, tools, skills, and MCP integrations, and whether its pipeline changes need approval.
+
+# Control what an AI agent can do
+
+An agent's reach is bounded in layers, and a capability has to be allowed by every layer to work:
+
+1. The **service account** the agent acts as. Its roles are the outer boundary and cap everything the agent can reach in Grepr.
+2. The **tools and skills** you enable. These narrow the agent to specific operations within what the service account permits.
+3. The **MCP integrations** you enable, and the tools you allow on each. These decide what the agent can reach in other systems.
+
+A fourth setting, the change approval mode, decides whether the agent can make automatic changes to your pipeline.
+
+These settings are on the agent's **Capabilities** step, and on the matching step of the create wizard.
+
+## Choose the service account an agent acts as \[#service-account]
+
+Every call an agent makes to Grepr authenticates as the service account you select in the **Service account** field. The service account's roles decide which pipelines, datasets, and integrations the agent can read and write to.
+
+The service account is the boundary that holds even if a tool grant is over-permissive. An agent with the pipeline editing tool but a service account that can only view jobs cannot change a pipeline. Grant the narrowest role that lets the agent finish its job. To create one, see [_](/admin/service-accounts).
+
+If the **Service account** menu is empty, create a service account before you continue.
+
+## What every agent can already do \[#sandbox-baseline]
+
+Each investigation runs in its own sandbox, and inside that sandbox an agent can:
+
+* Run shell commands.
+* Run Python for local analysis and scripting.
+* Query files it downloaded with DuckDB.
+* Read, create, and edit files in its own workspace.
+
+These are part of the sandbox and cannot be turned off. They act only on the sandbox, which is discarded when the investigation ends, so they do not reach your data or your pipelines. Everything that does reach Grepr is granted separately, as described next.
+
+## Grant access to Grepr with tools and skills \[#grepr-access]
+
+The **Grepr access** section is where you decide what the agent can do. You grant access in two ways, and most agents use both:
+
+* Enable a skill, which gives the agent guidance for a task and, when the skill needs them, the tools that task requires.
+* Pin an individual tool, which grants that tool with no accompanying guidance.
+
+Prefer skills. A skill tells the agent how to use what it grants, so an agent with a skill usually needs fewer turns than one holding the bare tool. Pin a tool when you want a capability that no skill attached covers.
+
+### Abilities and reference skills \[#skill-kinds]
+
+Skills are grouped by whether enabling one is a permission decision:
+
+* **Abilities** carry tools. Enabling one grants the agent the operations that skill needs, so treat it as granting access.
+* **Reference** skills carry only knowledge. Enabling one changes what the agent knows, never what it can do, so it is safe to enable freely.
+
+To read what a skill covers and what it grants before you enable it, open its detail from the selector. To learn what skills exist and how to write your own, see [_](/ai-agents/skills).
+
+### How much a skill grants \[#grant-scope]
+
+How wide a skill's grant is depends on its scope, and the difference matters when you are reasoning about least privilege:
+
+* A **platform skill**, which Grepr maintains, grants exactly the operations its definition lists. A skill that needs only to preview a pipeline change gets the preview operation and not the one that applies it.
+* An **organization skill**, which you create, grants the whole *tool family* behind each tool you approve on it, meaning every operation that tool covers rather than only the ones the skill uses. Approving the pipeline editing tool on your own skill grants everything that tool covers, not only the part your instructions use.
+
+So an organization skill is as broad as the tools you approve on it. To keep a grant narrow, approve fewer tools on the skill rather than relying on the skill's instructions to limit the agent.
+
+Enabling a tool directly always grants its whole family, the same way an organization skill does.
+
+### Tool reference \[#tool-table]
+
+| Tool | What it lets the agent do |
+| --- | --- |
+| `query_logs` | Query the logs in your Grepr datasets. |
+| `get_pipeline` | Read the configuration of your pipelines and templates. |
+| `edit_pipeline` | Propose a change to a pipeline's configuration, and preview a change before proposing it. |
+| `grok` | Build and test Grok parsers. |
+| `datasets` | List, read, and manage your Grepr datasets. |
+| `integrations` | List and read your Grepr integrations. |
+| `docs` | Search the Grepr documentation and validate SQL. |
+| `backfill` | Replay logs from the data lake to a vendor destination. |
+| `investigations` | Read agent configuration, past investigations, and their transcripts. |
+| `github_code` | Clone, edit, and publish source repositories. Requires an enabled GitHub MCP integration. |
+
+An agent's pipeline changes are scoped to a pipeline's Grok parsers and its SQL transforms, so granting the pipeline editing tool keeps the rest of the pipeline configuration out of the agent's reach. Both are add-only. An agent can add a Grok rule or add a SQL transform, and it cannot change or remove one that is already there, so its proposals accumulate alongside your configuration rather than rewriting it.
+
+A SQL transform an agent adds is a filter and nothing further. It reads the pipeline's logs and selects them unchanged against a single condition, so it cannot join, aggregate, read a dataset, register a function, or keep state. It routes the events it matches to the agent signal sink, which you configure yourself when you set the pipeline up. An agent can add routes to that sink, and it cannot create, change, or remove the sink. That limit is on what an agent adds by itself. A SQL output you route to the agent signal sink yourself carries no such restriction, so you can build the event an agent receives however you need. See [_](/ai-agents/subscriptions#agent-signal-sink).
+
+The tools an agent uses to record and search its memory are not in this list. They are granted by the agent's memory settings instead, so that turning memory on is the single decision that controls them. See [_](/ai-agents/memory).
+
+## Let an agent call an MCP server's tools \[#mcp-integrations]
+
+The **MCP integrations** section lists the MCP integrations in your organization and which of their tools the agent can use. Two agents can share one integration with different tool access enabled.
+
+Edit the integration's allowed tools and choose either every tool the server publishes or only the ones you select. Grepr reads the tool list from the server and marks each tool as read only or writing; for example, you can allow an agent to read incidents without allowing it to change them.
+
+Allowing every tool means the agent gains any tool the server adds later, which is convenient for a read-only server and worth avoiding for one that can make changes. Selecting individual tools keeps the enabled tools fixed until it is manually changed.
+
+Two rules apply to GitHub:
+
+* An agent can enable at most one GitHub MCP integration.
+* The `github_code` tool needs an enabled GitHub MCP integration, because that integration is how it reaches source code.
+
+To create an integration, see [_](/integrations/mcp).
+
+## Decide whether pipeline changes need approval \[#change-approval]
+
+An agent that decides a pipeline needs a configuration update does not edit it directly. It submits the change, and the **Pipeline changes** setting decides what happens next:
+
+| Mode | What happens when the agent proposes a change |
+| --- | --- |
+| **Require human approval** | Grepr records the change as a suggestion on the pipeline. Nothing changes until you review and apply it. |
+| **Auto-apply** | Grepr verifies the change and applies it. A running pipeline restarts to pick it up. No person is involved. |
+
+**Require human approval** is the default, and it is the right setting while you are learning how an agent behaves. Auto-apply an agent's changes only after its suggestions have consistently been ones you would have made yourself.
+
+Grepr enforces the mode at the operation level, so while an agent can always preview pipeline changes, it cannot bypass **Require human approval** to apply them.
+
+A change that lands on a running pipeline restarts it, which interrupts processing briefly.
+
+To review suggestions, see [_](/ai-agents/investigations#suggestions).
+
+## Frequently Asked Questions
+
+### How do I limit what a Grepr AI agent can reach?
+
+Reach is bounded in layers. The service account the agent acts as is the outer boundary and caps everything it can reach in Grepr. Within that, the tools and skills you enable narrow it to specific operations, and the MCP integrations you enable with their allowed tools decide what it can reach in other systems.
+
+### What can a Grepr AI agent do without any tools enabled?
+
+Inside its own sandbox it can always run shell commands and Python, query downloaded files with DuckDB, and read and write files in its workspace. These act only on the sandbox, which is discarded when the investigation ends, and they do not reach your data or pipelines.
+
+### What is the difference between an ability and a reference skill?
+
+An ability carries tools, so enabling one grants the agent the operations that skill needs and is a permission decision. A reference skill carries only knowledge, so enabling one changes what the agent knows but never what it can do.
+
+### Do platform skills and organization skills grant the same access?
+
+No. A platform skill grants exactly the operations its definition lists, which can be narrower than a whole tool. An organization skill grants the whole tool family behind each tool you approve on it, so keep its grant narrow by approving fewer tools.
+
+### Can a Grepr AI agent change my pipeline without approval?
+
+Only when you set its change approval mode to Auto-apply. The default, Require human approval, records every proposed change as a suggestion for you to review. Grepr enforces the mode server-side, so an agent has no route around it whatever its instructions say.

package/build/dist/docs-index/19f3545a-2f34-4174-b723-d0a4b85afc4c.txt

@@ -0,0 +1,40 @@
+# Pause or resume an agent's pipeline subscription
+
+**PUT** `/v1/agents/{id}/pipelines/{jobId}/state`
+
+**Operation ID**: `setPipelineState`
+**Summary**: Pause or resume an agent's pipeline subscription
+Sets one subscription to PAUSED or ACTIVE. While paused, new signals from the pipeline are dropped for this agent, and the pipeline keeps marking new patterns as sent. Investigations already queued still run. The running pipeline is not restarted.
+
+## Tags
+- Agents
+## Parameters
+
+- **id** (required) - path
+  - Type: string
+- **jobId** (required) - path
+  - Type: string
+
+## Request Body
+
+**Content-Type**: `application/json`
+
+**Schema**: `StateChangeRequest`
+
+## Responses
+
+### 204
+
+State set (or already set)
+
+### 400
+
+The state is not ACTIVE or PAUSED
+
+### 401
+
+Unauthorized
+
+### 404
+
+Agent not found, or not subscribed to the pipeline

package/build/dist/docs-index/1f1333ce-d787-4c14-949d-288f102c2099.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/1f1c24f4-f82a-464c-91b8-b1eaa48ef8ac.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/20f6c1b9-74a9-4604-a792-53eb68693059.txt

@@ -0,0 +1,11 @@
+# PromotionPolicyAttributeExclude
+
+**Type**: `object`
+
+## Properties
+
+- name: path (required)
+  type: string
+
+- name: prefix (optional)
+  type: boolean

package/build/dist/docs-index/23cb153e-fa0a-46f3-968b-6738a4bdbc94.txt

@@ -0,0 +1,102 @@
+Learn how Grepr indexes log attributes and tags as columns in the data lake, and the rules that decide which fields each dataset indexes.
+
+# Indexed columns
+
+Grepr stores each raw log's attributes as one JSON document and its tags as a map. A search that filters on one attribute reads every log's whole attribute document to find a match.
+
+An *indexed column* removes that cost for one field. Grepr writes the field into its own column in the dataset's data lake table, so a search that filters on the field reads that column and skips the files that can't contain a match. See [The Grepr data lake](/grepr-platform/data-lake).
+
+Searches don't change. The same search returns the same results whether or not a field is indexed, and runs faster when it is.
+
+## What Grepr indexes
+
+Each dataset's raw log table has indexing settings for two groups of fields:
+
+* Attributes, named by their dotted path, such as `http.method` or `kube.pod.name`. An indexed path has a column for its value, and a path that holds numbers can also have a numeric column, so that range filters skip files too.
+* Tags, named by their key, such as `region` or `pod_name`. An indexed tag key has a column for its value.
+
+Grepr always indexes the `service` and `host` tags, whatever the settings say.
+
+For each group, you choose whether Grepr discovers new fields, which fields it always indexes, and which fields it never indexes.
+
+## Discovery \[#discovery]
+
+When discovery is on, Grepr adds a column for a new field it finds in your logs, until the group has as many columns as its *discovery cap*. Your organization sets the largest cap you can choose. The tag cap doesn't count `service` and `host`.
+
+Discovery is off for a new dataset, so until you turn it on, Grepr indexes only `service`, `host`, and the fields on the always-index lists.
+
+When discovery is on and Grepr finds a number at an indexed path, the path also gets a numeric column. A numeric column doesn't count toward the cap.
+
+Turning discovery off stops Grepr from adding columns. Columns the table already has keep being written. To stop writing a column, add the field to the never-index list.
+
+## Always index and never index \[#lists]
+
+Grepr indexes a field on an always-index list whether discovery is on or off, and whether or not the group has reached its cap. Grepr stops writing a field on a never-index list.
+
+For attribute paths:
+
+* A path matches exactly and is case-sensitive. Write the path as it appears in the log.
+* An entry that includes nested paths covers the path and every path under it, split at dots. For example, `kube` with nested paths covers `kube` and `kube.pod.name`, but not `kubernetes`. Wildcards aren't supported.
+* An always-index entry marked numeric gets its numeric column the next time a pipeline writes the path, whether or not discovery is on. Use it for values that are numbers written as strings.
+* When a path is on both lists, always index wins. To stop indexing a subtree except for one path, add the subtree to the never-index list with nested paths, and add the one path to the always-index list.
+
+For tag keys:
+
+* A key matches exactly.
+* A key can't be on both lists.
+* `service`, `host`, and any key the table is partitioned on can't be on the never-index list.
+* To partition a table on a tag key, the key must be on the always-index list, and it stays there while the table is partitioned on it.
+
+## When changes take effect
+
+A change reaches running pipelines within about a minute, without a restart. A tag key you add to the always-index list gets its column when you save, so you can partition on it immediately. An attribute path gets its column the next time a pipeline writes a log that has it.
+
+## Excluded fields and removed columns \[#excluded]
+
+Grepr doesn't drop an indexed column. When you add a field to a never-index list, Grepr stops writing the field's column for new logs, and searches read the field from the log's attributes or tags instead, so they return the same results. The column and the data already written stay in the table, and the column still counts toward the discovery cap. To have columns removed, contact <support@grepr.ai>.
+
+## Change indexing through the API
+
+Reading a table's configuration returns its indexing settings with a `revision`. To change them, send the complete settings for both groups to the promotion endpoint, which replaces what's stored. Include the `revision` you read: if the settings changed since then, the request fails with a 409 error, and you read them again before you retry. Without a `revision`, the request replaces the stored settings whatever they are. See the [Datasets specification](/apis/api-spec#tag/Datasets).
+
+## Frequently Asked Questions
+
+### What is an indexed column in Grepr?
+
+An indexed column is a log attribute path or tag key that Grepr writes into its own column in the dataset's data lake table, instead of leaving it only in the log's attribute document or tags. Searches that filter on the field read that column and skip files that can't match, which makes them faster.
+
+### Do I have to list the fields I want indexed?
+
+No, if you turn on discovery. Grepr then adds a column for each new field it finds, up to the discovery cap. Discovery is off for a new dataset. List a field on the always-index list to index it whether or not discovery is on.
+
+### Do my searches change when a field is indexed?
+
+No. The same search returns the same results whether or not a field is indexed, and runs faster when it is.
+
+### What happens when I turn discovery off?
+
+Grepr stops adding columns. Every column the table already has keeps being written, and fields on the always-index list keep their columns.
+
+### How do I stop Grepr from writing a column?
+
+Add the field to the never-index list. Turning discovery off doesn't do it, because that only stops new columns. The column stays in the table, and the data already written stays searchable.
+
+### What if an attribute path is on both the always-index and never-index lists?
+
+Always index wins. You can exclude a subtree with a nested-paths entry and keep one path inside it indexed. A tag key can't be on both lists.
+
+### When do indexing changes take effect?
+
+Within about a minute on running pipelines, without a restart. A tag key you add gets its column when you save. An attribute path you add gets its column the next time a pipeline writes a log that has it.
+
+### Can I delete an indexed column?
+
+No. Adding the field to the never-index list stops Grepr from writing it, but the column stays in the table, the data already written stays searchable, and the column still counts toward the discovery cap. Contact support\@grepr.ai if you need columns removed.
+
+### Can I stop indexing service and host?
+
+No. Grepr always indexes the service and host tags, and neither key can be on the never-index list.
+
+### What does marking an always-index path numeric do?
+
+The path gets its numeric column the next time a pipeline writes it, whether or not discovery is on. Use it for values that are numbers written as strings.