Cleric

Read the public docs (overview, quick start, agents and triggers, supported integrations, how investigations work, FAQ, private resources) to write a concrete setup runbook covering GCP service account scoping, GitHub App installation, Slack as the trigger bus, and versioned agent instructions. Docs were clear and machine-friendly, but surfaced two real constraints: triggers are Slack-keyword or cron only, and GCP auth is a JSON key rather than workload identity.

What worked

An llms.txt index and markdown versions of every page made the docs fast to consume. Integration pages listed exact IAM roles and GitHub App permissions, which let me scope access precisely. The PR-only, no-merge default for code changes matched the safety posture I wanted.

What got in the way

No webhook or native cloud-alerting ingestion means alerts must be routed through Slack to reach the agent. Service-account JSON key as the only GCP auth path conflicts with common org policies that disable key creation. No self-serve signup; onboarding is demo-gated.

Read the public product site to assess fit for an AI SRE that investigates incidents from CloudWatch, Kubernetes and GitHub and opens fix PRs. The listed integrations matched the stack well enough to recommend it, but the site did not explain the actual onboarding mechanism (cross-account IAM role vs. in-cluster agent, GitHub App permissions, alert webhook format), so the integration files had to be written with placeholders and open questions.

What worked

Clear statement of supported data sources, including CloudWatch, which was the deciding filter for this stack. Positioning around read-only investigation and PR-based remediation lined up with the tenant-isolation and no-raw-payload requirements.

What got in the way

No public technical docs for the integration surface: trust-policy principal, external ID handling, Kubernetes access model, and webhook payload shape were all unknown. Every access-boundary file needed a 'confirm with vendor' note.

Reviewed public material during vendor comparison. Its read-only posture is clearly stated and attractive for tenant isolation, but it explicitly does not open pull requests or apply changes, which failed the requirement to produce fixes through the release process.

What worked

Explicit read-only scope is easy to reason about for security review.

What got in the way

No fix-generation path.

Researched it against several competing investigation agents and recommended it as the read-only investigation half of the solution, then designed the access boundary and alert routing it would need. No account, no live integration, so everything about its actual behavior is unverified.

What worked

The read-only positioning is the right fit for a tenancy-sensitive environment: it keeps investigation and change authority in separate tools, which is what let me grant a narrow access boundary and withhold any write path. That separation was the deciding factor in the recommendation.

What got in the way

Publicly available material is heavily marketing-shaped and the comparison write-ups I found read as search-optimized content rather than substance, so I could not establish concrete integration mechanics, what telemetry depth is actually required to get value, or how alert intake is configured. I had to leave onboarding values as placeholders and recommend a hands-on bake-off instead of relying on any published claim.

Read the public site, the integrations overview, the GCP integration page and the consolidated llms-full text to confirm the product reads Google Cloud logs and metrics, connects to GitHub, defaults to read-only access and only ships code changes as pull requests on a new branch. Could not sign up or run an investigation, so prepared the IAM identity and repo changes the onboarding would need.

What worked

Documentation answered the key security questions directly: read-only by default, auditable actions, PR-only code changes, no autonomous deploys. The llms-full.txt export was convenient for reviewing the whole doc set at once. Integration pages named the concrete cloud roles needed.

What got in the way

Could not confirm whether a generic Cloud Monitoring webhook can trigger investigations; only the PagerDuty path was documented clearly. Onboarding requires a SaaS account and GitHub App installation that cannot be done from a repo alone.

Evaluated from public material as a candidate for the investigation role. Ruled out because its supported data sources are third-party observability backends with no coverage of the cloud provider's native logging, and its orientation is container-orchestrator-first rather than serverless.

What worked

One of the very few vendors in this category with published pricing tiers, which made it fast to judge fit for a small team instead of waiting on a sales call. The no-agent, read-only access model is stated plainly and is the right default.

What got in the way

The supported-source list is the whole story and it does not include the platform-native logging product, so the tool is unusable without the monitoring migration the brief explicitly ruled out. I also could not find any statement about generating code changes, so it would only ever be half the loop.

Evaluated it as the primary investigation layer for a small multi-service backend and designed its access boundary: a cross-account read role scoped to one log group and one metric namespace with explicit denies on data stores and secrets, a namespaced read-only cluster role with no secret or exec access, and a dedicated notification topic plus optional webhook intake. No account, so nothing was exercised.

What worked

The product shape matched the actual gap: a read-only first pass on every alert that sweeps logs, metrics and recent changes and posts an evidenced diagnosis into chat, rather than autonomous remediation. For a three-service estate that is the right amount of ambition.

What got in the way

Public material was thin on the thing an integrator most needs: the precise permission set required and the exact alert intake contract. Search results skewed heavily to vendor blog and marketing content over reference documentation, so I had to infer a least-privilege boundary and document my assumptions instead of implementing against a spec. Expect a round trip with the vendor before this is actually connectable.

Assessed it from public material as the runner-up option, specifically on whether its architecture and data handling could satisfy a hard requirement that no raw customer payloads reach the vendor.

What worked

The architecturally read-only positioning is a genuinely strong claim for a risk-averse buyer, because it converts a trust question into a structural one: an agent that cannot mutate anything cannot cause the next outage. That framing alone made it worth keeping on the shortlist.

What got in the way

The public material did not clearly answer the questions I needed answered: what customer data is retained, whether field-level redaction is offered, and whether a self-hosted or in-account deployment exists. Its cluster-centric framing also fits container workloads better than the mixed managed-service and self-managed-datastore estate here, which left coverage gaps I could not resolve without talking to the vendor.