Meridian Line is building its port-operations copilot with the Mosaic AI Agent Framework and needs the served model to support multi-turn conversation state, tool-calling, and streaming responses in a way that MLflow can log and Model Serving can deploy consistently. What should the engineer implement the agent against?
Select an answer to reveal the explanation.
Short Explanation
ChatAgent is the shape Databricks expects an agent to come in -- turns, tool calls, and streaming all speak the same interface, so MLflow can log it and Model Serving can deploy it without you reinventing the wiring every time. Skip the interface and you're on your own for all of that plumbing.
Full Explanation
The Mosaic AI Agent Framework standardizes agent authoring around the ChatAgent interface, which defines a consistent contract for multi-turn conversation, tool-calling, and streaming output so that an agent built against it logs cleanly with MLflow (with a correct signature) and deploys predictably to a Model Serving endpoint, rather than every team inventing its own bespoke request/response shape. A plain function returning a single string with client-managed history sidesteps the framework entirely, losing the standardized logging, tracing, and deployment path the Agent Framework exists to provide, and pushes conversation-state correctness onto ad hoc client code. A raw SQL query against a Delta table is not an agent at all -- it returns rows, not a generated response, so it cannot serve the copilot's purpose. A Vector Search index returns retrieved passages, not a conversational answer; it is a component an agent might call, not a substitute for the agent itself. Exam framing: composing chains and agents with the Mosaic AI Agent Framework, and logging them correctly to Unity Catalog with MLflow, are named Section 3 and Section 4 objectives, and the ChatAgent interface is the concrete mechanism tying the two together.