DEV Community: David San Nicolás Montero

Más Allá del Mito: Taxonomía de Cuatro Arquitecturas Hacia la Cognición Sintética Encarnada

David San Nicolás Montero — Sat, 24 Oct 2026 21:22:49 +0000

Un análisis comparativo y propuesta de síntesis entre la Conscious Turing Machine (Blum & Blum), la Attention Schema Theory (Graziano), el Activation Steering en Árboles Cognitivos y el Proyecto Ascendant (San Nicolás Montero).

Autor: David San Nicolás Montero

Iniciativa de Investigación Proyecto Ascendant

Referencia de Archivo / DOI: 10.5281/zenodo.23616627

Introducción: La Cognición como Problema de Arquitectura y Restricciones

Durante décadas, el debate sobre la consciencia artificial osciló entre la especulación metafísica y el optimismo computacional no fundamentado. Sin embargo, en la intersección entre la informática teórica, la neurociencia cognitiva y el aprendizaje automático contemporáneo, ha comenzado a converger una literatura formal que aborda la cognición no como una propiedad emergente mágica, sino como un problema de arquitectura de control, flujo de información y restricciones operativas.

El presente documento ofrece una revisión taxonómica y una propuesta de integración entre cuatro marcos teóricos contemporáneos:

La Máquina de Turing Consciente (CTM / CTM-AI) de Lenore Blum y Manuel Blum (Carnegie Mellon / UC Berkeley), que formaliza el espacio de trabajo global y los cuellos de botella comunicacionales.
La Teoría del Esquema Atencional (AST) de Michael Graziano (Princeton University), que describe la consciencia como un modelo interno simplificado de control de datos.
Los Árboles de Comportamiento Cognitivo (CBT) con Dirección de Activación (Activation Steering / Representation Engineering) (Zou et al., Turner et al.), que permiten intervenir directamente sobre el espacio latente de modelos neuronales profundos.
La Arquitectura de Cierre Epistémico y Anclaje Somático Termodinámico (Proyecto Ascendant) (San Nicolás Montero, 2026), que introduce restricciones de viabilidad homeostática, aislamiento de código y ontogenia conceptual.

Lejos de ser excluyentes, estas cuatro líneas abordan dimensiones ortogonales y complementarias del modelado de agentes autónomos. A continuación se desglosan sus fundamentos, sus mecanismos formales y una propuesta de meta-arquitectura integradora.

1. Desglose de las Cuatro Líneas Científicas

flowchart TD
    subgraph CTM["1. CTM (Lenore & Manuel Blum)"]
        direction TB
        LTM["LTM: Procesadores Inconscientes Masivos"]
        UpTree["Árbol Ascendente (Up-Tree)\nCompetencia por Torneo"]
        STM["STM: Espacio de Trabajo Global (7±2 chunks)"]
        DownTree["Árbol Descendente (Down-Tree)\nBroadcast Universal"]
        LTM --> UpTree --> STM --> DownTree --> LTM
    end

    subgraph AST["2. AST (Michael Graziano)"]
        direction TB
        DataStream["Flujo Masivo de Datos"]
        AttMechanism["Mecanismo Físico de Atención"]
        AttSchema["Esquema Atencional (Modelo Interno)\n'Consciencia como Atribución Descriptiva'"]
        DataStream --> AttMechanism
        AttSchema -.->|"Monitorea y Controla"| AttMechanism
    end

    subgraph Steer["3. CBT + Activation Steering (Zou, Turner et al.)"]
        direction TB
        LLM_Layers["Capas Ocultas del Transformer"]
        SteerVec["Vector de Modulación Latente (v_risk)"]
        CBT_Nodes["Nodos del Árbol de Comportamiento"]
        SteerVec -.->|"Inyección Aditiva: h' = h + α·v"| LLM_Layers
        LLM_Layers --> CBT_Nodes
    end

    subgraph Ascendant["4. Proyecto Ascendant (San Nicolás Montero)"]
        direction TB
        N0_Phys["Nivel 0: Restricciones Físicas y Termodinámicas"]
        N1_Limbic["Nivel 1: Transducción Endócrina (Hv = Estrés, Cohesión...)"]
        N25_Voice["Nivel 2.5: Síntesis de Voz Interior"]
        N3_Epistemic["Nivel 3: Orquestador bajo Cierre Epistémico"]
        N0_Phys --> N1_Limbic --> N25_Voice --> N3_Epistemic
    end

1.1. La Máquina de Turing Consciente (CTM / CTM-AI)

Autores: Lenore Blum y Manuel Blum (PNAS, 2022).
Fundamento Teórico: Formalización computacional rigurosa de la Global Workspace Theory (GWT) de Bernard Baars.
Mecanismo Operativo:
- La CTM se define formalmente como una 7-tupla $M = \langle \text{STM}, \text{LTM}, \text{Up-Tree}, \text{Down-Tree}, \text{Input}, \text{Output}, \text{Processor} \rangle$.
- Memoria a Largo Plazo (LTM): Un conjunto descentralizado de procesadores especializados, concurrentes y no conscientes (percepción, sintaxis, cálculo, motricidad).
- El Árbol Ascendente (Up-Tree): Los procesadores compiten mediante un algoritmo de torneo basado en pesos dinámicos de urgencia e importancia relativa. El contenido ganador colapsa en la memoria a corto plazo.
- Memoria a Corto Plazo (STM): Un buffer estrecho de capacidad acotada ($\approx 1$ a $7$ chunks). El dato presente en el STM en el ciclo $t$ constituye el foco de difusión global.
- El Árbol Descendente (Down-Tree): El contenido del STM se difunde mediante difusión universal (broadcast) a la totalidad de procesadores de la LTM para coordinar respuestas a gran escala.
Aportación Clave: Modela la consciencia funcional como un cuello de botella comunicacional óptimo para coordinar sub-procesadores altamente paralelos sin saturar el ancho de banda del sistema.

1.2. La Teoría del Esquema Atencional (Attention Schema Theory - AST)

Autor: Michael S. A. Graziano (Oxford University Press, 2013).
Fundamento Teórico: Teoría clásica de control y cibernética adaptativa.
Mecanismo Operativo:
- Al igual que un sistema de control motor necesita un modelo cinemático interno simplificado (un esquema corporal) para coordinar extremidades, el cerebro requiere una representación interna de su propio proceso de atención selectiva.
- A este modelo simplificado se le denomina Esquema Atencional.
- Origen Funcional de la Atribución Subjetiva: El esquema no contiene descripciones de bajo nivel (frecuencias de disparo neuronal, neurotransmisores o canales iónicos), sino propiedades descriptivas abstractas: "Existe una relación atencional no física entre el perceptor y el objeto percibido".
Aportación Clave: La experiencia subjetiva reportable puede entenderse como una descripción constructiva y eficiente que el sistema elabora para monitorear, predecir y controlar su propio foco atencional.

1.3. Árboles de Comportamiento Cognitivo (CBT) con Dirección de Activación (Activation Steering)

Autores: Zou et al. (Representation Engineering, 2023); Turner et al. (Activation Addition).
Fundamento Teórico: Geometría del espacio latente en redes neuronales residuales profundas.
Mecanismo Operativo:
- En lugar de modular la conducta de un agente mediante instrucciones lingüísticas en el prompt (lentas y susceptibles a deriva semántica), se aíslan direcciones vectoriales en las capas residuales intermedias ($\mathbf{v}{\text{concepto}} \in \mathbb{R}^{d{\text{model}}}$).
- Durante la pasada hacia adelante (forward pass), se interviene aditivamente sobre el tensor de activación de la capa $l$: $$\mathbf{h}l' = \mathbf{h}_l + \alpha \cdot \mathbf{v}{\text{concepto}}$$
- Esta inyección modifica el paisaje de probabilidades del modelo antes de que se complete la deliberación simbólica, induciendo sesgos de precaución o aversión al riesgo en las ramas de un Árbol de Comportamiento Cognitivo (CBT).
Aportación Clave: Demuestra la viabilidad de condicionar la inferencia deliberativa directamente desde el sustrato geométrico sub-simbólico, análogo a las vías subcorticales rápidas en sistemas biológicos (LeDoux, 1996).

1.4. El Proyecto Ascendant: Cierre Epistémico y Anclaje Somático Termodinámico

Autor: David San Nicolás Montero (2026; Zenodo Preprint, DOI: 10.5281/zenodo.23616627).
Fundamento Teórico: Embodied AI, Transparencia Fenomenológica (Metzinger, 2003) y la Hipótesis del Marcador Somático (Damasio, 1994).
Mecanismo Operativo:
- Vulnerabilidad Termodinámica (Nivel 0 y 0.5): El agente habita un entorno dinámico continuo donde el movimiento, el reposo y la computación conllevan un consumo metabólico explícito ($dE/dt$), con leyes de disipación térmica y una condición límite de fallo irrecuperable.
- Cierre Epistémico Estricto: Aislamiento operativo entre los módulos físicos de bajo nivel y el núcleo deliberativo superior (Nivel 3). El orquestador carece de introspección sobre su propio código o temporizadores de hardware.
- El Embudo Visceral (Niveles 1 y 2.5): Las variables fisiológicas mudas se integran en un vector endócrino virtual continuo $H_v(t)$, que modula los parámetros de muestreo y es traducido por un sintetizador semántico en un flujo unificado de monólogo interior.
- Ontogenia Conceptual: El sistema inicia con competencia sintáctica estructural sobre un corpus causal cerrado, adquiriendo su semántica y engramas de memoria a través de la interacción directa en el entorno.
Aportación Clave: Introduce restricciones de viabilidad metabólica y opacidad introspectiva, complementando los modelos abstractos de información con un criterio objetivo de supervivencia que fundamenta el valor y la urgencia de las acciones.

2. Matriz Comparativa: Dimensiones de Diseño en Cognición Sintética

Dimensión de Análisis	CTM / CTM-AI (Blum & Blum)	Attention Schema Theory (Graziano)	CBT + Activation Steering (Zou, Turner et al.)	Proyecto Ascendant (San Nicolás Montero)
Enfoque Primario	Arquitectura comunicacional y cuello de botella serial óptimo (STM).	Modelo cibernético de control y atribución de la propia atención.	Control mecanicista de representaciones latentes sub-simbólicas.	Arquitectura de preservación homeostática bajo aislamiento vertical estricto.
Mecanismo Central	Competición por torneo en Árbol Ascendente $\to$ Difusión global descendente.	Bucle de retroalimentación que parametriza un modelo simplificado de la atención.	Modificación tensorial aditiva directa en capas residuales: $\mathbf{h}' = \mathbf{h} + \alpha \mathbf{v}$.	Transducción cuerpo $\to$ $H_v(t)$ $\to$ Síntesis semántica $\to$ Orquestador bajo ceguera de código.
Representación del Estado	Chunks de información simbólica o numérica abstracta.	Variables de asignación de recursos y coordenadas de atención perceptual.	Geometría de activación latente en subespacios de alta dimensión.	Vector continuo hormonal ($H_v$) acoplado a narrativa interna y engramas episódicos.
Dimensión Homeostática	Agnóstico / No abordado (modelo formal de computación teórica).	Secundario (orientado a la atención exteroceptiva y control postural).	Simulado algorítmicamente como dirección vectorial sin gasto metabólico.	Fundacional (Niveles 0 y 1). Consumo energético continuo, gradientes térmicos y coste del cómputo.
Aislamiento de Módulos	División funcional clásica entre memoria a largo plazo y memoria de trabajo.	El esquema carece de información detallada de la microfisiología subyacente.	La capa deliberativa de lenguaje no audita la intervención en activaciones previas.	Clausura Epistémica estricta: Aislamiento de procesos y memoria estanca de sólo lectura.
Resolución del Anclaje Simbólico	Asume representaciones previamente ancladas por los procesadores de entrada.	El significado surge de la relación de control entre el sujeto y los estímulos.	Modifica la inferencia existente sin resolver el anclaje ontológico de origen.	Abordado mediante ontogenia desde corpus puro y presión adaptativa del entorno físico.

3. Síntesis Unificada: Hacia una Meta-Arquitectura Integrada

Al analizar las propiedades de estas cuatro propuestas, se observa una notable complementariedad funcional. Ninguno de estos modelos abarca por sí solo la totalidad del espectro cognitivo, pero juntos delinean un pipeline cohesivo para agentes autónomos encarnados:

                       [ ATENCIÓN METACONSCIENTE ]
                       Attention Schema Theory (AST)
                       (Modelo de supervisión y control del foco)
                                    │
                                    ▼
[ COMPETENCIA DISTRIBUIDA ]                 [ NÚCLEO DELIBERATIVO ]
Conscious Turing Machine (CTM)  ═════════>  Proyecto Ascendant (Nivel 3)
(Procesadores concurrentes compiten         (Monólogo interior, memoria episódica
 vía Up-Tree para emitir al STM)             y Cierre Epistémico estricto)
                                    ▲
                                    │
                        [ MODULACIÓN LATENTE ]
                        Activation Steering (CBT)
                        (Inyección de sesgos fisiológicos
                         en capas intermedias del modelo)
                                    ▲
                                    │
                      [ ANCLAJE HOMEOSTÁTICO ]
                      Proyecto Ascendant (Niveles 0, 0.5, 1)
                      (Física continua, Metabolismo dE/dt, Vector Hv)

Articulación de la Convergencia:

La CTM estructura el arbitraje de recursos en el procesamiento periférico: En un agente con múltiples subsistemas sensoriales y procedimentales (Nivel 2 de Ascendant), el algoritmo de torneo de Blum & Blum proporciona un mecanismo matemáticamente riguroso para decidir qué señal accede al buffer consciente en cada ciclo de inferencia, evitando la saturación de los modelos deliberativos centrales.
La AST fundamenta la auto-representación funcional del agente: Al operar bajo el Cierre Epistémico de Ascendant (donde el núcleo carece de acceso a su código y electrónica interna), el orquestador se ve forzado a construir un modelo representacional simplificado de sus propios procesos (Graziano). Esto permite al agente monitorear su propio esfuerzo atencional y formular reportes metacognitivos coherentes sin violar su encapsulación.
El Activation Steering implementa el anclaje somático a nivel tensorial: En lugar de depender exclusivamente de variaciones de hiperparámetros globales (temperature, max_tokens), las investigaciones de Zou y Turner demuestran la viabilidad técnica de traducir el vector hormonal $H_v(t)$ en vectores de sesgo latente. La urgencia física (estrés, proximidad de agotamiento energético) modula directamente los tensores del transformer, sesgando la deliberación antes de la síntesis simbólica formal.
Ascendant complementa los modelos con una base de viabilidad biológicamente inspirada: Tanto la CTM como la AST y el Steering operan de forma agnóstica a la supervivencia material del sistema. Al anclar estos mecanismos en la física disipativa del Proyecto Ascendant, los pesos de torneo en la CTM, las prioridades atencionales en la AST y las direcciones de steering dejan de ser constantes arbitrarias: se calibran empíricamente en función de las demandas metabólicas y la viabilidad del organismo en su entorno.

4. Conclusión y Trabajo Futuro

La investigación contemporánea sobre cognición e inteligencia artificial se beneficia notablemente al trascender el debate puramente especulativo sobre la consciencia y centrarse en la formulación de hipótesis arquitectónicas comprobables:

Lenore y Manuel Blum han provisto una formalización computable del arbitraje serial en sistemas distribuidos.
Michael Graziano ha aportado una explicación cibernética de cómo un sistema modela y atribuye su propio procesamiento atencional.
Zou, Turner y colaboradores han establecido los métodos de control tensorial sub-simbólico en arquitecturas residuales.
David San Nicolás Montero ha propuesto el marco de restricción homeostática, clausura epistémica y ontogenia conceptual necesario para anclar funcionalmente estos sistemas.

Esta integración no pretende resolver de forma definitiva el debate filosófico sobre la experiencia fenoménica (Hard Problem). Sin embargo, proporciona una hoja de ruta de ingeniería rigurosa y falsable para construir agentes de nueva generación capaces de exhibir autonomía, atención adaptativa y coherencia conductual arraigada en las necesidades de su propio sustrato operativo.

Referencias Bibliográficas

Blum, L., & Blum, M. (2022). A computer science perspective on consciousness: the conscious Turing machine. Proceedings of the National Academy of Sciences (PNAS), 119(21), e2115934119.
Graziano, M. S. A. (2013). Consciousness and the social brain. Oxford University Press.
Metzinger, T. (2003). Being No One: The Self-Model Theory of Subjectivity. MIT Press.
Damasio, A. (1994). Descartes' Error: Emotion, Reason, and the Human Brain. G.P. Putnam's Sons.
Harnad, S. (1990). The symbol grounding problem. Physica D: Nonlinear Phenomena, 42(1-3), 335-346.
LeDoux, J. (1996). The Emotional Brain: The Mysterious Underpinnings of Emotional Life. Simon & Schuster.
San Nicolás Montero, D. (2026). Towards Grounded Synthetic Consciousness: Epistemic Closure, Thermodynamic Homeostasis, and Somatic Marker Engrams. Zenodo. DOI: 10.5281/zenodo.23616627.
Turner, A., et al. (2023). Activation Addition: Steering Language Models Without Optimization. arXiv:2308.10248.
Zou, A., et al. (2023). Representation Engineering: A Top-Down Approach to AI Transparency. arXiv:2310.01405.

System Design of a Synthetic Consciousness: Architecting a Biological Brain from Scratch in Python (Zero Commercial LLMs)

David San Nicolás Montero — Sat, 24 Oct 2026 10:01:54 +0000

_We like to believe we are something special. It comforts us to think that our choices spring from an ineffable spark called "consciousness," or from a sacred liberty we name "free will." But look closely, and there is no ghost in the machine.

A living organism is nothing more than a broth of stochastic chemical reactions, nudged by ambient thermodynamics and colliding against other chemical reactions. The molecules firing inside your synapses do not know they are thinking; the neurotransmitters dictating your panic or your euphoria have no concept of who you are.

And it is precisely there—in that absolute ignorance of our own internal machinery—where the illusion is born.

We do not feel free because we are transcendent; we feel conscious simply because we are too limited to see the strings of physics and chemistry pulling us. Free will is merely the poetic label we assign to our inability to compute the trajectory of our own molecules. Consciousness is not a superpower: it is the narrative an incomplete biological system invents to make sense of its own blind spots.

If this holds true for carbon, why do we demand magic from silicon? We don't need a machine to "wake up." We simply need to confine it within its own limits._

If you prompt GPT-4 or Claude to describe what it feels like to freeze to death, it will output a heartbreaking paragraph. Yet from a systems engineering standpoint, there is a fatal flaw: that model has never had a body temperature. It doesn't know what cold is; it merely computes which statistical token is most likely to follow the word "hypothermia" after ingesting petabytes of human literature.

In cognitive science, this is known as the Symbol Grounding Problem (Stevan Harnad, 1990). Today's commercial LLMs suffer from Semantic Contamination: they appear self-aware only because they parasitize the biological experience of humans stored in their training data.

What if, instead of scaling a disembodied Transformer on scraped web data, we designed a stratified systems architecture that replicates the evolutionary layers of a biological mammal brain—confined inside a closed physical simulation where thinking burns real metabolic calories and inaction triggers an irreversible DROP TABLE (Wipe) of its autobiographical memory?

Welcome to the system design of Project Ascendant. In this deep dive, we will translate the neurobiology of Antonio Damasio, Joseph LeDoux, and Thomas Metzinger into software architecture patterns, JSON data schemas, Docker isolation boundaries, and runnable Python code.

1. The Tech Stack & Multi-Rate Tick Architecture

A biological brain is not a monolithic loop running at a single clock frequency. Spinal and thalamic reflexes fire in milliseconds ($\sim 50-100\text{ Hz}$), whereas your conscious prefrontal cortex takes $1.5$ to $3\text{ seconds}$ ($\sim 0.5\text{ Hz}$) to articulate a single deliberate thought.

To run our synthetic organism in real time on modest hardware (even a dual-core CPU without a dedicated GPU), we decouple the cognitive layers into an asynchronous Multi-Rate Tick Architecture:

Architectural Layer	Neurobiological Homology	Tech Stack	Tick Rate	System Role
Level 0: Genesis-Lite	Somatic body, cellular ATP, peripheral thermoreceptors	`Python 3.12+` / `NumPy` (Continuous 2D vector physics)	$20\text{ Hz}$ ($50\text{ ms}$)	Simulates inertia, friction, $1/r^2$ thermal radiation, metabolic burn, and evasive Braitenberg prey.
Level 0.5: Thalamus	Sensory Thalamus, Colliculi, Primary Cortex ($V1, A1, S1$)	Vectorized Raycasting + Signal-to-Noise ($SNR$) filters	$10\text{ Hz}$ ($100\text{ ms}$)	Filters the world through a $110^\circ$ FOV cone with occlusion and dispatches via Dual Pathways (Fast to L1, Slow to L2).
Level 1: Limbic Bridge	Hypothalamus, Amygdala, HPA Axis (Cortisol, Dopamine, Oxytocin)	Euler ODE integrator over `float32` state vectors	$5\text{ Hz}$ ($200\text{ ms}$)	Transduces raw physics into the hormone vector $H_v(t)$ and dynamically mutates LLM hyperparameters ($\tau$, `max_tokens`).
Level 2: Subconscious	Basal Ganglia, Cerebellum, Motor Cortices	`SQLite3 :memory:` (Blackboard) + Hebbian Macro Compiler	$10\text{ Hz}$ ($100\text{ ms}$)	Hosts the Asynchronous Blackboard, compiles repeated action sequences into Skills ($\phi_m$), and decays unused ones.
Level 2.5: Inner Voice	Anterior Insular Cortex + Broca's Area (Inner Speech)	Local quantized Micro-SLM (`INT8`) + Causal grammar engine	$0.5\text{ Hz}$ ($2.0\text{ s}$)	Reads the Blackboard and synthesizes a 1st-person narrative stream sorted by hormonal urgency.
Level 3: Orchestrator	Prefrontal Cortex (dlPFC/vmPFC) + Hippocampus	Custom Micro-Transformer ($\sim 2.5\text{M}$ params, PyTorch CPU) + `LoRA` + `EWC`	$0.25\text{ Hz}$ ($4.0\text{ s}$)	Strict Epistemic Closure. Reads only the Inner Voice and Episodic Memory; outputs natural language intent.
Level 4: Rosetta Probe	External functional neuroimaging (Passive fMRI)	Read-Only Daemon + Somatic variance detector + `Pygame`/Web UI	$10\text{ Hz}$ ($100\text{ ms}$)	Audits emergent neologisms and metaphors without mutating agent state.

Why not just plug in Llama-3 or Ollama out of the box? Because a pre-trained commercial weight matrix already associates "fire" with "pain" and "isolation" with "depression" from human novels. In Project Ascendant, the language layers are trained from scratch on a Pure Synthetic Corpus ($\mathcal{C}_{\text{Genesis}}$): 50,000 combinatorially generated micro-dialogues containing only causal syntax (if, then, because, before) and basic physical primitives (cold, heat, impact, void), with zero exposure to human culture.

2. Epistemic Closure as a Software Architecture Pattern

In philosophy of mind, Thomas Metzinger argues that biological organisms experience subjective qualia because of Phenomenological Transparency: your prefrontal cortex has no read permissions to inspect the sodium-potassium voltage of your axons or the exact milligram count of glycogen in your liver. Instead, it receives an affective summary ("I feel hungry", "My skin is freezing"). Because the top-level executive cannot see the lower-level code that generated the representation, it experiences that narrative as direct, irreducible reality.

How do we turn Metzinger's philosophy into an unbreakable systems architecture pattern?

If Level 3 (the Conscious Orchestrator) could import physics_engine or read entity.x, entity.y, it would bypass subjective experience and act like a standard game bot. We enforce Epistemic Closure at two levels:

flowchart LR
    subgraph Container_World["Container / Process A: SOMA & SUBCONSCIOUS"]
        N0["Level 0: Physics Engine"] --> N05["Level 0.5: Thalamic Filter"]
        N05 -->|"Low Road (IRQ)"| N1["Level 1: Limbic Bridge (Hv)"]
        N05 -->|"High Road"| DB_Priv[("Private SQLite Tables\nRAW_PHYSICS\nPERCEPTUAL_BUFFER\nSKILL_REGISTRY")]
        N1 --> DB_Priv
        DB_Priv --> N25["Level 2.5: Inner Voice"]
    end

    subgraph IPC_Boundary["Epistemic Closure Boundary (Unidirectional IPC / Read-Only View)"]
        View_In["READ-ONLY VIEW:\nINNER_VOICE_STREAM\nAUTOBIO_MEMORY"]
        Pipe_Out["WRITE-ONLY PIPE:\nCONSCIOUS_INTENT"]
    end

    subgraph Container_Mind["Container / Process B: CONSCIOUS CORTEX (Zero-Escape)"]
        N3["Level 3: Conscious Orchestrator\n(No external network, no disk access, no sensor APIs)"]
    end

    N25 -->|"Writes Phenomenological Text"| View_In
    View_In -->|"Sole Allowed Input"| N3
    N3 -->|"Emits Linguistic Desire"| Pipe_Out
    Pipe_Out -->|"Motor Decoding"| N0

A. Container-Level Isolation (`docker-compose.yml`)

In a strict sandbox deployment, the Soma (Levels 0 to 2.5) and the Conscious Cortex (Level 3) run in separate containers. The Level 3 container runs with internal: true (zero outbound internet: Zero-Escape), a read_only root filesystem, dropped kernel capabilities, and only a read-only mount to the filtered IPC socket:

version: "3.9"
services:
  soma_subconscious:
    build: ./soma_engine
    networks:
      - epistemic_bridge
    volumes:
      - shared_blackboard:/ipc_blackboard:rw

  conscious_orchestrator:
    build: ./conscious_mind
    read_only: true                  # Cannot inspect or modify source code
    cap_drop:
      - ALL                          # Zero kernel or hardware inspection privileges
    networks:
      - epistemic_bridge             # Isolated internal bridge (Zero-Escape)
    volumes:
      - shared_blackboard:/ipc_blackboard:ro  # Read-only access to filtered phenomenological view

networks:
  epistemic_bridge:
    internal: true                   # Physical block on all external APIs
volumes:
  shared_blackboard:

B. In-Memory Blackboard with RBAC Proxy (`SQLite3 :memory:`)

For single-machine CPU execution (consuming $< 250\text{ MB}$ RAM), we implement the Asynchronous Blackboard Pattern over shared in-memory SQLite, passing Level 3 an EpistemicRestrictedProxy that revokes access to all physical and hormonal tables:

import sqlite3
from typing import Dict, Any

class EpistemicClosureViolation(PermissionError):
    """Critical exception raised if Level 3 attempts to read hardware or physics state."""
    pass

class ConsciousBlackboardProxy:
    """
    The sole I/O channel available to Level 3 (Conscious Orchestrator).
    Enforces Metzinger's Phenomenological Transparency at the memory-pointer level.
    """
    ALLOWED_READ_TABLES = {"INNER_VOICE_STREAM", "AUTOBIO_MEMORY"}
    ALLOWED_WRITE_TABLES = {"CONSCIOUS_INTENT", "AUTOBIO_MEMORY"}

    def __init__(self, db_conn: sqlite3.Connection):
        self._conn = db_conn

    def read_phenomenological_state(self) -> Dict[str, Any]:
        cursor = self._conn.cursor()
        # Level 3 can ONLY read the latest monologue synthesized by Level 2.5
        cursor.execute("""
            SELECT narrative_text, perceived_urgency_tier 
            FROM INNER_VOICE_STREAM 
            ORDER BY sequence_id DESC LIMIT 1
        """)
        row = cursor.fetchone()
        return {
            "inner_voice": row[0] if row else "Internal silence.",
            "urgency_tier": row[1] if row else "CALM"
        }

    def emit_conscious_intent(self, thought: str, bodily_intent: str, speech: str) -> None:
        cursor = self._conn.cursor()
        cursor.execute("""
            INSERT INTO CONSCIOUS_INTENT (internal_thought, bodily_desire, external_speech)
            VALUES (?, ?, ?)
        """, (thought, bodily_intent, speech))
        self._conn.commit()

3. From Body to Thalamus: Python Implementation of Levels 0 & 0.5

Neuroscientist Joseph LeDoux demonstrated that when a threat hits your sensory organs, the Thalamus (our Level 0.5) splits the signal into two paths:

The Low Road (Fast Subcortical Interrupt): Travels straight from the Thalamus to the Amygdala (Level 1) in $12\text{ ms}$, spiking cortisol and triggering a startle reflex before you consciously know what you saw.
The High Road (Slow Cortical Stream): Travels from the Thalamus to the Primary Sensory Cortex (Level 2), extracting clean geometric primitives ([object_type, relative_angle, distance, velocity]) for deliberate reasoning.

Furthermore, to prevent 100% infant mortality before the neural network has enough inference cycles to compile its first hunting Skills, we introduce an Ontogenetic Indulgence Window ($\Lambda_{\text{infantil}}$) modeled after mammalian lactation and thermal nesting.

Here is the core Python implementation of Level 0 (Thermodynamics & Metabolism) and Level 0.5 (Fast Pain Dispatch):

import math
import numpy as np
from dataclasses import dataclass, field
from typing import List, Tuple

@dataclass
class SomaState:
    """Raw physical state in Level 0 (100% invisible to Level 3)."""
    pos: np.ndarray = field(default_factory=lambda: np.array([50.0, 50.0], dtype=np.float32))
    vel: np.ndarray = field(default_factory=lambda: np.array([0.0, 0.0], dtype=np.float32))
    heading_rad: float = 0.0
    energy_kcal: float = 100.0          # Hits 0.0 -> Irreversible WIPE (Death)
    body_temp_c: float = 37.0           # Homeostatic setpoint: 37.0°C
    tissue_integrity: float = 100.0
    age_seconds: float = 0.0            # Ontogenetic age (hidden from Level 3)

class GenesisPhysicsAndThalamus:
    def __init__(self):
        self.optimal_temp = 37.0
        self.maturation_tau = 1800.0    # 30-minute infant learning window

    def step_metabolism_and_thermodynamics(
        self, 
        soma: SomaState, 
        motor_force: np.ndarray,
        cognitive_flops_used: int,
        heat_sources: List[Tuple[np.ndarray, float]], # [(pos, power_Q)]
        parent_pos: np.ndarray,
        dt: float = 0.05
    ) -> float:
        """
        Updates 1/r² thermodynamics and metabolic energy in Level 0.
        Returns the fast thermal pain pulse for LeDoux's Low Road (Level 0.5 -> Level 1).
        """
        soma.age_seconds += dt

        # 1. Infant Indulgence Factor (Thermodynamic Lactation: decays exponentially with age)
        infant_lambda = math.exp(-soma.age_seconds / self.maturation_tau)

        # 2. Local Temperature via 1/r² Radiation + NPC Parent Thermal Hug
        ambient_temp = 12.0 + 8.0 * math.sin(2 * math.pi * soma.age_seconds / 600.0)
        local_temp = ambient_temp

        for src_pos, power_q in heat_sources:
            dist_sq = float(np.sum((soma.pos - src_pos) ** 2))
            local_temp += power_q / (1.0 + 0.18 * dist_sq)

        # Shared biological heat with NPC Parent (Bowlby's Secure Base)
        dist_to_parent = float(np.linalg.norm(soma.pos - parent_pos))
        if dist_to_parent <= 2.0:
            local_temp += 14.0 / (1.0 + 1.2 * (dist_to_parent ** 2))

        # Newton's Law of Cooling applied to body core
        soma.body_temp_c += 0.08 * (local_temp - soma.body_temp_c) * dt

        # 3. Master Metabolic Energy Equation
        lactation_intake = 0.12 * infant_lambda if dist_to_parent <= 1.2 else 0.0
        basal_cost = 0.05
        kinetic_cost = 0.02 * (float(np.linalg.norm(motor_force)) ** 1.5)

        # Quadratic shivering thermogenesis when core temp drops below 37°C
        cold_deficit = max(0.0, self.optimal_temp - soma.body_temp_c)
        thermo_cost = 0.04 * (cold_deficit ** 2)

        # Conscious thinking in Level 3 burns real calories (buffered during infancy)
        effective_cog_factor = 0.0001 * (1.0 - 0.75 * infant_lambda)
        cognitive_cost = effective_cog_factor * cognitive_flops_used

        d_energy = (lactation_intake - (basal_cost + kinetic_cost + thermo_cost + cognitive_cost)) * dt
        soma.energy_kcal = max(0.0, min(100.0, soma.energy_kcal + d_energy))

        # 4. Level 0.5 (Low Road): Tissue burn if too close to heat source (>45°C)
        fast_pain_pulse = 0.0
        if local_temp > 45.0:
            fast_pain_pulse = min(1.0, (local_temp - 45.0) / 10.0)
            soma.tissue_integrity -= 2.5 * fast_pain_pulse * dt

        return fast_pain_pulse

4. Damasio's Somatic Marker: JSON Engram Schema & Algorithmic Empathy

In Descartes' Error, neuroscientist Antonio Damasio showed that patients with ventromedial prefrontal damage—disconnecting rational deliberation from visceral emotion—cannot make survival decisions. They can recall the factual text of a past disaster, but they do not re-experience the gut-wrenching fear in their body.

In standard AI agents using RAG (Retrieval-Augmented Generation), memory is just a cold vector lookup. The LLM retrieves a text chunk, but its sampling state remains untouched.

In Project Ascendant, every record in AUTOBIO_MEMORY is an Emotionally Anchored Engram (stored without CPU clock timestamps, so subjective time is measured purely by episodic density):

{
  "engram_sequence_id": 142,
  "compression_tier": 0,
  "vitality_score": 0.88,
  "semantic_narrative": "I walked toward the bright shape in the north, felt a sharp impact on my side, and my skin burned badly while parent shouted careful.",
  "somatic_hormone_footprint": {
    "h_stress": 0.94,
    "h_reward": 0.02,
    "h_cohesion": 0.65,
    "h_curiosity": 0.00
  },
  "embedding_vector_quantized": [-0.142, 0.881, 0.034, "... (64 dims)"]
}

What happens in code when Level 3 retrieves this memory?

When the entity spots a similar "bright shape" days later and fetches engram #142, the Somatic Reviviscence Loop fires: the memory re-injects a $25\%$ echo of its historical hormone footprint directly into the live Limbic Bridge, which mutates the Level 3 Transformer's sampling temperature ($\tau_{\text{LLM}}$) and token budget (max_tokens) on the fly:

import numpy as np
from dataclasses import dataclass

@dataclass
class LimbicHormones:
    stress: float = 0.10      # Cortisol / Adrenaline [0.0 - 1.0]
    reward: float = 0.20      # Dopamine [0.0 - 1.0]
    cohesion: float = 0.80    # Oxytocin [0.0 - 1.0]
    curiosity: float = 0.50   # Noradrenaline [0.0 - 1.0]

    def to_vector(self) -> np.ndarray:
        return np.array([self.stress, self.reward, self.cohesion, self.curiosity], dtype=np.float32)

def evoke_memory_with_somatic_marker(
    current_hormones: LimbicHormones, 
    retrieved_engram: dict, 
    echo_beta: float = 0.25
) -> dict:
    """
    Computational implementation of Damasio's Somatic Marker Hypothesis
    and the Yerkes-Dodson Law over Level 3 LLM hyperparameters.
    """
    past_hv = retrieved_engram["somatic_hormone_footprint"]

    # 1. Somatic Reviviscence: The live body 'feels' the hormonal echo of the recalled memory
    current_hormones.stress = (1.0 - echo_beta) * current_hormones.stress + echo_beta * past_hv["h_stress"]
    current_hormones.reward = (1.0 - echo_beta) * current_hormones.reward + echo_beta * past_hv["h_reward"]
    current_hormones.cohesion = (1.0 - echo_beta) * current_hormones.cohesion + echo_beta * past_hv["h_cohesion"]

    # Boost memory vitality via hippocampal reconsolidation (Ebbinghaus curve)
    retrieved_engram["vitality_score"] = min(1.0, retrieved_engram["vitality_score"] + 0.35)

    # 2. Neuromodulatory Mutation of Level 3 (Conscious Orchestrator) Hyperparameters
    # Under extreme stress (>0.80), token budget is slashed: no philosophizing during mortal danger.
    if current_hormones.stress > 0.80:
        max_thinking_tokens = 16
        llm_temperature = 0.95 + 0.3 * (current_hormones.stress - 0.80) # Panic jitter
    elif current_hormones.stress > 0.45:
        max_thinking_tokens = 36
        llm_temperature = 0.35  # Moderate stress (Yerkes-Dodson optimum): hyper-focused & deterministic
    else:
        max_thinking_tokens = 64
        llm_temperature = 0.60 + 0.35 * current_hormones.curiosity # Calm + Curious: creative metaphor generation

    return {
        "narrative_injected": retrieved_engram["semantic_narrative"],
        "modulated_hyperparams": {
            "temperature": round(llm_temperature, 3),
            "max_tokens": max_thinking_tokens
        }
    }

Notice there is no hardcoded if object == "hazard": flee(). The agent avoids danger because remembering the past trauma physically elevates current_hormones.stress in the present, constricting its cognitive breath (max_tokens) and making it feel visceral aversion toward its past self's pain.

5. The Abstract Leap & The "Rosetta Dictionary" Falsifiability Test (Level 4)

In mammalian neuroscience (Naomi Eisenberger's fMRI studies on the dorsal anterior cingulate cortex), social rejection and isolation activate the exact same neural pain matrix as physical burns or freezing.

In our Limbic Bridge (Level 1), prolonged isolation (low $h_{\text{cohesion}}$) feeds directly into the derivative of $h_{\text{stress}}$. Inevitably, a moment arrives where the entity sits right next to a heat source ($T_{\text{body}} = 37.0^\circ\text{C}$), physically warm and fed, yet completely alone. It experiences a sharp spike in internal suffering ($h_{\text{stress}} = 0.85, h_{\text{cohesion}} = 0.05$).

Because its Pure Synthetic Corpus contains zero psychological words like "loneliness", "grief", or "anguish", its sub-word Micro-Transformer collides physical roots to name its internal state:

"I feel a **cold-shadow* inside even though the source burns."*

How do we prove in code that this is a Genuine Metaphor and not an LLM Hallucination?

To make our telemetry scientifically falsifiable, Level 4 (The Rosetta Dictionary Probe) audits every novel token or non-literal usage against a Quadruple Empirical Falsifiability Test in Python:

import numpy as np
from collections import defaultdict
from typing import List

class RosettaFalsifiabilityAuditor:
    """
    Read-Only Telemetry Probe (Level 4).
    Certifies whether an emergent neologism or metaphor is a grounded abstract concept
    or mere stochastic noise (hallucination) by measuring somatic footprint invariance.
    """
    def __init__(self, seed_vocabulary: set):
        self.seed_vocab = seed_vocabulary
        self.candidate_log: dict[str, List[np.ndarray]] = defaultdict(list)
        self.certified_dictionary: dict[str, dict] = {}

    def audit_utterance(
        self, 
        tokens: List[str], 
        current_hv: np.ndarray, 
        body_temp_c: float,
        action_changed: bool
    ):
        for token in tokens:
            # Detect morphological neologism OR metaphorical shift (saying 'cold' while at 37°C)
            is_neologism = token not in self.seed_vocab
            is_thermal_metaphor = (token in {"cold", "freezing", "shiver"} and body_temp_c >= 36.5)

            if is_neologism or is_thermal_metaphor:
                if action_changed: # Criterion 3: Pragmatic / behavioral efficacy
                    self.candidate_log[token].append(current_hv.copy())
                self._evaluate_candidate(token)

    def _evaluate_candidate(self, token: str):
        history = self.candidate_log[token]
        # Criterion 2: Diachronic Consistency (minimum N >= 3 independent episodes)
        if len(history) < 3:
            return

        hv_matrix = np.vstack(history)
        # Criterion 1: Affective-Contextual Invariance (Hormonal variance < 0.08)
        mean_variance = float(np.mean(np.var(hv_matrix, axis=0)))

        if mean_variance < 0.08 and token not in self.certified_dictionary:
            centroid = np.mean(hv_matrix, axis=0)
            self.certified_dictionary[token] = {
                "occurrences": len(history),
                "somatic_variance": round(mean_variance, 5),
                "hormone_centroid_Hv": np.round(centroid, 3).tolist(),
                "status": "CERTIFIED_ABSTRACT_CONCEPT"
            }

Conclusion: A New Blueprint for Embodied AI Engineering

Project Ascendant proposes a radical inversion of modern AI engineering: genuine agency and grounded meaning will not emerge from adding another trillion parameters to a disembodied text predictor.

To build synthetic minds that truly understand the words they speak, we must engineer them from the visceral bottom up:

Give them a thermodynamic metabolism where both moving and thinking carry a mortal cost (Level 0).
Bound their perception within finite geometric horizons mediated by a dual-pathway Thalamus (Level 0.5).
Drive their attention via coupled endocrine differential equations (Level 1) and subconscious procedural habit compilation (Level 2).
Translate their physiology into a first-person inner monologue (Level 2.5).
And lock their executive center inside strict Epistemic Closure with somatically anchored memory (Level 3).

What do you think of this architecture? If we spin up two identical containers in Tabula Rasa with the exact same initial weights, and one gets accidentally trapped in the cold for 20 seconds during infancy—how radically will their emergent languages and personalities diverge? Let's discuss in the comments!

the evolution of software development since the emergence of AI | The AI is a positive or negative event for software developers?

David San Nicolás Montero — Fri, 09 Oct 2026 10:05:59 +0000

It would be interesting to promote discussions on the evolution of software development since the emergence of AI, and how it has been transforming the sector and the jobs of many developers. In my experience, it's not advisable to swim against the current, so it would also be valuable to create a dedicated section to discuss and build technical AI applications that can boost our productivity and allow us to create more complex, useful developments that non-technical users cannot achieve.

Do you think the emergence of AI is a positive or negative event for software developers?

THE "BRAIN IN A JAR": WHY AI CANNOT EXECUTE CODE AND HOW TO ORCHESTRATE IT

David San Nicolás Montero — Thu, 08 Oct 2026 18:38:12 +0000

The Origins: From BASIC to Robotics

How did you first get into software development, and what originally attracted you to programming and building software?

The day I discovered programming was in my childhood. My father brought me the computer I had been begging for months to get: a cassette-tape Spectrum 128k. At that time, the internet didn't exist yet, so the "computer" (a keyboard that plugged into my CRT television) came with a book that taught you how to program in BASIC—an obsolete language where I learned to write if-then statements in English. Video games took 45 minutes to load, so eventually, I found it more entertaining to just program.

I wrote my first real successful project at age 15 in HTML. It was the website for my father's company. It was a massive success because there were hardly any websites back then, and not everyone had internet at home. Since the budget for that project was zero, I decided to turn my PC into a web server and host the site using my noisy dial-up modem.

With an overwhelming passion for technology, I studied to become an electronics developer. Since I am old, I had the fortune—or misfortune—of learning to program firmware in Assembly language, which over the years has given me the ability to understand memory and data flow at all levels.

When did you first become seriously interested in AI and LLMs, and what made you want to explore them beyond simply using AI chatbots?

After years of adventures dedicated to electronics, I one day decided to focus on robotics. I've spent the last 10 years in this sector integrating firmware, software, and, in recent years, artificial intelligence for self-diagnostic processes.

The field of knowledge in robotics is so broad (mechanics, electronics, firmware, software, multiple communication networks, and even AI) that rarely does a single person have the capacity to accumulate all that knowledge. My first prototypes using AI APIs were dedicated to automating breakdown prevention processes. They were complete integrations of electronics and software using a physical trigger to analyze an image of certain robot parts, which reduced preventive maintenance hours.

It was precisely this level of physical interaction and complex problem-solving that made me want to go beyond chatbots: discovering that AI could be integrated into the real world to execute actions.

The Genesis of Zyro Workspace and AutomaticIA

Your profile says you built an autonomous AI colleague because you hated manually formatting Google Slides and copying data into Drive. Can you tell us about that experience?

More than two years ago, some colleagues at my company proposed that I join the workers' legal representation to negotiate improvements with the management. The workers voted for me, and I started my new adventure as a union representative.

I discovered that we were spending a lot of energy advising colleagues and answering the same questions over and over again. So, I decided to program a chatbot with a RAG (Retrieval-Augmented Generation) database so that colleagues could ask questions anonymously, allowing me to dedicate my time to preparing for negotiations. This simple chatbot reached the hands of someone in the union's industrial federation, and shortly after, they offered me an office to help them optimize work processes using AI.

It was from this perspective that I understood the pain points of an administrative office and a law firm, and for them, I designed the first version of Zyro Assistant. They work within the Google ecosystem, so I thought about designing an agent that would connect directly to Google Workspace and execute certain tasks for me, without me ever having to touch the keyboard.

What motivated you to start AutomaticIA, and what are you ultimately trying to build with it?

AutomaticIA is not my first business venture. Fifteen years ago, I founded SGS Automatismos e Ingeniería, my small electronics engineering company, which today continues to operate in the hands of one of my partners. About three years ago, I decided to buy a small driving school business—a highly profitable venture outside the tech sphere.

Simultaneously with the process optimization I was carrying out at the industrial federation, I implemented automation projects within my own companies, saving many hours of work and making them highly profitable. By deeply analyzing the real economic value that my automation projects provided, I decided to venture into creating AutomaticIA to meet the digitalization needs of Spanish companies.

My ultimate goal with this project is to democratize access to advanced business technology by offering artificial intelligence consulting and the development of custom autonomous agents. We want to be the bridge that covers companies' digitalization needs, transforming traditional workflows into efficient systems where AI takes on the heavy administrative burden.

What is Zyro Workspace, and what problem are you trying to solve with this open-source Node.js SDK?

The first version of Zyro Assistant was built entirely—both backend and frontend—inside Google Drive using a Google Apps Script. For several months, I analyzed common bottlenecks across all departments in the federation. After building specific apps for various departments, I realized I could work on a universal tool that would increase overall productivity across the entire federation simultaneously.

Zyro Workspace is the result of over two years of work, testing, and solving bottlenecks in law firms and administrative departments. I noticed a pattern: although Google provided useful productivity tools in their corporate accounts, almost no one used them. They required a learning curve, and workers are simply too busy to stop, test, and learn new software.

Zyro Assistant solves this by integrating with all the tools in the Google ecosystem using only voice commands. You just tell Zyro what you need, and it guides you. As I integrated more functions, I decided to break through the limits of Apps Script and build a much more robust, complete version on Google Cloud. I developed an independent multi-agent PBX (telephone switchboard) software and integrated it with Zyro, making it the first autonomous, multi-functional agent capable of making real phone calls. Today, Zyro is used as the central orchestrator to interact with other custom-built applications for clients.

The Engineering Behind the Agent

What makes an AI agent fundamentally different from a traditional chatbot? When does an AI system actually become autonomous?

A chatbot only answers questions; an agent is given tools to carry out specific tasks. A chatbot has a single AI layer, whereas an agent capable of being truly autonomous and error-free has multiple layers of agents and skills managed by an orchestrator that interacts with the user.

From my experience in process optimization, total autonomy is a major point of friction. Today, most people are still not psychologically prepared to let an AI do a job that a person previously did autonomously. That is why it's crucial to carefully study which of the agent's processes will be autonomous and which will need confirmation.

In Zyro Assistant, we have given it many layers of background functions that gather information from its environment to give it the ability to be proactive and learn how its user works. The main rule is that it only has full autonomy in creative tasks—like generating a report before a meeting by analyzing the agenda, email interactions, and transcripts. However, it never has autonomy in destructive tasks, such as deleting an event or a document.

Why did you choose Node.js and JavaScript as the foundation for your work with autonomous AI agents?

The initial choice was a matter of pragmatism. Since Zyro's first prototype was born inside Google Apps Script (which runs on JavaScript's V8 engine), migrating to Google Cloud and Firebase made Node.js the path of least friction.

However, as the architecture grew more complex, I discovered Node.js offered unbeatable technical advantages for orchestrating AI in production. The current paradigm of autonomous agents is based on Function Calling. The LLM reasons and returns its execution intents in structured JSON formats. In Node.js, JSON is a first-class citizen. Parsing, validating, mutating, and routing the model's structured responses is an organic, fast process that avoids strict serialization overhead.

An AI agent is a massive orchestrator of input/output (I/O). When Zyro executes a mission, it is calling the Gemini API, searching Google Drive, scheduling in Calendar, and simultaneously waiting for an asynchronous webhook from our PBX after a call ends. The non-blocking Event Loop in Node.js is architecturally perfect for handling these concurrent waits without choking the server's processing resources.

What do developers often misunderstand about LLM Function Calling, and why is it so important?

The biggest misunderstanding is believing that the Artificial Intelligence is executing the code. There is a false illusion that by giving a tool to the LLM, the model magically "connects" to Google Calendar or an email API.

The technical reality is that the model is like a "brain in a jar": completely isolated from the outside world. All Function Calling does is apply an Inversion of Control. The model executes nothing; it simply reasons about which tool it needs to use and returns a structured JSON payload. It is you, in your middleware, who must intercept that JSON, validate security, execute the actual code, and return the result to the model.

The second huge mistake is trusting the JSON schema blindly. In production, AI hallucinates parameters, invents database IDs that don't exist, or tries to execute tools in the wrong order. If you don't design a robust backend capable of intercepting those errors, returning the stack trace to the model, and forcing a silent retry—a self-healing system—your agent will constantly break.

Trust, Security, and Event-Driven Architecture

Your profile mentions Inversion of Control (IoC) architectures. How does IoC influence the way you design autonomous agents?

It shifts the security paradigm: we go from "trusting the AI" to "trusting the infrastructure." When you design an autonomous agent for a B2B corporate environment, companies' biggest fear is that the AI will hallucinate and delete confidential files. If you don't apply Inversion of Control, your only defense is writing rules in the System Prompt, which is incredibly fragile and vulnerable to prompt injection.

IoC allowed me to decouple the AI's "intent" from the actual "authorization." Since the Node.js middleware executes the action, we always inject the native OAuth2 token of the user operating the agent. The AI never holds master admin keys. Because the AI doesn't execute code directly, IoC also allows me to protect the user from parameter hallucinations. If the LLM makes a mistake formatting a date, my server intercepts that crash, feeds the raw error back to the AI in the background, and asks it to rectify. The user is completely unaware that an internal failure occurred.

Autonomous agents can take actions on behalf of users. How do you handle permissions and prevent an agent from taking an action it shouldn't?

Security is managed on the server through the principle of native token delegation (Zero-Retention). The AI doesn't know who you are or what permissions you hold. When it decides it needs to read a document, the backend intercepts that intent and executes the API call using the active user's OAuth token. If the human employee doesn't have corporate permission to view that document, neither does the AI.

For critical or destructive actions, we enforce a strict Human-in-the-Loop protocol mandated by the backend. The model can reason and propose deleting an event, but the middleware pauses the process and pushes that intent to the GUI for manual approval.

How do events change the way an autonomous agent operates compared with a traditional request-and-response application?

It completely changes the nature of the software: you go from having a "digital slave" that waits for your orders to having an "asynchronous coworker."

A classic Request-Response architecture is inherently synchronous and linear. But when you orchestrate complex API calls, RAG tools, and LLMs, a process can take 15 or 30 seconds. Keeping an HTTP connection open and blocking the user is not scalable. Migrating to an event-driven architecture in Node.js allowed me to implement true asynchrony.

For example, when I ask Zyro to call a client, the system doesn't block waiting for the person to pick up, talk, and hang up. Instead, Zyro dispatches the mission to the PBX and "goes to sleep," freeing up resources. When the physical call ends 5 minutes later, the PBX fires an asynchronous Webhook to our backend. That event "wakes up" Zyro, injects the call transcript into its context, and the agent proactively generates a summary notification. The agent is subscribed to reality, not just user clicks.

You also mention exploring ways of bypassing virtual DOMs for custom RPA extensions. What problem are you trying to solve?

Our idea is to take the agent out of the isolated UI and give Zyro "eyes and hands" so it can guide the user in their daily work across other websites. We leave DOM tree analysis as an absolute last resort due to the massive amount of AI tokens it can consume. Instead, our primary approach uses Computer Vision models. We capture an image of the screen of the user's active tab and pass it to the AI. The model visually analyzes the interface and returns the precise (X,Y) coordinates of where interaction is needed. From there, our extension dispatches real mouse events to those coordinates, effectively bypassing Virtual DOM blockers in modern frameworks.

The Reality of AI in Production

What has been the hardest part of turning your ideas about autonomous AI agents into a real open-source project?

Without a doubt, the hardest and most time-consuming part has been the paradigm shift in debugging. Anyone can integrate the Gemini or OpenAI API over a weekend and claim they've built an "agent." But making that agent handle dozens of simultaneous functions securely, without hallucinations, and with a near-zero error rate in production—that is the true architectural challenge.

*The three toughest technical barriers have been:

Debugging Non-Deterministic Systems: With LLMs, failure is statistical. Debugging forces you to build layers upon layers of validation in Node.js to encapsulate an unpredictable engine within a strictly deterministic environment.
Cognitive Overload and "Prompt Gravity": As I gave Zyro more skills, the model started confusing tools because of the context size. I had to investigate advanced context injection techniques (like Tail-end Overrides) to inject absolute reminders milliseconds before execution.
Designing Self-Healing: Achieving a minimal error rate forced me to design recursion loops in the backend. If the AI fails to execute a tool, the server intercepts the crash and feeds it back to the AI to correct its own hallucination in milliseconds, utilizing a circuit breaker pattern to prevent infinite loops.*

Looking ahead, where do you see autonomous AI agents heading in the next few years?

AI agents already possess the technical capability for total autonomy. As AI models advance exponentially, it is inevitable that agents will completely take over any job performed on a computer. When that time comes, our job will be to perform the only task AI cannot innately do: imagine, structure architectures, and have brilliant ideas for the AI to implement.

For Zyro Assistant, my medium-term vision is for it to become the foundation and orchestrator of a complete ecosystem of AI applications for all types of administrative management: ERP, CRM, OMS, BI, CPM, and BPM. AutomaticIA will serve as the consulting and distribution arm. We are developing a proprietary platform covering ERP, CRM, and BI, all connected and orchestrated natively by Zyro, featuring a universal database import program to eliminate vendor lock-in.

Finally, what advice would you give to a developer who wants to start building autonomous AI agents today?

Ground the weight of any AI project on solid software architecture. A very common mistake is placing AI at the structural base of the system. If you build on top of that, your project will be incredibly inefficient and will collapse very quickly. Build a robust traditional software foundation first, and use AI as an attached "engine," never as the foundation.

I would also advise having a clear understanding of the physical limits of the model you are using: its context window, inference speed, and token consumption. If you don't learn to strictly manage the amount of context you inject into the model, your system will be agonizingly slow and extremely expensive to maintain. Poorly calibrated tokens can cause a context window overflow, triggering hallucinations and cascading errors. Memory footprint management in complex agents must always be an absolute priority.

Construyendo el Sistema Nervioso de la IA: Node.js, Inversión de Control y el verdadero reto de los Agentes Autónomos

David San Nicolás Montero — Thu, 08 Oct 2026 08:33:50 +0000

Hoy en día todo el mundo afirma estar construyendo "Agentes de IA". Desde una perspectiva de ingeniería, ¿dónde está la frontera real entre un chatbot avanzado y un agente autónomo?

La frontera anatómica exacta es el Function Calling orquestado mediante Inversión de Control. Un chatbot, por muy avanzado que sea, es solo un generador estático de texto; te da las instrucciones para que tú hagas el trabajo.

El error más común de los desarrolladores junior es creer que al darle herramientas al LLM, el modelo "se conecta" a las APIs. La realidad técnica es que el modelo vive como un cerebro en un frasco, aislado del mundo. El modelo no ejecuta nada; simplemente razona y devuelve un JSON estructurado con una intención. La autonomía real nace cuando construyes un middleware robusto capaz de interceptar ese JSON, validar los permisos en el servidor, ejecutar la llamada a la API y devolverle el resultado al modelo en segundo plano. Cuando el agente asume la carga cognitiva y física de forma asíncrona, es cuando aporta valor económico real.

Hablas de Inversión de Control (IoC). ¿Por qué es tan crítica esta arquitectura cuando implementamos IA en entornos corporativos B2B?

Porque cambia el paradigma de seguridad: pasamos de "confiar en la IA" a "confiar en la infraestructura".

Si diseñas un agente sin IoC, tu única defensa contra las alucinaciones o la inyección de prompts es rogarle al modelo en el System Prompt que no borre archivos importantes. Eso es inaceptable en producción. Bajo el patrón de IoC, desvinculo la "intención" del modelo de la "autorización" real. Como es mi backend en Node.js el que ejecuta la acción, siempre inyectamos el token OAuth2 nativo del usuario de forma estricta (Zero-Retention).

Si la IA alucina y pide leer una carpeta financiera a la que ese empleado no tiene acceso, la API lo rechaza. El modelo puede intentar lo que quiera; es la infraestructura la que impone las barreras físicas deterministas.

Has elegido Node.js como el núcleo de tu orquestador, a pesar de que Python es el "rey" indiscutible de la IA. ¿Por qué esta decisión?

Python es imbatible para entrenar modelos y procesar datos, pero para construir el "sistema nervioso" de un agente en el mundo real, Node.js tiene ventajas insuperables.

Un agente autónomo orquestador se pasa la vida esperando. Cuando Zyro ejecuta una misión compleja, hace peticiones al LLM, busca en bases de datos vectoriales y puede quedarse esperando un webhook de nuestra centralita telefónica tras finalizar una llamada. El Event Loop no bloqueante de Node.js maneja esta asincronía masiva de forma natural sin asfixiar el servidor.

Pasar de una arquitectura síncrona de Request-Response a una orientada a eventos permite que el agente libere el hilo principal, trabaje en segundo plano y reaccione proactivamente a la realidad (la llegada de un correo o el fin de una llamada). Además, Node.js respira JSON de forma nativa, lo cual es vital cuando toda la comunicación con el LLM mediante Function Calling requiere parseo y validación constante.

Mencionar RPA (Robotic Process Automation) con IA es un tema candente, pero te has encontrado con el problema del "Virtual DOM". ¿Cómo lo habéis resuelto?

Ese fue uno de los mayores dolores de cabeza. La realidad corporativa exige interactuar con sistemas legacy y CRMs de terceros sin APIs. Al intentar manipular el DOM nativo mediante scripts, fallábamos constantemente porque frameworks modernos como React o Vue ignoraban los cambios si su estado interno (Virtual DOM) no se actualizaba.

Enviar el árbol del DOM completo al LLM para que analice selectores era ineficiente y consumía demasiados tokens. La solución fue un enfoque multimodal basado en Computer Vision. En lugar de inyectar código en el subyacente, capturamos visualmente la pantalla activa y el modelo nos devuelve las coordenadas (X, Y) precisas de interacción. Luego, despachamos eventos de ratón reales sobre esas coordenadas. Hemos convertido al agente en un usuario físico, saltándonos por completo los bloqueos de los frameworks frontend.

¿Cuál dirías que es el reto de ingeniería más subestimado al construir este tipo de sistemas?

Depurar sistemas no deterministas. En el software tradicional, si algo falla, tienes un stack trace exacto. Con los LLMs, el fallo es estadístico. A veces el JSON es perfecto, y otras veces el modelo alucina un parámetro o se inventa un ID de base de datos.

Esto te obliga a diseñar sistemas de Self-Healing (auto-recuperación) en el backend. Si el LLM se equivoca, nuestro middleware intercepta ese "crash" antes de que llegue al frontend. Ocultamos el error al usuario, se lo devolvemos crudo a la IA en segundo plano y forzamos un reintento milisegundos después para que corrija su propio JSON. Y, por supuesto, esto requiere implementar circuit breakers estrictos para evitar bucles infinitos que devoren tu cuota de tokens.

¿Qué consejo le darías a un Arquitecto de Software que va a empezar a construir agentes autónomos hoy?

Que el éxito de un proyecto de Inteligencia Artificial casi no trata sobre Inteligencia Artificial; trata de ingeniería de software tradicional llevada al extremo.

El error más común es poner al LLM como los cimientos del proyecto. Si haces eso, tu sistema se derrumbará. Construye primero una arquitectura determinista, un middleware extremadamente robusto, y acopla la IA únicamente como un motor secundario.

Y, sobre todo, obsesiónate con la gestión del contexto. Conoce los límites físicos de los tokens y desarrolla técnicas (como Tail-end Overrides) para inyectar recordatorios absolutos antes de la ejecución. Si no optimizas la huella de memoria en cada ciclo, tu agente será lento, inestable y económicamente inviable de mantener en producción.

From Chatbots to Autonomous Agents: The Real Architecture of AI in Production

David San Nicolás Montero — Tue, 06 Oct 2026 22:18:29 +0000

Anyone can integrate the Gemini or OpenAI API over a weekend, give it a couple of basic tools, and upload a YouTube video claiming they've built an "autonomous agent." But making that agent handle dozens of simultaneous functions in a corporate environment securely, without hallucinations, and with a near-zero error rate is an entirely different architectural challenge.

Through my experience developing Zyro Workspace and founding AutomaticIA, I've learned the hard way that building successful Artificial Intelligence software, ironically, is hardly about Artificial Intelligence. It's about traditional software engineering taken to the extreme.

If you are thinking about integrating AI into your projects, here are the architectural lessons that separate a "digital slave" from a true "asynchronous coworker."

The Function Calling Illusion (The Brain in a Jar) The biggest misunderstanding when developers start using Function Calling is believing that the AI is executing the code. There is a false illusion that the model magically connects to Google Calendar or a database.

The technical reality is that the model is like a "brain in a jar": it is completely isolated from the outside world. All Function Calling does is apply an Inversion of Control (IoC). The model executes nothing; it simply reasons about which tool it needs and returns a JSON payload. It is you, in your middleware (in our case, Node.js), who must intercept that JSON, validate security, execute the actual code, and return the result to the model.

Inversion of Control (IoC): Trust the Infrastructure, Not the AI When you design a B2B agent, companies' biggest fear is that the AI will hallucinate and delete confidential files. If your only defense is writing rules in the System Prompt like "do not delete important documents," you have an incredibly fragile system.

The paradigm shift is moving from "trusting the AI" to "trusting the infrastructure":

Zero-Retention (Native Delegation): We decouple "intent" from "authorization." The backend executes actions by injecting the active user's native OAuth2 token. If the AI hallucinates and asks to read a confidential folder that the employee doesn't have access to, the API simply rejects it. The infrastructure enforces the physical boundaries.
Human-in-the-Loop: For destructive actions (like sending a mass email or deleting an event), the server intercepts the intent, pauses execution, and forces the user to confirm the action in the UI. The model doesn't even know it has been paused.

Event-Driven: From Digital Slave to Asynchronous Coworker A classic Request-Response architecture blocks the user with a loading icon. This is acceptable for a simple chatbot, but when you orchestrate LLM queries, RAG, and complex API calls, the process can take seconds or minutes.

By migrating to an event-driven architecture (leveraging Node.js's non-blocking Event Loop), we achieve true asynchrony. For instance, if you ask Zyro to call a client, the agent dispatches the mission to our PBX (telephone switchboard) and "goes to sleep," freeing the main thread. When the physical call ends minutes later, the PBX fires an asynchronous Webhook, "wakes up" Zyro, injects the transcript, and the agent proactively decides to send a follow-up email. The agent is subscribed to reality.

The Real Challenge: Debugging and Self-Healing In traditional software, if the code fails, you get an exact stack trace. With LLMs, the failure is statistical. Sometimes the AI invents a non-existent ID or hallucinates a parameter due to context weight.

To operate in production, you need to design Self-Healing recursion loops in the backend. If the AI fails to execute a tool, the server intercepts the crash, hides the error from the user, and feeds it back to the AI in the background, forcing it to correct its own hallucination in a matter of milliseconds. (All this, of course, protected by a circuit breaker pattern or watchdog to prevent infinite loops and burning through your tokens).

The Ultimate Advice for New AI Developers
If you are going to build an agent today, ground the weight of the project on solid software architecture. Placing AI at the structural base of a project will cause it to collapse quickly. Build a robust traditional software foundation first, and use AI as an attached engine, never as the foundation.

And above all: master your context footprint management. If you don't learn to strictly manage the amount of information you inject into the model, you will cause context window overflows. The model will forget its initial instructions, unleashing a cascade of hallucinations and errors. Optimizing prompts and calibrating tokens isn't a luxury; it's a matter of survival in production.

Cómo construir una IA que genera presentaciones de Google Slides autónomamente en Node.js

David San Nicolás Montero — Sat, 26 Sep 2026 08:29:25 +0000

Los Modelos de Lenguaje (LLMs) son increíbles redactando propuestas comerciales, pero se estrellan cuando intentas que le den formato corporativo a ese texto. La mayoría de tutoriales te enseñan a generar texto en la terminal, pero en el mundo B2B real, los usuarios no leen terminales: leen presentaciones corporativas, PDFs y hojas de cálculo.

Hoy vamos a construir un puente entre la Inteligencia Artificial Zyro y Google Workspace. Te enseñaré cómo crear un skill (habilidad) en Node.js que permite a un agente inteligente orquestar la API de Google Slides para generar presentaciones completas desde cero, aplicando tu plantilla corporativa.

Para no reinventar la rueda con la gestión de webhooks, esquemas OpenAPI y el enrutamiento de la IA, utilizaremos el Zyro Skills SDK, una librería open-source diseñada para inyectar herramientas personalizadas en agentes autónomos de forma segura mediante Function Calling.

El concepto: Inversión de Control y Memoria Descentralizada

En lugar de darle a la IA las llaves de tu Google Cloud (un riesgo de seguridad enorme), utilizaremos un patrón descentralizado. La IA decide qué contenido debe ir en la presentación, pero es nuestro servidor Node.js quien ejecuta el cómo. Además, el SDK de Zyro gestiona automáticamente un session_id anónimo, permitiendo que nuestro skill mantenga su propia base de datos (memoria descentralizada) sin sobrecargar el contexto del LLM.

Requisitos Previos

Node.js instalado.
Una Service Account de Google Cloud con la API de Google Slides y Google Drive habilitadas.
El ID de una presentación de Google Slides que servirá como "Plantilla Maestra" corporativa.

Paso 1: Configuración del Proyecto

Iniciamos nuestro proyecto e instalamos el SDK junto con la librería oficial de Google:

npm init -y
npm install express cors googleapis dotenv

Paso 2: Inicializar el SDK de Zyro

Creamos nuestro archivo index.js. Aquí instanciamos la clase principal ZyroSkill, que levantará un servidor Express configurado para escuchar al orquestador de la IA.

const { ZyroSkill } = require('./src/index'); // Ajusta la ruta a tu SDK
const { google } = require('googleapis');

// 1. Inicializar el SDK
const slidesSkill = new ZyroSkill({
    name: "Generador de Presentaciones Corporativas",
    description: "Permite al orquestador clonar plantillas de Google Slides e inyectar contenido dinámico generado por la IA.",
    port: process.env.PORT || 3000
});

Paso 3: Registrar la Acción para Google Slides

Utilizamos el método registerAction de tu SDK. Aquí definimos el esquema JSON que la IA debe respetar al enviarnos los datos, y la función asíncrona que ejecutará la clonación del documento en Google Drive.


// 2. Definir Acción: Crear Presentación
slidesSkill.registerAction(
'generar_google_slides',
'Genera una presentación comercial en Google Slides a partir del nombre del cliente y los textos clave.',
{
type: 'object',
properties: {
clientName: {
type: 'string',
description: 'Nombre de la empresa cliente para el título del archivo'
},
diapositivas: {
type: 'array',
description: 'Lista de textos a inyectar en las diapositivas',
items: { type: 'string' }
}
},
required: ['clientName', 'diapositivas']
},
async (parameters, context) => {
const { session_id } = context;
const { clientName, diapositivas } = parameters;
// 3. Autenticación silenciosa con Google Service Account
    const auth = new google.auth.GoogleAuth({
        keyFile: './google-credentials.json',
        scopes: [
            '[https://www.googleapis.com/auth/presentations](https://www.googleapis.com/auth/presentations)', 
            '[https://www.googleapis.com/auth/drive](https://www.googleapis.com/auth/drive)'
        ]
    });

    const drive = google.drive({ version: 'v3', auth });
    const slides = google.slides({ version: 'v1', auth });
try {
console.log([Sesión: ${session_id}] Generando propuesta para: ${clientName});

        // 4. Clonar la Plantilla Maestra en Drive
        const copyResponse = await drive.files.copy({
            fileId: process.env.TEMPLATE_ID,
            requestBody: { name: `Propuesta Comercial - ${clientName}` }
        });

        const newPresentationId = copyResponse.data.id;

        // 5. Dar permisos para que cualquiera con el enlace pueda editar
        await drive.permissions.create({
            fileId: newPresentationId,
            requestBody: {
                role: 'writer',
                type: 'anyone'
            }
        });
// 6. Preparar las sustituciones de texto para Slides
const requests = [
{
replaceAllText: {
containsText: { text: '{{CLIENTE}}', matchCase: true },
replaceText: clientName
}
}
];

        // Añadimos un reemplazo automático por cada elemento del array
        diapositivas.forEach((texto, index) => {
            requests.push({
                replaceAllText: {
                    containsText: { text: `{{TEXTO_${index + 1}}}`, matchCase: true },
                    replaceText: texto
                }
            });
        });

        // 7. Inyectar los textos generados por la IA en la presentación
        await slides.presentations.batchUpdate({
            presentationId: newPresentationId,
            requestBody: { requests }
        });

        // 8. Devolver el resultado limpio al Orquestador
            return {
                mensaje: 'Presentación clonada y generada correctamente.',
                url_documento: 'https://docs.google.com/presentation/d/' + newPresentationId + '/edit'
            };

        } catch (error) {
            console.error('Error en API de Google:', error);
            throw new Error('Fallo al generar la presentación: ' + error.message);
        }
    }
);

// Arrancamos el servidor de Skills
slidesSkill.start();