Academy

Three lessons the human mind offers agent architecture

Several hard problems in agent design rhyme with how the human mind works: focus over clutter, knowing when a job is done, and separating the layers of memory. The resemblances are a good guide for design.

The Felesh team 5 min

Some hard problems in agent design bear a striking resemblance to human cognition. This resemblance does not necessarily mean these solutions were drawn from neuroscience; rather, it shows that good engineering often arrives at the same patterns the human mind reached long ago. Let’s look at three of them.

Focus, not clutter

The human mind does not hold all of the day’s concerns in working memory at once; at any moment, it focuses only on what is relevant to the task at hand. Agents require the same discipline. When an agent has access to everything, processing costs increase, and — more importantly — irrelevant context causes the model to hallucinate and err.

Everything in context versus only the slice the intent needsA customer asks where order 7203 is. On the left the model is handed all six items in context, including a stale 2023 returns policy, and replies that returns are open 30 days, which answers a question nobody asked. On the right the intent is read as order status, only the order 7203 record and the task list are passed, and the reply says the parcel arrives Thursday.14 messagesprice listprofileorder 72032023 returnstask listorder 7203task list14 messagesprofileprice list2023 returnsall of it, every callonly the slice the intent needs“Where is my order 7203?”intent: order statusreply: returns open 30 daysreply: arrives Thursday
A component sees only what the user's intent needs, so a stale 2023 policy never reaches the reply.

The solution is to scope context to the user’s intent. First, detect what the user wants, then give each component only the slice of information needed for that intent. A component whose job is distributing tasks does not need the conversation history; it only needs the task list. This is, in effect, the principle of “least privilege” applied to knowledge: each component receives only what its job requires. The result is an agentic system that is both cheaper and more accurate.

Which context each component receivesA grid of three components against five context items: history, task list, profile, order record, policy. The dispatcher receives only the task list. The order lookup receives the task list and the order record. The reply writer receives history, profile and the order record. Nobody receives the policy, and nobody receives all five.givenwithheldhistorytask listprofileorderpolicydispatcherhands out tasksorder lookupfinds the parcelreply writerwords the answerthe dispatcher gets the task list, nothing else
Each component is handed the slice its job needs: the dispatcher gets the task list and nothing else.

Knowing when the job is done

A person usually has a clear sense of whether they have finished a task — a simple self-awareness of where the work stands. A capable agentic system needs the same: a component whose sole responsibility is to evaluate if the work is actually complete.

The subtle point is that this judgement does not require the intelligence of a language model. “Are all the tasks done?” is a matter of arithmetic, not reasoning; you simply count the completed tasks. Handing this to a language model is expensive and needlessly fragile. It is better for this completion monitor to be deterministic and predictable. Separating the responsibility of detecting the end of the work into an independent, deterministic component makes the system both simpler and more robust.

A completion monitor counts done tasksA task list for the order 7203 question has four tasks: look up the order, read the carrier scan, draft the reply, send the reply. As each is ticked, a completion monitor counts from 0 of 4 to 4 of 4 and fills a four-segment bar. When the done count equals the list length, the job is done, with no model call. Asking a language model the same question is shown as the costly, fragile alternative.look up order 7203read carrier scandraft the replysend the replycompletion monitor0 of 41 of 42 of 43 of 44 of 4rule: done countequals list length4 of 4: job is doneor ask a model instead:costly, fragile
Finishing is a count of done tasks against the list, so a plain program can decide it without asking a model.

Separating the layers of memory

A human does not have one monolithic memory. They have several, with different lifespans and functions: what is in mind right now is not the same as what is recalled from years ago. Agents benefit from the same separation.

In agent design, you must separate at least two kinds of memory. First is coordination memory: temporary data that only makes sense during a single request — the answer to “how are we working together right now?” This data is transient and is cleared when the work ends. What is cleared, however, is only the request-local working context — the live scratchpad of how components are cooperating in that moment — not the record of what happened and why; that account of the reasoning is kept in durable memory. Second is domain memory: what we know about the user and the conversation, which must persist over time. This separation carries a significant advantage: even if an error occurs midway through a task, domain memory is untouched and accumulated knowledge is not lost. Set the lifespan of each piece of data by its role, not with a single rule for everything.

Three memories with three lifespansOne request runs left to right through three memory lanes. In the coordination lane, two scratch entries appear, step 1 lookup and step 2 carrier. An error strikes midway and its line stops at the border of the domain lane, which holds prefers SMS and order 7203 and stays untouched. The reasoning lane records why the carrier scan was used. When the request ends, the scratch entries are cleared; the reasoning stays on record.request endscoordinationthis request onlyreasoningdurable recorddomainuser, over time1: lookup2: carriererrorcleared when the request endsscan: left the depotkeptprefers SMSorder 7203untouched
The scratchpad of one request is cleared when it ends and a mid-task error never reaches domain memory, while the reasoning stays on record.

The resemblances aren’t accidental

These three patterns — context focus, the completion monitor, and multi-layer memory — are engineering answers to specific problems. But their resemblance to familiar patterns of human cognition is not accidental. When you are dealing with limited attention, the probability of error, and the need for durability, good solutions converge. The human mind is not a bad roadmap for designing agents.