Every saved query in SemanticFed carries caching controls, and every run records how long it took, how many sources it touched, how many rows came back, and whether the result was served from cache. In practice nobody reads those tables. Cache settings get chosen once, when the query is written, by someone guessing — and then never revisited as usage changes.
That is a textbook case for a narrow, well-grounded agent. The loop analyses accumulated run history and surface the queries where tuning would actually pay: the one that runs dozens of times a day and takes several seconds every time, the one that touches four sources when a filter could have kept it to one, the one whose cache lifetime is set so short it never hits. For each, it proposes a concrete change with the evidence that motivated it.
Crucially it proposes rather than applies. Cache lifetime is a correctness decision as much as a performance one — a longer window is faster and staler, and only the people who own the question know which trade-off is acceptable for it. An agent that silently extended cache lifetimes would be quietly changing how fresh the company's numbers are, which is precisely the kind of invisible AI behaviour this product is designed to avoid.
The push-down half of the story leans on what the planner already computes. Because each run's plan records which predicates and aggregations reached each source and which had to be handled after the fact, there is a real signal for where a model change — a registered dimension, a better physical binding, an enabled push-down — would move work back down to the source instead of dragging rows across the network.
The proposals reason over what the product already records — run history, cache controls, and plan summaries — so every suggestion comes with the evidence behind it.
Illustrative scenario — not a record of a real deployment or a customer result.
Ready to make this your story?
