An engineer logging the maintenance-triage agent with MLflow wants the Model Serving endpoint to reproduce the exact same Python library versions used during development, so the agent's tool-calling behavior does not subtly change in production. Which practice ensures this?
Select an answer to reveal the explanation.
Short Explanation
If you don't pack the ingredients with the recipe, the kitchen improvises — and improvised library versions are exactly what causes an agent to behave differently in production than it did in the notebook. Capturing pip requirements with the MLflow logging call packs the ingredients in.
Full Explanation
MLflow's logging APIs capture the model's Python dependencies (via a requirements.txt-style pip list or a conda environment) alongside the model artifact itself, and Model Serving uses that captured environment to reconstruct a matching runtime when the model is deployed. This is the mechanism that guarantees the exact library versions used during development are the ones running in production, which directly protects against subtle behavior drift in something as sensitive to library version as agent tool-calling. Manually documenting versions in a README is a human-readable reference but is not consumed by Model Serving to build the runtime — it can drift out of date and does nothing automatically. Assuming the serving endpoint's default runtime always matches the notebook's runtime is false; without explicit dependency capture, the serving environment can differ in installed package versions, which is exactly the risk the scenario describes. Pinning versions only inside tool functions (e.g., in code comments or local imports) does not communicate anything to MLflow's environment-reconstruction process and leaves the rest of the model's dependencies unpinned. For the exam, remember that dependency capture is part of the MLflow logging step, not a separate manual documentation task.