northline_support_runAIrefund_agentget_ordercheck_return_windowcreate_refundPolicyViolation
Get everyone
on the same page
Evidence, failures, feedback, decisions, and fixes all stay connected. Everyone works from the same context, in the tool they’re already using.
Works where your team already does:
SlackDiscordIntercomGmailLinearJiraSearch
14 steps · 18sExpand all
+northline_support_runWorkflowError
+triage_agentAgent
+lookup_customerTool
+gpt-5.5-2026-04-24Model
+knowledge_agentAgent
+search_kbTool
+render_policy_briefTool1
+resolution_agentAgentError
+get_orderTool
+case_media_boardTool2
+create_refundToolError4
Turn feedback intoproduction context
Customers and teammates describe problems in their own words. neatlogs connects the message to the relevant run and the exact step it describes.
FinThe team can also help
Hi there 👋
You are now speaking with Fin. How can I help?
Traces
Matching Intercom reportSearching production history for Sarah’s refund conversationConnecting
TraceStatusStartedInput → output
northline_support_runWorkflowCompletedCustomer requestRefund refused
returns_assistantWorkflowCompletedCustomer requestRefund refused
northline_support_runWorkflowCompletedRepeat-delivery exceptionRefund should be approved Intercom report linked
Intercom report linkedbilling_questionWorkflowCompletedCustomer requestRefund refused
policy_exception_reviewWorkflowCompletedCustomer requestRefund refused
support_escalationWorkflowCompletedCustomer requestRefund refused
←Customer history ignored
SarahMy order never arrived. This is the third delivery failure. Why was my refund refused?
Issue createdRepeat-delivery exception missedBusiness context and production evidence attached
Use neatlogs without
opening neatlogs.
Answer in SlacknneatlogsApp10:42 AM
The decide_resolution span produced this policy failure:
Policy violation: customer history was loaded but not used before the refund decision.
Does the repeat-delivery exception apply to this customer?
Production evidencerun_1842 · decide_resolution
customer_history found two prior delivery failures but was not used.
2 replies
Yes. After two delivery failures, the current undelivered order should be refunded.
Agreed. I’ll pass customer history into the decision and add the exception check.
Issues ›Customer history ignored before refund decision
Open4 SepToday
northline_support_runrefund_agentdecide_resolution Policy violation
MarkYes. After two delivery failures, the current undelivered order should be refunded.
Issue created: issue_refund. The refund was refused even though delivery_failures=2 and order_delivered=false.
From feedback toa verified fix
neatlogs# agent-support
The customer has two prior delivery failures, but the agent refused the refund without using that history. Can someone look at this?
Matched production evidencesupport_agent.run
4 refusalscustomer_history · ignoredStep 01
Someone notices
A customer, support lead, PM, or engineer says something went wrong, in the tool they’re already working in.
Incident
Opensupport_runrefund_agent
run_1842 · failed at refund_agentFailed
Comment on refund quality evalSarah
The refund should have been approved because this was the third delivery failure.
Run and eval comment attached
Step 02
neatlogs finds the run
It connects the message to the runs it’s about, and raises it as an issue with severity and source attached.
Slack notificationCustomer history ignored before refund decision
Sarah · #agent-support
Failed production tracenorthline_support_run
Failedrun_1842 · refund_agent
Eval comment“The repeat-delivery exception should apply.”
Refund quality eval
InvestigationRefund policy failure
3 sources attachedRoot causeCustomer history was dropped before the decision
customer_history found two prior delivery failures, but decide_resolution evaluated only the standard return window.
Customer reportSlackFailure at refund_agentTrace
Policy exception confirmedEvalStep 03
The investigation uses their context
The reported outcome, business rules, and team decisions become part of the diagnosis.
Investigation V1
77%
Medium confidence
Root cause
Open in
Cursor
Codex
Claude Code
GitHub Copilot
CursorCodexClaude CodeGitHub CopilotIssue tracker
Linear
Jira
LinearJiraSUP-482
Require escalation before enterprise refunds
Investigation report4 evidence spans attachedLinked
Step 04
The fix moves forward
The report goes to the owner as a ticket, or to your coding agent with the evidence intact.
Total traces248↑ 18.4%
Error rate0.0%↓ 100%
Detection rate100%↑ 24.6%
No failures after deploy
Fix is holding in production
Step 05
The loop closes
The person who raised the problem can see what changed. neatlogs watches your agent to check whether the fix held.
People and AI
work the same case.
neatlogs assembles the evidence.
Customer reportrun_1842 failed2 sources attachedExperts add business context, and set standards.
SarahDomain expertSupport approval is required before an exception refund.
Standard addedneatlogs catches failures, and creates fixes.
refund_agentFailedapproval_guard.ts+12You approve each fix, and ship it to your coding agent.
Proposed fixAdd approval guard
Sent to Claude Codeneatlogs monitors production to see if the fix held.
Import traces from your current platform. Then connect the places where customers and teammates already report problems.
Langfuse
LangSmith
Braintrust
Phoenix
Raindrop
OpenTelemetry
FAQs01 / 09
Do reviewers need to understand traces?
Not at all. Someone answering a question in Slack sees the output being judged and the evidence behind it. Because the people who know what correct means at your company are usually not the people who can read a trace.
FAQs
Not at all. Someone answering a question in Slack sees the output being judged and the evidence behind it. Because the people who know what correct means at your company are usually not the people who can read a trace.
Still unsure?
We’ll look at your stack with you.
Comment on theexact evidence
Tag your experts. Keep their answers next to the questions.
On a span
Point to the prompt, retrieval, tool argument, or line of output that needs attention.
On a detection
Decide whether the signal is useful, noisy, or scoped incorrectly.
Apply the repeat-delivery exception before this ships.
On an investigation
Challenge the root cause, add missing context, or review the recommended fix.
On an eval
Discuss the verdict, the standard, or why two reviewers disagreed.