Learn

Learning preferences

Make learning more comfortable. Changes apply immediately.

Enlarges page content, including diagrams and their labels. You can also use your browser’s zoom.

Choose the colours that are easiest for you to distinguish. Applies to lesson diagrams and lab plots. Labels, shapes, hatching and line patterns also distinguish meanings. Source photographs and raw image brightness stay unchanged; mask-only views are available for image overlays.

ExampleComparisonSample link

Saved in this browser on this device. Preferences are separate from progress backups.

Lesson 3 of 4 in this unit

Build AI Systems · SOURCE LESSON 23

Share the right information at the right time.

Control a three-slot event workspace and compare shared processing with a fast local response loop.

By the end: Explain shared working state, priority gating, and multiple timescales without treating a brain analogy as an intelligence guarantee.

Start with the exampleJump to the experimentRead the explanation
Prerequisites and path options

Why learn this? Choose what collaborating components need to share so important information survives limited space and attention.

01 · TRY

Start with something concrete.

While carrying a cup, a household robot receives routine scene updates and then sees someone enter its path. A useful observation still has to reach a controller in time. Storing it somewhere is not the same as responding to it.

Try the interactive model
02 · PREDICT
Before you experiment

An urgent event has the highest priority, but its consumer reads only once every 100 ms. Does high priority alone guarantee a response within 50 ms?

An urgent event has the highest priority, but its consumer reads only once every 100 ms. Does high priority alone guarantee a response within 50 ms?
03 · EXPERIMENT

Change one thing. Watch what follows.

Loading this browser experiment…

04 · UNDERSTAND
READ & CONNECT

Understand what changed.

Back to the experiment

A shorter explanation, with the original worked examples available below. Both explain the same experiment and its limits.

Same learning goal in both modes: Explain shared working state, priority gating, and multiple timescales without treating a brain analogy as an intelligence guarantee.

The idea in everyday terms

A shared workspace holds information that several components need for the current task. Its limited capacity makes admission, priority and replacement important. Publishing every observation can bury the one that requires attention.

What to watch in the experiment

Compare local-only handling with sharing selected events. Inspect which component can read an event, when it arrives and what gets displaced. Fast local reactions and slower deliberation can need different communication paths.

What this does not establish

Sharing information is not itself learning or a guarantee of coordination. This bounded event simulation does not establish that one central workspace is best for every system.

Open the full worked examples, calculations and limitations

This is the same reference used in Technical mode. Expand it whenever you need the exact numbers, assumptions or further explanation.

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.

05 · APPLY
Check your understanding

Which responsibility should ordinarily stay in a fast local loop rather than wait for a long language-model response?

Which responsibility should ordinarily stay in a fast local loop rather than wait for a long language-model response?
06 · CONTINUE

Take this idea with you.

A shared workspace needs admission rules, priorities, and suitable consumers. Use fast local feedback where timing requires it; brain-inspired organization is an engineering analogy to test.

My Learning
Explore related topics and the topic map

How this topic connects

Explore this topic on the interactive map

Use these connections to review a foundation or choose where to go next. You can open any topic without completing the others.

What it builds on

  • Tools and observations

    Build assistants that inspect tool results and recover from failures instead of treating every returned value as trustworthy.

  • Specialist interfaces

    Prevent errors when components exchange units, coordinates or representations.

You are hereShare the right information at the right time

Control a three-slot event workspace and compare shared processing with a fast local response loop.

What it enables