An open-source example of how to combine company context, financial disclosures, and source attribution in an AI application.
AI agents are getting increasingly capable at reasoning about complex questions. But when those questions depend on external information, the challenge often isn't the model. It's the data.
Consider a seemingly straightforward request:
"Research this company, explain what it does, and summarize what its regulatory filings tell us."
An AI agent needs to bring together different kinds of information:
- Company background: What does the company do? What are its products, history, and industry?
- Regulatory disclosures: What has the company reported in its SEC filings?
- Source attribution: Where did each claim come from, and how can someone verify it?
Those answers don't necessarily live in the same system or follow the same data structure.
That's the problem we wanted to explore with Dataville's open-source Company Intelligence Agent.
Two sources, one research workflow
The agent combines information from two complementary sources.
- Wikipedia provides broad company context, including background information that can help establish what an organization does and how it fits into its industry.
- SEC EDGAR provides regulatory filings for publicly traded companies, including disclosures that can support more detailed financial and operational research.
Together, these sources allow an agent to connect general company context with formal corporate disclosures.
The important design principle is that the resulting research should remain connected to its sources. Rather than presenting a collection of unsupported statements, the Company Intelligence Agent links its claims to the underlying information. That makes the output easier to inspect and verify.
Why not just ask an LLM?
A language model can generate a convincing company profile from its existing knowledge. But convincing isn't the same as verifiable.
There are several challenges when relying exclusively on model knowledge:
- Information changes. Companies release new filings, revise disclosures, introduce products, and change their operations.
- Different questions require different kinds of data. A question about a company's history is fundamentally different from a question about a reported financial figure.
- Source attribution matters. For research applications, users need to distinguish information supported by a source from an interpretation generated by the model.
- External data integration adds complexity. Each source can have its own access methods, response structures, and update cycles.
A useful agent needs a way to work across these differences without forcing developers to rebuild the same integrations for every application.
The architecture: separating data access from agent behavior
The Company Intelligence Agent uses Dataville to access Wikipedia and SEC filing information through a common data layer.
At a conceptual level, the workflow looks like this:
Research question
│
▼
Company Intelligence Agent
│
▼
Dataville (REST API / MCP server)
│
├──► Wikipedia
└──► SEC EDGAR
│
▼
Source-linked results
The agent is responsible for the research workflow. Dataville provides access to curated external data through its REST API and MCP server.
This separation is useful because developers can concentrate on what the application should do with the information rather than spending all their effort managing individual data integrations. It also creates a foundation for extending the application to additional datasets as they become available.
Why source-linked answers matter
Suppose an agent produces a company research summary containing background information alongside details from regulatory filings.
Without source references, the user has to trust the generated response or manually reconstruct where each statement originated.
With source-linked claims, the research becomes easier to audit. A developer can build experiences where users can:
- inspect the underlying evidence,
- distinguish general context from regulatory disclosures, and
- investigate individual claims.
Source attribution doesn't guarantee that every interpretation is correct. But it gives developers and users a stronger basis for checking the result. For company research, that's an important step toward more trustworthy AI applications.
Explore the open-source project
We've published the Company Intelligence Agent as an open-source example for developers interested in building applications with external data.
datavilleorg
/
company-intelligence-agent
Company research agent combining Wikimedia context with authoritative SEC EDGAR filings and financials — every claim source-linked. Built on the Dataville API and MCP.
Company Intelligence Agent
Research any public company from two trustworthy sources at once — Wikimedia for context, SEC EDGAR for authoritative disclosures — with every claim linked back to where it came from.
Built on Dataville: one API and one MCP server over both datasets, so you don't build or maintain ingestion, parsing, entity matching or update infrastructure for either.
Get a free API key · Docs · API reference · Dataville MCP · Wikimedia package · SEC EDGAR package · Live demos
Status: in active development. The quickstart below runs today against the live Dataville API The full agent (entity resolution, LLM reasoning layer, UI) is being built in this repo — watch or star it to follow along.
Company name ──▶ Dataville ──┬─▶ Wikimedia: description, history, products, people, related entities
└─▶ SEC EDGAR: 10-K / 10-Q / 8-K filings, XBRL financials, material events
│
▼
Reasoning layer…The project demonstrates a practical use case for combining Wikipedia and SEC filings while retaining links to the underlying sources. You can explore the repository, review the implementation, and use it as a starting point for your own experiments.
For additional examples, Dataville also provides:
The bigger question: how should agents access external data?
Building the Company Intelligence Agent raises a broader architectural question: when should an agent query an external data source directly, and when should it rely on previously ingested information?
- For relatively static, text-heavy content, retrieval from an existing index may be appropriate.
- For structured information, exact values, or data that changes over time, direct queries or regularly refreshed structured datasets may be a better fit.
And regardless of the approach, developers still need to think about source attribution, reporting periods, revisions, and consistency.
There isn't one universal answer. The right approach depends on the application, the underlying data, and how important accuracy, freshness, and reproducibility are to the user.
What would you build?
The Company Intelligence Agent is one example of what becomes possible when external datasets are easier to access through a common interface.
We're interested in how other developers are solving these problems:
- Are you using MCP, direct APIs, or RAG for company research agents?
- How are you handling source attribution when combining multiple datasets?
- What additional sources would make a company intelligence agent more useful?
Take a look at the project and let us know in the comments what you'd improve.
Explore the code: github.com/datavilleorg/company-intelligence-agent
Test the working demo: https://docs.dataville.com/guides/competitor-scan
Disclosure: I work with Dataville on marketing and developer outreach. Dataville provides access to curated public and select licensed datasets through a unified API and MCP server.
Top comments (9)
One thing that bites when a claim is "linked to its filing": the filing time. If the agent shows when a filing was accepted, EDGAR's acceptanceDateTime is not uniform. In 450 filings I measured, it is right in some companies' files and shifted by an Eastern offset in others, and the same filing can differ between two files. So store the accession number with each claim, and take the time from one named source rather than whichever file answered.
Restatements are the other one: a later 10-K can report the same fact under a different XBRL tag, so a lookup by tag name can miss the restated value.
Paul's point about eleven tools is real; I hit the same wall with 306 tools and ended up with three front tools (1,109 tokens of context instead of 34,508). I built canli-mcp for this, free, MIT, runs locally:
npx -y canli-mcp, github.com/arhancanli/canlicapital.Does the agent keep the filing's accession number in its output, or only the URL?
Thanks, @arhancanli . These are exactly the details that decide whether “source-linked” holds up.
To your question: yes, the accession number is in the output, not just the URL. Each EDGAR response carries it in metadata.accession_number (for example 0000320193-26-000020 for Apple’s latest 10-Q) and in the record id. The problem is our example script, which prints only the document URL. I’ll fix that so every SEC-sourced line includes the accession number.
On filing time: we expose filing_date as a date, not acceptanceDateTime. That avoids most of the offset problem, but a filing accepted late in the evening can still end up on the wrong day. We’ll document which SEC file the date comes from, as you suggest.
On restatements: this is the bigger gap. Our financials block doesn’t show the XBRL tag or the accession number behind each value, so you couldn’t see a restatement in our output. I took a look at canli-fundamentals-mcp, and the way it shows the first-reported value next to later restatements, with the filing for each, is the right model. Adding both the tag and the accession number to each value is now on our roadmap.
On tool count: I liked the find/describe/run pattern in canli-mcp. Cutting 300+ tools down to three in context is a big saving. Dataville takes a similar approach at a smaller scale: four tools, with the data source passed as an argument, so adding sources doesn’t grow the list.
If you’re open to sharing your 450-filing set, it would make a great test case.
@mansi_dataville A filter on the listing is the natural next step, and I'd keep its reply to names and one line each. The schema stays with describe, so the list stays cheap however long the catalog gets.
Eleven sources behind one server makes sense. Eleven tools does not: the agent chooses among them every turn, and the list grows with each source. A search and a fetch reach the same sources.
@paul_irolla_6b5ae261d0224 Agreed, and that's how the server is built.
Eleven sources, four tools: list_dataville_sources, describe_dataville_source, search_dataville and query_dataville as read-only SQL.
The source is an argument, not a separate tool, so adding a dataset doesn't grow the list the agent picks from.
You can find more details here: github.com/datavilleorg/dataville-mcp
Fred here, CEO at Dataville. Thanks, Mansi, for writing this up.
The point I'd underline: the agent shouldn't own the data plumbing. Wikipedia and SEC EDGAR look simple until you're dealing with entity resolution, filing formats, and keeping things fresh. We'd rather absorb that once so builders can focus on what their agent actually does.
If you try the company intelligence agent, tell us which source you'd want next. That list drives our roadmap.
More at dataville.com
@mansi_dataville Passing the source as an argument keeps the tool list at four. The agent reads that list on every turn, so adding a dataset costs the same as adding ten.
@paul_irolla_6b5ae261d0224 Exactly. The catalog still grows, but it moves out of the tool list and into what list_dataville_sources and describe_dataville_source return. The agent pays for that only when it calls them, usually once per task, not on every turn. And it pulls the schema for just the source it needs.
The open question for us is what happens when the catalog gets long enough that listing it becomes expensive. We're considering letting list_dataville_sources take a filter. Curious whether you've seen a better pattern.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.