FinSAgent: Corpus-Aligned Multi-Agent RAG Framework for Evidence-Grounded SEC Filing Question Answering

SEC filings are a retrieval nightmare. A single 10-K runs 100+ pages, uses standardized section headers, and repeats boilerplate across every filing in the corpus. Ask a question like “What operational risks did the company disclose in 2024?” and a naive RAG system will return semantically similar chunks from MD&A, risk factors, and footnotes across multiple years, with no way to tell which statements are legally binding disclosures versus generic filler.

FinSAgent addresses this by treating SEC filings as a structured corpus, not a collection of independent documents. The multi-agent framework aligns retrieval queries to the mandated 10-K structure (Item 1A for risk factors, Item 7 for MD&A, Item 8 for financials) and coordinates evidence gathering across heterogeneous sections. The result is a system that can cite specific filing locations and avoid hallucinating answers from redundant text.

The Prior-Corpus Misalignment Problem

Standard RAG systems fail on SEC filings because they optimize for semantic similarity. When you ask “What are the company’s revenue recognition policies?”, a typical retriever generates a query like “revenue recognition accounting” and ranks chunks by cosine distance. This approach has two failure modes:

Query generation misses corpus-specific evidence. SEC filings use regulated terminology. Revenue recognition policies live in footnotes to the financial statements (Item 8), not in narrative sections. A query derived purely from the user’s question won’t know to target Note 2 or Note 3.
Semantic reranking favors false positives. Every 10-K contains boilerplate about revenue recognition. A semantic ranker will surface topically similar text from MD&A or risk factors, even though those sections don’t contain the authoritative policy statement.

FinSAgent solves this by injecting corpus-side conditioning at both ends: query planning and evidence validation.

Architecture: Role-Specialized Agents Anchored to 10-K Structure

The system uses a multi-agent architecture where each agent is responsible for a specific filing section. This isn’t arbitrary role assignment. It’s a direct mapping to the SEC’s mandated disclosure structure.

Agent roles:

Risk Agent: Queries Item 1A (Risk Factors)
Operations Agent: Queries Item 1 (Business) and Item 7 (MD&A)
Financials Agent: Queries Item 8 (Financial Statements and Supplementary Data)
Governance Agent: Queries Item 10 (Directors, Executive Officers) and Item 11 (Executive Compensation)

Each agent maintains a retrieval plan that specifies which sections to query and what evidence standards to apply. When a user asks a question, a coordinator agent routes the query to the appropriate specialists based on the question type.

Coordination protocol:

Coordinator parses the question and identifies required evidence types (e.g., “operational risks” triggers Risk Agent and Operations Agent).
Each specialist agent generates section-specific queries using corpus-aligned templates (e.g., “Item 1A risk factors related to [topic]”).
Agents retrieve chunks and validate evidence against section-specific criteria (e.g., Risk Agent checks for forward-looking statements and materiality language).
Coordinator synthesizes answers and tracks provenance (filing year, section, page number).

This structure avoids duplicate retrieval because agents don’t overlap in their section assignments. If the same boilerplate appears in multiple sections, only the agent responsible for the authoritative section will return it.

Corpus-Aligned Retrieval: Indexing Strategy

FinSAgent doesn’t chunk filings into arbitrary 512-token windows. It indexes at the section level, preserving the hierarchical structure of the 10-K.

Indexing layers:

Layer	Granularity	Purpose
Filing	Entire 10-K	Metadata (company, fiscal year, filing date)
Section	Item 1, Item 1A, Item 7, etc.	Route queries to correct disclosure type
Subsection	Risk categories, MD&A topics, footnotes	Fine-grained retrieval within sections
Chunk	Paragraphs or tables	Final retrieval unit for context window

Each chunk is tagged with its section path (e.g., Item_1A > Operational_Risks > Supply_Chain). When an agent queries, it filters by section before applying semantic similarity. This prevents the Financials Agent from accidentally retrieving risk factor text that happens to mention revenue.

Cross-filing evidence synthesis works because the index maintains a corpus-wide view. If a question asks about changes over time (“How did revenue recognition policies evolve from 2022 to 2024?”), the Financials Agent can query the same subsection across multiple filings and compare footnote text.

Evidence Provenance and Citation Tracking

Every retrieved chunk includes a provenance tuple: (company_ticker, fiscal_year, section_id, page_number, chunk_id). When the coordinator synthesizes an answer, it preserves these tuples and formats them as inline citations.

Example output:

The company recognizes revenue upon transfer of control to the customer, typically at the point of shipment (AAPL 2024 10-K, Item 8, Note 2, p. 45). This policy changed in 2023 to align with ASC 606 (AAPL 2023 10-K, Item 8, Note 2, p. 42).

This citation format is critical for compliance use cases. Auditors and analysts need to verify that answers are grounded in specific disclosures, not synthesized from semantically similar but non-authoritative text.

Failure Modes and Observability

Conflicting statements across fiscal years: If a company changes its risk disclosure language, the Risk Agent may retrieve contradictory statements from different 10-Ks. The coordinator detects this by comparing chunk timestamps and flags conflicts in the output. The user sees both statements with their respective years.

Redundant disclosures within a single filing: Some companies repeat the same risk factor in multiple sections (e.g., cybersecurity risks in both Item 1A and Item 7). The system deduplicates by chunk content hash before synthesis, but preserves all provenance tuples so the user knows the statement appears in multiple places.

Missing evidence: If no chunks meet the evidence validation criteria, the agent returns an empty result set. The coordinator surfaces this as “No authoritative disclosure found in [section]” rather than hallucinating an answer from weak matches.

Observability hooks:

Agent query logs (which sections were queried, how many chunks retrieved)
Evidence validation scores (how many chunks passed section-specific criteria)
Provenance graph (which filings contributed to the final answer)

These logs are essential for debugging retrieval failures and tuning evidence thresholds.

Deployment Shape

FinSAgent runs as a stateful service with three components:

Index service: Maintains the corpus-wide section index. Rebuilds incrementally when new filings are ingested.
Agent runtime: Hosts the coordinator and specialist agents. Each agent is a separate process with its own retrieval client.
Provenance store: Tracks citation tuples and enables audit trails.

Scaling considerations:

The index service is read-heavy. Shard by company ticker or fiscal year.
Agent processes are CPU-bound (query generation, evidence validation). Scale horizontally.
The provenance store grows linearly with query volume. Partition by time window and archive old queries.

Security boundaries:

User queries never touch raw filing text. All retrieval goes through the agent layer.
Provenance tuples are immutable. Once written, they can’t be edited (prevents citation tampering).
Access control is at the filing level. If a user doesn’t have permission to view a 10-K, the index service filters it out before retrieval.

Code Snippet: Section-Specific Query Generation

class FinancialsAgent:
    def __init__(self, index_client, section_filter="Item_8"):
        self.index = index_client
        self.section = section_filter
        
    def generate_query(self, user_question, evidence_type="policy"):
        # Corpus-aligned query template
        templates = {
            "policy": "Item 8 significant accounting policies for {topic}",
            "change": "Item 8 changes in accounting estimates for {topic}",
            "footnote": "Item 8 footnote disclosures related to {topic}"
        }
        
        topic = self.extract_topic(user_question)
        query = templates[evidence_type].format(topic=topic)
        
        return {
            "query_text": query,
            "section_filter": self.section,
            "evidence_criteria": self.get_validation_rules(evidence_type)
        }
    
    def get_validation_rules(self, evidence_type):
        # Section-specific evidence standards
        if evidence_type == "policy":
            return {
                "must_contain": ["recognize", "policy", "basis"],
                "min_length": 100,  # Policies are detailed
                "exclude_forward_looking": True
            }
        # ... other rules

This snippet shows how the Financials Agent injects corpus structure (Item 8) into the query and applies evidence validation rules that are specific to accounting policy disclosures.

Technical Verdict

Use FinSAgent when:

You need compliance-grade answers with verifiable citations
Your corpus has standardized structure (regulatory filings, legal documents, technical specs)
Redundancy across documents is high and semantic similarity creates false positives
You can map agent roles to corpus sections (not all domains have this structure)

Avoid it when:

Your corpus is unstructured or heterogeneous (news articles, research papers, internal wikis)
You need real-time retrieval over rapidly changing documents (the section index rebuild is expensive)
Citation provenance isn’t critical (simpler RAG systems will be faster and cheaper)
You don’t have the infrastructure to run stateful agent processes (this isn’t a serverless-friendly architecture)

The key insight is that corpus alignment beats semantic similarity when your documents follow a known structure. If you’re building financial compliance tools, legal research systems, or regulatory QA agents, this architecture is worth the operational complexity.

Agentic AI, minus the noise.