The "Blank Slate" Problem For Agent-Based Models

I have taken a stab at building up an agent-based simulator over the holidays. The state of progress would look rather unimpressive, but that is about what I expected. The difficulty with building a complex software package is that it needs to be set up in a way that it can be continuously tested. Unfortunately, the structure used requires a fair amount of software plumbing to be put in place. Once the framework is set up, we then run into the steepest problem: it is very hard to define behaviour for agents without other agents already in the model (the economy is a "blank slate"). Once we have minimal set of agents, it will be a lot easier to develop new behaviour, as the new agents will have an existing set of relative prices to work with.

Client-Server: Why?

(The code is available on GitHub: https://github.com/brianr747/Simple4Xpygame/tree/economic_engine It is still embedded as a branch in another project. Since I do not have a huge amount of time to devote to this project, I am not going to break it out into a new one.)

The decision to use a client-server architecture generates a fair amount of programming overhead. The system simulation is divided into two distinct components.

• The server keeps tracks of the "laws of physics" for the simulation: the inventory of each agent, the state of buy/sell orders on the market, and production functions.
• The clients communicate with the server, and handle all decision-making. The decisions will include sending orders to the markets, and undertaking production decisions. 

Since the simulator all runs within a single process, the client-server design presumably looks somewhat loopy. However, testing in a multi-process environment is a pain, so I will not add in network communications until later. Building the framework to cleanly handle both networked and non-networked modes was the biggest challenge I dealt with in the design so far.

The key advantage of the client-server architecture is flexibility. Each client (an agent) can be designed completely independently from other agents as well as the server. All that is required is that it interacts with other agents using the rules set by the server. Another advantage of the client-server design is that it would be possible for others to build components in other computer languages if so desired.

No Mathematical Model!

One of the side effects of the design is that we do not really have a mathematical model of the simulation (other than observing that it is implemented on a digital computer). The clients and server communicate via text messages that require parsing, and each will have to build out its own internal representation of the model.

From the server's perspective, the system state is just the physical inventories of the agents, their cash balances, and the existing set of orders on exchanges. It will also track some transaction history, so that agents can use that information in their decision making.

However, that state information tells us very little about the behaviour of the simulation. We need to augment it with the state of the client decision-making processes. The server will know nothing about that information.

This could distress some of an academic bent. There is no mathematical model to work with, and no way to prove anything about behaviour. If you wanted to develop a mathematical model of the simulation, you would actually need to abstract away the simulation details and come up with a reduced form version of the simulation behaviour -- just like simulating real-world economies.

This is intentional. If we force the state information to take a certain form, we are effectively forcing the agents to follow certain rules of behaviour. This limits the flexibility of the simulation, and we do not know whether any behavioural patterns are the result of the simplifying assumptions, or agent behaviour. As a classic example, take the "equilibrium" assumption of mainstream economics. That assumption has locked mainstream models into a theoretical dead end, and makes it extremely difficult to relate economic models to actual behaviour.

State of the Simulator

The client-server architecture does not do a lot at present; it covers the transmission of the system time as well as the bulk of exchange order processing.

Although transmitting the simulation time sounds laughably easy to do, there are hidden difficulties. The simulator is expected to run in real-time mode, with clock time corresponding to simulation time (with an acceleration factor). The clients may be running on different machines than the server. Meanwhile, there are events that will be associated with particular simulation times, such as the end of a production process. Therefore, the handling of time is trickier than it would be in a straight mathematical model.

The exchange order handling is largely done; I just want to add a feature that prevents agents from trying to sell more of a commodity than they have in inventory. (Buying too much is less of an issue; I think it should be possible to have an automated reaction by the exchange for dealing with over-levered agents.)

The main remaining server components are the production functions as well as shipping commodities between exchanges. These should be actually very straightforward to implement. The production functions will be a set of possible operations to produce commodities using commodity inputs (as discussed further below).

After that, almost all work would be on client behaviour.

The Blank Slate Problem

When the simulation starts up, there are no orders on the exchanges. An agent might to make decisions in the complete absence of any external pricing information. How is supposed to do that?

This is exactly the same problem that bedevils mainstream macroeconomic models. It is possible to pin down the relative price between wages and the one (composite) commodity, but there is nothing to pin down the initial price level.

One possible approach is to "seed" initial price information by making design decisions. It is extremely likely that this will result in wildly different outcomes depending on the initial seed values. However, we would have to force certain agents to insert bids and offers into the exchange at initialisation. Those agents might immediately withdraw those orders, leaving the simulation without any market prices once again.

Another approach is to be neo-Chartalist, and have the government set at least some initial prices by making bids at arbitrary prices. The government is able and willing to leave those bids in place, and so provides an initial pool of pricing information that private agents can use for decision-making.

(The labour market will be aggregated, and wages will be sticky. Once it is implemented, the labour market might do a very good job of pinning down an initial price level.)

Capital is a Commodity

Everything in the simulation is a commodity, and traded on markets -- including capital. (This might make Sraffians happy.) The objective is to eliminate non-arms length transactions between agents (firms). (The labour and retail markets would be added later, and act in an aggregated fashion, and outside the exchange system.) 

As a side effect, capital is permanent; it is assumed to be maintained to be "good as new" at all times. (It would be possible to de-construct capital goods to provide raw materials if there is a glut of capital; this would be another option in the menu of production function choices.)

Otherwise, we would need to set prices for used capital goods (that have a limited life span). The question is why any firm would offer a non-negligible price for such goods. The main reason an agent would try selling capital goods is that they are facing liquidity constraints; why bail them out with a reasonable bid for what they are selling?

Who Needs Land, Anyway?

One of the complaints raised by some heterodox economists is that standard models ignore land; they want land, capital, and labour as being the base factors of production.

The simulation side-steps the issue by having the backstory of being set in space. In space, land is not a factor of production.

The Financial System

The decision to make everything exchange-based makes the financial system a lot easier to handle. We just assume that the exchanges are government-backed, and that agents are allowed to incur margin debt based on the market value of their inventories. The "money" in the system is the agent's cash balance at the exchange, which would normally be expected to be negative (borrowing against inventory, including capital).

Adding a banking system poses a great many issues. Banking is a non-arm's length business, and it is unclear how to set it up. One possible system is a keiretsu (or chaebol) where banks are embedded within a grouping of industrial firms. Firms would be expected to deal with their captive bank, and the bank would also interact with the aggregated household sector following simple rules.

The architecture of the system allows multiple currencies, but that is unlikely to be implemented for some time.

Concluding Remarks

After the holidays, I will probably get back to working on a report on inflation-linked bonds. However, I hope to have put together the core server systems of the agent-based simulator, so that I can start puttering around with agent behaviour when I am bored.

(c) Brian Romanchuk 2017