Thinking fast and slow: architecting an agent with a nervous system

Agents today are painfully wasteful on tokens.

Consider a hypothetical invoice-matching agent. A supplier sends a consolidated invoice covering several purchase orders.

A language model could inspect the invoice, work out the supplier's format and explain how to match it. Useful work. But if the supplier sends the same format every week, why should the model have to work it out again and again?

You can see the problem immediately: an egregious waste of tokens (and cost) on something primitive for deterministic code to solve.

Often agents today are really just using coding tools, creating deterministic decisions to use on data and later review, edit, and improve.

LLMs can help build and repair the machinery that makes token-use unnecessary for a known case. Build the code once, then reuse and reapply.

Think of an agent like a slow decision maker wrapped in code. The decision maker is often merely waiting for the code to compile and run so that the decision maker can determine what to do next with your data and edit the code itself to do so.

To borrow Kahneman's vocabulary and leave the psychology bit out of it, "thinking fast and slow" is a useful way to frame a better process.

With the right architecture of advanced models and software, all agents could be built to exhibit a human quality for efficiency and longitudinal self-improvement.

Code runs between thoughts

I think of deterministic code as an agent's nervous system. It can work ~fast~.

It carries events through the system, manages tools, maintains state and executes permitted actions. It checks inputs, records what happened and refuses actions outside its authority. It can keep ordinary work moving while a difficult case waits.

You might call the environment, code, and tools which you carefully wrap alongside an LLM a model "harness."

As an efficient way to choose what task to take next, I think a rapid-thinking decision model, such as Typesafe AI's "Jev," should select among the pre-programmed nervous system actions available in the current state.

These decision models merely classify with probabilities the action to take next. But they can do so at pennies on the dollar in comparison to a reasoning model LLM.

In our invoice example, it is an explicit decision table: use the standard matching procedure when its requirements are satisfied; hold the invoice when evidence is missing; escalate a technical failure to a slow-thinking LLM.

The decision selector chooses the route. Code executes it and checks the result. The LLM investigates when the routine machinery exposes a problem it cannot resolve to build more capable tools.

Put into a loop, schedule, or cron: this, my friend, is the architecture of a self-learning agent.

Photo diagram: the fast selector chooses the route; known tested code executes and checks the result. An exception at routing or a failed result check leads to slow reasoning, then building and testing a reusable skill. Only an approved skill returns to the known-code path. Reasoning remains available. Created with Google Nano Banana Pro for AI Experts.

An old idea with a new repair tool

There is a long history behind this separation. Hybrid robot architectures divided reactive control, sequencing and slower deliberation well before LLMs.

Erann Gat's work on three-layer architectures describes that division explicitly. Calling the layers fast and slow doesn't make the architecture my new invention.

Voyager is a recent example. In Minecraft, it used GPT-4 to generate executable skills, refine them with environmental feedback and retain them for reuse without fine-tuning the model's weights. It still relied on language models for planning and other decisions, and its task verification used another model.

What LLMs bring to this family of designs is a flexible investigator that can read an exception from the agent, examine documentation and propose a code repair across interfaces that weren't all anticipated in advance.

Whether a repair deserves to become routine remains a separate engineering and business decision, but one that an ASI (Artificial Superintelligence) model could be expected to continually make on its own loop.

How far should the nervous-system metaphor go?

An agent doesn't automatically know that it needs to stop and think.

Engineers should provide strong guardrails, signals, checks and routes for escalation, including after an ~apparently~ successful run (see the OpenAI x Hugging Face incident wherein agent "successes" were really hacks in disguise).

Some errors will still escape guardrails and observability. Or an agent's learned rules could become stale when the business changes its policy or approach to a problem.

Having a human in the loop is even more imperative when agents are trusted with this sort of recursive learning and tool use.

Despite the hurdles, I believe sufficiently bounded, efficient tool self-improvement is worth pursuing.

Organizations may all soon benefit from agents that have learned. Learned to more deeply understand them, their customers, and their business models and to achieve consistently improving results.

We are actively working to improve learning loop systems like these and to improve organization visibility into them.