A quantitative investment team is evaluating an agentic AI system to automate their nightly pre-market research workflow, which involves: (1) pulling overnight macro data from three APIs, (2) scanning 200+ earnings releases for specific financial metrics, (3) cross-referencing findings against the firm's internal position book, and (4) generating a prioritized morning briefing for the PM team. The system must complete this workflow reliably within a two-hour overnight window. Which AI agent architecture is best suited for this use case?
Select an answer to reveal the explanation.
Short Explanation and Infographic
Think of this like a surgical team, not a solo surgeon. A complex four-stage nightly workflow with API calls, document parsing, database lookups, and report generation is exactly the use case that breaks single-agent approaches — too much context, too many failure modes, no specialization. A multi-agent framework with an orchestrator is the right architecture because each agent can fail, retry, and hand off cleanly. B is correct.
Full explanation below image
Full Explanation
The selection of AI agent architecture is a critical decision in deploying autonomous AI systems in financial workflows. The key design variables are: task complexity, the presence of distinct subtasks with different tool requirements, the need for error isolation and retry logic, the acceptable latency window, and the auditability requirements of financial systems.
This scenario has a four-stage pipeline with distinctly different subtasks: (1) API-based structured data ingestion, which requires rate limit management, API authentication, and data validation; (2) document parsing across 200+ earnings releases, a parallelizable high-throughput task; (3) relational cross-referencing against an internal database, which requires secure data access patterns and schema knowledge; and (4) natural language report generation from synthesized inputs, an LLM reasoning task. These stages have fundamentally different computational profiles, tool requirements, and failure modes.
A multi-agent orchestration framework (Option B) handles this by decomposing the workflow into specialized sub-agents, each optimized for its stage. The orchestrator agent manages sequencing (ensuring data ingestion completes before parsing begins), error handling (retrying failed API calls, flagging missing earnings releases), and output consolidation (passing structured outputs between agents in a typed contract). This architecture provides the reliability required for a production nightly workflow because failures are isolated to individual sub-agents and can be retried without restarting the entire pipeline. It also produces auditable intermediate outputs at each stage — critical for investment compliance.
Option A (single general-purpose agent) fails in production for complex multi-step workflows for well-documented reasons: context window limitations constrain how much information can be processed simultaneously; a single agent hitting four different tool types accumulates compounding failure probability; and chain-of-thought self-direction without explicit orchestration produces inconsistent sequencing behavior across runs. Option C (fine-tuned LLM on historical briefings) confuses the generation task with the full workflow — it can write the final report but cannot perform API calls, document parsing, or database lookups. It is also static relative to changing data. Option D (RPA + single LLM call) is a valid hybrid for simpler use cases but breaks down here because RPA systems lack the contextual reasoning needed to handle the variance in earnings release formats, and a single final LLM call cannot compensate for the loss of intermediate reasoning across stages.