Meridian Line's customs-compliance agent calls a tool that looks up HS-code tariff rates from an external reference table, and another tool that validates a declaration's required fields. When the team logs this agent with MLflow for deployment, what must they do beyond logging the LLM prompt chain itself?

An agent that calls tools needs those tools, and the resources they depend on, captured as part of the logged and deployed model — not just the prompting/reasoning chain. In the Databricks agent-logging pattern, that means declaring the agent's tool functions (for example, Unity Catalog functions the tools invoke) and any other resources (tables, indexes, other endpoints) as part of what gets logged, so the serving environment provisions the credentials and connectivity the tools need at inference time. Assuming MLflow automatically discovers every function an agent might call at runtime overstates what logging does — MLflow packages what it's told about, not everything reachable from the code path, so unlisted resources fail at serving time exactly like the missing-dependency failure elsewhere in this section. Forcing every tool into a SQL view is both unnecessary and false as a constraint — MLflow serves agents that call external functions and tools all the time; that isn't a hard limitation of the platform. Splitting the tools into an entirely separate, unrelated model breaks the point of an agent: the LLM's tool-calling loop needs the tools available to it directly during a single inference call, not orchestrated by the client stitching two independent models together. Exam framing: this is the agent-specific extension of 'log and register a chain/agent to Unity Catalog using MLflow, with a correct signature and dependencies' — for agents, dependencies include tool resources, not just Python packages.