Call Investigation

Call Investigation explains a call that went wrong. Connect a key from your own LLM provider, open the call in the dashboard, and press Investigate: a model on your account reads that call's diagnostic logs and tells you what the problem was, what caused it, and whose side it is on.

Overview#

When a caller complains, the useful questions are always the same. Did the call fail on your side, on the platform's, or on the caller's line? At what moment? And what do you do about it? Answering them by hand means reading logs that were never written for you.

An investigation does that reading for you. It follows the call through the platform from the moment it arrived to the moment it ended, looks for the step that broke, and gives you a short verdict:

• Problem: what went wrong, in a sentence.
• Cause: why it went wrong.
• Responsible: your system (for example your server or one of your tools), the platform, the caller or their network, or not determined when the evidence does not settle it.
• When: the moment in the call it happened.
• Next step: what to do about it.

If the call deserves a closer look, create a support ticket from the result in one click. The ticket carries your verdict, and OnCore attempts to attach the technical report for its support team.

The model runs on your own account with the LLM provider, so its model usage is billed to you by that provider.

Prerequisites#

An account with one of the supported LLM providers, and an API key created in it:

Only these four are supported. Keys from any other provider, including providers that resell or proxy these models, are refused.

The key needs credit on the provider's side. Connecting checks that the key is valid and can use the model you pick, but it cannot check your balance, so an account with no credit is only discovered when an investigation runs.

Choosing a model#

You pick the provider and one of its available models when you connect. Each provider has a short list, with one model marked Recommended. Models outside the list cannot be chosen.

When a provider retires a model, it comes off the list, and investigations on a tenant that picked it use that provider's recommended model instead. You do not have to reconnect. If a provider is removed from the list altogether, its connection stops working for investigations and the integration's screen asks you to choose another provider.

How to connect#

You can also connect, test and disconnect the key over the API, with the same endpoints as every other integration. The investigation itself runs from the dashboard only; it is not in the public API.

curl -X PUT https://core-api.heysadie.ai/integrations/call_autopsy \
  -H "Authorization: ApiKey YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "apiKey": "YOUR_LLM_PROVIDER_KEY",
    "llmProvider": "anthropic",
    "model": "MODEL_ID_FROM_THE_LIST"
  }'

Use the selected tenant's API key. llmProvider is one of anthropic, openai, google or xai, and model is an id from List call investigation models. Both are required when connecting call_autopsy. The reference for Connect a provider has the full request and response.

When a call can be investigated#

A call can be investigated once it has finished: five minutes after it ends, so that every part of the platform has finished writing about it. A call that never recorded an end can be investigated twelve hours after it started. Until then the button stays disabled and says when it will be ready.

Diagnostic data is not kept forever. When it is no longer available for a call, the investigation says so rather than guessing, and you can still create a ticket for it.

The platform limits concurrent investigations, and the same call cannot be investigated twice at once. If you reach a limit, wait for a running investigation to finish before starting another.

What gets sent to your provider#

An investigation lets the model make up to six read-only searches over the diagnostic logs and traces for that one call. Your LLM provider receives the results of those searches, the instructions the model follows, and the sentence you typed, if any. The model can only look up data for the call you are investigating; a request for any other call is refused before it reaches the logs.

Before anything leaves the platform, OnCore replaces internal component names, hostnames, network addresses, headers, credentials, and secret-like values with neutral placeholders. URLs and similar values in transcripts or tool data may also be replaced by that masking pass.

Your provider may keep what you send. Some providers store requests and show them in your account's history. Treat that history the way you treat your own call records: the transcript is the conversation verbatim, so anything a caller says out loud is in it, alongside their number.

What OnCore keeps#

OnCore does not persist the verdict or technical report as an investigation record. It logs operational metadata such as the tenant, call, provider, model, outcome, token counts, query count, and duration. The result itself is shown in your browser and kept only in that tab:

• Leave the page and come back in the same tab, and the result is still there, without running again or billing you again.
• Close the tab or the browser, and it is gone. Investigating the call again runs a new investigation, billed again.
• Leave the page while an investigation is running, and it stops, so it does not keep spending on your account for a result nobody reads. Closing or reloading the tab asks you to confirm first.

To keep a result, create a ticket from it.

Creating a ticket#

Under a finished verdict, press Create ticket, optionally with a note. The ticket opens with the verdict as its description and a link back to the call, and it appears in your tickets like any other. OnCore also attempts to attach the technical report as a staff-only note; if that attachment fails, the ticket still exists. If a ticket is already open for that call, you normally get a link to it instead of a second ticket.

A ticket can only be created within 24 hours and while the verdict is still in your tab. If the result expires or you close the tab, investigate the call again first.

If something goes wrong#

A verdict marked as based on incomplete data means the model reached the end of its search before it could be sure. Read the cause as a lead rather than a conclusion, and create a ticket if it matters.

If you rotate the key#

A key that is rotated or revoked in your provider's account stops working for OnCore at the same moment, and the next investigation reports that the key was rejected.

Paste the current key on the same screen you connected from, and use the connection test there to confirm the provider accepts it. Changing the provider or the model also needs the key pasted again.

Testing does not save the replacement. After the test succeeds, press Replace key.

Disconnecting#

Disconnecting removes the stored key for this tenant. Calls in that tenant can no longer be investigated until a key is connected again. Tickets you already created are unaffected, and so is anything in your provider account's history.

Next steps#

• Integrations: how bring-your-own-account integrations work across the platform.
• Troubleshooting calls: the checks to run yourself when a call misbehaves.
• Read call activity: pull the call you are investigating over the REST API.