fix: copilot by using bucketId and adjust agent models

[joanagmaia]

This pull request introduces significant improvements to the Data Copilot's agent orchestration and data auditing, focusing on model selection, Tinybird integration, and auditor prompt accuracy. The changes enable more precise use of language models for different agents, ensure correct data partitioning with Tinybird's bucketId, and enhance the auditor's ability to provide user-relevant summaries by including actual data samples.

Model selection and agent orchestration:

• Refactored the DataCopilot class to use two separate Bedrock models: Sonnet for routing and pipe agents, and Opus for text-to-SQL and auditor agents, allowing for more optimal model usage per agent type.

Tinybird integration and data partitioning:

• Added logic to fetch and cache the Tinybird bucketId per project, injecting it into all relevant Tinybird pipe calls and tool executions to ensure correct data partitioning and prevent cross-project data leakage.

Auditor prompt and data summary improvements:

• Enhanced the auditor prompt to include the top rows of actual data (not just statistics), requiring the summary to reference these real values and handle unknown or placeholder entries appropriately.
• Adjusted the auditor output schema to allow feedback_to_router and summary to be nullable, reflecting cases where these may not be present.

Other improvements:

• Filtered out Tinybird tools with empty descriptions to prevent Bedrock validation errors.
• Minor bug fix: ensured previousFeedback is set to undefined if not present, improving retry logic robustness.

These changes collectively improve the reliability, accuracy, and user-friendliness of the Data Copilot's responses and its integration with the Tinybird data backend.

[Copilot]

Pull request overview

This PR updates the AWS Bedrock model identifier from Claude Sonnet 4 (us.anthropic.claude-sonnet-4-20250514-v1:0) to Claude Opus 4-6 (us.anthropic.claude-opus-4-6-v1) across all usage locations in the chat/data copilot system. This represents both a model upgrade (from Sonnet to Opus) and a change in the model identifier format.

Changes:

• Updated Bedrock model identifier from Sonnet 4 to Opus 4-6 across all code and test files
• Updated documentation to reflect the new model configuration
• Maintained consistency across production code, tests, and documentation

Reviewed changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
frontend/lib/chat/data-copilot.ts	Updated BEDROCK_MODEL_ID constant in main DataCopilot class
frontend/lib/chat/chart/generator.ts	Updated model identifier for chart generation functionality
frontend/lib/chat/tests/router.test.ts	Updated model identifier in router agent tests
frontend/lib/chat/tests/auditor.test.ts	Updated model identifier in auditor agent tests
frontend/lib/chat/Readme.md	Updated documentation to reflect new model configuration

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[joanagmaia]

@epipav can you check it out and let me know what you think? — Summary of the changes in the PR description.

The copilot was quite broken in production, so I made a set of changes to address the main issues.

The primary problem was that bucketId logic was never implemented. As a result, most requests were returning 0 because the system couldn’t properly resolve projects (this is the current production behavior). This PR introduces the missing bucketId handling to ensure queries are correctly scoped.

I also evaluated using Opus 4.6 across all agents, but it proved too slow—particularly for the Router and Pipe agents, where it would often stall or take too long to respond. Given the current architecture, it doesn’t seem viable to use it there without more significant changes, so I’m now using one model for some agents, and opus model for others.

Additionally, I improved the data summary returned to the user by including the top 3 rows. This increases token usage slightly, but the improvement in response clarity and UX is noticeable. While this won’t cover every edge case, it works well for common queries like “most active X” and similar straightforward requests.

Let me know if anything here doesn’t look right—especially since you have more context on some parts of the system.

Some tests:

[epipav]

Looks good overall - have u tried using Sonnet 4.6?

[epipav]

Thanks for fixing the bucket issue! Added nitpicks and few readablity comments

[epipav]

Anything important is missing descriptions? Should we report these to Tinybird support?