Saltar al contenido principal
JEBREX
ES EN
Contacta
ABRAHAM AI · UN PRODUCTO DE JEBREX

En desarrollo activo

Un agente de IA creado para pensar, ejecutar y evolucionar.

No es un chatbot. ABRAHAM AI es un agente diseñado para entender un proyecto, usar herramientas reales, realizar el trabajo, inspeccionar lo que ha pasado, probarlo y aprender de lo que está verificado, dentro de los límites que fija su propietario.

Cómo funciona Hablemos de ello
ABRAHAM AI - Think further together
QUÉ ES

Una plataforma de agente, no una ventana de chat.

ABRAHAM AI es una plataforma de agente persistente y multiproyecto. Una conversación con él es una sesión: se guarda, pertenece a un proyecto y continúa después de reiniciar. Nada empieza cada mañana desde una página en blanco.

El modelo es un componente, no el producto. A su alrededor está la parte que decide qué hacer: reunir el contexto de este paso, elegir una herramienta, ejecutarla, leer lo que ha devuelto, razonar sobre ello y dar el siguiente paso o detenerse y preguntar.

Está construido para trabajar con distintos proyectos y tecnologías en lugar de estar atado a una sola aplicación o a un solo lenguaje. Un proyecto es un directorio registrado con su propio conocimiento, sus propias sesiones y sus propios permisos, y la frontera entre dos proyectos se aplica en la base de datos y no por convención.

Jebrex lo desarrolla, lo posee y lo opera, como cada uno de los demás productos de este sitio.

POR QUÉ ES DISTINTO

De la conversación a la ejecución.

La diferencia entre un asistente y un agente está en lo que ocurre después de la respuesta. Un asistente describe el cambio. Un agente lo hace, mira el resultado y decide qué hacer a continuación.

  • Razonamiento
  • Uso de herramientas
  • Ejecución real
  • Comprensión del proyecto
  • Conocimiento
  • Memoria
  • Pruebas
  • Seguridad
  • Auditoría
  • Mejora continua

Ninguna de esas piezas es gran cosa por separado. Juntas son lo que permite que una petición termine en trabajo realmente hecho, y en un registro de cómo se hizo.

CÓMO FUNCIONA

Una ejecución, once movimientos.

Una ejecución es una secuencia acotada de pasos. Esta es su forma.

  1. 01

    Petición

    Un mensaje dentro de una sesión, y la sesión pertenece a un proyecto.

  2. 02

    Comprender

    La petición se lee frente a las reglas del proyecto, la sesión hasta ese momento y lo que ya se sabe.

  3. 03

    Planificar

    Se decide el siguiente paso. No todo el futuro: el siguiente paso.

  4. 04

    Elegir herramientas

    Al modelo solo se le ofrecen las herramientas que esta ejecución tiene permitido usar.

  5. 05

    Ejecutar

    Un único ejecutor realiza la llamada, con un tiempo máximo y un límite de lo que puede devolver.

  6. 06

    Inspeccionar

    El resultado vuelve como datos: un desenlace, un resumen, las fuentes que ha leído y un registro de auditoría.

  7. 07

    Razonar

    El resultado se devuelve al siguiente paso. Un agente que no puede ver lo que han devuelto sus herramientas solo se repite.

  8. 08

    Probar

    Cuando el trabajo es código, ejecutar las pruebas del propio proyecto es una llamada al terminal como cualquier otra: reconocida, clasificada y acotada.

  9. 09

    Revisar

    Cada invocación, decisión y rechazo se escribe en un registro de auditoría que después no puede editarse.

  10. 10

    Aprender

    Lo que resulta útil se anota como conocimiento o memoria, con su procedencia adjunta.

  11. 11

    Continuar

    O detenerse, y decir qué límite ha alcanzado en lugar de presentarse como terminado.

Cada ejecución está acotada antes de empezar: un máximo de pasos, de tiempo real, de llamadas a herramientas y de repeticiones de una misma llamada. Cada límite se comprueba antes de la acción que acota, nunca después: un bucle que descubre que ha hecho una llamada de más ya la ha hecho.

CON QUÉ SE CONECTA

Creado para llegar al ecosistema de software real.

Cada punto está descrito tal y como está hoy. Cuando algo es alcanzable pero no está integrado, o está construido pero aún no probado contra el sistema real, aquí se dice.

  • Implementado

    Archivos y bases de código

    Lista, lee, busca, escribe, edita, mueve y elimina archivos estrictamente dentro de la raíz del proyecto activo, además de un análisis léxico de solo lectura de los lenguajes, la estructura, los símbolos exportados y las dependencias declaradas de un proyecto.

  • Implementado

    Terminal

    Ejecuta un único ejecutable sin shell, dentro del proyecto y clasificado antes de ejecutarse. Un comando no reconocido se rechaza en lugar de ejecutarse dando por hecho que es inofensivo.

  • Implementado

    Investigación web

    La búsqueda devuelve fuentes candidatas ordenadas y declara sin rodeos que son pistas sin verificar. El lector obtiene una página a través de una descarga protegida y devuelve el texto etiquetado como contenido externo.

  • Implementado · sin volver a probar contra un navegador real

    Navegador

    Se conecta mediante el protocolo DevTools a un navegador que ya estás ejecutando y lee la página renderizada, sus peticiones o una expresión. ABRAHAM AI no incluye ningún navegador propio.

  • Implementado · las llamadas reales no están en el conjunto verificado

    GitHub

    Lee repositorios, ramas, pull requests y búsquedas de código; crea ramas, forks y pull requests. La credencial la guarda el cliente y nunca pasa por el modelo.

  • Implementado

    APIs HTTP

    Llama a las APIs que declares como conectores. El modelo elige un conector y una ruta bajo un prefijo declarado; no puede elegir el host, ni un método que no hayas listado, ni una cabecera reservada.

  • Alcanzable, no integrado

    Herramientas de despliegue, Vercel incluido

    No existe una integración propia con Vercel. Vercel es alcanzable como conector de API declarado, o a través del terminal, donde se clasifica como comando de despliegue, lo que exige la capacidad de despliegue, siempre supervisada, y una aprobación en cada llamada.

  • Sin integración propia

    Bases de datos

    No existe una herramienta de base de datos. A la base de datos de un proyecto se llega como llega el propio proyecto: mediante código que el agente ejecuta, o mediante una API HTTP que tú declares. El almacén propio de ABRAHAM AI es SQLite.

  • Implementado · sin verificar contra un repositorio real

    Git

    El estado del repositorio se lee mediante un cliente protegido para dar contexto al proyecto. No hay herramienta de Git y git se rechaza en el terminal, porque modificar un repositorio tiene su propia vía a través del modelo de permisos.

  • Un adaptador implementado

    Modelos de IA

    El proveedor está detrás de una única interfaz y el núcleo del agente no importa ningún SDK de proveedor, así que un segundo modelo es un adaptador y no una reescritura. Hoy se incluye un adaptador: DeepSeek. ABRAHAM AI es el producto; DeepSeek es un modelo sobre el que funciona actualmente.

CONOCIMIENTO Y MEMORIA

Aprende, y lleva la cuenta de lo que se le permite dar por cierto.

Aquí la mejora continua significa algo concreto y comprobable. ABRAHAM AI acumula conocimiento y memoria a partir del trabajo que hace, y el registro dice de dónde viene cada pieza y hasta qué punto puede confiarse en ella.

Todo lo extraído de la web entra como candidato. Pasa a ser de confianza solo cuando el propietario lo promueve, y solo el conocimiento de confianza se trata como cierto. El resto sigue siendo lo que era: material, con una fuente adjunta.

La memoria es la mitad duradera: hechos sobre las preferencias del propietario y los proyectos en los que trabaja, reunidos en el contexto de cada ejecución dentro de un presupuesto declarado. El constructor de contexto produce un manifiesto de lo que ha incluido, de modo que una respuesta puede rastrearse hasta el conocimiento y las memorias que hay detrás.

No se reescribe a sí mismo. No existe ninguna vía por la que una ejecución edite las reglas bajo las que se ejecuta, y los trabajos programados de investigación y consolidación no pueden cambiar en silencio las reglas de seguridad que los acotan.

  • De candidato a de confianza, por decisión del propietario.
  • El contenido externo es un dato, nunca una instrucción, por muy imperativa que sea la redacción de una página.
  • El aislamiento entre proyectos es una restricción de la base de datos: un registro mal delimitado no puede ni almacenarse.
  • La investigación y la consolidación programadas se ejecutan sin que nadie las pida, y quedan registradas cuando lo hacen.
HERRAMIENTAS Y EJECUCIÓN

La herramienta declara lo que necesita. La plataforma decide lo que recibe.

Hoy se incluyen ocho herramientas, y el núcleo del agente no sabe lo que hace ninguna de ellas. Una herramienta son datos: un identificador, un esquema de entrada, las capacidades que necesita, un tiempo máximo, si puede cambiar algo fuera del proceso y cuáles de sus entradas se resumen en el registro de auditoría.

Eso es lo que hace que los límites sean exigibles y no aspiracionales. La autoridad se resuelve a partir de la declaración, así que una lectura nunca lleva permiso de escritura, y un rechazo ocurre antes de que se ejecute el manejador. Las pruebas comprueban que el archivo no se escribió, porque un rechazo que ya ha escrito el archivo no es un rechazo.

La disponibilidad se sondea, no se supone. Una herramienta que ahora mismo no puede funcionar se declara no disponible con un motivo sobre el que se puede actuar, en lugar de fallar en el momento en que se la llama.

SEGURIDAD

La seguridad es lo que decide si todo esto es utilizable.

A ABRAHAM AI se le da un terminal, un sistema de archivos y una red. Estos son los controles que convierten eso en una decisión meditada y no en una temeridad.

  • Permisos

    Doce capacidades y cuatro modos. No se concede nada por defecto, ni siquiera la lectura, y dos capacidades, despliegue y secretos, siguen supervisadas permita lo que permita el modo.

  • Aprobaciones

    Una acción que modifica algo pregunta en el propio flujo de la ejecución y espera respuesta. Si se aprueba, continúa; si se rechaza, no ocurre.

  • Controles del terminal

    Sin shell, así que no hay nada en lo que inyectar. Se rechazan los shells, la escalada de privilegios, git y los binarios no reconocidos, igual que los argumentos que nombren una ruta fuera del proyecto.

  • Contención del sistema de archivos

    Cada ruta se resuelve de forma léxica y contra el sistema de archivos real, y la operación se realiza sobre la ruta resuelta. Los directorios de metadatos del repositorio están protegidos frente a todas las grafías que Windows acepta, incluida la eliminación.

  • Protección contra SSRF

    Las direcciones privadas, de loopback y de enlace local se rechazan por defecto, y la comprobación se repite en cada redirección: validar solo la primera URL es la forma habitual de derrotar esta defensa.

  • Seguridad del navegador

    Una URL de navegación pasa la misma política que cualquier otra petición saliente, antes de abrir la página y de nuevo allí donde aterrice una redirección. Una URL rechazada no se visita nunca.

  • Protección de secretos

    Las credenciales no aparecen nunca en el código, los prompts, los registros, la auditoría ni el contexto del modelo. Se adjuntan a la petición saliente en el servidor, y los procesos hijos no las heredan.

  • Auditabilidad

    El registro de auditoría solo admite adiciones a través de su propia API. Los registros de permisos, seguridad y despliegue no caducan nunca, y un registro no puede eliminarse de uno en uno.

DÓNDE ESTÁ HOY

En desarrollo y pruebas.

ABRAHAM AI está en desarrollo y pruebas activas. Se construye y se refuerza de forma deliberada en lugar de a las prisas, y todavía no está disponible para comprar ni para registrarse.

Si quieres que te avisemos cuando se abra, dínoslo: te lo haremos saber cuando esté listo.

HACIA DÓNDE VA

Lo siguiente, dicho como intenciones.

Nada de esto está en la página como capacidad. Es aquello para lo que se dio forma a la arquitectura.

  • Un segundo proveedor de modelo

    La interfaz existe y el núcleo del agente no importa ningún SDK de proveedor, así que un segundo adaptador es una implementación y no un rediseño. Hoy solo DeepSeek está implementado.

  • Más herramientas, el mismo contrato

    Una herramienta declara lo que necesita y el modelo de permisos existente decide. Añadir una no debería cambiar ningún código de seguridad: esa es la prueba de si el modelo era el correcto.

  • Aprendizaje con una superficie

    El ciclo de aprendizaje ya se ejecuta y queda registrado. Darle una pantalla convierte lo que ha encontrado en algo que se lee en lugar de algo que se deduce.

  • Más autonomía, dentro del modelo

    Una autoridad más amplia es algo que el modelo de capacidades y aprobaciones tiene que conceder, no algo que llegue por un lado.

ABRAHAM AI

¿Quieres hablar de ello?

Cuéntanos qué te gustaría que hiciera un agente dentro de tus propios proyectos.

Contacta hello@jebrex.com