## Design an Entitlement-Aware Agentic Portfolio Workflow Design an agentic workflow that accepts a portfolio-related request, obtains only the data the caller is allowed to use, invokes one or more specialized agents or tools, and returns an auditable result. Explain the architecture through one representative request rather than describing an abstract collection of AI components. ### Constraints & Assumptions - The workflow may use more than one model or model provider. - Data access is controlled by user and dataset entitlements; the model must not be the authority for access decisions. - Some operations may be long-running, and a caller needs a way to retrieve status and results. - Your design should distinguish ordinary service endpoints, data-access components, the orchestrator, specialized agents, and any MCP server you choose to use. - Do not assume a particular provider feature unless you state it as an assumption. ### Clarifying Questions to Ask - Is the representative request read-only analysis, or can it trigger portfolio changes or other side effects? - Which data domains and tools are required, and which entitlement dimensions apply to them? - What evidence must be retained to reproduce or audit a response? - Are model providers restricted by data residency, confidentiality, latency, or cost? ### Part 1 — Trace the Workflow and Choose Models Choose a concrete request and trace it from the public endpoint to the final response. Identify the model-dependent steps, explain whether one model or several models are appropriate, and define how provider selection and fallback work. #### What This Part Should Cover - A request lifecycle with explicit intermediate state and tool results. - Task-based model selection rather than a provider-name list. - The behavior when a provider is unavailable or produces an invalid response. - A way to evaluate whether routing to a different model improves the workflow. ```hint Separate decisions from execution List which steps interpret intent, which steps retrieve facts, and which steps perform deterministic actions before assigning models. ``` ### Part 2 — Draw the Service and Agent Boundaries Explain which responsibilities belong to endpoints, data-access services, entitlement checks, the orchestrator, and specialized agents. State whether agents are independent services, in-process tools, prompt configurations, or a deliberate mixture, and justify that boundary. #### What This Part Should Cover - Stable contracts between the orchestrator and each capability. - Centralized authorization enforcement before data or tools are exposed. - State, retry, timeout, and idempotency ownership. - The trade-off between independently deployed agents and tool-based agents in one service. ```hint Put state in one place Choose which component owns the workflow state machine before deciding whether an agent deserves its own deployment. ``` ### Part 3 — Place MCP and Operational Controls If MCP is useful, specify the resources or tools an MCP server exposes and what it does not control. Then cover logging, lineage, failure isolation, and safe handling of side effects. #### What This Part Should Cover - A concrete MCP boundary instead of treating MCP as the entire architecture. - Propagation of authenticated identity and entitlement context. - Audit records that bind inputs, data versions, tool calls, model versions, and outputs. - Safe retries and human confirmation for consequential actions. ```hint Keep policy outside the protocol Use MCP to expose typed capabilities, while a trusted service enforces identity, entitlements, and confirmation requirements. ``` ### What a Strong Answer Covers - A coherent end-to-end trace whose components have non-overlapping responsibilities. - Authorization and data access enforced in deterministic services, not delegated to a prompt. - Explicit provider and agent-boundary trade-offs tied to the chosen workflow. - Reproducibility, observability, and failure behavior that are designed into the request lifecycle. ### Follow-up Questions 1. How would the workflow continue safely if the selected model provider failed after several tools had already run? 2. What changes if a specialized agent becomes an independently deployed service owned by another team? 3. How would you prove that an MCP tool never returned data outside the caller's entitlements? 4. Which records would you inspect when two runs of the same request produced different answers?