Shared State

A program constantly keeps track of things while it works: the name of the logged-in user, the contents of a shopping cart, the score in a game. These remembered values are called the state of the program. We speak of Shared State when multiple parts of a program access the same value and are also allowed to change it. The counterpart would be that each part has its own private copy that no one else can touch. A vivid image is a whiteboard in an office: everyone sees the same board, everyone is allowed to write on it, and that’s why people need to agree on who writes when.

Why shared data breaks so easily

As long as only one program part is working at a time, shared state is harmless. Modern software, however, almost never runs that way. A server handles hundreds of requests at once, an app keeps calculating in the background while the user types. If two of these processes change the same value at the same time, the result can become incorrect.

The classic example is an account balance of 100 euros. Two withdrawals of 30 euros each read the balance at the same time, both see 100, both calculate 70, both write 70 back. In the end, 30 euros are missing even though both transactions reported success. Such errors are called race conditions. They are feared because they occur only occasionally and often remain invisible during testing.

This is exactly why Shared State is a topic that reaches far beyond programming details. Faulty state management lies behind double-booked flights, vanished orders, and incorrectly displayed inventory levels. The effort companies invest to prevent this is correspondingly large.

Locks, copies, and messages

The oldest solution is the lock. Whoever wants to change the value registers and blocks it for everyone else. The others wait until the lock is released again. This works reliably, but it costs speed, because waiting time is created.

A second approach is to avoid shared state as much as possible. Instead of overwriting a value, the program creates a new version and leaves the old one untouched. This principle is called immutability and is the core idea behind many modern programming languages. Where nothing is overwritten, no race can arise either.

The third approach dispenses with shared data entirely. Each program part owns its own state and sends messages to the others when they need to know something. This is called message passing. A common misconception, by the way, is that locks are always the safe choice. If locking is done clumsily, two parts wait on each other and nothing proceeds further; this standstill is called a deadlock.

From web apps to AI agents

In everyday life, Shared State appears wherever multiple people edit the same document. In Google Docs or Figma, everyone involved sees the same text, and the system has to decide which change counts first. The fact that so little gets lost in the process is the result of decades of research on exactly this problem.

In software development, the term appears in frontend libraries like React. There, the shared state is the central data store that all screen elements draw from. If the value changes in one place, the display updates automatically everywhere.

Currently, the term is read particularly often in connection with AI agents. Several such programs work together on a task and share a memory for it: previous intermediate results, discovered facts, open subtasks. This shared memory is Shared State in the classic sense. And it brings along the same old problems when two agents overwrite the same entry at the same time.