如何使用 ZizkaDB Suggestions，在自主掌控下節省成本並改善 AI 智能體效能

Most monitoring tools show you what happened and leave the next step to you. Some newer tools go the other way and change your system automatically. Neither is ideal for a production agent. The first leaves you with a chart and a question. The second makes changes you did not approve, to a system that may be handling money, customers, or regulated decisions.

ZizkaDB’s Suggestions take a middle path. They are built from the data your agent has actually produced, they tell you specifically what to change to save cost or correct performance, and they do nothing on their own. You review each one, decide, and apply it through your own process. This guide shows how to use that well.

What Suggestions are, and what they are not

Based on how the feature has been described:

They come from your actual data. The basis is the sessions, calls, and behavior your agent has recorded, not generic advice.
They are specific. A useful suggestion names the step, tool, model, or behavior concerned, and what to change.
They are advisory. Nothing is switched, rerouted, or rewritten for you.
They cover two goals, reducing cost and correcting agent performance.

They are not an autopilot, they do not replace your judgment about quality and risk, and they cannot know your business context. A suggestion that says a step could use a smaller model cannot know that the step feeds a regulated decision. You can.

Why advice without automation is the right design

You stay accountable. If an agent touches money, health, or contracts, a change to its behavior is a decision someone must own. Automatic changes blur who decided.

Regulators expect human oversight. Rules such as the EU AI Act’s human oversight provisions assume people can understand, intervene, and decide. A tool that edits production behavior silently works against that.

Changes carry quality risk. A cheaper model or a shorter context can save money and quietly hurt answers. Only you can judge whether that trade is acceptable for a given step.

You get a record. When a person reviews, accepts, and applies a change, you can write down who decided, why, and what happened afterwards.

It keeps trust. Teams adopt tools that explain and recommend far more readily than tools that act unasked.

Step 1: Give Suggestions good data to work from

Suggestions are only as good as the record behind them. Before relying on them, check these:

Token usage is logged on every model call. Include the model, input tokens, output tokens, and cached tokens where your provider reports them. Without these, cost suggestions have little to stand on.
Tools are named. Log which tool ran, so a suggestion can say that one particular tool is failing or being retried, not just that tool calls are high.
Events are linked. Use parent links so a suggestion can point to the chain behind an expensive or failing step.
Agent names are stable. Renaming an agent splits its history.
There are enough sessions. A few dozen sessions is thin evidence. Give the system a week or two of normal traffic before treating a suggestion as reliable.
Slicing fields exist. Feature, step, and prompt version let a suggestion say where the problem sits.

If your suggestions seem vague, thin data is the usual reason, so improve the logging before blaming the feature.

Step 2: Open Suggestions and read the evidence first

Open the Suggestions section of the dashboard. Availability may depend on your plan. A listing describes Suggestions as part of the managed cloud and enterprise dashboards, so check what your deployment includes.

For each suggestion, read the evidence before the recommendation. A suggestion worth acting on should let you answer:

What data supports it? How many sessions or calls, and over what period?
Where is it concentrated? One feature, one step, one tool, one customer?
How large is the effect? Estimated saving, error reduction, or time saved, with the assumptions visible.
Is it new or old? A long-standing pattern differs from something that began after a change.

If a suggestion does not show its evidence, treat it as a hypothesis to check, not an instruction.

Step 3: Check it against real sessions

Before accepting anything, verify the claim yourself using the other tools in the product:

Open two or three sessions that the suggestion points to, in Session Replay.
Use zizkadb why or db.why() on the step concerned, to see what led to it.
Look at the surrounding behavior. Did the pattern start after a specific change?
Check the opposite case. Find sessions where the same step went well, and see what differed.

This takes minutes and protects you from acting on a pattern that is real in the data but irrelevant to your goals.

Step 4: Sort suggestions by type and risk

Put each suggestion into a simple grid.

Low risk    Higher risk

Cost Trim oversized tool output, cap an obvious retry loop, remove duplicate calls Move a step to a cheaper model, cut retrieved context, reduce output limits
Performance Fix a tool that errors on a known input, restore a dropped validation step Change a prompt that affects many sessions, alter routing logic, change decision rules

Low-risk changes can usually go through your normal review quickly. Higher-risk changes need a test, a rollout plan, and a named approver. If the agent affects customers or regulated decisions, route higher-risk changes through whoever is accountable for that agent.

Step 5: Decide, and write the decision down

For every suggestion, choose one of three outcomes:

Accept: you will apply it, with an owner and a date.
Defer: the evidence is promising, but you need more data or a safer moment.
Reject: you disagree, or the trade-off is wrong for your business. Record why, so the same suggestion does not get re-debated every week.

Keep these decisions somewhere durable. You can also log them in the same record as the agent’s activity, which ties each change to the reasoning behind it:

python

illustrative, adapt to your SDK version

await db.log(
agent="support-bot",
event="suggestion_reviewed",
data={
"suggestion": "Route classification step to smaller model",
"decision": "accepted",
"reviewer": "j.martin",
"reason": "Step is low risk, 98% of cases are simple",
"planned_change": "model-large -> model-small for step=classify",
},
)

Event names like this are your own convention, not a built-in type. Keep to a small fixed set so your behavioral baselines stay clean.

Step 6: Apply one change at a time, through your own process

Suggestions do not change anything, so the application is yours to do. Use your normal route: a pull request, a configuration change, a prompt version bump. A few rules keep the results readable:

One change per release, or at least per feature, so you can tell what helped.
Record the baseline first. Note cost per session, cost per completed task, error rate, and the relevant behavior before you change anything.
Version the change. Use a prompt or configuration version identifier that appears in your logs, so results can be split by version.
Roll out gradually where you can. Apply to a fraction of traffic first, then widen.
Keep a rollback ready.
Step 7: Measure what happened

After the change has run long enough to collect a fair sample, compare with the baseline:

Cost per session and, more importantly, cost per completed task
Task success or resolution rate
Error rate and retries
Escalations to humans and customer corrections
A reviewed sample of outputs, or a fixed evaluation set run before and after

Then check behavior. The drift view, or db.baseline("your-agent"), shows whether the change moved the pattern the way you intended and whether anything unexpected moved too. A cost saving that comes with a rise in escalations is not a saving.

Step 8: Close the loop

Write down the outcome next to the original decision: expected effect, actual effect, and whether you would accept a similar suggestion next time. Over a few months this becomes a record of which kinds of suggestions pay off for your agent and which do not. It also gives you evidence for questions from finance, auditors, or customers about how you manage your agent’s behavior.

Step 9: Set a routine
Weekly, review new suggestions for ten to fifteen minutes. Triage them using the grid in Step 4.
After every release, check for suggestions that mention the changed area.
Monthly, review the decisions log, the measured outcomes, and any deferred items.
Quarterly, revisit rejected suggestions, since data and context change.
How suggestions fit into the bigger picture

Suggestions work best alongside the other functions, not instead of them. Replay lets you see what a suggestion is describing. Causal lineage explains why. Point-in-time state shows what the agent looked like when the pattern began. Drift detection shows when behavior moved. Cost records show what it all costs. Suggestions sit on top of that, turning the evidence into a short list of things worth doing.

What the business case looks like

These figures are modeled assumptions, not measured results. Replace them with your own.

Assume a product spends 12,000 euro a month on model calls and has a few agent performance issues each month. Suppose reviewing suggestions weekly leads to 3 accepted changes a month. If those changes remove about 15 percent of spend, that is 1,800 euro a month, or 21,600 euro a year.

Add performance. If acting on suggestions removes two recurring failure patterns that each cause 5 support escalations a week, at 30 minutes of handling per escalation and 50 euro per hour, that is about 2,170 euro a month in handling time, before counting customer goodwill.

Add effort. Reviewing suggestions takes perhaps 2 hours a week, so about 800 euro a month at 100 euro per hour. Even with that cost, the net is positive in these assumptions, and the review habit also improves your understanding of the agent.

Plan costs vary. The managed cloud was listed at 29 euro a month for Pro and 69 euro for Team, so check which plan includes Suggestions.

Common mistakes to avoid

Accepting without reading the evidence. A suggestion is a hypothesis until you check it.

Acting on thin data. A few sessions are not a pattern.

Applying several changes at once. You will not know which one worked.

Judging by cost per call. Cost per completed task is the measure that matters.

Ignoring quality after a cost change. Watch escalations, corrections, and sampled outputs.

Rejecting without recording why. The same debate returns every week.

Treating suggestions as automatic. Nothing happens unless a person applies it.

Skipping the decision log. Without it, you cannot show how changes were governed.

Start this week

Open the Suggestions section for your busiest agent. Pick the top three. For each one, read the evidence, replay two sessions, and write down accept, defer, or reject with a reason. Apply the lowest-risk accepted change, record your baseline first, and check the result a week later. That one cycle shows you how much of the feature’s value depends on your data and your review habits.

If you share a screenshot of your Suggestions page, or tell me what your agent does and what you spend each month, I can help you sort the suggestions into the grid and plan the first change.

Want to test ZizkaDB on your agent? Try our open source version here: https://github.com/ZIZKA-AI-SL/ZizkaDB

Interested in a design partnership? Fill in the form on our site or reach me directly at founder@zizka.ai

Sources: A software listing describes ZizkaDB dashboards as covering Activity, Behavior, Reports, Suggestions, and Fleet features for managed cloud and enterprise users. Slashdot listing · ZizkaDB Python SDK wiki · ZizkaDB repository README