Thanks for the article. This is how bots must be written, to avoid the proliferation of new useless ones (the previous failed hype wave).

This is awesome, because this is the exactly same concept that we built our platform (fredbots.com). I’ve been a game developer previously, so I created the initial Fred’s bot machine architecture as a game loop, for exactly the same reason that you pointed: “player state”. But we also carry “game state” and “game environment”.

All conversations have a permanent persistent state associated with them, which we call “attributes” in our machine. This allows for very complex and transactional bots to simpler ones.

Also attributes can be moved and updated anytime, as well new ones added dynamically at any stage (no schema constraint).

Example in a game:

  • [health: 10, enemies: [:x, :y, :z]]
  • [health: 9, pickups: [:potion], enemies: [:x, :y, :z]]
  • [health: 5, pickups: [:potion, :sword], enemies: [:x, :y, :z]]
  • [health: 6, pickups: [], enemies: [:x]]

Now transforming this to an example in our engine, considering an user assembling a pizza:

  • [current_pizza: {}, store_toppings: [:x, :y, :z], order: []]
  • [current_pizza: {toppings: [:x]}, store_toppings: [:x, :y, :z]]
  • [current_pizza: {toppings: [:x, :z]}, store_toppings: [:x, :y, :z], order: []]
  • [current_pizza: {}, store_toppings: [:x, :y, :z], order: [pizza{toppings: [:x, :z]}]]

And this data is ALWAYS accessible anywhere in any message. Attributes are added/updated via API calls (store toppings, drinks, working delivery hours, etc), user input, etc.

With a single concept, basically ANY kind of bot, for any kind of company can be assembled, because everything is state and data transit.

Autistic Savant software engineer with 25 years of development experience. By night, a game developer and artist.

Autistic Savant software engineer with 25 years of development experience. By night, a game developer and artist.