@grepr/cli 1.11.5-1e100fc → 1.11.5-20d1a69

package/build/dist/docs-index/aaac445d-0985-4128-bb55-3ce8ffd99ec5.txt

@@ -0,0 +1,59 @@
+# ReadOrgConstraints
+
+**Type**: `object`
+
+## Properties
+
+- name: maxAnthropicIntegrations (optional)
+  type: integer
+
+- name: maxDataWarehouseIntegrations (optional)
+  type: integer
+
+- name: maxDatadogApiKeysPerIntegration (optional)
+  type: integer
+
+- name: maxDatadogIntegrations (optional)
+  type: integer
+
+- name: maxGeminiIntegrations (optional)
+  type: integer
+
+- name: maxLiteLlmIntegrations (optional)
+  type: integer
+
+- name: maxMcpIntegrations (optional)
+  type: integer
+
+- name: maxNewRelicIntegrations (optional)
+  type: integer
+
+- name: maxOpenAiIntegrations (optional)
+  type: integer
+
+- name: maxOtlpIntegrations (optional)
+  type: integer
+
+- name: maxPipelines (optional)
+  type: integer
+
+- name: maxPromotedAttributeColumns (optional)
+  type: integer
+
+- name: maxPromotedTagColumns (optional)
+  type: integer
+
+- name: maxPromotionPolicyEntriesPerList (optional)
+  type: integer
+
+- name: maxS3DataWarehouseIntegrations (optional)
+  type: integer
+
+- name: maxS3VectorIndexIntegrations (optional)
+  type: integer
+
+- name: maxSplunkIntegrations (optional)
+  type: integer
+
+- name: maxSumoIntegrations (optional)
+  type: integer

package/build/dist/docs-index/ab5b5225-9232-429f-a087-1a5748b2b6ba.txt

@@ -0,0 +1,31 @@
+# Get a dataset table config
+
+**GET** `/v1/datasets/{id}/{tableKey}/config`
+
+**Operation ID**: `getTableConfig`
+**Summary**: Get a dataset table config
+Returns the configuration for one of the dataset's tables (e.g. logs_raw), including the system-controlled effective partition spec. Without an override, the spec's editable rows are the table's defaults.
+
+## Tags
+- Datasets
+## Parameters
+
+- **id** (required) - path
+  - Type: string
+- **tableKey** (required) - path
+  - Type: string
+
+## Responses
+
+### 200
+
+The table config, with effectiveSpec always populated.
+
+- **Content-Type**: `application/json` / `TableConfigRead`
+### 400
+
+Unsupported table key.
+
+### 404
+
+Dataset not found.

package/build/dist/docs-index/affdebce-33db-42db-ac12-6c1b667d706d.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/b270310e-d3a3-4586-9e25-cf507c830361.txt

@@ -0,0 +1,158 @@
+A reference for the permission types in the Grepr platform, and which permissions are assigned to different roles.
+
+# Permissions in the Grepr platform
+
+This page is a reference to the permissions available in the Grepr platform. These permissions are assigned to users based on the user's role:
+
+* Organization-level roles: Admin, Member, and Reader
+* Team-level roles: Leader and Member
+
+A user can be assigned both an organization-level role and a team-level role. For example, an organization Member can also be a team Leader, giving them view access organization-wide and edit access to their team's resources.
+
+You can also create custom roles with a specific subset of Grepr platform permissions. To learn more about roles, including custom roles, see [Manage users in the Grepr platform](/admin/manage-users).
+
+At both the organization and team levels, there are three types of permissions:
+
+* View: Grants read-only access to specified resources.
+* Edit: Grants edit permissions over specified resources, including creating, editing, and deleting those resources.
+* Write: Grants permission to send data through an integration when the integration is used as a sink in a job, such as a backfill job that writes data to a vendor integration. Edit permission on an integration controls the integration's configuration. Write permission on an integration controls whether you can send data through it.
+
+Resources in the Grepr platform include your organization, vendor, and storage integrations, datasets, templates, users, teams, and jobs.
+
+The following sections provide more details on permissions in the Grepr platform and the permissions for each role type.
+
+## Available permissions in the Grepr platform
+
+This table lists all available permissions for organization and team-level roles:
+
+| Permission | Resource | Scope |
+| --- | --- | --- |
+| Edit | Organization settings | Organization |
+| View | Organization settings | Organization or Team |
+| Edit | Integrations | Organization or Team |
+| View | Integrations | Organization or Team |
+| Write | Integrations | Organization or Team |
+| Edit | Jobs | Organization or Team |
+| View | Jobs | Organization or Team |
+| Edit | Users | Organization |
+| View | Users | Organization or Team |
+| Edit | Teams | Organization or Team |
+| View | Teams | Organization or Team |
+| Edit | Templates | Organization or Team |
+| View | Templates | Organization or Team |
+| Edit | Datasets | Organization or Team |
+| View | Datasets | Organization or Team |
+
+## Permissions for AI agent resources \[#ai-agent-permissions]
+
+AI agents, skills, and agent memory do not have permissions of their own. They are governed by the permissions already in the table:
+
+| To do this | You need |
+| --- | --- |
+| View an agent, its investigations, or its skills | View on integrations |
+| Create, edit, or delete an agent or an organization skill | Edit on integrations |
+| Create or edit an LLM, MCP, or Grepr Agent integration | Edit on integrations |
+| Subscribe an agent to a pipeline, or unsubscribe it | Edit on jobs |
+| View the pipeline changes an agent proposed | View on jobs |
+| Apply or reject a pipeline change an agent proposed | Edit on jobs |
+
+An agent's own reach is separate from yours. An agent acts as the service account you assign it, and that account's roles cap what the agent can read and change, whatever tools it holds. To learn more, see [_](/ai-agents/capabilities#service-account).
+
+## Permissions by role
+
+The following are the permissions granted to each role type in the Grepr platform:
+
+* Organization Admins have full control over all resources in the organization, including all team-scoped resources, and can write to any vendor integration.
+* Organization Members have view-only permissions to all resources in the organization, and have write permission on all vendor integrations so they can run backfill jobs.
+* Organization Readers have view-only permissions to all resources in the organization. Readers can query logs, but cannot create or edit any resources and cannot run backfill jobs that send data to a vendor integration.
+* Team Leaders have edit permissions for all resources scoped to their specific team or teams. This includes permissions to create and edit jobs, integrations, templates, and datasets assigned to the team, and to write to integrations assigned to the team. Team Leaders can also view all organization resources but only edit resources scoped to their team or teams.
+* Team Members have view-only permissions to resources scoped to their specific team or teams, plus write permission on integrations assigned to the team so they can run backfill jobs. A team Member can view resources assigned to the team and query logs, but does not have permission to create or edit resources, such as jobs, integrations, templates, or datasets, assigned to the team.
+* Teams can be granted access to resources, such as integrations, datasets, or templates, scoped at the organization level. When a team is granted access to a resource, team Leaders have edit permissions on the resource, and team Members have view-only permissions. However, to create or edit a job, such as a pipeline, a team Leader must have view permissions on all the integrations and datasets used by the job, and write permission on every vendor integration the job uses as a sink. For example, if a job is assigned to the `DevOps` team, but the team hasn't been granted access to an integration used in the job, a `DevOps` team Leader cannot edit or run the job.
+* To create a dataset, you must have edit permission on the integration the dataset belongs to.
+
+For each resource in the Grepr platform, this table shows the specific permissions granted to each role type at both the organization and team levels:
+
+| Permission | Resource | Access Scope | Organization Admin | Organization Member | Organization Reader | Team Leader | Team Member |
+| --- | --- | --- | --- | --- | --- | --- | --- |
+| View | Organization Settings | Organization | ✅ | ✅ | ✅ | ✅ | ✅ |
+| Edit | Organization Settings | Organization | ✅ | ❌ | ❌ | ❌ | ❌ |
+| View | Users | Organization | ✅ | ✅ | ✅ | ✅ | ❌ |
+| Edit | Users | Organization | ✅ | ❌ | ❌ | ❌ | ❌ |
+| View | Teams | Organization | ✅ | ✅ | ✅ | ✅ | ❌ |
+| Edit | Teams | Organization | ✅ | ❌ | ❌ | ❌ | ❌ |
+| View | Integrations | Organization | ✅ | ✅ | ✅ | ❌ | ❌ |
+| Edit | Integrations | Organization | ✅ | ❌ | ❌ | ❌ | ❌ |
+| Write | Integrations | Organization | ✅ | ✅ | ❌ | ❌ | ❌ |
+| View | Datasets | Organization | ✅ | ✅ | ✅ | ❌ | ❌ |
+| Edit | Datasets | Organization | ✅ | ❌ | ❌ | ❌ | ❌ |
+| View | Jobs | Organization | ✅ | ✅ | ✅ | ❌ | ❌ |
+| Edit | Jobs | Organization | ✅ | ❌ | ❌ | ❌ | ❌ |
+| View | Templates | Organization | ✅ | ✅ | ✅ | ✅ | ❌ |
+| Edit | Templates | Organization | ✅ | ❌ | ❌ | ❌ | ❌ |
+| View | Teams | Team | ✅ | ✅ | ✅ | ✅ | ✅ |
+| Edit | Teams | Team | ✅ | ❌ | ❌ | ✅ | ❌ |
+| View | Integrations | Team | ✅ | ✅ | ✅ | ✅ | ✅ |
+| Edit | Integrations | Team | ✅ | ❌ | ❌ | ✅ | ❌ |
+| Write | Integrations | Team | ✅ | ✅ | ❌ | ✅ | ✅ |
+| View | Datasets | Team | ✅ | ✅ | ✅ | ✅ | ✅ |
+| Edit | Datasets | Team | ✅ | ❌ | ❌ | ✅ | ❌ |
+| View | Jobs | Team | ✅ | ✅ | ✅ | ✅ | ✅ |
+| Edit | Jobs | Team | ✅ | ❌ | ❌ | ✅ | ❌ |
+| View | Templates | Team | ✅ | ✅ | ✅ | ✅ | ✅ |
+| Edit | Templates | Team | ✅ | ❌ | ❌ | ✅ | ❌ |
+
+## Organization roles vs. team roles
+
+This table describes the difference between organization-level and team-level roles. Users can have both types of roles:
+
+\| | Organization roles | Team roles | | :-------- | :----------------------------------------------------- | :------------------------------------------ | | Scope | Entire organization | A specific team | | Types | Admin, Member, Reader, or Custom Roles | Leader or Member | | Examples | - Admin: Full access to all resources and settings.\
+\- Member: View organization resources and run backfill jobs.\
+\- Reader: View organization resources and query logs only; no backfills to vendor integrations.\
+\- Custom role, such as "Developer": Specific permissions like "view all jobs, edit templates". | - Leader: Manage team members, create team-scoped integrations.\
+\- Member: View team resources and run backfill jobs to team integrations. |
+
+## Frequently Asked Questions
+
+### What are the main permission types in Grepr?
+
+The main permission types are View (grants read-only access to specified resources), Edit (grants permissions to create, edit, and delete specified resources), and Write (grants permission to send data through an integration when the integration is used as a sink in a job, such as a backfill). These permissions are assigned based on user roles at both organization and team levels.
+
+### What are organization-level roles?
+
+Organization-level roles control access across the entire organization. The standard roles are Admin (full control over all resources), Member (view access plus permission to run backfill jobs), and Reader (view-only access; no backfills to vendor integrations). You can also create custom roles with specific subsets of permissions tailored to your organization's needs.
+
+### What are team-level roles?
+
+Team-level roles control access to resources within a specific team. There are two team roles: Leader (edit permissions for team-scoped resources and view permissions for organization resources) and Member (view-only permissions for team resources). A user can be assigned to multiple teams with different roles.
+
+### Can a user have both organization and team roles?
+
+Yes, users can have both organization-level and team-level roles simultaneously. For example, a user can be an organization Member for organization-wide access while also being a Team Leader for a specific team, granting them edit access to that team's resources.
+
+### What resources can be controlled with Grepr permissions?
+
+Grepr permissions can control access to: organization settings, integrations (observability and storage), jobs, users, teams, templates, and datasets. Each resource can have view or edit permissions assigned at organization or team scope.
+
+### What permissions does an Organization Admin have?
+
+Organization Admins have full control over all resources in the organization, including all team-scoped resources. They can create, edit, and delete any resource, manage users, configure organization settings, and manage all integrations and datasets.
+
+### What permissions does an Organization Member have?
+
+Organization Members have view permissions to all resources in the organization, plus write permission on integrations so they can run backfill jobs. They can view integrations, datasets, jobs, users, and teams and write data through any vendor integration, but cannot create, edit, or delete any resources at the organization level.
+
+### What permissions does an Organization Reader have?
+
+Organization Readers have view-only permissions to all resources in the organization and can query logs. Readers cannot create, edit, or delete any resources, and cannot run backfill jobs that send data to a vendor integration. Use the Reader role for users who need to investigate data without incurring vendor write costs.
+
+### What permissions does a Team Leader have?
+
+Team Leaders have edit permissions for all resources scoped to their specific team(s), including creating and editing jobs, integrations, templates, and datasets. They can also view all organization resources but can only edit resources scoped to their team. Team Leaders can also manage team members.
+
+### What permissions does a Team Member have?
+
+Team Members have view permissions to resources scoped to their team, plus write permission on integrations assigned to the team so they can run backfill jobs. They can view jobs, integrations, templates, and datasets assigned to the team, query logs, and run backfills to team integrations, but cannot create or edit any resources.
+
+### What is a custom role in Grepr?
+
+Custom roles allow you to create roles with a specific subset of Grepr platform permissions tailored to your organization's needs. Instead of using standard roles, you can create custom roles like 'Developer' with permissions such as 'view all jobs' and 'edit templates' to match your team's responsibilities and access requirements.

package/build/dist/docs-index/b7f5e35b-cab8-4556-a8f3-28092b39d4b5.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/bdafe28f-c5f8-483f-9377-9d738f8a00f3.txt

@@ -0,0 +1,21 @@
+# ParsedQueryImportStatus
+
+**Type**: `object`
+
+## Properties
+
+- name: coveredIntegrationIds (required)
+  type: array of string
+  description: Every integration an import updates. Integrations that share a vendor account share one fetch, so importing for one imports for all of them.
+
+- name: hasCredential (required)
+  type: boolean
+  description: Whether the credential the import needs is saved. For Datadog this is the application key.
+
+- name: importing (required)
+  type: boolean
+  description: Whether an import covering this integration is already under way.
+
+- name: supported (required)
+  type: boolean
+  description: Whether this vendor's parsed queries can be imported at all. False for vendors Grepr cannot read alert queries from.

package/build/dist/docs-index/c7b47250-7a04-4ad3-a627-d784bf80f60d.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/ca6da1f8-44b8-4757-98d6-d74a8b6538e6.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.