How the loop runs.
A ticket is a piece of work with a lifecycle: intake, understanding, evidence, a decision, and ownership until it closes. This guide covers the deployment model and the operating rules behind that loop.
On this page
One loop, from event to close.
cognilogs polls the ticketing system your team already runs. It reads the request, decides what kind of work it is, gathers the evidence needed, and either resolves the ticket or prepares a complete human handoff.
The loop does not end at a suggested reply. It continues through the confidence decision, the child ticket, the SLA watch, the customer reply, and the CSAT request.
Any ticketing system.
cognilogs is not tied to one help desk. A scheduler polls the ticketing system you use on the interval you set, from every five minutes to every hour. New and replied tickets arrive with the thread, customer, and SLA context. The content is sanitized before the model sees it.
The three paths.
The classifier chooses the path before any tool runs. Each path has its own evidence standard and its own definition of done.
Query
Customer answerRetrieve the closest knowledge passages from official docs, internal notes, and previous agent replies. Draft an answer with the sources attached, then score the confidence.
Issue
Resolution or complete handoffRead audit logs, search the codebase, query the database, and check Kibana, Sentry, or Datadog. Fix what is in scope, verify the result, and open a child ticket for the rest.
Feature enablement
Enabled feature + customer replyCheck the real feature state. Use an API or browser automation to enable it, with an approval loop where the change is sensitive. Reply with the change and the permission trail.
The agent handles five to ten tickets at a time, depending on the complexity of the investigation and the time each check takes.
Deployment and models.
The first deployment target is local. cognilogs runs on your servers or inside your network. The app, the SLA worker, and the run history stay in the environment you control.
Stays in your environment
- Ticket content and replies
- Private notes and run evidence
- Credentials and connector configuration
- SLA records and follow-up history
Any local model
Run the model your infrastructure can serve, including open-weight models. Stronger models produce better work. The evidence, approval, and audit rules stay the same.
Your team controls host access, network access, backups, and retention. We agree on the support and upgrade model before deployment.
Confidence and human review.
Every path ends at the confidence evaluator. The default threshold is 0.85. Above it, cognilogs can reply and resolve. Below it, the customer does not receive the draft.
High confidence
Reply, resolve, and keep the sources attached.
Low confidence
A private note goes to the human queue. The customer does not see a guess.
What the private note contains
The customer request summary
The run and evidence collected
The drafted reply, held back
The suggested next step
SLA and notifications.
If a case needs a person, cognilogs creates a linked child ticket, records severity and priority, and registers the case with the SLA tracker. A background worker checks open child tickets every 15 minutes.
Open
Child ticket linked
Severity recorded
Sync
Parent note updated
Every internal change
Remind
Slack + email
Nudges before breach
Escalate
Manager alerted
After 3 notifications
Audit and security.
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 calls
Read-only first, with a record of each check.
Browser actions
Clicks and field changes are traced.
Approvals
Who signed, when, and for which change.
Replies
The source and confidence stay attached.
Security review is part of deployment. We provide documentation and describe which controls belong to your team and which belong to us. Certification work is in progress.
Connections.
The ticketing system is the system of record. The evidence layer reads the tools your team already trusts. Actions can use an API or the browser when that is the only path.
Availability depends on the deployment and the permissions you grant. Logos are the property of their respective owners.
Operating notes.
The ticket stays the record.
Replies, private notes, statuses, and linked child tickets remain in the ticketing system.
A person can take over.
A person can review, override, or reassign the case at any point.
The threshold is a policy.
The 0.85 default is a starting point. Stricter lines belong on more sensitive queues.
The customer gets clarity.
Ask for the missing detail once. Hold back a reply when the evidence is thin.
This guide describes the product workflow and the local deployment model. It is not a committed release date or a live integration catalog.
Want to see the loop on your queue?
We are onboarding local deployments in small groups.