A research answer has to show where its data came from

I contributed to Research Syndicator from data and chart integration through source handling, generative widgets, caching and an agentic research loop. The central operator problem was trust: a strategic briefing can sound complete even when the requested source did not return data.

My most useful contribution story starts by removing that false completeness.

Delete the invented answer before improving the interface

The authored change removed fabricated offline briefing content. Its replacement lists resolved and unavailable sources, offers follow-up queries and builds citations from the pipeline results. It also removes citation selection based on whether the model's prose happens to mention a benchmark.

That is a concrete behavior change.

The authored tests check degraded responses and the absence of old fabricated figures. I inspected their assertions; I did not rerun the employer suite. A source citation here identifies a pipeline, not the exact row or observation supporting every sentence. The benchmark pipeline can also return configured fallback values, so its presence alone does not establish an empirical benchmark database result.

I would make those distinctions visible to the user before using the answer to recommend spend changes.

Later work lets the model request data

The authored change extracted an orchestrator that supplies tool definitions, validates requested arguments and executes read tools for spend, benchmarks and web traffic. It records tool status and duration, appends the returned data to the prompt and allows at most three model/tool turns.

The limit bounds turns, not the total number of tool calls or domains requested in a turn.

The streaming protocol emits tool-start, tool-complete and generative-UI events. At the end, it emits the assembled answer in a token event and then a done event.

The inspected loop waits for the final model response before that answer event. I describe it as progress streaming and assembled-answer delivery.

Inspect the system diagram

Open full-size SVG →Horizontal version →

There are useful limits to discuss. A model-call failure breaks the loop. Reaching the turn cap while the model still requests tools can leave the final message empty. The handler still builds a response. Client disconnection is checked between stages; the inspected code does not cancel every already-started provider operation.

My implementation review also found a later inconsistency with the earlier citation rule. The dynamic Similarweb and BigQuery branches append a citation after the tool path executes, even if it returns no data. Some benchmark widgets use the benchmark median as their client value. I would not present either as verified client evidence. Correcting those branches would be future implementation work, separate from this historical case study.

Reusing traffic results without hiding freshness

The cache in the authored change normalizes domains, hashes the normalized value for storage and uses a default fourteen-day expiry. A hit returns the stored traffic result. Expired, invalid or unavailable storage becomes a miss; the wrapper then calls the live delegate and awaits a cache write when data exists.

I can explain the tradeoff without inventing a savings number.

The cache can reduce repeated calls for the same domain within that freshness window. It does not coordinate concurrent misses with a single-flight claim. Two misses can still call the provider. A failed cache write does not discard otherwise returned live data, and the default result reports a hit flag rather than a full freshness provenance record.

Measured quota or cost reduction would require provider usage logs. Fourteen days is the configured reuse window, not measured data accuracy.

Invented briefing walkthrough

1. Ask for a competitive briefing for fictional company Harbor Bikes against two invented domains.
2. Resolve spend data, one traffic result and a configured benchmark fallback. Mark the missing competitor result explicitly.
3. Show the offline/degraded answer without fabricated market shares or performance figures.
4. Reconstruct a cache hit and an expired entry. Explain when a fresh delegate call occurs.
5. Show tool-start and tool-complete events, then the assembled answer. Distinguish an attempted tool from a populated evidence result.
6. Reach the three-turn limit while another tool is requested. Treat incomplete synthesis as a failure case to improve, not a successful final briefing.

This walkthrough is reconstructed from code paths and contains no client data.

Contribution scope and results

My history includes Similarweb and domain-resolution work, charts, Markdown rendering, nested advertiser permissions, research widgets, slash-command navigation and the later orchestration changes. One PR was mislabelled: authored changes's final diff and sole original commit change only the PPC auditor account selector. That record maps to the auditor study. It does not support a Research Syndicator launch claim.

The reviewed changes establish a real progression from static briefing output toward data-aware degradation and inspectable tool execution. They do not establish general adoption, calibrated research quality or savings.