Wow: autonomous agents!

The problem is not the autonomy. The problem isn’t even particularly with the intelligence…

Autonomous, intelligent agents offer some great opportunities for our digital lives*.  There, look, I said it.  They will book meetings for us, negotiate cheap holidays, order our children’s complete school outfit for the beginning of term, and let us know when it’s time to go to the nurse for our check-up.  Our business lives, our personal lives, our family relationships – they’ll all be revolutionised by autonomous agents.  Autonomous agents will learn our preferences, have access to our diaries, pay for items, be able to send messages to our friends.

This is all fantastic, and I’m very excited about it.  The problem is that I’ve been excited about it for nearly 20 years, when I was involved in a project around autonomous agents in Java.  It was very neat then, and it’s still very neat now***.

Of course, technology has moved on.  Some of the underlying capabilities are much more advanced now than then.  General availability of APIs, consistency of data formats, better Machine Learning (or Artificial Intelligence, if you must), less computationally expensive cryptography, and the rise of blockchains and distributed ledgers: they all bring the ability for us to build autonomous agents closer than ever before.  We talked about disintermediation back in the day, and that looked plausible.  We really can build scalable marketplaces now in ways which just weren’t as feasible two decades ago.

The problem, though, isn’t the technology.  It was never the technology.  We could have made the technology work 20 years ago, even if it wasn’t as fast, secure or wide-ranging as it could be today.  It isn’t even vested interests from the large platform players, who arguably own much of this space at the moment – though these interests are much more consolidated than they were when I was first looking at this issue.

The problem is not the autonomy.  The problem isn’t even particularly with the intelligence: you can program as much or as little in as you want, or as the technology allows.  The problem is with the agency.

How much of my life do I want to hand over to what’s basically a ‘bot?  Ignore***** the fact that these things will get hacked******, and assume we’re talking about normal, intended usage.  What does “agency” mean?  It means acting for someone: being their agent – think of what actors’ agents do, for example.  When I engage a lawyer or a builder or an accountant to do something for me, or when an actor employs an agent for that matter, we’re very clear about what they’ll be doing.  This is to protect both me and them from unintended consequences.  There’s a huge legal corpus around defining, in different fields, exactly the scope of work to be carried out by a person or a company who is acting as an agent.  There are contracts, and agreed restitutions – basically punishments – for when things go wrong.  Say that an accountant buys 500 shares in a bank, and then I turn round and say that she never had the authority to do so: if we’ve set up the relationship correctly, it should be entirely clear whether or not she did, and whose responsibility it is to deal with any fall-out from that purchase.

Now think about that in terms of autonomous, intelligent agents.  Write me that contract, and make it equivalent in software and the legal system.  Tell me what happens when things go wrong with the software.  Show me how to prove that I didn’t tell the agent to buy those shares.  Explain to me where the restitution lies.

And these are arguably the simple problems.  How to I rebuild the business reputation that I’ve built up over the past 15 years when my agent posts on Twitter a tweet about how I use a competitor’s products, when I’m just trialling them for interest?  How does an agent know not to let my wife see the diary entry for my meeting with that divorce lawyer*******?  What aspects of my browsing profile are appropriate for suggesting – or even buying – online products or services with my personal or business credit card*********?  And there’s the classic “buying flowers for the mistress and having them sent to the wife” problem**********.

I don’t think we have an answer to these questions: not even close.  You know that virtual admin assistant we’ve been promised in sci-fi movies for decades now: the one with the futuristic haircut who appears as a hologram outside our office?  Holograms – nearly.  Technology behind it – pretty much.  Trust, reputation and agency?  Nowhere near.

 


*I hate this word: “digital”.  Well, not really, but it’s used far too much as a shorthand for “newest technology”**.

**”Digital businesses”.  You mean, unlike all the analogue ones?  Come on.

***this is one of those words that my kids hate me using.  There are two types of word that come into this category: old words and new words.  Either I’m showing how old I am, or I’m trying to be hip****, which is arguably worse.  I can’t win.

****yeah, they don’t say hip.  That’s one of the “old person words”.

*****for now, at least.  Let’s not forget it.

******_everything_  gets hacked*******.

*******I could say “cracked”, but some of it won’t be malicious, and hacking might be positive.

********I’m not.  This is an example.

*********this isn’t even about “dodgy” things I might have been browsing on home time.  I may have been browsing for analyst services, with the intent to buy a subscription: how sure am I that the agent won’t decide to charge these to my personal credit card when it knows that I perform other “business-like” actions like pay for business-related books myself sometimes?

**********how many times do I have to tell you, darling…?

Is blockchain a security topic?

… we need to understand how systems and the business work together …

Blockchains are big news at the moment.  There are conferences, start-ups, exhibitions, open source projects – all we need now are hipster-run blockchain-themed cafés*.  If you’re looking for an initial overview, you could do worse than the Wikipedia entry – that’s not the aim of this post.

Before we go much further, one useful thing to know about many blockchains projects is that they aren’t.  Blockchains, that is.  They are, more accurately, distributed ledgers****.  For now, however, let’s roll in blockchain and distributed ledger technologies and assume we’re talking about the same thing: it’ll make it easier for now, and in most cases, the difference is immaterial for our discussions.

I’m not planning to go into the basics here, but we should briefly talk about the main link with crypto and blockchains, and that’s the blocks themselves. In order to build a block, a set of transactions to put into a blockchain, and then to link it into the blockchain, cryptographic hashes are used.   This is the most obvious relationship that the various blockchains have with cryptography.

There’s another, equally important one, however, which is about identity*****.  Now, for many blockchain-based crypto-currencies, a major part of the point of using them at all is that identity isn’t, at one level, important.  There are many actors in a crypto-currency who may be passing each other vanishingly small or eye-wateringly big amounts of money, and they don’t need to know who each other is in order to make transactions.  To be more clear, the uniqueness of each actor absolutely is important – I want to be sure that I’m sending money to the entity who has just rendered me a service – but being able to tie that unique identity to a particular person IRL****** is not required.  To use the technical term, such a system is pseudonymous.  Now, if pseudonymity is a key part of the system, then protecting that property is likely to be important to its users.  Crypto-currencies do this with various degrees of success.  The lesson here is that you should do some serious reading and research if you’re planning to use a crypto-currency, and this property matters to you.

On the other hand, there are many blockchain/distributed ledger technologies where pseudonymity is not a required property, and may actually be unwanted.  These are the types of system in which I am most generally interested from a professional point of view.

In particular, I’m interested in permissioned blockchains.  Permissionless (or non-permissioned) blockchains are those where you don’t need permission from anyone in order to participate.  You can see why pseudonimity and permissionless blockchains can fit well today: most (all?) crypto-currencies are permissionless.  Permissioned blockchains are a different kettle of fish, however, and they’re the ones at which many businesses are looking at the moment.  In these cases, you know the people or entities who are going to be participating – or, if you don’t know now, you’ll want to check on them and their identity before they join your blockchain (or distributed ledger).  And here’s why blockchains are interesting in business********.  It’s not just that identity is interesting, though it is, because how you marry a particular entity to an identity and make sure that this binding is not spoofable over the lifetime of the system is difficult, difficult, lemon difficult******** – but there’s more to it than that.

What’s really interesting is that if you’re thinking about moving to a permissioned blockchain or distributed ledger with permissioned actors, then you’re going to have to spend some time thinking about trust.  You’re unlikely to be using a proof-of-work system for making blocks – there’s little point in a permissioned system – so who decides what comprises as “valid” block, that the rest of the system should agree on?  Well, you can rotate around some (or all) of the entities, or you can have a random choice, or you can elect a small number of über-trusted entities.  Combinations of these schemes may also work.  If these entities all exist within one trust domain, which you control, then fine, but what if they’re distributors, or customers, or partners, or other banks, or manufacturers, or semi-autonomous drones, or vehicles in a commercial fleet?  You really need to ensure that the trust relationships that you’re encoding into your implementation/deployment truly reflect the legal and IRL trust relationships that you have with the entities which are being represented in your system.

And the problem is that once you’ve deployed that system, it’s likely to be very difficult to backtrack, adjust or reset the trust relationships that you’ve designed in.  And if you don’t think about the questions I noted above about long-term bindings of identity, you’re going to be in some serious problems when, for instance:

  • an entity is spoofed;
  • an entity goes bankrupt;
  • an entity is acquired by another entity (buy-outs, acquisitions, mergers, etc.);
  • an entity moves into a different jurisdiction;
  • legislation or regulation changes.

These are all issues that are well catered for within existing legal frameworks (with the possible exception of the first), but which are more difficult to manage within the sorts of systems with which we are generally concerned in this blog.

Please don’t confuse the issues noted above with the questions around how to map legal agreements to the so-called “smart contracts” in blockchain/distributed ledger systems.  That’s another thorny (and, to be honest, not unconnected issue), but this one goes right to the heart of what a system is, and it’s the reason that people need to think very hard about what they’re really trying to achieve when they adopt our latest buzz-word technology.  Yet again, we need to understand how systems and the business work together, and be honest about the fit.

 


*if you come across one of these, please let me know.  Put a picture in a comment or something.**

**even better – start one yourself. Make sure I get an invitation to the opening***.

***and free everything.

****there have been onlines spats about this.  I’m not joining in.

*****there are others, but I’ll save those for another day.

******IRL == “In Real Life”.  I’m so old-skool.

*******for me.  If you’ve got this far into the article, I’m hoping there’s an evens chance that the same will go for you, too.

********I’ll leave this as an exercise for the reader.  Watch it, though, and the TV series on which it’s based.  Unless you don’t like swearing, in which case don’t watch either.