Your company wants an internal assistant that goes beyond document search. Employees should be able to ask "what is the status of the Helios migration?", "who owns the billing service?", "how many support tickets did we close last week?", and "summarise what happened in the incident on Tuesday".
These questions cannot be answered by retrieval over documents alone. Some need structured data (the ticket database), some need entity resolution (who owns a service), some need aggregation across sources, and some need multiple steps.
The assistant will be used by 40,000 employees across engineering, sales, support and finance. Each group has different data access and different vocabulary: "pipeline" means something different to a sales rep and to a data engineer.
Design a system that handles this range without becoming an unmaintainable pile of special cases.
Build the architecture on a canvas: place the components, configure them, connect them into a data flow, and write a short reason for each one. The AI reviewer grades your design against a rubric written specifically for this problem.
Why not just let the model write SQL against a read replica? Give me three concrete reasons.
A sales rep and an engineer both ask about 'the pipeline'. How does your system tell them apart?
'What is the status of the Helios migration?': trace the tool calls your system makes.
Minimum 8 components · needs a wide desktop screen