AdofLabs®
JOIN THE MISSION
03RESEARCH DIRECTION

Should intelligence run on more than one clock?

Our serial control exposed an uncomfortable mismatch: the fastest parts of interaction need updates far more often than the most expensive parts of cognition. Speech activity can change within tens of milliseconds. Conversational state may need revision several times a second. A tool may complete seconds later. Deep planning may be unnecessary for most of that interval. Yet a conventional agent architecture tends to repeatedly route these events through the same general reasoning path.

We are investigating whether a continuously operating agent should have more than one computational clock: a cheap state process that runs continuously, slower semantic and execution processes that update when relevant events arrive, and sparse global cognition that is invoked only when local state is insufficient.

Figure 1 — Candidate timing model

FAST                  MEDIUM                    SPARSE
1–100 ms              100 ms–seconds           event triggered

perception             semantic state           deep reasoning
floor state            tool coordination        replanning
interruptions          response control         global correction
local prediction       verification

        \                  |                    /
         \                 |                   /
          └──────── VERSIONED SHARED STATE ───┘

Candidate ranges for multi-clock operation.

The interesting part is not assigning different models to different speeds. The difficult part is preserving one coherent objective while those processes operate on different versions of the world. If global reasoning begins at state version 41 and perception advances the system to version 47 before reasoning finishes, the result cannot automatically be treated as current.

One design we want to test is versioned shared state. Fast processes continuously publish small updates. Slower processes read a specific state version and return proposals rather than immediately mutating the world. Before an irreversible action is committed, the runtime checks whether the assumptions behind the proposal still hold against the latest intent and external state.

Figure 2 — Stale reasoning and commit validation

v41 ── deep reasoning starts
 │
v42 ── speech update
 │
v43 ── tool result
 │
v44 ── user correction
 │
v45
 │
 └──── reasoning result from v41 arrives
                  │
                  ▼
            validate assumptions
             /            \
         still valid      stale
            │              │
         commit          rebase/replan

The reason we are interested in recurrent or state-space style computation is not that recurrence is inherently better than attention. It is that continuous interaction creates a different economic problem. Maintaining a compact evolving state may be cheaper than repeatedly reconstructing the entire relevant past whenever a small event arrives. Global attention can then be reserved for the moments where broad context or difficult reasoning is actually required.

Tool execution makes the separation more useful. A network request does not need to occupy the conversational reasoning loop while it waits. It can become an event source. The runtime can continue listening, speaking and updating local state; the eventual tool result is incorporated when it arrives. The difficult part is deciding whether that result is still relevant to the current objective.

Figure 3 — Tool as asynchronous event, not blocking step

speech   ────────────── listening & updating ──────────────>
tool     (request sent) · · · · · · · · · (result arrives)

Sparse global cognition only works if the system can recognize when local processing is no longer enough. Candidate escalation signals include rising uncertainty, conflicting state updates, an irreversible action, verification failure, a novel task structure or a large difference between expected and observed external state. We do not yet know which of these signals are sufficient, or whether learning the escalation policy will outperform explicit rules.

The useful experiment is not “multi-clock versus single-clock accuracy.” We need to compare a strong serial control against an asynchronous runtime while holding task and model capability as constant as possible. The measurements we care about are end-of-input to useful response, compute consumed per active conversational minute, interruption recovery, stale-state rejection, successful concurrent tool execution, verified task completion and the frequency with which local processing unnecessarily escalates to global cognition.

Figure 4 — Experimental matrix

Serial controlMulti-clock candidate
Reasoningevery turnevent/escalation
Statereconstructedcontinuously updated
Toolsblockingasynchronous
Verificationterminalfeedback event
Speechdownstreamconcurrent target

There are several ways this direction can fail. Coordination may cost more than the computation it saves. Slower reasoning may become stale too frequently. Compact recurrent state may discard information that global reasoning later needs. Concurrency may improve latency while making task completion less reliable. If those effects dominate, a simpler serialized architecture may remain the better engineering tradeoff.

So the question behind “more than one clock” is not whether intelligence can be split into fast and slow modules. It is whether a system can allow cognition to progress asynchronously without losing a coherent relationship between intent, state and action. That is the part we have not validated yet.