On systems of intelligence

Let’s look at this theory bottom-up. Since forever, every service has existed as a system of interactions between humans. Let’s classify them as ‘internal’ [servicer] and ‘external’ [servicee]. Interactions here are of two kinds: Inter-organizational and Intra-organizational. For most of this article, we will assume the externals do not interact with each other, at least for the duration of the service.

Inter-organizational (I-E) interactions are necessary to provide services reliably: understanding the external’s needs and providing the actual service itself. Intra-organizational (I-I) interactions can be seen as organizational necessities. The service can continue as a system of interactions purely between humans as long as every piece of information reaches where it needs to be, on time.

It’s easier to understand this with an example. Claude always uses chef-kitchen examples for me, so I’m used to restaurant analogies. I-E interactions happen between servers and diners. I-I interactions need to happen between servers and chefs. When does this system of interactions break? When there is a loss in information. On a busy day, waiters cannot wait on every diner. The diners wait for their turn to relay the information to chefs. This need for information, in my opinion, led to the creation of ‘records’. Records are stored, accessible information. In this case, the record would be a dinner order card. You can imagine how order cards would make things easier on a busy day. As the service scales, there will be multiple points where records would be created. Chefs using notes to write down pending orders [too many to remember]. Noting down the names of all customers [too many to remember]. Storing all payment details [too many to remember]. Altogether, these form a system of records.

New player, new types of interactions. There are now record-external, record-internal, and record-record interactions. Examples are unnecessary. These are fundamentally different from human-human interactions. I’d like to call these record interactions ‘engagements’. Altogether, these form a system of engagements.

Records were created to prevent information loss between humans across time. Having plugged information leaks, the new bottleneck becomes the time it takes for the information to reach people, ergo, the time consumed in human-record interactions: the speed at which a diner can read the entire menu. The speed at which the chef can write down orders.

But busy restaurants with menu cards still face difficulties. How can we collapse the information relay time? Human-human interactions cannot be reduced. Record-record interactions can be made instant, in the case of digital systems. This opens up the well-known field of ‘automation’: digitalization [of records] and plumbing [collapsing record-record interactions].

Now the new bottlenecks are record-human interactions and the extent of automation. It is easy to figure out what parts of a service need to be automated.

1. Parts where records are not natively digital. The digitalization speed becomes the bottleneck. Solution → record-human interactions should be directly digital.

Receptionist noting down diner names in a book and typing them out into a computer at the end of the day.

2. Parts where record-record interactions happen through a human. In most cases, this should be downstream of the above because only digital records can interact on their own. But for some stupid reason, there is a major lack of plumbing between digital systems as well. Solution → plumbing. I call these humans ‘wires’.

Waiters conveying diner orders to chefs, instead of diner orders directly reaching the chefs.

Moving forward, we will be using the word ‘system’ only for digital systems, for the sake of relevance [although I think the abstractions apply to non-digital systems as well]. System refers to a digital entity which includes records, engagements, and future concepts.

If you have been following till now, our only remaining bottleneck is record-human interactions, happening through a user interface (UI). But there isn’t much scope for improvement there. Assuming a service is fully automated, your only bottleneck remains your understanding of user interfaces.

What actually causes people to use something? This is a very interesting thing to think about.

• Obviously, the first factor is access. Is the actor aware of the object? Is the actor allowed to use it? Does the actor have the necessary resources [mostly money, knowledge] required to use the object?
• Next is its pull. How useful is the object to the actor? Are people around them using it?
• Ease. Is it inherently pleasant to use? Does it show up when they need it? Are they habituated to it?
• Reliability. Does it achieve what they want, every time? Can it be used against them? Does it respect their dignity?
• And finally, the most important one: push. Is using the object the only way for the actor to achieve their goal? Will they be punished if they do not use it?

The first and last ones are important because they have forcible outcomes. You cannot optimize for all of the above factors [the perfect interface is your imagination]. For a particular interface, you only have to identify the weakest reasons and work on them. Unless they are forced to, no particular factor that is moderately strong can be enough to cause them to use something on their own, as we can imagine that they would most likely slip through the leaks allowed by the weaker reasons. It’s always the weaker ones causing the user not to use it. If these factors cannot be optimized for, then you simply make it the only way to do it.

Now we have a pretty solid system with every possible information delay being optimized for. How do we further collapse the distance? Predictions. Predictions require pattern recognition. Statistics, neural networks, human intuition. With all the data from the systems of record and engagement, we can analyze the underlying patterns and try to predict which information needs to be relayed before the information even exists. For example, using hourly crowd data to predict demand in a restaurant. The restaurant can be ready for busier hours with faster information networks if demand is predicted well. These analyses can be useful in improving the economics of the service as well. Altogether, we shall call this a system of predictions.

Until now, we have been thinking of digital systems as a supplement to the existing set made of internal humans. Ideally, we should have collapsed every information path between internal-internals and external-internals by now. But what if there exists an optimal combination of digital systems and humans, where information travels faster? A direct way to think about it is: human interactions are slow, digital interactions are fast → fewer humans, the better. What is the ideal combination? One where the functions that can only be carried out by humans are the only functions carried out by them. For all non-essential, administrative tasks, humans are not needed. I have mentioned ‘wires’ before, humans who carry out automatable tasks. We do away with them. This is how I envision a perfect restaurant. A restaurant with only chefs and diners.

One needs to be careful with this level of optimization. The most dangerous aspect of highly digital systems is their lack of accountability. Given that it is nearly impossible to reach this level from the bottom up, there will be mistakes and imbalances caused by these systems. There has to be somebody accountable for those. Every process should be carried out by a system, but every decision should be made by a human.

What’s next? Merely predicting outcomes is not enough. For a system to truly become autonomous, it needs to act on those predictions as well. Action requires two things: environments and agents.

Given a certain prediction, the system needs to be able to observe the current state of the environment. The restaurant is about to get crowded in the evening. We need more chefs. How many more? Do we know how many chefs are present? Do we know the entire state of the restaurant? It is possible to construct its state through records, engagements, and predictions. This is not simply a linear extension of the previous systems. When trying to construct a state, there will be new kinds of records needed. Number of chefs, inventory of ingredients, number of diners, etc. Newer records also imply newer engagements and predictions. To completely capture the state of the service, you need the states of the individual environments within it. I call this the system of states.

The second half are the agents themselves. These agents can be either human or digital. A diner who reserved a table has not shown up. Prediction goes wrong → system records the empty table state → calls up the diner [digital agent]. Food spill → identify location → send cleaning staff [human agent]. If digital agents are faster and better than human ones for a particular task, or vice versa, they should be appropriately replaced. Here, by digital agents I refer to all non-human agents, including robotic agents. Altogether, this becomes a system of agents.

Systems of records, engagements, predictions, states, and agents. Collectively, they form a system of intelligence.

What’s next? It is difficult to imagine. Feedback, probably. A system is not truly intelligent until it can recursively improve. We have also not considered the case where externals might interact; this would expand the system of engagements and add one more bottleneck. The current service has three players: externals, essential internals, and the system of intelligence. When digital systems become capable of making decisions, most essential internal humans can be replaced. If we find a way to make them accountable, all internals can be replaced. The service becomes truly digital. When truly digital services exist, they are capable of interacting with other services, creating a network of these intelligent systems. As I said, it is difficult to imagine further.