An AI agent that works with businesses will sooner or later be asked about a company: is this supplier real, is this customer still active, what is this company's registered name. A model can write a confident answer to all of these from memory. The trouble is that memory stops at a training date, mixes companies with similar names, and has no idea what was registered last week. If your product depends on those answers, the agent needs to look them up, and you need to be able to show where each answer came from.
This guide is for teams building agents. It covers what "reliable" means for company facts, how to design the tool your agent calls, and how to handle the cases that go wrong.
What you'll learn
- Why company facts are a bad fit for a model's memory
- What a reliable company answer contains
- How to design or choose the tool your agent calls
- How to handle "unknown", "not covered" and errors without the agent making things up
- A short checklist before you ship
Why can't the model just answer?
Three reasons, each enough on its own.
Company facts change. Companies are created, renamed, moved, put into liquidation and closed every day. A model's training data has a cut-off; the register doesn't.
Names are ambiguous. Many companies share a name, or nearly do. A model asked about "a company called X" will often blend several into one plausible answer.
Nobody can check a guess. When an agent says "this company is active", your user, your auditor or your own support team will eventually ask: according to whom, and when? A model's memory has no answer to that.
So for company facts, the agent's job isn't to know; it's to ask a source that knows, and to pass on what the source said, with the source.
What does a reliable company answer contain?
Five things:
- The fact, in one plain sentence: "RENAULT is active."
- The identifier that pins down which company it is: here, SIREN 441639465.
- The source: which official register, with a link to the record.
- The date: when the source was checked, and the date the source gives for the fact.
- The licence: under which terms the data was published, so you know what you may do with it.
That's the shape Fuentio's answers take: one plain first sentence, then the record, then the source stamp. The agent can repeat the sentence and cite the stamp, and a person can open the source to check.
How should the agent's tool be designed?
Whether you build the tool yourself or use a provider's, the same rules make it safe for an agent.
Look up by identifier when you have one. A number (a SIREN, a SIRET, a registry sheet) leaves no doubt about which company is meant. Search by name only when you don't have a number, and show the agent several candidates rather than one best guess.
Keep the tool narrow and well described. An agent decides what to call from the tool's name and description. "Look up one company by its official number in France or Spain" is better than "get company data".
Return the source with the fact, every time. If the source travels with the answer, the agent can cite it without extra calls, and your logs show it later.
Use the protocol your agents already speak. If your agents run in Claude, Cursor or another MCP host, an MCP server lets them discover and call the tool without custom glue. See what MCP is and why agents need it.
How do you handle the cases that go wrong?
This is where reliable agents differ from impressive demos.
"Unknown" must stay "unknown". Some registers don't state some facts. In Spain, for instance, a company whose only published act is its incorporation has no status act, so its status is unknown. If the tool says "unknown", the agent should say so, not guess "probably active". Tell it so in its instructions.
"Not covered" is not "doesn't exist". If a company is in a country your source doesn't cover, the honest answer is that it's outside the source, with a link to the official register, not "no such company". Fuentio's answers say "not covered by an automated source" in that case, so the agent can tell the user exactly that.
Errors should say what to do next. A good tool returns an error code and a next step (search by name instead, try again later, check the identifier format). The agent can follow it, or tell the user plainly.
Never let the agent fill a gap with memory. If the tool failed, the agent should say the check couldn't be done, not answer from training data. Put that rule in the agent's instructions and test it.
What should you test before shipping?
A short list, run as real conversations with your agent:
- A well-known active company, by its official number. Does the agent cite the source and date?
- A company that has closed. Does the agent say closed, with the date and source?
- A company whose status the source doesn't state. Does the agent say "unknown"?
- A company outside the source's coverage. Does the agent say so, and give the register's link?
- A typo in a number. Does the agent explain the error instead of inventing a company?
- Two companies with similar names. Does the agent ask which one, or show both?
If all six behave, your agent is ready to talk about companies in front of users.
Where does Fuentio fit?
Fuentio gives agents official company records for France and Spain, through a REST API and an MCP server, both opening soon. Every answer starts with one plain sentence and ends with its source. See what we cover, and for the registers behind the answers, French company registers explained.
Limits. A source makes an agent's company facts checkable; it doesn't make the agent's decisions right. Fuentio covers France and Spain; anything else is outside its sources, and its answers say so. It returns register facts, not judgements about a company.
Frequently asked questions
Can't I just let the agent search the web?
Web results mix official pages with copies of unknown age. For facts you need to defend, ask the official source, and keep its link.
Should the agent look up by name or by number?
By number whenever you have one. Names are ambiguous; numbers aren't.
How do I stop the agent from guessing?
Give it a tool that returns "unknown" and "not covered" explicitly, tell it in its instructions never to answer company facts from memory, and test both cases.
Do I need MCP?
If your agents run in an MCP host, it's the simplest way to give them a tool. If you call models from your own code, a plain API call works too.
Sources
- Model Context Protocol: modelcontextprotocol.io
- INSEE, definition of the SIREN number: insee.fr