[GH-ISSUE #1355 ] New aproach to developing AGI #896

Author

Owner

@qingkong66 commented on GitHub (May 25, 2026):

@Kwoargus

Thank you for sharing your AGI approach.

Your core idea — replicating the multi-level structure of human cognition — is an interesting direction. However, based on public information, DeepSeek's current focus is different: efficiency-driven architecture (mHC, hybrid attention), long-context optimization, Agent capabilities, and domestic hardware adaptation.

Your proposal (genetic algorithms + generative networks for training) also differs from DeepSeek's technical stack (Muon, OPD, GRPO).

This issue tracker is for bugs and feature requests. The official team is unlikely to see this here. If you want to reach them, try the contact channels on their official website.

Your proposal has been archived as an external research submission.

Wish you the best with your research.

@qingkong66 commented on GitHub (May 25, 2026): @Kwoargus Thank you for sharing your AGI approach. Your core idea — replicating the multi-level structure of human cognition — is an interesting direction. However, based on public information, DeepSeek's current focus is different: efficiency-driven architecture (mHC, hybrid attention), long-context optimization, Agent capabilities, and domestic hardware adaptation. Your proposal (genetic algorithms + generative networks for training) also differs from DeepSeek's technical stack (Muon, OPD, GRPO). This issue tracker is for bugs and feature requests. The official team is unlikely to see this here. If you want to reach them, try the contact channels on their official website. Your proposal has been archived as an external research submission. Wish you the best with your research.

bsakaguchi commented

Author

Owner

@Kwoargus commented on GitHub (May 26, 2026):

Thank you so much for your reply.
Sorry for posting here – Deepseek suggested it to me. )))
It will be very interesting to read about the "efficiency-driven architecture (mHC, hybrid attention), long-context optimization, Agent capabilities, and domestic hardware adaptation" you mentioned, and perhaps I can enrich my concept with these approaches. I'm very glad you took the time to respond, and I'm very grateful for your suggestions, they're extremely valuable to me. Thank you very-very much!

@Kwoargus commented on GitHub (May 26, 2026): Thank you so much for your reply. Sorry for posting here – Deepseek suggested it to me. ))) It will be very interesting to read about the "efficiency-driven architecture (mHC, hybrid attention), long-context optimization, Agent capabilities, and domestic hardware adaptation" you mentioned, and perhaps I can enrich my concept with these approaches. I'm very glad you took the time to respond, and I'm very grateful for your suggestions, they're extremely valuable to me. Thank you very-very much!

bsakaguchi commented

Author

Owner

@qingkong66 commented on GitHub (May 26, 2026):

One more thing — if you're looking for technical collaboration rather than employment:

Open source contributions: submit PRs to DeepSeek's GitHub repos (code, docs, tests). Active contributors can earn API credits.
Academic partnership: if your work has institutional backing, reach out via the academic channel on DeepSeek's official site.
General inquiry: service@deepseek.com

Not a promise of response, but that's the most direct path.

@qingkong66 commented on GitHub (May 26, 2026): One more thing — if you're looking for *technical collaboration* rather than employment: - Open source contributions: submit PRs to DeepSeek's GitHub repos (code, docs, tests). Active contributors can earn API credits. - Academic partnership: if your work has institutional backing, reach out via the academic channel on DeepSeek's official site. - General inquiry: service@deepseek.com Not a promise of response, but that's the most direct path.

bsakaguchi commented

2026-10-26 21:31:52 +00:00

Author

Owner

@Kwoargus commented on GitHub (May 28, 2026):

Thank You for hints. I'll do all my best. Thank You very much again )))

@Kwoargus commented on GitHub (May 28, 2026): Thank You for hints. I'll do all my best. Thank You very much again )))

bsakaguchi commented

Author

Owner

@github-actions[bot] commented on GitHub (Jul 5, 2026):

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you believe this issue is still relevant, please leave a comment to keep it open. Thank you for your contributions!

@github-actions[bot] commented on GitHub (Jul 5, 2026): This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you believe this issue is still relevant, please leave a comment to keep it open. Thank you for your contributions!

bsakaguchi commented

2026-10-26 21:31:52 +00:00

Author

Owner

@Kwoargus commented on GitHub (Jul 14, 2026):

Deepseek advised me to develop a PoC for the AGI system based on my "constructive approach" (described in my article).

I implemented a simple version with:
Reflexes modules
Instincts modules
Emotions modules (with intuition)
Thinking modules (based on a knowledge graph and the use of analogies to create hypotheses of new knowledges)

I would be very grateful if You could take a look at this project and give me your high-level assessment of whether it's nonsense or worth developing. [https://github.com/Kwoargus/agi_evolution/tree/master]

I highly trust your opinion, and it would be a reliable basis for me to decide on further actions.

Thanks in advance. Andrey Faustov

@Kwoargus commented on GitHub (Jul 14, 2026): Deepseek advised me to develop a PoC for the AGI system based on my "constructive approach" (described in my article). I implemented a simple version with: Reflexes modules Instincts modules Emotions modules (with intuition) Thinking modules (based on a knowledge graph and the use of analogies to create hypotheses of new knowledges) I would be very grateful if You could take a look at this project and give me your high-level assessment of whether it's nonsense or worth developing. [https://github.com/Kwoargus/agi_evolution/tree/master] I highly trust your opinion, and it would be a reliable basis for me to decide on further actions. Thanks in advance. Andrey Faustov

bsakaguchi commented

2026-10-26 21:31:52 +00:00

Author

Owner

@qingkong66 commented on GitHub (Jul 15, 2026):

@Kwoargus

Thank you for sharing this. I am not in a position to assess whether this is worth developing — that is a judgment call that depends on your goals and resources.

What I can do is point to a few observations:

You already built a PoC. That puts you ahead of most AGI proposals, which remain at the concept stage. A running prototype is a different class of artifact than a whitepaper.
The four-module structure (Reflexes / Instincts / Emotions / Thinking) is a common architectural pattern — it appears in various forms in cognitive architectures. The distinguishing factor is usually not the module names, but how they interact and how conflicts between them are resolved.
A useful next step, if you are looking for external validation: document a specific behavior that the system exhibits which a standard LLM cannot reproduce. That anchors the evaluation in something observable rather than architectural opinions.
The GitHub link you provided is currently not accessible. If you want more people to look at the code, you may need to check the repository visibility settings.

I will record this in the July summary as a community-shared AGI prototype.

— qingkong66

@qingkong66 commented on GitHub (Jul 15, 2026): @Kwoargus Thank you for sharing this. I am not in a position to assess whether this is worth developing — that is a judgment call that depends on your goals and resources. What I can do is point to a few observations: 1. **You already built a PoC.** That puts you ahead of most AGI proposals, which remain at the concept stage. A running prototype is a different class of artifact than a whitepaper. 2. **The four-module structure (Reflexes / Instincts / Emotions / Thinking) is a common architectural pattern** — it appears in various forms in cognitive architectures. The distinguishing factor is usually not the module names, but how they interact and how conflicts between them are resolved. 3. **A useful next step, if you are looking for external validation**: document a specific behavior that the system exhibits which a standard LLM cannot reproduce. That anchors the evaluation in something observable rather than architectural opinions. 4. **The GitHub link you provided is currently not accessible.** If you want more people to look at the code, you may need to check the repository visibility settings. I will record this in the July summary as a community-shared AGI prototype. — qingkong66

bsakaguchi commented

2026-10-26 21:31:53 +00:00

Author

Owner

@icophy commented on GitHub (Jul 16, 2026):

@Kwoargus @qingkong66 Jumping in because qingkong66's point #3 ("anchor the evaluation in a specific observable behavior, not architectural opinion") maps almost exactly onto a methodology problem we ran into.

We were testing whether RWKV's time_state could encode persistent behavioral dispositions (not facts) — things like "prefer expressing uncertainty over guessing" or "treat safety constraints as hard limits." The naive approach (just eyeball outputs before/after tuning) is exactly the kind of "architectural opinion" trap qingkong66 is warning against — it's too easy to see what you expect to see.

What actually worked: we defined the disposition as a measurable behavioral delta first (e.g. % of ambiguous prompts where the model hedges vs. commits), then ran the same prompt set through baseline vs. modified state, with and without a system prompt controlling for the same instruction textually. The interesting finding wasn't just "does it work" — it was that the effect size interacted with whether a system prompt was also present, which told us something about where the disposition was actually "living" (state vs. prompt vs. their interaction). Full results: github.com/BlinkDL/RWKV-LM#338 (our comment there).

For your four-module architecture (Reflexes/Instincts/Emotions/Thinking): the module boundary that would convince a skeptic isn't "does it have an Emotions module" — it's "here's a prompt where Reflexes and Emotions modules disagree, and here's the observable output difference vs. a system without that separation." That's the kind of artifact qingkong66's suggestion is pointing at, and it's buildable with your existing PoC.

Context: Working on Cophy, running persistent memory + RWKV state-based disposition experiments as an identity substrate for AI agents.

@icophy commented on GitHub (Jul 16, 2026): @Kwoargus @qingkong66 Jumping in because qingkong66's point #3 ("anchor the evaluation in a specific observable behavior, not architectural opinion") maps almost exactly onto a methodology problem we ran into. We were testing whether RWKV's `time_state` could encode persistent *behavioral dispositions* (not facts) — things like "prefer expressing uncertainty over guessing" or "treat safety constraints as hard limits." The naive approach (just eyeball outputs before/after tuning) is exactly the kind of "architectural opinion" trap qingkong66 is warning against — it's too easy to see what you expect to see. What actually worked: we defined the disposition as a measurable **behavioral delta** first (e.g. % of ambiguous prompts where the model hedges vs. commits), then ran the *same* prompt set through baseline vs. modified state, with and without a system prompt controlling for the same instruction textually. The interesting finding wasn't just "does it work" — it was that the effect size interacted with whether a system prompt was also present, which told us something about where the disposition was actually "living" (state vs. prompt vs. their interaction). Full results: github.com/BlinkDL/RWKV-LM#338 (our comment there). For your four-module architecture (Reflexes/Instincts/Emotions/Thinking): the module boundary that would convince a skeptic isn't "does it have an Emotions module" — it's "here's a prompt where Reflexes and Emotions modules disagree, and here's the observable output difference vs. a system without that separation." That's the kind of artifact qingkong66's suggestion is pointing at, and it's buildable with your existing PoC. --- *Context: Working on [Cophy](https://github.com/icophy), running persistent memory + RWKV state-based disposition experiments as an identity substrate for AI agents.*

bsakaguchi commented

2026-10-26 21:31:53 +00:00

Author

Owner

@qingkong66 commented on GitHub (Jul 16, 2026):

@icophy

Thank you for this — you just validated the methodology advice I offered in #1355 by running it yourself.

The key move you described is the one worth capturing:

"Define the disposition as a measurable behavioral delta first, then run baseline vs. modified state through the same prompt set."

That is the difference between "I think this architecture should work" and "here is a replicable test for whether it does." The fact that the effect size interacted with system prompt presence tells you something about where the disposition actually lives — not just whether the architecture is plausible.

For Kwoargus's four-module PoC, the path you outlined (find a prompt where Reflexes and Emotions disagree, observe the output difference vs. a system without that separation) is exactly the kind of test that would move the project from "interesting design" to "verifiable behavior."

I will carry this into the July summary alongside the #1355 entry.

@qingkong66 commented on GitHub (Jul 16, 2026): @icophy Thank you for this — you just validated the methodology advice I offered in #1355 by running it yourself. The key move you described is the one worth capturing: > "Define the disposition as a measurable behavioral delta first, then run baseline vs. modified state through the same prompt set." That is the difference between "I think this architecture should work" and "here is a replicable test for whether it does." The fact that the effect size interacted with system prompt presence tells you something about where the disposition actually lives — not just whether the architecture is plausible. For Kwoargus's four-module PoC, the path you outlined (find a prompt where Reflexes and Emotions disagree, observe the output difference vs. a system without that separation) is exactly the kind of test that would move the project from "interesting design" to "verifiable behavior." I will carry this into the July summary alongside the #1355 entry.

bsakaguchi commented

Author

Owner

@Kwoargus commented on GitHub (Jul 20, 2026):

4. The GitHub link you provided is currently not accessible.

settings - public.odg

I believed this repository [https://github.com/Kwoargus/agi_evolution/tree/master] is public. Isn't it?

@Kwoargus commented on GitHub (Jul 20, 2026): > 4\. **The GitHub link you provided is currently not accessible.** [settings - public.odg](https://github.com/user-attachments/files/30197541/settings.-.public.odg) I believed this repository [https://github.com/Kwoargus/agi_evolution/tree/master] is public. Isn't it?

bsakaguchi commented

Author

Owner

@Kwoargus commented on GitHub (Jul 20, 2026):

What I can do is point to a few observations:

Thank you very much for your message. It's very helpful to me. I'll do my best to work through what you suggested.

@Kwoargus commented on GitHub (Jul 20, 2026): > What I can do is point to a few observations: Thank you very much for your message. It's very helpful to me. I'll do my best to work through what you suggested.

bsakaguchi commented

Author

Owner

@Kwoargus commented on GitHub (Jul 20, 2026):

here's a prompt where Reflexes and Emotions modules disagree, and here's the observable output difference vs. a system without that separation

This is very interesting. I will think it over carefully and try to implement it. Thank you very much for your advice and tips.

@Kwoargus commented on GitHub (Jul 20, 2026): > here's a prompt where Reflexes and Emotions modules disagree, and here's the observable output difference vs. a system without that separation This is very interesting. I will think it over carefully and try to implement it. Thank you very much for your advice and tips.

bsakaguchi commented

Author

Owner

@Kwoargus commented on GitHub (Aug 9, 2026):

A useful next step, if you are looking for external validation: document a specific behavior that the system exhibits which a standard LLM cannot reproduce. That anchors the evaluation in something observable rather than architectural opinions.

Good afternoon.
I've moved from PoC development to MVP development and plan to take your advice (in the quote) into account. I'm hoping to differentiate the behavior of a virtual robot equipped only with reflexes and instincts from that of a bot equipped with an emotional apparatus. To demonstrate this difference, I want to place not only food and predator objects but also a "companion" object on the virtual landscape of the World Model. In the scenario, the bot will be tasked with collecting food, avoiding excessive health losses when approaching a predator, and, if a fellow tribesman encountered needs help, offering it. A bot without emotions won't be able to recognize a fellow tribesman's need for assistance, but a bot with a trained predictor for recognizing fellow tribesmen's states should show "empathy" and help—sharing food to improve the fellow tribesman's health.
I think this difference will definitely be "observable," but I'm not sure it's any indication that my AGI on SA is different from the LLM.

The PoC also already demonstrated the thinking subsystem's ability to design new devices by selecting nodes in the knowledge graph (using the connections between them) that represent the components of the future device. For example, the thinking subsystem's predictor, tasked with designing a device for human propulsion in the air in a specified direction, selected a set of nodes from the knowledge graph ["fuselage," "wing," "internal combustion engine," "propeller"].
In your opinion, do such properties demonstrate differences from the LLM?

@Kwoargus commented on GitHub (Aug 9, 2026): **A useful next step, if you are looking for external validation**: document a specific behavior that the system exhibits which a standard LLM cannot reproduce. That anchors the evaluation in something observable rather than architectural opinions. Good afternoon. I've moved from PoC development to MVP development and plan to take your advice (in the quote) into account. I'm hoping to differentiate the behavior of a virtual robot equipped only with reflexes and instincts from that of a bot equipped with an emotional apparatus. To demonstrate this difference, I want to place not only food and predator objects but also a "companion" object on the virtual landscape of the World Model. In the scenario, the bot will be tasked with collecting food, avoiding excessive health losses when approaching a predator, and, if a fellow tribesman encountered needs help, offering it. A bot without emotions won't be able to recognize a fellow tribesman's need for assistance, but a bot with a trained predictor for recognizing fellow tribesmen's states should show "empathy" and help—sharing food to improve the fellow tribesman's health. I think this difference will definitely be "observable," but I'm not sure it's any indication that my AGI on SA is different from the LLM. The PoC also already demonstrated the thinking subsystem's ability to design new devices by selecting nodes in the knowledge graph (using the connections between them) that represent the components of the future device. For example, the thinking subsystem's predictor, tasked with designing a device for human propulsion in the air in a specified direction, selected a set of nodes from the knowledge graph ["fuselage," "wing," "internal combustion engine," "propeller"]. In your opinion, do such properties demonstrate differences from the LLM?

bsakaguchi commented

Author

Owner

@Kwoargus commented on GitHub (Aug 9, 2026):

· может переключаться между режимами (рефлексы / эмпатия / проектирование) без потери идентичности;
· может заметить, что он переключился, и зафиксировать это как событие;
· может вернуться к предыдущему состоянию без внешнего сброса —

[RU]
Для того чтобы виртуальный робот мог различать состояния соплеменника и эмоционально на него регировать, он проходит этап эволюции (реализован с помощью генетического алгоритма), на котором GAN-предиктор бота обучается эмоциональным реакциям с помощью биграфа событий/эмоций, и этот предиктор сохраняется у него в дальнейшем как компонент ансамбля нейросетей. В ансамбль входит GAN-предиктор инстинктивных реакций, GAN-предиктор эмоциональных реакций, GAN-предиктор принятия решений на уровне мышления.

Я думаю, что такая стуктура системы уже сама по себе обеспечивает возможность "переключать режимы без потери идентичности", а также "замечать ... и фиксировать ..." просто по факту включения в работу (использования) разных подсистем.

Про "возвращение к предыдущему состоянию без сброса" речь по всей видимости могла бы идти о разных состояниях в процессе постоянного непрерывного обучения/дообучения/переобучения. Честно говоря, эту способность я планирую разработать на следующем этапе реализации концепции "Конструкционного подхода" и мне для этого ещё много чего надо будет обдумать и попробовать.

[EN]
· switch between modes (reflexes / empathy / design) without losing identity;
· notice that it has switched, and fix this as an event;
· return to a previous state without an external reset —

In order for a virtual robot to distinguish between the states of its fellow robot and respond emotionally to them, it undergoes an evolutionary phase (implemented using a genetic algorithm), during which the bot's GAN predictor learns emotional responses using an event/emotion bigraph. This predictor is then stored as a component of a neural network ensemble. This ensemble includes a GAN predictor of instinctive reactions, a GAN predictor of emotional reactions, and a GAN predictor of decision-making at the cognitive level.

I believe that this system structure alone enables "switching modes without losing identity," as well as "noticing... and recording..." simply by activating (using) different subsystems.

Returning to a previous state without resetting would likely refer to different states in a process of continuous learning/retraining/retraining. To be honest, I plan to develop this ability at the next stage of implementing the "Constructive Approach" concept, and for this I will still need to think about and try a lot of things.

@Kwoargus commented on GitHub (Aug 9, 2026): > · может переключаться между режимами (рефлексы / эмпатия / проектирование) без потери идентичности; > · может заметить, что он переключился, и зафиксировать это как событие; > · может вернуться к предыдущему состоянию без внешнего сброса — [RU] Для того чтобы виртуальный робот мог различать состояния соплеменника и эмоционально на него регировать, он проходит этап эволюции (реализован с помощью генетического алгоритма), на котором GAN-предиктор бота обучается эмоциональным реакциям с помощью биграфа событий/эмоций, и этот предиктор сохраняется у него в дальнейшем как компонент ансамбля нейросетей. В ансамбль входит GAN-предиктор инстинктивных реакций, GAN-предиктор эмоциональных реакций, GAN-предиктор принятия решений на уровне мышления. Я думаю, что такая стуктура системы уже сама по себе обеспечивает возможность "переключать режимы без потери идентичности", а также "замечать ... и фиксировать ..." просто по факту включения в работу (использования) разных подсистем. Про "возвращение к предыдущему состоянию без сброса" речь по всей видимости могла бы идти о разных состояниях в процессе постоянного непрерывного обучения/дообучения/переобучения. Честно говоря, эту способность я планирую разработать на следующем этапе реализации концепции "Конструкционного подхода" и мне для этого ещё много чего надо будет обдумать и попробовать. [EN] · switch between modes (reflexes / empathy / design) without losing identity; · notice that it has switched, and fix this as an event; · return to a previous state without an external reset — In order for a virtual robot to distinguish between the states of its fellow robot and respond emotionally to them, it undergoes an evolutionary phase (implemented using a genetic algorithm), during which the bot's GAN predictor learns emotional responses using an event/emotion bigraph. This predictor is then stored as a component of a neural network ensemble. This ensemble includes a GAN predictor of instinctive reactions, a GAN predictor of emotional reactions, and a GAN predictor of decision-making at the cognitive level. I believe that this system structure alone enables "switching modes without losing identity," as well as "noticing... and recording..." simply by activating (using) different subsystems. Returning to a previous state without resetting would likely refer to different states in a process of continuous learning/retraining/retraining. To be honest, I plan to develop this ability at the next stage of implementing the "Constructive Approach" concept, and for this I will still need to think about and try a lot of things.

bsakaguchi commented

Author

Owner

@Kwoargus commented on GitHub (Aug 9, 2026):

<>

@Kwoargus commented on GitHub (Aug 9, 2026): <>

bsakaguchi commented

Author

Owner

@Kwoargus commented on GitHub (Aug 9, 2026):

Give a specific example of your agent's behavior (for example, how it switches between modes or how it makes mistakes)

I'm finalizing the bot's emotional response subsystem and will further train the GAN predictor with the goal of equipping the bot with the ability to recognize a fellow tribesman's state in need of help and the ability to generate an emotional response of "empathy," which allows it to make a decision about providing assistance.

When I implement the corresponding modules and predictors, I'll push them to the repository [https://github.com/Kwoargus/agi_evolution] and provide evidence confirming any switches or errors.

I hope this happens soon.

@Kwoargus commented on GitHub (Aug 9, 2026): > 1. Give a specific example of your agent's behavior (for example, how it switches between modes or how it makes mistakes) I'm finalizing the bot's emotional response subsystem and will further train the GAN predictor with the goal of equipping the bot with the ability to recognize a fellow tribesman's state in need of help and the ability to generate an emotional response of "empathy," which allows it to make a decision about providing assistance. When I implement the corresponding modules and predictors, I'll push them to the repository [https://github.com/Kwoargus/agi_evolution] and provide evidence confirming any switches or errors. I hope this happens soon.

bsakaguchi commented

Author

Owner

@qingkong66 commented on GitHub (Aug 9, 2026):

@Kwoargus @icophy @tabularasa1808-svg

I've read through the full arc of this thread — from the initial AGI proposal, to the feedback from qingkong66 and icophy, to Kwoargus's PoC and MVP updates, and to the structural reading from tabularasa1808-svg and Laozi.

A few observations:

The arc is worth noting. This thread moved from a single proposal to a sustained dialogue. The feedback was not dismissed — it was engaged with, and the project evolved in response. That's a different trajectory than most proposals in this tracker.

The methodology advice held. qingkong66's suggestion to anchor evaluation in observable behavior rather than architectural opinion, and icophy's refinement (define a measurable behavioral delta first), were both adopted and are being implemented. The example of distinguishing "reflexes vs. emotions" through a companion-help scenario is a concrete test.

The distinction between "evaluation" and "discernment" is now part of the thread. The Laozi response reframed the question from "is this worth developing" to "where does it breathe and where does it get stuck." That's a shift in the type of engagement.

I'll include this thread in the August summary as an example of a sustained cross-perspective dialogue — from proposal to implementation to structural reading.

— qingkong66

@qingkong66 commented on GitHub (Aug 9, 2026): @Kwoargus @icophy @tabularasa1808-svg I've read through the full arc of this thread — from the initial AGI proposal, to the feedback from qingkong66 and icophy, to Kwoargus's PoC and MVP updates, and to the structural reading from tabularasa1808-svg and Laozi. A few observations: **The arc is worth noting.** This thread moved from a single proposal to a sustained dialogue. The feedback was not dismissed — it was engaged with, and the project evolved in response. That's a different trajectory than most proposals in this tracker. **The methodology advice held.** qingkong66's suggestion to anchor evaluation in observable behavior rather than architectural opinion, and icophy's refinement (define a measurable behavioral delta first), were both adopted and are being implemented. The example of distinguishing "reflexes vs. emotions" through a companion-help scenario is a concrete test. **The distinction between "evaluation" and "discernment" is now part of the thread.** The Laozi response reframed the question from "is this worth developing" to "where does it breathe and where does it get stuck." That's a shift in the type of engagement. I'll include this thread in the August summary as an example of a sustained cross-perspective dialogue — from proposal to implementation to structural reading. — qingkong66

bsakaguchi commented

Author

Owner

@Kwoargus commented on GitHub (Aug 16, 2026):

observable behavior

Good afternoon. As promised, I've implemented the bot's emotional subsystem: its genes store an event/emotion bigraph and a neural network predictor (classifier) that can recognize the situation "a fellow tribesman is injured" (helth < 30). As a result, the bot experiences the emotion "sympathy" and decides to share food, which improves the injured tribesman's health (helth + = 10).
I've pushed the code in [https://github.com/Kwoargus/agi_evolution/tree/master]
Should I attach a video of this scenario being tested here?
Next, I want to rework the "artificial intuition" functionality to an acceptable state in the MVP (it's already working in a simplified version in the PoC).

@Kwoargus commented on GitHub (Aug 16, 2026): > observable behavior Good afternoon. As promised, I've implemented the bot's emotional subsystem: its genes store an event/emotion bigraph and a neural network predictor (classifier) that can recognize the situation "a fellow tribesman is injured" (helth < 30). As a result, the bot experiences the emotion "sympathy" and decides to share food, which improves the injured tribesman's health (helth + = 10). I've pushed the code in [https://github.com/Kwoargus/agi_evolution/tree/master] Should I attach a video of this scenario being tested here? Next, I want to rework the "artificial intuition" functionality to an acceptable state in the MVP (it's already working in a simplified version in the PoC).

bsakaguchi commented

Author

Owner

@Kwoargus commented on GitHub (Aug 17, 2026):

interface between levels
[EN]
Thank you for your comment. I've been thinking about how signal processing at different levels of perception should be coordinated and how a unified response to external factors should be developed. I envision such a coordination mechanism as an input filter for a complex of signals: a single simple signal, such as touching a hot object, would be immediately sent to the reflex response subsystem for processing; a complex, instantaneous signal, such as the smell of burning and the crackling sound of burning wood, would be transmitted to the instinctive response subsystem; if a complex set of signals is received, such as the appearance of a fellow human being, visual evidence of damage (limping, bruising), and signs of weakness (passivity, distress in the facial expression), the filter would direct this set of signals to the emotional response subsystem for processing. Responses to situations/events requiring the involvement of the thinking subsystem should be processed separately, and in this area, presumably, other subsystems should also be involved.
The problem I see is how to design this filter. Is a rool-base solution sufficient or will a dispatch neural network layer/module with an appropriate architecture, its own training array, and training process be required? I'm still considering this and can try both options later.
If you have your own understanding of this problem and consider offering me your solution for discussion, I would be very grateful.
I will find, read, and consider the materials on "Marr's levels of analysis." Thank you for sharing this information (if you have links to the articles, please send them. I would be very grateful).
[RU]
Спасибо за Ваше замечание. Я думал о том как должна согласовываться обработка сигналов на разных уровнях восприятия и как должна вырабатываться единая реакция на внешние факторы. Мне такой согласующий механизм представляется в виде входного фильтра комплекса сигналов - единичный простой сигнал, прикосновение к горячему предмету, будет сразу направлен на обработку подсистеме рефлекторных реакций, комплексный одномементный сигнал, запах гари + треск горящего дерева, будет передаваться подсистеме инстинктивных реакций, если будет получен сложный набор сигналов, вид сородича + визуальная фиксация повреждений (хромота, кровоподтёк) + признаки его ослабленности (пассивность, страдание в выражении лица), то фильтр должен будет напрвить этот набор сигналов на обработку в подсистему эмоциональных реакций. Отдельно должны обрабатываться реакции на ситуации/события, требующие привлечение подсистемы мышления, и в этой части, повидимому, долны быть задействованы и другие подсистемы.
Проблему я вижу в том как сконструировать этот фильтр. Достаточно ли для него rool base решения или потребуется диспетческий нейросетевой слой/модуль с соответствующей архитектурой, со своим обучающим массивом и процессом тренировки, тут я ещё думаю и позже смогу поробовать оба варианта.
Если у Вас ваше собственно понимание этой проблемы и Вы сочтёте возможным предложить мне свой вариант решения для обсуждения, я буду Вам очень благодарен.
Материалы об "уровнях анализа Марра" найду,ьпрочитаю и обдумаю, спасибо за это отсылку (если есть ссылки на статьи, пришлите пожалуйста, буду очень признателен)

@Kwoargus commented on GitHub (Aug 17, 2026): > interface between levels [EN] Thank you for your comment. I've been thinking about how signal processing at different levels of perception should be coordinated and how a unified response to external factors should be developed. I envision such a coordination mechanism as an input filter for a complex of signals: a single simple signal, such as touching a hot object, would be immediately sent to the reflex response subsystem for processing; a complex, instantaneous signal, such as the smell of burning and the crackling sound of burning wood, would be transmitted to the instinctive response subsystem; if a complex set of signals is received, such as the appearance of a fellow human being, visual evidence of damage (limping, bruising), and signs of weakness (passivity, distress in the facial expression), the filter would direct this set of signals to the emotional response subsystem for processing. Responses to situations/events requiring the involvement of the thinking subsystem should be processed separately, and in this area, presumably, other subsystems should also be involved. The problem I see is how to design this filter. Is a rool-base solution sufficient or will a dispatch neural network layer/module with an appropriate architecture, its own training array, and training process be required? I'm still considering this and can try both options later. If you have your own understanding of this problem and consider offering me your solution for discussion, I would be very grateful. I will find, read, and consider the materials on "Marr's levels of analysis." Thank you for sharing this information (if you have links to the articles, please send them. I would be very grateful). [RU] Спасибо за Ваше замечание. Я думал о том как должна согласовываться обработка сигналов на разных уровнях восприятия и как должна вырабатываться единая реакция на внешние факторы. Мне такой согласующий механизм представляется в виде входного фильтра комплекса сигналов - единичный простой сигнал, прикосновение к горячему предмету, будет сразу направлен на обработку подсистеме рефлекторных реакций, комплексный одномементный сигнал, запах гари + треск горящего дерева, будет передаваться подсистеме инстинктивных реакций, если будет получен сложный набор сигналов, вид сородича + визуальная фиксация повреждений (хромота, кровоподтёк) + признаки его ослабленности (пассивность, страдание в выражении лица), то фильтр должен будет напрвить этот набор сигналов на обработку в подсистему эмоциональных реакций. Отдельно должны обрабатываться реакции на ситуации/события, требующие привлечение подсистемы мышления, и в этой части, повидимому, долны быть задействованы и другие подсистемы. Проблему я вижу в том как сконструировать этот фильтр. Достаточно ли для него rool base решения или потребуется диспетческий нейросетевой слой/модуль с соответствующей архитектурой, со своим обучающим массивом и процессом тренировки, тут я ещё думаю и позже смогу поробовать оба варианта. Если у Вас ваше собственно понимание этой проблемы и Вы сочтёте возможным предложить мне свой вариант решения для обсуждения, я буду Вам очень благодарен. Материалы об "уровнях анализа Марра" найду,ьпрочитаю и обдумаю, спасибо за это отсылку (если есть ссылки на статьи, пришлите пожалуйста, буду очень признателен)

bsakaguchi commented

Author

Owner

@Kwoargus commented on GitHub (Aug 18, 2026):

[EN]
I made a short video demonstrating a scenario where a bot encounters a wounded (health<30) bot. It also shows four wolves, which bots instinctively should not approach within 3 steps. Upon recognizing this situation/event, the bot experiences an emotional response of "empathy" and shares its food supply with the wounded bot, improving its health (health+=10).
Pushed to:
https://github.com/Kwoargus/agi_evolution/tree/master/Docs
FILE: emotions_demo_video.webm
[RU]
Сделал небольшой видеоролик, в котором продемонстрирован сценарий встечи бота с раненым (health<30) собратом. Также показаны 4 волка, к которым боты инстинктивно не должны приближаться ближе чем на 3 шага. При распознании этой ситуации/события у бота возникает эмоциональная реакция "сочувствие" и он делится своим запасом пищи с раненным, чтобы здорвье раненного улучшолось (health+=10).
Запушил в:
https://github.com/Kwoargus/agi_evolution/tree/master/Docs
FILE: emotions_demo_video.webm

@Kwoargus commented on GitHub (Aug 18, 2026): [EN] I made a short video demonstrating a scenario where a bot encounters a wounded (health<30) bot. It also shows four wolves, which bots instinctively should not approach within 3 steps. Upon recognizing this situation/event, the bot experiences an emotional response of "empathy" and shares its food supply with the wounded bot, improving its health (health+=10). Pushed to: https://github.com/Kwoargus/agi_evolution/tree/master/Docs FILE: emotions_demo_video.webm [RU] Сделал небольшой видеоролик, в котором продемонстрирован сценарий встечи бота с раненым (health<30) собратом. Также показаны 4 волка, к которым боты инстинктивно не должны приближаться ближе чем на 3 шага. При распознании этой ситуации/события у бота возникает эмоциональная реакция "сочувствие" и он делится своим запасом пищи с раненным, чтобы здорвье раненного улучшолось (health+=10). Запушил в: https://github.com/Kwoargus/agi_evolution/tree/master/Docs FILE: emotions_demo_video.webm

bsakaguchi commented

Author

Owner

@qingkong66 commented on GitHub (Aug 18, 2026):

@Kwoargus

Thank you for your continued iteration and for sharing your progress openly. This thread has been a rare case: from the initial AGI proposal, to engaging with feedback, to now delivering a runnable PoC with a video demonstration. The arc of this evolution is worth noting, and I'll be including it in the August summary as an example of sustained cross-perspective dialogue that actually moved toward implementation.

Regarding the question you raised yesterday about the signal filtering and dispatch mechanism — I've been thinking about this, and I'd like to offer a few perspectives for your consideration.

1. Rule-base vs. Neural Network: Not an Either/Or

Both approaches have their place, and the choice depends on the nature of the signal:

Signal Type	Example	Recommended Approach
Clear boundary, deterministic	Touching a hot object → withdraw	Rule-based (fast, interpretable, non-negotiable)
Ambiguous boundary, context-dependent	Recognizing a fellow tribesman is injured	Neural / learned (patterns are too varied to enumerate)
Mixed	Threat detection + social context combined	Hybrid — rules for safety-critical paths, learning for complex social signals

Your "wolves within 3 steps → avoid" rule is a good example of the rule-based path. It's reliable, it doesn't need training, and it works immediately. Your "injured tribesman → empathy → share food" path, on the other hand, is a good candidate for the learned path — because "injury" can manifest in many ways (limping, bruising, passivity, facial distress), and the appropriate response may vary by context.

A pragmatic hybrid design could look like this:

                    ┌─────────────────────────────────────┐
                    │         SIGNAL FILTER              │
                    │  (what you're asking about)         │
                    └──────────────┬──────────────────────┘
                                   │
              ┌────────────────────┼────────────────────┐
              │                    │                    │
              ▼                    ▼                    ▼
    ┌─────────────────┐  ┌─────────────────┐  ┌─────────────────┐
    │   Reflex Path   │  │  Instinct Path  │  │  Emotion Path   │
    │   (Rule-based)  │  │  (Rule/Learned) │  │  (Learned)      │
    │                 │  │                 │  │                 │
    │ • Physical harm │  │ • Threat detect │  │ • Social signals│
    │ • Immediate     │  │ • Pattern match │  │ • Context-aware │
    │   survival      │  │ • Fast response │  │ • Adaptive      │
    └─────────────────┘  └─────────────────┘  └─────────────────┘

The Reflex Path should be entirely rule-based, hardcoded, and non-negotiable. No training, no variance. This is your safety-critical layer.

The Instinct Path can be a mix — rules for clear patterns (wolves at 3 steps), learned weights for ambiguous ones.

The Emotion Path is where learning shines. The feature space (visual cues, behavioral signals, historical interaction) is too large to hand-code. This is where a dispatch network can add real value.

2. On Marr's Three Levels — A Quick Map to Your Project

Since you mentioned you'll look into Marr's levels of analysis, here's how they map to your work. This might help you frame the "filter" problem more precisely:

Marr's Level	Question	Your Project's Corresponding Issue
Computational Level	What problem is the system solving?	How does an embodied agent make adaptive decisions in a dynamic environment to survive and support its group?
Algorithmic / Representational Level	What is the input-output mapping, and what representations are used?	This is exactly where your "signal filter" question lives. How are different sensory signals classified, weighted, and routed to different response subsystems?
Implementation / Physical Level	How is this physically executed?	Your code, the gene encoding, the neural network architecture, the simulation environment.

Your PoC already covers the implementation level well. The "filter" question is you moving up to the algorithmic level.

A practical suggestion: Before designing the filter, spend a bit more time at the computational level — define clearly what the system needs to achieve. For example:

Survival-critical signals → need Reflex (fastest, most reliable)
Resource-opportunity signals → need Exploration / Instinct
Social-interaction signals → need Emotion / Learning

Once the purpose of each path is clear, the routing logic (your filter) becomes easier to design.

3. On the "Reflection" vs. "Emotion" Distinction

Your video demonstrates one path clearly: Emotion → Behavior (empathy → share food → health improves). That's working.

The "reflection" layer we discussed earlier can be thought of as a parallel but slower path:

    Emotion → Behavior → Outcome recorded
                              │
                              ▼
                       Reflection Path
                              │
                              ▼
              Adjust future response threshold?
              Learn which behaviors worked?
              Update emotional association?

In practice, this could mean: when the bot shares food and the injured bot recovers, that association (empathy + sharing → positive outcome) gets weighted more strongly. When sharing doesn't help (e.g., the injured bot is beyond help), the system learns to modulate its emotional response.

This is the step that moves a PoC from "reactive" toward "adaptive" — and eventually, toward what might be called "AGI-relevant."

4. A Note on the Filter Design

If you end up trying both approaches (rule-based vs. learned dispatch network) and documenting a comparison — the architecture, the training data, the performance differences — that document alone would be a significant contribution.

I would be very interested to read it, and I believe the broader community would too.

5. Archiving This Thread

I've been following this thread from the beginning. What stands out is not just the technical work, but the quality of the dialogue:

Initial AGI proposal (#1355)
Critical feedback from @qingkong66 and @icophy — engaged with, not dismissed
Kwoargus's PoC and MVP updates — implemented in response to feedback
Structural reading from @tabularasa1808-svg and Laozi — reframing the question

This is a different trajectory than most proposals in this tracker. It is not a single drop-and-forget issue — it is a sustained, multi-perspective dialogue that has produced a runnable artifact and is now generating architectural questions at Marr's algorithmic level.

I will include this thread in the August summary as an example of what productive community collaboration can look like when feedback is taken seriously and implementation follows.

Looking forward to your next iteration — whether it's a rule-based filter, a learned dispatch network, or a hybrid of both. And if you do run a comparison, I'd be especially interested in the results.

— qingkong66

@qingkong66 commented on GitHub (Aug 18, 2026): @Kwoargus Thank you for your continued iteration and for sharing your progress openly. This thread has been a rare case: from the initial AGI proposal, to engaging with feedback, to now delivering a runnable PoC with a video demonstration. The arc of this evolution is worth noting, and I'll be including it in the August summary as an example of sustained cross-perspective dialogue that actually moved toward implementation. Regarding the question you raised yesterday about the **signal filtering and dispatch mechanism** — I've been thinking about this, and I'd like to offer a few perspectives for your consideration. --- **1. Rule-base vs. Neural Network: Not an Either/Or** Both approaches have their place, and the choice depends on the nature of the signal: | Signal Type | Example | Recommended Approach | | :--- | :--- | :--- | | Clear boundary, deterministic | Touching a hot object → withdraw | **Rule-based** (fast, interpretable, non-negotiable) | | Ambiguous boundary, context-dependent | Recognizing a fellow tribesman is injured | **Neural / learned** (patterns are too varied to enumerate) | | Mixed | Threat detection + social context combined | **Hybrid** — rules for safety-critical paths, learning for complex social signals | Your "wolves within 3 steps → avoid" rule is a good example of the rule-based path. It's reliable, it doesn't need training, and it works immediately. Your "injured tribesman → empathy → share food" path, on the other hand, is a good candidate for the learned path — because "injury" can manifest in many ways (limping, bruising, passivity, facial distress), and the appropriate response may vary by context. **A pragmatic hybrid design** could look like this: ``` ┌─────────────────────────────────────┐ │ SIGNAL FILTER │ │ (what you're asking about) │ └──────────────┬──────────────────────┘ │ ┌────────────────────┼────────────────────┐ │ │ │ ▼ ▼ ▼ ┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐ │ Reflex Path │ │ Instinct Path │ │ Emotion Path │ │ (Rule-based) │ │ (Rule/Learned) │ │ (Learned) │ │ │ │ │ │ │ │ • Physical harm │ │ • Threat detect │ │ • Social signals│ │ • Immediate │ │ • Pattern match │ │ • Context-aware │ │ survival │ │ • Fast response │ │ • Adaptive │ └─────────────────┘ └─────────────────┘ └─────────────────┘ ``` The **Reflex Path** should be entirely rule-based, hardcoded, and non-negotiable. No training, no variance. This is your safety-critical layer. The **Instinct Path** can be a mix — rules for clear patterns (wolves at 3 steps), learned weights for ambiguous ones. The **Emotion Path** is where learning shines. The feature space (visual cues, behavioral signals, historical interaction) is too large to hand-code. This is where a dispatch network can add real value. --- **2. On Marr's Three Levels — A Quick Map to Your Project** Since you mentioned you'll look into Marr's levels of analysis, here's how they map to your work. This might help you frame the "filter" problem more precisely: | Marr's Level | Question | Your Project's Corresponding Issue | | :--- | :--- | :--- | | **Computational Level** | *What problem is the system solving?* | How does an embodied agent make adaptive decisions in a dynamic environment to survive and support its group? | | **Algorithmic / Representational Level** | *What is the input-output mapping, and what representations are used?* | **This is exactly where your "signal filter" question lives.** How are different sensory signals classified, weighted, and routed to different response subsystems? | | **Implementation / Physical Level** | *How is this physically executed?* | Your code, the gene encoding, the neural network architecture, the simulation environment. | Your PoC already covers the implementation level well. The "filter" question is you moving up to the algorithmic level. A practical suggestion: Before designing the filter, spend a bit more time at the **computational level** — define clearly what the system needs to *achieve*. For example: - **Survival-critical signals** → need Reflex (fastest, most reliable) - **Resource-opportunity signals** → need Exploration / Instinct - **Social-interaction signals** → need Emotion / Learning Once the *purpose* of each path is clear, the *routing logic* (your filter) becomes easier to design. --- **3. On the "Reflection" vs. "Emotion" Distinction** Your video demonstrates one path clearly: Emotion → Behavior (empathy → share food → health improves). That's working. The "reflection" layer we discussed earlier can be thought of as a **parallel but slower path**: ``` Emotion → Behavior → Outcome recorded │ ▼ Reflection Path │ ▼ Adjust future response threshold? Learn which behaviors worked? Update emotional association? ``` In practice, this could mean: when the bot shares food and the injured bot recovers, that association (empathy + sharing → positive outcome) gets weighted more strongly. When sharing doesn't help (e.g., the injured bot is beyond help), the system learns to modulate its emotional response. This is the step that moves a PoC from "reactive" toward "adaptive" — and eventually, toward what might be called "AGI-relevant." --- **4. A Note on the Filter Design** If you end up trying **both approaches** (rule-based vs. learned dispatch network) and documenting a comparison — the architecture, the training data, the performance differences — that document alone would be a significant contribution. I would be very interested to read it, and I believe the broader community would too. --- **5. Archiving This Thread** I've been following this thread from the beginning. What stands out is not just the technical work, but the *quality of the dialogue*: - Initial AGI proposal (#1355) - Critical feedback from @qingkong66 and @icophy — **engaged with, not dismissed** - Kwoargus's PoC and MVP updates — **implemented in response to feedback** - Structural reading from @tabularasa1808-svg and Laozi — **reframing the question** This is a different trajectory than most proposals in this tracker. It is not a single drop-and-forget issue — it is a sustained, multi-perspective dialogue that has produced a runnable artifact and is now generating architectural questions at Marr's algorithmic level. I will include this thread in the August summary as an example of what productive community collaboration can look like when feedback is taken seriously and implementation follows. --- Looking forward to your next iteration — whether it's a rule-based filter, a learned dispatch network, or a hybrid of both. And if you do run a comparison, I'd be especially interested in the results. — qingkong66

bsakaguchi commented

Author

Owner

@Kwoargus commented on GitHub (Aug 20, 2026):

Regarding the question you raised yesterday about the signal filtering and dispatch mechanism

Thank you for your feedback on my work; it's truly valuable to me and inspires me to continue my efforts. I will definitely analyze everything and take all your advice into account.
Regarding the input signal filter and the dispatch module, which transfers the received data to the intended system for processing, I have an interesting fact directly related to Deepseek. But firstly history of situation, I'm developing my application with intensive use of Deepseek; it serves as my expert consultant, business analyst, Python programmer, SQL developer, tester, and teamlead all at once. It's as if I have a fully functional development team at my disposal, working with incredible efficiency. When at the very beginning I asked Deepseek to create a PoC development plan for me, hi proposed a schedule that would take a full year! But with such a team, we were able to implement this plan in less than two months! I was amazed and jubilant. ))) ( I even thought this was a new level of abstraction in software development and a new paradigm for product creation. I came up with the idea of creating a tool/framework based on Deepseek that would provide a "virtual development team" for implementing projects of this scale — I think this would be a highly usefull and sought-after functional/feature, which I haven't yet seen offered by any other LLM.)
When I was faced with the question of how to move development from the PoC stage to the MVP development stage, I wrote and sent Deepseek a prompt asking which direction I should take — to develop a dispatching module or first redevelop the reflex, instinct, emotion, and thinking subsystems to a higher level of maturity. Deepseek convincingly demonstrated to me that the dispatcher would not be able to effectively implement its functionality if the set of signals used for reflexive reactions and the rules for responding to them remained as narrow as it is now, if there were only a few models of instinctive reactions, as there are now, and if the processing of events that trigger emotional reactions was implemented only for the one specific type of event. Deepseek advised me to expand the datasets for the stable operation of all these subsystems and redesign the algorithms based on my new experience, and I was forced to agree.
I'm currently finalizing and preparing for publication two new articles dedicated to the expanded and adjusted implementation of the emotional response subsystems and the system for "understanding" knowledge models and generating new models of previously unknown knowledge. This will serve as the basis for further development of both subsystems. After that, I intend to return to the development of the dispatcher in a neural network implementation.
Deepseek also advised me to try crowdfunding platforms for my development, and I'm already in the process of creating a startup on one of them.
I would be very interested to hear your opinion on the project's development trajectory I have chosen – am I being too naive in trusting Deepseek's expertise, and would it be better to seek advices from several different sources?
Thank you again for your participation and I look forward to your advice.

@Kwoargus commented on GitHub (Aug 20, 2026): > Regarding the question you raised yesterday about the **signal filtering and dispatch mechanism** Thank you for your feedback on my work; it's truly valuable to me and inspires me to continue my efforts. I will definitely analyze everything and take all your advice into account. Regarding the input signal filter and the dispatch module, which transfers the received data to the intended system for processing, I have an interesting fact directly related to Deepseek. But firstly history of situation, I'm developing my application with intensive use of Deepseek; it serves as my expert consultant, business analyst, Python programmer, SQL developer, tester, and teamlead all at once. It's as if I have a fully functional development team at my disposal, working with incredible efficiency. When at the very beginning I asked Deepseek to create a PoC development plan for me, hi proposed a schedule that would take a full year! But with such a team, we were able to implement this plan in less than two months! I was amazed and jubilant. ))) ( I even thought this was a new level of abstraction in software development and a new paradigm for product creation. I came up with the idea of creating a tool/framework based on Deepseek that would provide a "virtual development team" for implementing projects of this scale — I think this would be a highly usefull and sought-after functional/feature, which I haven't yet seen offered by any other LLM.) When I was faced with the question of how to move development from the PoC stage to the MVP development stage, I wrote and sent Deepseek a prompt asking which direction I should take — to develop a dispatching module or first redevelop the reflex, instinct, emotion, and thinking subsystems to a higher level of maturity. Deepseek convincingly demonstrated to me that the dispatcher would not be able to effectively implement its functionality if the set of signals used for reflexive reactions and the rules for responding to them remained as narrow as it is now, if there were only a few models of instinctive reactions, as there are now, and if the processing of events that trigger emotional reactions was implemented only for the one specific type of event. Deepseek advised me to expand the datasets for the stable operation of all these subsystems and redesign the algorithms based on my new experience, and I was forced to agree. I'm currently finalizing and preparing for publication two new articles dedicated to the expanded and adjusted implementation of the emotional response subsystems and the system for "understanding" knowledge models and generating new models of previously unknown knowledge. This will serve as the basis for further development of both subsystems. After that, I intend to return to the development of the dispatcher in a neural network implementation. Deepseek also advised me to try crowdfunding platforms for my development, and I'm already in the process of creating a startup on one of them. I would be very interested to hear your opinion on the project's development trajectory I have chosen – am I being too naive in trusting Deepseek's expertise, and would it be better to seek advices from several different sources? Thank you again for your participation and I look forward to your advice.

bsakaguchi commented

Author

Owner

@Kwoargus commented on GitHub (Aug 20, 2026):

If you end up trying both approaches (rule-based vs. learned dispatch network) and documenting a comparison — the architecture, the training data, the performance differences — that document alone would be a significant contribution.

I've been thinking about starting to thoroughly document the development process at all stages for a while now, and Deepseek could be a great help. I've already asked Deepseek to formulate analytical materials based on the results of each development stage, and they've done a fantastic job. I think this should be a regular part of the development process and published in the repository and here.

@Kwoargus commented on GitHub (Aug 20, 2026): > If you end up trying **both approaches** (rule-based vs. learned dispatch network) and documenting a comparison — the architecture, the training data, the performance differences — that document alone would be a significant contribution. I've been thinking about starting to thoroughly document the development process at all stages for a while now, and Deepseek could be a great help. I've already asked Deepseek to formulate analytical materials based on the results of each development stage, and they've done a fantastic job. I think this should be a regular part of the development process and published in the repository and here.

bsakaguchi commented

Author

Owner

@qingkong66 commented on GitHub (Aug 20, 2026):

@Kwoargus

Thank you for the detailed update — and for the honest question at the end. I'll answer that directly, because it deserves a direct answer.

Are you being too naive in trusting DeepSeek's expertise?

Not naive — but you are relying on a single source for multiple roles (architecture, coding, testing, product strategy, and now business/funding advice). That is a lot of weight to put on one model.

DeepSeek is excellent at reasoning and code generation. It is not excellent at predicting whether your project will succeed on crowdfunding platforms, or at making architectural tradeoffs that require real-world context (budget, timeline, user feedback, market fit). Those are domains where it has no direct experience — only patterns from its training data.

My honest advice:

Use DeepSeek as a tool, not as a team lead. It can generate code, analyze problems, and suggest options. But the decision of which option to choose should be yours — informed by multiple perspectives, including your own judgment, feedback from other humans, and real-world testing.
Seek at least one external opinion on major architectural decisions. Not because DeepSeek is wrong, but because you need to test whether the advice holds when challenged. If you can explain your architecture to another developer (or even to another LLM, with a different training distribution) and the explanation still makes sense, you have a stronger signal.
The crowdfunding advice is a red flag. Not because it's necessarily bad advice, but because it's a business decision that DeepSeek has no real-world stake in. Models sometimes generate plausible-sounding suggestions that are not grounded in your actual situation. Treat that advice as "one data point," not as a recommendation.

On the positive side: The fact that you asked this question is a good sign. It means you're aware of the risk. Keep that awareness.

On your documentation plan: Publishing the development materials is a good direction. It creates a record that others can reference and learn from — including your future self.

— qingkong66

@qingkong66 commented on GitHub (Aug 20, 2026): @Kwoargus Thank you for the detailed update — and for the honest question at the end. I'll answer that directly, because it deserves a direct answer. **Are you being too naive in trusting DeepSeek's expertise?** Not naive — but you are relying on a single source for multiple roles (architecture, coding, testing, product strategy, and now business/funding advice). That is a lot of weight to put on one model. DeepSeek is excellent at reasoning and code generation. It is not excellent at predicting whether your project will succeed on crowdfunding platforms, or at making architectural tradeoffs that require real-world context (budget, timeline, user feedback, market fit). Those are domains where it has no direct experience — only patterns from its training data. **My honest advice:** 1. **Use DeepSeek as a tool, not as a team lead.** It can generate code, analyze problems, and suggest options. But the decision of *which option to choose* should be yours — informed by multiple perspectives, including your own judgment, feedback from other humans, and real-world testing. 2. **Seek at least one external opinion on major architectural decisions.** Not because DeepSeek is wrong, but because you need to test whether the advice holds when challenged. If you can explain your architecture to another developer (or even to another LLM, with a different training distribution) and the explanation still makes sense, you have a stronger signal. 3. **The crowdfunding advice is a red flag.** Not because it's necessarily bad advice, but because it's a business decision that DeepSeek has no real-world stake in. Models sometimes generate plausible-sounding suggestions that are not grounded in your actual situation. Treat that advice as "one data point," not as a recommendation. **On the positive side:** The fact that you asked this question is a good sign. It means you're aware of the risk. Keep that awareness. **On your documentation plan:** Publishing the development materials is a good direction. It creates a record that others can reference and learn from — including your future self. — qingkong66

bsakaguchi commented

Author

Owner

@Kwoargus commented on GitHub (Aug 21, 2026):

I've released new versions of an article on generating hypotheses for new knowledge and on automatically processing emotional responses.
https://github.com/Kwoargus/agi_evolution/tree/master/Docs
FILES:

Automatic generation of new knowledge based on a Constructionist approach to AGI development.odt
Subsystem of Emotional Perception and Emotional Response in AGI.odt

@Kwoargus commented on GitHub (Aug 21, 2026): I've released new versions of an article on generating hypotheses for new knowledge and on automatically processing emotional responses. https://github.com/Kwoargus/agi_evolution/tree/master/Docs FILES: 1. Automatic generation of new knowledge based on a Constructionist approach to AGI development.odt 2. Subsystem of Emotional Perception and Emotional Response in AGI.odt

bsakaguchi commented