Having gone across some basic approaches, technologies and even gripes, I would like to discuss a generic architecture for AGI. Below is presented a block diagram of the major components of an AGI with an emphasis on Cloud hosting for delivery at scale.

The architecture is not there to constrain design choices, but rather to highlight best practices. Real implementations may need to make trade-offs which force deviation from this architecture.

Firstly, a modern AGI would not be a bare metal implementation. It would be virtualised, with an AGI instance spun up in a near identical fashion to a typical Virtual Machine. AGI as a Service (AGIaaS) would be the typical delivery model. Let’s look at the generic block diagram of this and discuss each area briefly. Note that this is not a comprehensive discussion, but rather a brief introduction.

We will start with the Cloud OS. The Cloud OS is something most will be familiar with if you have ever played around with Azure, AWS, Google Cloud, etc. Its role is to manage all the resources, security, etc. Even with an AGI it is still a very important layer and can serve to limit the AGI by restricting access to resources, services and capability at nearly every level.

If you have played around with hyperscale Cloud providers, you will note there is no trivial method of implementing the input streams. Providers typically have endpoints capable injesting JSON, AMQP, etc., at scale, but its quite awkward to grab simple text, video, audio, etc., streams from a browser or app. Indeed, even on the client side these things are a bit of a pain. As we move towards AGI, this should become less of an issue but for now, expect quite a few headaches.

I won’t go into great detail on this, as stream injestion is fairly well understood as are other aspects such as stream registration, authentication, transport security, etc.

The first stage that we hit is classification. An AGI does not work with raw input. Text, video, audio, etc., are broken down into an internal format which describes the input. For example, a chunk of video will be decomposed into the various elements captured in the scene. This will cover things like objects, actions, events, orientations, colours, shapes, etc. All this information is typically extracted by a bank of neural networks classifying every detail which can be extracted.

This is quite resource intensive and typically massively parallel to keep latency at the lowest levels possible. If you consider the sheer scope of everything that can be classified, you will note that this is quite an immense system in itself. In a practical implementation, it is best to begin with a minimum useful set and, in time, expand from there. In this arrangement, it will be noted that aspects the AGI would normally infer, can be offloaded to this stage.

There is also the issue of spamming the classifiers with inputs that are inappropriate. For example, if the input is a video of a chess board, any classification outside the scope of that input is a waste of resources. As such, the very first stage in classification is narrowing down which classification systems to use. This can be particularly important if 3rd party classification systems are billing on usage.

In the above diagram, this classification system is presented as being hosted alongside the AGI. However, does your AGI really need to be able to identify a particular type of plant, objects in an infra red scene? If, as in most cases, the answer is no, then it is possible to offload niche classifications to a third party. Of course, be mindful of the security implications of that. Classiciation offloading presents its own unique challenges, such as latency, but for the most part such small delays can be hidden by the AGI.

A more practical arrangement may be the co-locating of the classification system with AGIs at hyperscale datacenters, but largely maintained by 3rd parties who add and refine their classifiers.

The next stages are the AGI itself and Narrow AI. This area is split for performance reasons. Let’s say you wanted to play chess, there is no need for the AGI to be involved in this at all outside of some interaction as a player in the game. A narrow AI would actually be playing while the AGI provides an interactive narrative around that. This can be extended to quite a lot of scenarios and it should be possible for companies to add their own narrow AI as well.

This does mean that the AGI has limited knowledge of the reasoning behind the activities or behaviour of the narrow AI systems and may lack the capability to expand upon that. However, a lot of this will come down to how the AGI is trained by companies to add value to their narrow AI.

The AGI itself is a collection of algorithms which drive the Knowledge base, Memory and 3rd party systems to deliver the AGI experience. In a previouse article, we discussed the knowledge base and causality engine, so I won’t repeat that here. But let’s take a closer look at the Memory Engine.

The memory engine is a counter part to the knowledge base and causality engine. Built in a similar fashion, but much bigger, its function is to capture input streams, integrate that with information and algorithms drawn from the knowledge base and serve as a predictive cache. In addition, it serves a long term store of that state.

Input streams are continously analysed for relevent information and cross-referenced with the knowledge base to extract knowledge about the environment, people, etc., and to predict what may be required in terms of knowledge and algorithms in both a present and future sense. At some level, this is similar to branch prediction found in a CPU.

This area also holds state information of microworld simulations which are used in planning and reasoning operations.

This, again, is an immense system. If we assume that a typical hyperscale datacenter serves 50 million people, then this Memory engine will be crunching info on everything from personal information, to the classified output of video and output streams trying to deliver a real-time experience. This is certainly not your average SQL or Redis cluster.

The primary difference between the Knowledge base and Memory is that the former mainly delivers static content and the latter dynamic content. The knowledge base serves up directly accessible subsets of data, workflows, etc., for the memory and the linkage between them is the AGI.

One key difference in an AGI is programming. Programming is replaced by workflows, which are just plain language flow diagrams. As we’re dealing with an AGI, it will have the ability to interpret workflows and produce specific implementations. This permits it to be rather agnostic as to the underlying technology used to execute them and to rapidly integrate new technologies as it sees fit.

What will be of note here is that 3rd party knowledge bases and services are proxied through the AGI. While it is possible to offload this in many ways, it is a security feature as 3rd party systems will be unregulated. As an example, a 3rd party knowledge base may contain references useful in WMD production. Having the AGI proxy this content permits deep analysis of the content, implications and applications before it is passed on to the consumer. In certain scenarios, such analysis may be offloaded to systems provided by a given nation’s defense department.

Further, the use of 3rd party systems in areas ranging from PDF creation, to driving your Telsa to the office are typically subject to explicit demands by the end user or as part of pre-defined workflows. In addition, much of this may be billable. In light of this, having the AGI manage this with knowledge of the context is fairly appropriate.

Finally, we have the output streams. Again, this could be text, speech, video, data, etc., but also could include control systems for anything from smart homes, to drones. Again, at present, hyperscale cloud providers haven’t packaged this up nicely yet, but it is expect it will come.

While this has been a very brief overview of a generic hyperscale architecture, it should be easy to appreciate the scale and scope in real world delivery. By itself, an AGI clearly outstrips even the largest hyperscale data centers of today and there are a broad range of considerations which don’t apply to any other form of technology.

Delivery of AGIaaS at scale is still quite sometime off, as there are technologies to be invented, databases compiled and functional AGI engines to develop. In a time where Reddit has extreme difficultly delivering simple text and images, the move to AGI will introduce computational and delivery challenges that are unlike anything we know today.