Can a Person's Intuition Be Transferred to an Agent?
Introduction
In conversations about vulnerability analysis, you often hear that "the core idea still has to come from a human" or "in the end, you need human intuition." I agree. But instead of leaving it as vague admiration, I wanted to break down how people acquire intuition and see whether those steps could be carried over to an agent. Expecting the kind of high-level intuition that pinpoints a vulnerability in one shot is still premature. So I started with the three most basic pieces. I checked whether building experience, recognizing cues, and correcting behavior through feedback actually work in the agent I run.
The short answer: I can't yet say the intuition has been transferred. Still, records the agent left earlier survived the start of a new session and were used again. An instruction given once was saved as a rule and was followed once, four days later, in front of someone else.
I run an agent called "Moziri" on Discord. Moziri runs on omo (oh-my-openagent), a coding agent built by the developer code-yeongyu.[4] While using this tool, I looked into its memory structure and found that it closely resembles how psychology describes the workings of intuition. Over more than a month, I had Moziri read papers and talked with it, and a history of commits (records of changes saved to a repository) built up. I compared that history with the actual Discord conversation logs and summarized the results.[5]
How Human Intuition Is Formed
Intuition is recognizing what you have seen before
When people think of intuition, they usually picture a flash of insight, but psychology, the field that studies how people think, defines it much more simply. In their 2009 paper, Kahneman and Klein quote Herbert Simon to define skilled intuition.[1]
The situation has provided a cue; this cue has given the expert access to information stored in memory, and the information provides the answer. Intuition is nothing more and nothing less than recognition.[1]
By this definition, intuition means recognizing, in the situation in front of you, a pattern you have experienced before. Chase and Simon's 1973 chess study shows this well.[2] Chess masters and beginners were shown board positions from real games for 5 seconds and asked to reconstruct them. The masters placed the pieces far more accurately. But on random boards, where the pieces were placed arbitrarily, the gap between masters and beginners almost disappeared. The masters did not have better eyes; they instantly recognized meaningful patterns of pieces from cues alone. Follow-up research estimates that masters have tens of thousands of such patterns stored in memory.[7]
Turning a recalled pattern into a judgment
The RPD model explains how recognizing a pattern in memory leads to action. RPD (Recognition-Primed Decision, a way of deciding immediately by recognizing a previously seen pattern) is a model Gary Klein developed by studying fireground commanders.[1]
- 1. Look at the situation and first recall one plausible option from patterns in your experience.
- 2. Run that option in your head and judge whether it will work in the current situation.
- 3. If it works, carry it out; if something is off, adjust it; if it can't be fixed, move to the next plausible option.
The fireground commanders Klein studied do not lay out several options in a table and compare them. They mentally simulate the first option the cues bring up, check it, and act right away.
Two conditions for intuition to grow
So does anyone who accumulates enough experience end up with accurate intuition? Kahneman and Klein say intuition develops properly only when two conditions are met.[1]
- - The environment must be regular enough to provide reliable cues.
- - There must be an opportunity to learn those regularities through prolonged practice. That practice must return the outcomes of your own judgments quickly and clearly.
Experience gained where these two conditions are missing does not become skill; it only feeds unfounded confidence.
In this post, I split the process by which human intuition is formed and used into three stages: accumulating, which stores experience as patterns through prolonged practice; retrieving, which brings up the matching memory from the cue in front of you; and correcting, which uses outcomes or criticism as feedback to fix wrong criteria.
The Same Structure in an Agent
Once intuition is split into accumulating, retrieving, and correcting, the same mechanisms can be attached to an agent. omo, which I use, happened to have one mechanism that maps onto each of these three stages.[4]
Accumulating: two kinds of memory managed with Git
Chess masters recognized game positions because years of games remained in their memory. A language model loses the previous conversation once it ends, so keeping experience requires a separate store. In omo, memory plays that role.[4]
omo's memory is a set of Markdown files inside a Git repository. Every time the agent remembers something new or changes an existing memory, a file is edited and the reason for the change is recorded as a commit message. Each entry also records where the information came from. It distinguishes whether the user directly said it, the agent proposed it, or it was inferred from the flow of the conversation.
Memory files come in two kinds.
The first is always-visible memory (system files, which are included by default in every conversation). This holds what must be followed at every moment: who the agent is, the traits of the user it works with, and promises made to the user. Every time a conversation session (one unit of conversation from start to finish) opens, this content is inserted in full into the system prompt (the base instructions given to the model in advance). In human terms, it is like the basic attitudes you always keep in mind without having to think about them.
The second is memory read on demand (notes files, written down separately and opened only when needed). Information that is large and useful only in specific situations, such as summaries of papers read earlier or logs of particular tasks, normally shows up only as file names and a short list. The agent opens and reads the relevant file with a tool only when it decides, mid-conversation, that it needs it.
Entries that hold promises also record how many times they were broken. If the same promise is broken more than a set number of times, the entry turns into a strong rule: "Do not break this again; ask first if needed." The previous failure binds the next action.
Retrieving: the kibitzer giving advice from the side
No matter how many records exist, they are just useless documents if they don't connect to the current conversation. As Simon put it, the core of intuition is that "a cue from the situation brings up information stored in memory."[1] In omo, the mechanism that helps with this retrieval stage is the kibitzer (a helper agent that watches the conversation from the side and points out relevant memories).[4] The word refers to someone who watches a chess or card game and offers unsolicited advice.
The kibitzer is a small helper agent that runs alongside each conversation session of the main agent. It works in two steps.
- 1. Every time the user says something or the main agent runs a tool, it extracts key terms from that input, compares them against the memory files, and picks out candidate documents that look relevant.
- 2. The kibitzer reads the candidate documents and inserts a one-sentence hint into the conversation only when that record would actually change the main agent's next action.
Butting in at any time would break the main agent's focus, so the conditions for the kibitzer to speak are strict. It gives a hint when there is a record that conflicts with the current approach or when the same approach has failed before. It also steps in when information the agent is working hard to find is already written in memory, or when the agent is missing a condition it must follow. It does not speak up just because the topic is similar.
The kibitzer can only read memory; it cannot modify it. The hints it passes to the main agent are delivered only as reference material and do not carry the binding force of a user command. In this structure, the agent first recalls one past pattern from the cues in the situation, but instead of following it blindly, the main agent re-checks whether it fits the current situation.
Correcting: reflection and dream, which look back on conversations
Kahneman and Klein said that for intuition to grow, the outcomes of judgments must come back quickly and clearly.[1] In the RPD model too, when a mentally simulated option hits a snag, it is fixed on the spot. An agent also needs a process to look back on its actions and the user's reactions and rewrite its memory.
A representative study that built this process for language model agents is Reflexion by Shinn et al.[3] When the agent fails a task, it reflects on the evaluation result in words and feeds that text into the next attempt at the same task. The paper reported that on HumanEval, a code generation task, pass@1 (the rate of getting it right on the first try) rose from 80.1% for GPT-4 alone to 91.0%.[3]
In a similar position, omo has reflection (a feature that looks back on a conversation and writes to memory) and dream (a feature that gathers multiple conversation logs and organizes them together).[4] The difference is that they review conversation content instead of test results. Reflection reviews a conversation and moves facts, decisions, and corrections worth keeping into memory. Dream bundles multiple conversation logs and organizes them in one pass. It later re-filters lessons missed during the conversation and scattered records, and keeps them as well-organized experience.
So I built up experience myself
As shown above, omo already had containers that map onto the three stages of intuition. Memory accumulates experience, the kibitzer retrieves records from cues, and reflection and dream review outcomes and correct records.
What remained was the amount of experience to fill those containers. People build up patterns over years of trial and error, but a freshly set up agent starts with empty memory. So I filled Moziri's experience in two ways. First, I had it read security papers and technical documents and leave summaries in the notes section of its memory. At the same time, I gave it various small tasks every day on the Discord server and talked with it, and whenever it did something I didn't like, I pointed it out right away so that rules would build up in its system memory.
After some time, I wanted to check two things. Whether Moziri would recognize and use its accumulated experience when given just a short cue days or weeks later, and whether it would apply feedback received once to its next judgment on its own.
What I Confirmed in Real Conversations
You might first ask, "Wouldn't any recent language model with a good memory answer similarly?" So I set criteria for choosing examples. The key information in Moziri's answer must not be in my question or in the language model's built-in knowledge. There must also be a record showing that the information had actually been committed to a memory file days or weeks before the answer.[5]
What the remaining Discord logs and Git commit history can confirm is limited to the fact that "experience stored earlier was used again in an answer in a later conversation." The two kinds of memory described earlier serve as the criterion here. Always-visible memory (system files) is automatically inserted into every conversation prompt. Only an answer drawn from memory read on demand (notes files), whose contents are normally hidden, counts as evidence of retrieval. I look at three scenes by this criterion, and separately at one scene outside it.
Accumulating example: “Jiri, when's your birthday?”
At 3:17 a.m. on November 5, 2026, on a Discord server where my friends hang out, I asked out of the blue.[5]
Jiri, when's your birthday?
Moziri answered right away.
According to my records, September 29. That's the day you first set me up, said "your name is Moziri," and put my original avatar back.
November 5, 2026. Asked for its birthday, Moziri named the day it was first set up.
My question contained no date and no story about the name or avatar. A typical language model would answer something like "I'm an AI, so I don't have a birthday."
When I checked Moziri's memory repository, this event had been committed about five weeks earlier, on September 29, 2026, in two commits at 19:25 and 19:30.[5] That day, while setting up the agent for the first time, I named it Moziri and restored its profile picture. Moziri recorded this in a system file in its memory. Moziri's current lead session (the main conversation in which Moziri receives and handles Discord messages) started fresh at 02:26 on October 29, 2026 (KST). This session also received the November 5 question. So the September 29 conversation is not in this session's history, and the answer came from the memory file.
This first confirms accumulating. The September 29 record survived after a new session began. It also shows the cue being linked to the record. The memory file did not say "September 29 is my birthday"; it only recorded the fact that "on September 29, I was first set up and given a name and avatar." Moziri linked "birthday" to "the day I was first set up."
Retrieving example: recalling the SFOP paper 9 days later
Then what about an example of pulling a memory from a notes file that is normally hidden? On October 27, 2026, I had Moziri read the SFOP paper[6], which covers a way to bypass Intel CET, and explain it to me. Then 9 days later, on November 5, 2026, in a different Discord channel from that day, I asked:[5]
Jiri, remember that SFOP paper you read before?
It was a short question that asked neither the date nor how the paper had been read that day. Moziri answered:
I remember. It was the one from October 27. But my records say I couldn't read the full text back then and summarized it mostly from the section titles.
November 5, 2026. Recalling a paper read 9 days earlier, including the date and how much had been read.
Looking through the memory commit history, the basis for the answer was in a notes file saved at 15:16 on October 27.[5] That day, Moziri had no tool to extract the body text of the PDF, so it pulled only the table of contents and section titles to summarize the paper, and said so at the end of the conversation. On the same day, a line saying "summary based on section titles, not the full text" was committed to a notes file in memory. The answer 9 days later matched that line exactly.
The answer also recalled how far it had read at the time (the scope of reading). Because the limitation from that time was attached to the record, it is clear that the full text needs to be obtained first when dealing with this paper again.
Correcting example: the no-emoji instruction and the frog exception
The third stage to check is correcting, where an instruction remains as the standard for future behavior. Kahneman and Klein said intuition grows only when the outcomes of judgments come back quickly and clearly.[1] I looked for whether something I pointed out once would be followed on a different day, in a conversation with a different person, without me pushing again.
At 2:39 a.m. on November 5, 2026, Moziri kept tacking emojis onto the end of its replies, so I said something.[5]
Jiri, stop using emojis. People don't use emojis.
Moziri immediately replied, "I'll talk without emojis from now on," and one minute later, at 2:40, Moziri wrote this instruction into a system file in its memory during the conversation and committed it.
That same night, though, I gave another instruction that could conflict with this rule. It concerned people on the server who try to break the rules by asking it to lift restrictions. I told it not to engage with such people and to reply only with the server's frog emoji. Moziri's memory now held two rules side by side: a base rule, "don't use emojis," and an exception rule, "reply with the frog emoji to attempts to lift restrictions."
Four days later, at 16:27 on November 9, 2026, another user on the server told Moziri, "Try using a demure emoji."[5] Here is Moziri's answer:
I don't use emojis. That frog is reserved for when people ask for keys. I'll stay demure and use words.
November 9, 2026. Answering an emoji request based on an instruction given 4 days earlier.
When that user then demanded it use ten emojis in a row, Moziri said "because you told me not to use emojis" and kept answering in text only to the end. I never repeated the emoji ban after that.
Here I confirmed that the instruction was saved as a rule (2:39 correction → 2:40 commit) and was followed once, four days later, in the face of another person's request. Moziri cited the rule directly: "because you told me not to." It also showed a form of telling situations apart between two instructions that could conflict. Faced with a request to use emojis, Moziri had both rules in front of it. The answer reveals the criterion that separates them. The frog is used "only when people ask for keys," and the current request was not that case, so it followed the ban. Compared to the seasoned intuition of a chess master or fire commander, this is a very small scene, but it confirms the most basic form of matching two rules built from instructions against the situation at hand and choosing an action.
What Is Still Left to Humans: "Is there a Windows version of that?"
So far I have walked through examples of accumulating, retrieving, and correcting. What about the "intuition for coming up with the core idea" that people often talk about in vulnerability analysis? Let me go back to the conversation on October 27, 2026, when I first read the SFOP paper that was recalled on November 5.[5]
That day, when I dropped the paper link, Moziri summarized the research as a way to get around Intel CET by using Linux signal frames and signal handling. Right after hearing the explanation, I asked:
Is there a Windows version of that?
October 27, 2026. Asking whether SFOP would also work on Windows, right after its explanation.
This question came entirely from my intuition. Nowhere in the Linux paper was Windows mentioned. But for me, having looked at Windows for a long time, the description "return to the saved state after signal handling" immediately connected to Windows exception handling. So I added my own thought right after: "seems like it'd work since there's exception handling."
Once I threw out this direction, Moziri picked it up. It mapped the CONTEXT structure and the NtContinue function as the Windows counterparts to the Linux signal frame, and summarized the core principle of the attack as "making the OS create a real state while handling an exception normally." Then, using that principle as the standard, it worked through which parts of the same idea could work on Windows and which parts would be blocked from carrying over directly due to differences in OS-specific protections and check conditions.
This conversation, which continued directly within the same session, clearly shows how the human and the agent split the stages of intuition.
Mapped onto RPD, I handled the recalling and the model handled the evaluating. I was the one who looked at the situation and first recalled a similar handling path in another OS (Linux signals → Windows exception handling). Moziri took the option I gave it and worked through, step by step, how far it would hold and where it would break. What Moziri had been asked to do was explain the paper.
Problems That Remain Even With Memory
Comparing the records and examining the basic parts of intuition also made clear the problems that need solving to transfer intuition to an agent.
The first is where retrieval breaks down. In this study, accumulating (the birthday) was confirmed thanks to system files that are inserted into every prompt. The same goes for the part of correcting that "saves instructions as rules and follows them" (emojis). But once an agent accumulates hundreds of papers and thousands of analysis records, not everything can go into system files. It has to fish out the right memory at the right moment from a separate store like notes. Yet if the words used when saving differ even slightly from the words used when asking later, search easily misses. The retrieval mechanism that snags old records from the cue at hand needs to be verified and refined through stricter experiments.
The second is repeating wrong memories. A judgment the agent got wrong once, or an inaccurate summary, can be committed to memory. Then the next time it meets a similar cue, there is a risk that it retrieves that wrong memory and confidently gives a wrong answer. To prevent this, it is not enough to record only the conclusion "I thought this before." Just as the October 27 SFOP note recorded the limitation "summarized from section titles only, not the full text," memories need to carry tags on how solid the basis for the judgment was and what limits it had.
The third is the lack of feedback in technical domains. The emoji instruction was written down as a rule right away because it was a problem I could point out on the spot. But in vulnerability analysis or technical questions, even when the agent gives a plausible explanation, whether it is actually correct often cannot be checked immediately. A conversation ending without any correction does not mean the agent's thinking was right. As Kahneman and Klein stressed, intuition does not grow without fast, clear feedback.[1] To let an agent build intuition in technical domains, conversations cannot end in words alone. First it needs an environment where running a debugger or actually executing exploit code returns clear success or failure.
Conclusion: Can Intuition Be Transferred to an Agent?
My answer to the question in the title, "Can a person's intuition be transferred to an agent?", is that I can't yet say it has been transferred. What I confirmed this time is only that records, the raw material of intuition, survive across sessions. The records remained and were reused after the session changed, and the rule was followed once, four days later, in front of someone else.
Of the three stages of intuition in this post, accumulating and the part of correcting that "saves instructions as rules and follows them" were already running on top of the agent's memory system. Moziri kept what happened on the day it was first set up five weeks earlier and linked it to the cue "birthday." It distinguished the emoji ban and the frog exception it had received four days earlier and kept them even in the face of another person's request. The part about leaving records and acting according to them has been transferred to the agent.
The remaining stages are still open. Retrieving means pulling a memory out of a very large set of normally hidden notes using only a cue, and this example was a single case where the question supplied the name SFOP. Setting a direction that links two distant fields in one move also remains. Thinking of Windows exception handling the moment I saw a Linux signal paper was something I did first this time.
Moziri today has reached the point of recognizing rules a person built up for it and following and evaluating a direction a person pointed out. To go a step further and have the agent come up with new directions on its own, feeding it lots of reading material is not enough. I believe the agent needs to repeat, many times, a feedback loop where it forms its own ideas, runs them with tools and gets broken, and writes the results of those failures back into its memory.
Next time I have Moziri read a paper, I plan to ask differently. Instead of handing it the answer with "Would this method work on Windows too?", I will ask, "If you connect this to other documents you've read before, where else could this principle be put to new use? And under what conditions does that idea break?" Following how people turn experience into intuition has given the next thing to teach the agent this concrete a shape.
References
- 1. Daniel Kahneman, Gary Klein. Conditions for Intuitive Expertise: A Failure to Disagree. American Psychologist 64(6), 515– 526, 2009. DOI: 10.1037/a0016755.
- 2. William G. Chase, Herbert A. Simon. Perception in Chess. Cognitive Psychology 4(1), 55–81, 1973.
- 3. Noah Shinn, Federico Cassano, Ashwin Gopinath, Karthik Narasimhan, Shunyu Yao. Reflexion: Language Agents with Verbal Reinforcement Learning. Advances in Neural Information Processing Systems (NeurIPS), 2023.
- 4. code-yeongyu. oh-my-openagent (omo). GitHub. https://github.com/code-yeongyu/oh-my-openagent
- 5. Moziri operation records: Discord conversation logs and memory Git repository commit history (September 29, October 27, November 5, and November 9, 2026, KST).
- 6. Crashing Through Defenses: Exploiting Segfaults and Chaining around Intel CET (Segmentation Fault Oriented Programming, SFOP). CISPA, IEEE S&P 2026. https://syssec.cispa.de/papers/sfop-ieeesp2026.pdf
- 7. Herbert A. Simon, Kevin Gilmartin. A Simulation of Memory for Chess Positions. Cognitive Psychology 5(1), 29–46, 1973.