Multi-agent LLM chat service: subagent prompt design and WebSocket streaming framing

In a deep dive on an AI project from your resume, the interviewer goes down to implementation detail: how you wrote each subagent's prompt and how each subagent is configured, and what delimiter separates the messages when the conversation streams over a WebSocket. The report does not describe the project itself, so assume this shape: a backend service receives a user's message over a WebSocket, runs an orchestrating agent that delegates parts of the work to subagents (for example, a document-search subagent and a subagent that calls tools) through a language-model API, and streams the final answer back to the browser token by token. ### Clarifying Questions - Does each subagent make its own model calls with its own system prompt, or do the agents share one conversation context? - Should the browser show only the answer text as it streams, or also progress from the subagents? - Can one connection carry several conversations or overlapping requests, for example a new question asked before the previous answer ends? - Must an answer resume after the connection drops, or may it start over? ### Part 1 — Subagent prompts and configuration Explain how you write the prompt for each subagent, what you configure per subagent, and how the orchestrator passes work to the subagents and gets results back. ```hint A contract, not a persona Treat each subagent as a function with an input and an output, and ask what its prompt and settings must pin down for the orchestrator to rely on what comes back. ``` #### What This Part Should Cover - The parts of a subagent prompt: scope, inputs, allowed tools, rules for grounding and for failure, and an exact output format - Per-subagent settings: model, sampling temperature, token and tool-call limits, timeouts and retries, and the reason for each - How context and results move between the orchestrator and the subagents, and how prompts are versioned and tested ### Part 2 — Framing the streamed answer over the WebSocket The answer streams to the browser over a WebSocket. Explain what separates one message from the next, how the client knows the answer is complete, and how errors and subagent progress travel on the same connection. ```hint What the protocol already does Before choosing a delimiter, ask what the WebSocket protocol itself already defines about message boundaries, and what is then left for your application to define. ``` #### What This Part Should Cover - WebSocket messages and frames, compared with a raw byte stream that needs a delimiter - An application-level message envelope with types, request identifiers, ordering and an explicit end-of-answer message - How the model API's own stream is parsed on the server, and why a delimiter inside the generated text is unsafe ### What a Strong Answer Covers - Concrete prompts and settings tied to what each subagent does, rather than general prompt advice - A message protocol that stays unambiguous under partial delivery, errors, cancellation and overlapping questions - Failure handling: subagent timeouts, model errors in the middle of a stream, and client disconnects - How the system is tested and observed: evaluation sets for prompts, and per-subagent latency, cost and failure rates ### Follow-up Questions - The user presses Stop while the answer is streaming. What happens on the client, on the server and in the model calls? - A subagent sometimes returns output that does not match the format the orchestrator expects. How do you detect and handle it? - The service runs on several instances behind a load balancer. What changes for the WebSocket connections? - How would you resume a stream after the client's connection drops?