Share the right information at the right time.

A shared place to coordinate

A specialist may produce a useful observation that other components need. A shared workspace makes selected observations, active goals, and references available across the system. Its messages can include text, structured events, tensors, or links to longer-term memory.

This is a form of working memory: information needed for the task currently in progress. It differs from retaining every past observation forever. The workspace needs rules for what gets published, replaced, read, and cleared.

The lab’s three event slots make capacity visible. The supplied observations and priorities are programmed examples; no neural policy decides what enters. The execution history is separate from these active slots, so a message can leave the workspace while evidence of its earlier publication remains inspectable.

Admission is a systems-level attention problem

The robot’s goal arrives first, followed by routine scene updates. A person appears at simulated time 35 ms. Under the lab’s FIFO rule, a full workspace rejects later arrivals, even if an incoming event is more important. Priority admission can instead evict a less urgent observation.

This attention allocation concerns which information reaches which component and when. It is distinct from the dot-product attention inside a Transformer. Both select or weight information, but a message queue does not become a Transformer attention layer merely because it prioritizes inputs.

Priorities also have tradeoffs. If high-priority events arrive continuously, lower-priority work may wait or be dropped. Real systems may need reserved capacity, expiry rules, fairness, separate channels, and explicit acknowledgement. An event’s importance does not make an overloaded communication system unlimited.

Preserving an event is not enough

With a 50 ms shared reader interval, priority admission preserves the person event and the consumer reads it at 50 ms. The resulting 15 ms delay meets this example’s deadline. With a 100 ms reader interval, the same preserved event is not handled until 100 ms. The 65 ms delay misses the requirement to respond by 85 ms.

The timing requirement is invented for teaching. The important point is to measure the full path: sensing, publication, transport or queueing, consumer scheduling, computation, and action. A high priority number cannot remove every delay along that path.

The source’s worked example describes a person crossing a robot’s path. The motion controller needs prompt access to that observation without waiting for a prose summary and another long model inference. The lab implements a direct signal read by a local loop every 10 simulated milliseconds. It responds at 40 ms, five milliseconds after the observation.

Issuing a simulated stop is not a model of physical stopping distance, sensor errors, actuator failure, or collision avoidance. Those would require additional engineering and validation. This experiment isolates communication and scheduling.

Different jobs need different timescales

Fast motion feedback, slower perception updates, deliberative planning, and periodic model training do not need to run at the same rate. A language model should not have to produce a fresh sentence for every small motor adjustment. Local controllers can execute bounded feedback loops while a higher-level controller chooses objectives, allocates resources, and handles exceptions.

The shared workspace can still carry the event to planning and memory. A direct fast path and a slower coordination path serve different responsibilities. Avoid assuming that one global communication bottleneck should mediate every interaction.

What a brain analogy can—and cannot—tell us

The source draws inspiration from interacting biological systems involved in perception, memory, movement, executive control, and learning. Engineering principles such as specialization, recurrent communication, local autonomy, and selective sharing can be useful starting points.

Naming software components after brain regions does not demonstrate biological equivalence, consciousness, or general intelligence. A software workspace is an architecture to test, not evidence that a particular theory of the brain is correct. Evaluate its behavior against simpler alternatives, resource limits, and failure cases.

Assign household-robot responsibilities

For the source exercise, place each task in a fast local loop, the shared workspace, or deliberative planning. Some tasks need more than one path.

Worked allocation with reasons

• React to an obstacle during motion: fast local feedback, plus a shared event so the planner can revise its route.
• Notice that a cup was put down: a structured observation for current state and any components that depend on its location.
• Choose a cleaning order: deliberative planning using goals, constraints, and remembered context.
• Maintain a grip: local control at a suitable feedback rate, with bounded targets supplied by higher-level planning.
• Learn a better policy from collected experience: a separate training process, followed by evaluation before replacing the operating model.

The exact rates depend on the actual system. The lesson’s 10–100 ms intervals are deliberately simple simulation parameters.