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 is designed to analyse 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.
This capability is on the roadmap. The recorded run history, the cache controls, and the plan summaries it would reason over exist today; the analysis and proposal layer does not yet.
Because the agent-driven analysis and proposal layer is not yet built, this story does not yet have a clickable "Do it yourself" web walkthrough.
Ready to make this your story?
