Part of a series on building cz-agents → under the hood

The Czech Republic has surprisingly good open data. ARES holds company records, ISIR covers insolvency, ČNB publishes exchange rates and monetary statistics, ADIS tracks VAT payer reliability, OFAC and EU sanctions are available through ESMA. All public, all free, all accessible to anyone who can make an HTTP request.

The problem is that "anyone who can make an HTTP request" in 2026 doesn't include the typical developer building an AI agent. And certainly not the LLM that's supposed to drive the agent. We have the data. We're missing the interface.

What specifically hurts

Let me give three examples from different government registries. Not to complain, but to show that these aren't isolated problems.

ARES. It returns different XML structures for different legal forms. An s.r.o. has a different structure than a joint-stock company, a sole trader looks different from a civic association. Fields that exist for one type are missing in another without warning. No documentation on which fields apply to which type — you find out when it blows up in production. The endpoint has changed multiple times, breaking changes shipped without release notes. Fields get renamed without announcement. The developers of downstream tools find out from error messages sent in by their users.

ISIR. The insolvency registry has an extensive WSDL contract with no example calls. No sandbox. No test endpoint. If you want to write a client, you have two options: spend hours deciphering XSD schemas, or try it against production and hope the rate limiter doesn't cut you off. For a small company that needs it once a year for compliance, it's three days of work, not an afternoon.

ČNB. Daily exchange rates are exported as CSV. A format unchanged since 2003 — which sounds like stability, until you notice it's semicolon-delimited, uses Czech decimal commas, and is encoded in Windows-1250. No JSON endpoint, no OpenAPI. When I was pulling the rates into @czagents/cnb, the parser took an hour — not because CSV is complicated, but because every language fights Windows-1250 differently in a UTF-8 world.

These aren't bugs. These are design decisions from an era when the consumer of government data was a human with a browser or an accounting app running in Microsoft Access. That world is gone.

Estonia as a reference point

Estonia gets invoked in e-government discussions so often it's become a cliché. But it's worth looking at what they actually did differently — and what's transferable.

X-Road has been running since 2001. It isn't a central database — it's a federated layer for data exchange between registries. Each registry holds its own data; X-Road is the transport layer with signatures, an audit log, and a standard contract. The key detail: a standard contract. When you as a developer want data from the business registry, the population register, or the land registry, you speak the same protocol with all of them. The schema differs — the protocol doesn't.

eID handles consent. An Estonian citizen gives consent for a specific service to read their data from a specific registry. The audit log then tells them who queried their data. In the Czech Republic this is handled through datová schránka and BankID, but as a developer my impression is that it wasn't deliberately designed for third-party developers.

The EU DESI index consistently places Estonia among Europe's top performers in digital public services. The exact numbers vary between sources, but the order of magnitude is clear — well ahead of where the Czech Republic stands today.

What's transferable: a standard contract across registries, a dev portal with active maintenance, a sandbox with test data, shared entity schemas (one definition of "company", "person", "address" across all registries).

What isn't transferable: Estonia had a twenty-year head start. 1.4 million inhabitants is a different order of complexity — fewer edge cases, fewer legacy systems, fewer institutional interests. And they had a tabula rasa after the Soviet era — no obligation to respect thirty years of accumulated legacy infrastructure. The Czech Republic doesn't have that and never will. Copying Estonia 1:1 makes no sense. Learning from their approach does.

AI agents change the requirements

This matters more than any comparison with Estonia, because it's a trend nobody can avoid. eGovernment in the Czech Republic (and in Estonia) has historically been optimised for a citizen with a browser or an institution with a thick client. That will always be needed. But a new consumer is arriving fast: the LLM agent.

What an LLM agent needs that a human consumer never had to think about:

The creation of DIA (the Digital and Information Agency) in 2023 is a good signal. Consolidating digital services under one roof was necessary. What's still missing from DIA's communications, though, is a layer aimed at developers. Strategic documents, concepts, and RIA analyses — yes. "Here's the sandbox, here's the changelog, here's semver on the endpoint, here's the developer contact" — not yet.

Practical paths forward

This isn't a problem that gets solved by a single ministerial resolution. But it's also not a problem that requires a revolution. Concrete steps that are within reach:

REST + JSON wrapper over existing SOAP/CSV endpoints. SOAP doesn't need to be killed — just add a REST layer alongside it. That's infrastructure work measured in months, not years. ARES already has something like this (a REST API published in recent years), but it doesn't cover everything and lacks consistent behaviour across legal forms.

Dev portal on a unified domain. Something like developers.gov.cz. A central place with documentation for all government APIs, example calls, a sandbox, OpenAPI specs, service status, and a changelog. Not just a list of endpoints — actual developer experience.

Sandbox with test data. A dedicated instance of ARES/ISIR with a representative sample of test companies and insolvencies, accessible to developers without registration or with just an email address. Test a client before you push it to production.

Semver + 6-month deprecation notice. When you want to change a schema, you announce it in the changelog, keep the old version running in parallel for 6 months, and give clients time to migrate. Standard practice at every serious API provider.

Standardised shared entities. Company, person, address, company ID, legal form — every government registry should use the same definition. Today, each one has its own.

This isn't a revolution. This is ordinary 21st-century maintenance.

What I'm doing about it

In the meantime, while the infrastructure catches up, I'm building cz-agents.dev as an adaptation layer. Open-source MCP servers that sit between an LLM agent and the government registries. They normalise schemas, convert CSV to JSON, maintain a stable interface, return structured errors, and handle rate limits.

It's not competition for the state. It's a bridge. Once the government has developer-focused APIs, this layer will disappear — it won't be needed. And that will be a good thing. Until then, it's the only way to connect AI agents to Czech data without every developer spending weeks deciphering WSDL files.

Three concrete invitations:

We have the data. Estonia shows that the interface can be caught up. AI agents are pushing for it to be done properly. The rest is execution.