--- name: lseg-ai-rfq-quote-status-review description: Build one consolidated status picture of open RFQs and quotes on LSEG AI, by listing active requests, the quote responses and rejects that came back, and the active quotes, then reconciling them into a single view for the user. Read-only; changes nothing. Use when the user asks what RFQs are still open, which quotes came back, which were rejected, what is still live, or wants a status check before acting on a request. --- # Review RFQ and quote status The goal is one picture answering: **for each request, what is open, what came back, what was rejected, and what is still live?** This job is read-only. Its output is the state of the book, not a recommendation to trade. Do not act on what you find. Keep it distinct from execution reconciliation: this job asks what is currently open and what responses exist. It does not check whether anything was executed against what was quoted. ## 1. Confirm the session and scope first Before listing anything, confirm with the user which account or session the review covers, and whether they want all open items or a specific request. Do not assume the session that happens to be connected is the one they mean. If the user wants a different account or workspace, stop and ask for their explicit yes before switching, because switching changes the context every later read depends on. If the first call fails with a sign-in or permission error, report that plainly and stop. Do not retry in a loop or guess at alternative ids. ## 2. List the requests you are reviewing Call `lse24-get_active_rfq_requests` to get the set of open requests. This is the spine of the review. Record each request's identifier and whatever status or timing fields come back, exactly as returned. Note the count. If the list is empty, say so. An empty result is a finding (nothing open), not a failure. Skip to step 5 to check whether any quotes are still live without a parent request. ## 3. Gather responses and rejects for those requests Call `lse24-get_latest_quote_responses` to see what came back against the requests, and `lse24-get_active_quote_request_rejects` to see what was rejected. Match each response and reject to its request identifier. Keep these as separate lists: a response is a counterparty answer, a reject is a rejection of the request or quote, and the two can mean different things for the next action. Where a response has no matching request in step 2, list it as an orphan and say so. It may belong to a request that has already closed. ## 4. Pull the live quotes Call `lse24-get_active_quotes` to see which quotes are currently live. Cross-check each live quote against the responses from step 3. A quote that is live but has no matching response, or a response that is not reflected in any live quote, is worth flagging for the user to look at. Do not try to resolve the gap yourself. ## 5. Reconcile into one status per request Build one row per request with four facts: open or closed as reported, number of responses, number of rejects, and whether a live quote exists. Then add a short status label for each row, using only these labels: - **Open, no responses**: request is live and nothing has come back yet. - **Open, responses pending action**: responses exist and no live quote or reject has resolved them. - **Open, quoted and live**: a live quote exists against it. - **Rejected**: a reject exists and no live quote remains. - **Inconsistent**: the sources disagree (for example a live quote against a request reported closed). Explain the disagreement and stop there. Do not invent a status outside these labels. If the data does not fit one, use Inconsistent and say why. ## Common patterns and traps - **Mixing up responses and rejects.** A response is a counterparty answer; a reject means something was declined. Keep the two lists separate and never count a reject as a quote. - **Treating an empty list as an error.** No active requests usually means nothing is open. Report it as a finding, then check for orphan live quotes. - **Matching on the wrong key.** Only match responses and quotes to requests on identifiers returned by the tools. Do not match on similar-looking instrument names or sizes. - **Silent staleness.** These are point-in-time reads. Print the time of the read in the output, and tell the user the picture can change while they read it. - **Partial reads.** If one of the four list calls fails, mark that section as not checked rather than filling it with inference from the others. - **Over-reading a label.** "Quoted and live" does not mean a trade will happen. Report the state, not the expectation. ## Output ``` As of: