Confidence & limits
What the Sazabi agent searches by default, how it shows its evidence, what a root-cause claim actually means, and what your logs alone cannot tell it.
The Sazabi agent is grounded in your data, and it is honest about the edges of what that data can support. Knowing what it searches, how it shows its work, and where its evidence runs out lets you trust the answers you should and push on the ones you should not.
What the agent searches by default
By default, the agent searches your project's logs. When your project has log storage, log search is always available to an investigation, and it is where the agent starts.
Other sources are opt-in:
- The public web is searched only if you have enabled web search under Settings > Tools.
- Your code is read only for repositories you have connected under Settings > Code.
So if the agent has not been given web or code access, its answers are grounded in your telemetry alone — which is often exactly what you want.
How the agent expresses uncertainty
The agent shows its work. As it investigates, you see the tool calls it makes and the queries it runs, and you can expand any of them to see the underlying data. It answers with the specific records it found and does not make claims it cannot back with evidence — when it is unsure, it says so and tells you what it did and did not find. This is the practical form of its confidence: not a score, but a visible chain from question to evidence to answer that you can check.
What a root-cause claim means
When the agent names a likely cause, it means the evidence it found points there — a correlation in time, an error pattern, a change that lines up with the symptom. It is a well-supported hypothesis grounded in your data, not a guarantee. Treat it the way you would a strong finding from a careful colleague: check the evidence it cites, and confirm the fix addresses the cause rather than the symptom.
What logs alone cannot tell you
Logs record what your systems emitted. They cannot reveal what was never logged. If a failure path produces no log line, the agent cannot see it — the absence of evidence is not evidence of absence. When an investigation depends on something your logs do not capture, the honest answer is that the data does not show it, and the fix is to instrument that path so next time it does.
How data gaps affect answers
Several kinds of gap change what the agent can conclude:
- Retention. Logs are kept for a plan-based retention window — see Storage. The agent cannot investigate a period older than what you have retained.
- Latency. A log that was emitted a moment ago takes a short time to become searchable, so a question about the last few seconds may not yet have the newest records.
- Sampling. If a source samples or drops logs before sending, the agent sees only what arrived — counts and rates reflect the sampled stream, not the full traffic.
- Missing logs. A source that has stopped sending, or a code path that emits nothing, leaves a blind spot. If answers seem thin, confirm the relevant source is still flowing under Settings > Log streams.
The way to widen what the agent can conclude is to close these gaps: retain longer where it matters, instrument the paths you care about, and keep your sources healthy.