The work behind the reply.

cognilogs reads tickets from any ticketing system, does the investigation your team would do, and either resolves the work or hands it over with the evidence attached. It runs on your servers, with the local model you choose.

Join the waitlist See the loop

Any ticketing system. Any local model. Human review where it matters.

Capability index

End to end

Poll and sanitize

Any ticketing system, on your interval.

Classify intent

Query, issue, or feature enablement.

Investigate

Audit logs, code, databases, observability.

Enable features

API or browser, with approval.

Draft the RCA

Human review before it leaves.

Watch the SLA

Child tickets, reminders, CSAT.

Ticketing event inevidence-backed close

Three kinds of work. One agent.

Most tools pick one lane. cognilogs reads the request and chooses the path that can actually finish it. See how the three paths run end to end.

Query

The answer is buried.

“Which subprocessors can see the attachments in our support tickets, and where are they hosted?”

The agent retrieves the current policy, the subprocessor list, and the last answer an agent gave on the same account. The reply carries the sources.

Policy retrieved

Subprocessor list

Answer cited

Issue

The system disagrees.

“We rotated our IdP certificate. Forty finance users are in a login loop, and the rollout email went to the wrong cohort.”

The agent reads the audit log, searches the code path, queries the cohort table, and checks Sentry. It fixes the state, opens a child ticket for the rest, and drafts the RCA.

Audit event

Cohort query

RCA review

Feature

The switch is off.

“Enable SCIM for our contractor cohort. We need it before the next onboarding wave.”

The agent checks the feature state, requests approval from the right owner, then enables it through the admin API or the browser. The customer gets a reply with the change and the permission trail.

Feature state

Owner approval

Enabled + reply

It checks the places your team checks.

A reply is only as good as the evidence behind it. The agent reads audit logs, searches the codebase, runs database queries, and follows the trace through Kibana, Sentry, or Datadog.

Investigation run #184live

$ audit.events --actor svc-sso

certificate.rotated 04:12 · metadata.publish 04:19

$ codebase.search metadata.publish

services/sso/metadata.ts:88 · legacy plan field

$ db.query cohort_members --job 8841

42 rows · 12 outside pilot · 30 expected

$ sentry.issue login.loop --since 04:20

38 events · finance workspace · first seen 04:21

Evidence attached to the run4 sources · read-only first

Audit logs

Who changed what, when, and from where.

IdP · admin · rollout

Codebase

The code path that explains the behavior.

GitHub · GitLab

Databases

The row that proves the state.

Postgres · MySQL · warehouse

Observability

The error, trace, and timing around it.

Kibana · Sentry · Datadog

The agent can handle five to ten tickets at once, depending on the depth of each investigation.See the full loop

Enable the feature, with permission.

A feature request should not end with “we will pass it to the product team.” cognilogs can check the feature state, request approval, then enable it through an API or by using the browser.

API enablement when the admin surface exposes one.
Browser automation when the only path is a screen.
Approval loops for sensitive or high-impact features.
A reply with the change and the permission trail.

Permissions stay scoped to the workflow. The agent records every click, API call, and approval.

Feature enablement

Approval required

API path

$ feature.state --flag scim

disabled · plan enterprise

$ feature.enable --cohort 42

enabled · audit 7f3a

Browser path

admin.internal/cohorts

Settings → Access

SCIM provisioning

Enable for cohort 42

Approver

security owner

Waiting

approval window

Enabled

customer replied

Every API call and click is recorded for audit.

The RCA writes itself. A person signs it.

When an issue needs a root cause analysis, cognilogs assembles the timeline, the evidence, the impact, and the fix. It never sends an RCA without human review.

Draft · not sent

Critical documents keep a human in the loop even when confidence is high.

Incident · INC-2189

SSO login loop after certificate rotation

Human review

Timeline

04:12 certificate rotated · 04:19 metadata published · 04:21 login loop begins

Impact

42 finance accounts · 38 login loop events · 12 accounts outside the pilot cohort

Root cause

The metadata publish step used the legacy plan field; the client cache expired before the new certificate was live.

Fix and prevention

Metadata restored, rollout paused, cohort filter patched, staging verification passed.

Drafted from 5 evidence sourcesReview and sign

Every child ticket stays on the clock.

Escalations create linked child tickets. Each one enters an SLA tracker by severity and priority, and the watch keeps going until someone moves it.

The current owner is notified by Slack or email.
After three notifications, the manager is brought in.
Child resolution is checked for a customer-safe answer.
A CSAT request can follow a successful resolution and is customizable per deployment.

SLA tracker

1 breach risk

#4910 · Verify IdP metadata

Identity team

P12h 14m

#4911 · Patch cohort filter

Platform

P25h 02m

#4912 · Customer reply QA

Support

P28h 40m

3 notifications · Slack + emailmanager next

Audit and compliance

Every action is traceable.

Model reasoning, tool calls, browser actions, approvals, replies, and child-ticket updates are recorded. Your team can review what happened, not just what the model said.

Tool callsread-only first

Browser actionsclick + field trace

Approvalswho signed, when

Repliessource attached

The stack you already run.

Your ticketing system stays the system of record. The agent brings its own evidence layer and can act through the tools your team already trusts.

1,500+integrations

Available today, and the agent can connect with any app in your stack through APIs, webhooks, or the browser.

Local deployment

Run any local model your infrastructure can serve. Stronger models produce better work; the evidence and approval rules stay the same. The deployment guide lists what runs where.

Ticketing

Any system can be polled.

Evidence

Read the trail before you answer.

Actions

Update, enable, notify, and close.

Models

Bring your own local model.

Logos are the property of their respective owners. Availability depends on the deployment and the permissions you grant.

Early access

Put the whole loop on your queue.

We are opening a small number of local deployments. Tell us which tickets take the most time.

Join the waitlist See pricing