A logistics firm wants an agent that reads order status. An order API already returns that status to other applications. A proposal funds a new orchestration layer before any agent work. What should the build strategy do?
Select an answer to reveal the explanation.
Short Explanation
You do not pave a new highway beside a ramp that already reaches the warehouse. You reuse the order API that already returns status, and you defer a new orchestration layer until that API cannot serve the agent. A model that guesses status from email is not a system of record.
Full Explanation
Build strategy spends new platform money only when the system the firm already runs cannot do the job. The order API returns status to other applications, and reading that status is the agent's need, so the strategy should bind the agent to that API and defer a new orchestration layer until the API cannot serve. Funding the new orchestration layer first and leaving the current order API unused until that layer is live delays the agent and pays for a tier the status read has not required. Rebuilding order status inside the agent so the project does not depend on any existing interface creates a second source that will drift from the orders the rest of the firm trusts. Training a custom model to guess order status from old emails instead of calling a system of record replaces a record with a prediction and will be wrong the moment an order changes. Exam caveat: reusing the API does not decide the agent's channel or its identity. It decides where status comes from. Operational check: the design names the existing order API as the status source, and the orchestration project is not in the funded scope of this pass.