I have been catching up on some of my programming backlog, and I think I am in position to aim for a minimum viable product (MVP) version of my Python agent-based model (ABM) project. The figure above shows the visible progress made so far — which is not not at first glance an economic simulation. (In case you are wondering, the green balls are planets, and the blue box is supposed to be a spaceship flying between them. Or the balls could be island cities in an ocean at night, and the blue box is a container ship. Whatever.)
The challenge I face with this project is that every single aspect can explode in complexity, and so I can be paralysed by the need to deal with every potential quirk in the simulation. For this reason, I need to force myself to aim at a MVP, and worry about the cut corners later.
Note: The hour of doom has come for Feedburner subscriptions! If you want to receive my articles by email, please opt in to my free Substack: https://bondeconomics.substack.com/
The visible interface hides the economic simulation that is running in the background. The interface will allow the user to take control of the agents within the model. This makes the project both suitable as a teaching tool (people can see what is happening inside an economy as events happen) and as a hobby video game.
The economic simulation will be defined as follows.
Time is effectively “continuous” - the simulation advances in very small steps, mainly stopping based on events that can occur at any time. The baseline time unit is the “simulation day,” and most agents will have a cycle of events that they process during the day. Some agents might be very active decision-makers, others may only make one decision per “day.” (The client can pause the passage of simulation time.)
Simulation time will be metric — 10 days per month, and 10 months per year. Once day equals 1.0 time units, and so t=100.0 is the end of the first year.
Trade will be of various “commodity” goods (no branding of products), and transactions occur in centralised markets. (This might make post-Keynesians wince, but agents need to know what the prices of things are, and a market is the simplest mechanism to simulate. Bilateral deals would require some very impressive AI work.)
The overall economy will have multiple locations, each with a set of markets. Goods will need to be shipped between them.
Although my first models will only have a single consumer good (food), will need to extend to having a few consumer goods and capital goods, along with raw materials. We need capital goods to get a good business cycle going.
Households live within an aggregated sector, but firms have business units that are each agents within the model. The government will have a few agents to implement policy, so it is midway between an aggregate and an agent.
The household sector will have a high-level consumption function that is based on stock-flow-consistent model consumption functions, although I will need to adapt for multiple consumer goods.
Business units will be a variety of types. The first to be added will be production units that sell wares into the market. Then, we have agents that transport goods. After that, we could have agents that trade in markets, acting as market makers.
The household sector will directly buy goods from markets. (Retailers would be added later.)
Although I would like to add banks as agents, will only have (government) money as the only financial asset in the first models. As such, no interest rates.
The minimum viable product will only have a single currency, but I fear that if I ever want to consider the possibility of multiple currencies, I will need to add currency support as soon the base simulation code is working. (Starting with multiple currencies might look more sensible in terms of avoiding re-writing code, but I need to avoid making the task too difficult.)
The user can either take control of the government, or a corporation that owns multiple business units. The user then sets and adjusts high-level strategies as the simulation rolls in simulated time.
Although the framework has a structure that resembles a client-server structure, the code currently only runs within a single process. (From a gaming perspective, no multiplayer — but it designed to be easily added.)
The Main Challenge — No Prices
A major challenge I am faced with is the absence of any prices being set at the initialisation of the simulation. It is relatively easy to come up with rules for behaviour if we have price information at our finger tips. For example, if we produce something with only labour as an input cost, we can set our output price as some mark up over the unit production cost. But if we do not know what our hourly labour costs are, we do not know what our unit labour cost is.
This is not entirely surprising — the determination of the initial price level has long been a theoretical issue within economics. The solution I am starting off with is to apply Modern Monetary Theory (MMT). For a fiat currency, the government can pin down the price level by setting a key price, with labour being the natural choice. This is what the Job Guarantee does, as I describe in Section 4.3 of my latest book, Modern Monetary Theory and the Recovery. The very first model I am working on is a variant of what I refer to as The Monetary Monopoly Model. (There are few descriptions of this model, and from what I recall, they might use different names). The idea of price level determination with the Job Guarantee was independently arrived at by William Mitchell and Warren Mosler, but the mathematical model I referred to in my book was one published by Pavlina Tcherneva.
(Creating an agent-based version of the Monetary Monopoly Model is an even more minimal “minimum viable product,” but I think it is missing too many features I want to be considered my MVP. Unless I am missing something, I will have a version of that model developed within a week or two.)
The next challenge is that I tend to over-think the way in which agents interact with markets. (“They can’t follow this simple rule, they would front-run by speculators!”) The challenge with a model like this is closing the economic loop, so that we have circular flows of money and goods through the economy. I need my agents to do something, even if it is really dumb. Once I have a functioning closed loop, I will have the luxury of making the agents react more sensibly.
(This is why market makers need to be included in the minimum viable product. By providing relatively solid bid and ask prices, other agents have the luxury of being price takers.)
As an example of forcing a simple rule, my plan is to use this as the consumption rule for households.
Once per day, a daily expenditure amount is calculated for the household, using the basic consumption function from the simplest models within Godley and Lavoie’s Monetary Economics. (Right now, only a single consumer good, so need to worry about how to allocate the spending.)
Any existing “buy orders” in the market by the household sector is pulled, and the cash put into its “overflow spending” mental account. The new order is added with a price set some percentage (5%?) below the ask price (which had better exist), and the quantity determined by the total to be spent.
At intervals during the day (4 times a day?) a certain percentage of the “overflow spending” account will be used to buy goods at the market price.
The household sector has its own inventory of goods, and consumes out of them at a steady pace. For example, households might try to keep 14 days worth of consumption on hand, and eats out of that stockpile. (If the stockpile starts dropping, they might be forced on a crash diet…)
This behaviour creates the desired dynamic for markets. Households will create a relatively chunky bid below the asking price (one day’s consumption). Other agents might hit that bid during the day. Otherwise, the money left over from previous unfilled bids are used to hit the ask, so that the households do get a regular supply of food.
This is unrealistic, but the best that can be done in the absence of retailers. (We could pretend that the retailers are embedded within the household sector.) Running off the “overflow spending” in this simple fashion would be a disastrous strategy in a real market, but since no other agents are implemented to exploit this, not yet a concern.
Using the MVP
The objective is that it will be possible to run the same simulation from two different perspectives: as a policy maker, or from the perspective of a trading firm trying to make a profit. The two uses will probably require different clients (user interfaces), but the simulation code itself would be identical. All that happens is that a human has taken over decision-making that would be done by an algorithm.
This is useful from a teaching and entertainment perspective. From a theoretical perspective, I have some very limited aims.
Build models that demonstrate business cycles and preferably Minsky’s Financial Instability Hypothesis. Academics have done things like this, but I want a code base that I can tune for my own purposes.
Look at the microfoundations of stock-flow consistent (SFC) models. Does an agent-based model behave like a SFC model?
Recession forecasting theory. Can we forecast recessions in agent-based models solely armed with aggregate data?
I am not too interested in trying to build a forecasting model with them, although I might take a look. I have seen a few people linking this paper by Poledna, Miess, and Hommes , but I have not had a chance to read it yet: https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3484768
I have done a burst of programming, but I am likely going to be reverting to working on my inflation primer shortly. I will be rotating through my various projects over the coming months, which is my preferred strategy. Unless something else interrupts me, getting to the MVP version of the agent-based project should be feasible by about September (at which point, I will probably start to do the final push on my inflation primer).