Your human-oriented service being consumed by agents represents a service design failure. The same goes for your documents or knowledge sets that, before AI, were designed for human consumption. If your customers need a piece of software to interact with your software, why isn't that software part of your software? If your documents or knowledge sets are no longer fit for human consumption, how did you get there and how long has that been going on? Has your service, in fact, evolved into something entirely unusable?
That's not a very comforting thought. Sometimes there's a good reason for that service design failure, and sometimes that reason cannot be removed easily. The Estonian set of laws has grown more complex over time and is probably nearing a point where it can no longer be understood holistically without something like an LLM.
The plateau of decent design
While Estonian electronic services are overall quite sensible and the famous use cases of establishing a business or filing your taxes in a few minutes are true, we have hit a plateau a while ago. Many of our services are still mind-bogglingly difficult to use, and many of our support structures (e.g., services for physical or medical health patients) are incomprehensible. This has been the case regardless (or maybe because of) the money or talent poured into the problem over the past decade or more.
While the engineer in me gets frustrated every time I meet a badly designed service with an apparently trivial fix, the system architect in me must concede that I have no good idea how to stop the public sector from producing such failures at an alarming rate.
So it would seem our digital state indeed needs to compensate for our apparent inability to provide a sensible service to our citizens.
Various LLM-based agents fit the bill. A person could send their minions to do the frustrating work and get back a clear guide on how to navigate the bureaucracy to get the specific service they need. An agent could have a corporate annual report filed or wrestle with the notoriously complex administrative processes surrounding building a house. Something would get done with less frustration and time spent.
Unfortunately, these minions, much like the yellow ones in the movies, are adorable but not perfect and could be bent to a nefarious will with relative ease. Also, it doesn't really matter what shape these minions are. Some folks would prefer to prompt an LLM-based agent, while others would rather craft a more limited but easier-to-control piece of code.
The problem of control exists beyond the current revolution in LLM capabilities. There is a broader need to control the actions of software operating on your behalf, and for the service provider to recognise them as such. People usually want their minions on a leash, the other end of which is firmly in their grip.
This authentication and authorisation problem is not new. I don't know about you, but I personally can't directly communicate with a server; we all use software and hardware to act on our behalf daily, and we have for a long time.
Protocols like OAuth and OpenID Connect were explicitly designed to solve the technical part of this issue and are used right now to let agents prove their right to do something. So why can't we just plop these on top of our existing service base of thousands of services across hundreds of agencies and call it a day?
Because all technical solutions to this challenge, regardless of the technology used, suffer from the complementary-products problem. Who in their right mind would buy the Apple Vision Pro that, in the absence of dedicated software making use of its amazing capabilities, just acts as a glorified monitor? And who would take on the considerable expense of tailoring their software's user experience to a device modality with a nonexistent user base? There are no users because there is no software, and there is no software because there are no users.
The same goes for identity products: services have no reason to integrate whatever agent-based identity and access management mechanism is agreed upon if no one uses it. And it is hard to see a vibrant ecosystem of agents using any IAM solution emerge without wide service support. No services exist because the use case doesn't make sense, and the use case makes no sense because (at least we hope so) no services exist. The problem is both figuring out the technical solution and getting it adopted. Solving just one isn't enough; both are complicated.
There are several ways to overcome this deadlock and to solve the adoption problem. The approach Estonia is seriously considering right now is to make the agents look like people. Estonia's digital services already support delegation between people and have done so for several decades.
The population registry maintains my right to act on behalf of my children. The business registry allows me to act on behalf of my company. More complex services have built additional delegation features on top. It's not perfect, but it does work. If we could use the existing authentication and authorisation mechanisms, we'd instantly gain 100% support from the services, and the deadlock would be broken.
Imitation
The key point is that the agents would look like people rather than become them. Computer-based agents are ephemeral; a code change, a shift in an LLM's training data, or any update to the massive software stack we all rely on can dramatically change their behaviour. So we are not considering issuing agents' identities. Instead, we're issuing people additional identities they can control. The state gives you a numbered leash you can put on a minion of your liking. It's the same basic idea of using different accounts on your computer for everyday work and for deep system updates. It's still you, but the identifiers are different.
This approach is not without its issues. Many people baulk at the mere idea of agents looking like humans. There's the limited address space for Estonian identity codes, and the scalability challenge of tracking tens of these subordinate identities.
We also face technical challenges. But the important bit here is that we are not content with the status quo. We'd like our state to be more open, more accessible, more convenient for both our citizens and for the world. Let's see if we can make it work.
Andres Kütt is a system architect helping organisations execute their digital strategies. Over the past 35 years, he has built websites, internet banks, energy and government systems. He was an architecture team lead at Skype. A passion for architecting things led him to the MIT, where he received a MsC from the System Design and Management program. Andres subsequently applied the knowledge gained at as a Chief Architect of Estonia, the leading digital nation, and now continues the same mission internationally.
He is a published writer and a researcher. Andres taught a unique system architecture approach to enterprise architecture at TalTech and an is teaching an e-government masterclass at the University of Tartu. Andres lives in Tallinn, Estonia, with his lovely wife, two teenagers and probably too many guitars.
Comments ()