# Marca personal: banner, perfiles y próximas publicaciones **Reporte:** REPORT-20260521-marca-personal-banner-contenidos-mi-lsp **Estado:** borrador operativo para Gabriel **Fecha:** 2026-05-21 **Uso:** ordenar el banner de LinkedIn, el storytelling de Perfil 1 / Perfil 2, la serie de publicaciones y el puente hacia `mi-lsp` como proyecto open source dentro del ecosistema TEDI. --- ## 1. Qué haría ahora Yo no intentaría abrir diez frentes al mismo tiempo. Haría tres movimientos coordinados: 1. **Actualizar el perfil y banner** para que cualquiera entienda en 5 segundos el territorio: Wiki-First Agentic Engineering. 2. **Continuar la línea del primer post de Naur/wiki**, pero sin repetirlo. La siguiente pieza tiene que avanzar de “la wiki como teoría compartida” hacia “la wiki como sistema operativo para agentes”. 3. **Preparar `mi-lsp` como prueba pública**: no solo como herramienta técnica, sino como evidencia de que estás construyendo la infraestructura que predicás. La secuencia correcta es: ```text Naur / teoría compartida -> Wiki como canon operativo -> Agentic Engineering wiki-first -> mi-lsp como navegación para agentes -> TEDI como suite futura de herramientas ``` Esto conecta marca personal, open source y producto sin que parezca venta forzada. --- ## 2. Perfil 1 y Perfil 2, bien ordenados Para mí, esto queda así: ```text Perfil 1 = arquitecto / builder práctico Perfil 2 = educador técnico ``` No son dos marcas separadas. Son dos capas. ### Perfil 1 — el que manda **Identidad:** > Arquitecto / builder de sistemas agentic gobernables. **Promesa:** > Construyo sistemas para que humanos y agentes trabajen con canon, decisiones, contratos, evidencia y aprendizaje acumulativo. **Qué transmite:** - criterio técnico; - experiencia real; - capacidad de construir tooling; - distancia del humo de IA; - autoridad para hablar con CTOs, founders y equipos técnicos. Este perfil es el que te da credibilidad. ### Perfil 2 — el que distribuye **Identidad:** > Educador técnico que explica cómo pasar de prompts sueltos a sistemas agentic gobernados. **Promesa:** > Traduzco lo que estoy construyendo en modelos simples para que otros equipos puedan trabajar mejor con agentes. **Qué transmite:** - claridad; - generosidad; - capacidad pedagógica; - liderazgo de conversación pública; - potencial para comunidad, workshops, guías y contenido. Este perfil es el que te da alcance. ### Fórmula final > **Construyo sistemas agentic gobernables y comparto los principios que los hacen funcionar.** O más específico: > **Diseño workflows humano-agente donde la wiki gobierna, los harnesses ejecutan, los workers producen evidencia y el aprendizaje vuelve al sistema.** --- ## 3. Perfil LinkedIn recomendado ### Headline principal > **Software Architect / Builder · Wiki-First Agentic Engineering · Canon, evidence & human-agent workflows** Me gusta porque es claro, internacional y no suena a “influencer de IA”. ### Headline más fuerte, si querés ir más niche > **Building wiki-first systems for reliable human-agent software work · Canon, contracts, workers & evidence** Esta segunda es más distintiva, pero un poco menos reconocible para recruiters generales. Yo usaría la primera ahora y dejaría la segunda para GitHub, web personal o landing. ### About corto para LinkedIn > I build wiki-first systems for reliable human-agent software work. > > My focus is Agentic Engineering: turning scattered context, decisions and lessons into operational canon that humans and AI agents can use to plan, execute, validate and learn. > > I work on workflows where the wiki governs, harnesses execute, workers produce evidence and learning goes back into the system. > > Current interests: canonical documentation, decision locks, operational contracts, evidence-driven AI work, open-source tooling and human-agent software workflows. ### About en español, para usar como base narrativa > Construyo sistemas wiki-first para que humanos y agentes trabajen con menos caos, más trazabilidad y evidencia real. > > Mi foco es Agentic Engineering: convertir contexto disperso, decisiones y aprendizajes en canon operativo que pueda ser leído por personas y agentes. > > La idea que guía mi trabajo es simple: el harness ejecuta, pero la wiki gobierna. Los agentes no deberían trabajar sobre intuiciones, prompts infinitos o memoria implícita. Deberían trabajar sobre decisiones claras, contratos operativos y evidencia verificable. > > Estoy construyendo herramientas, metodología y contenido alrededor de esa idea. --- ## 4. Banner de LinkedIn: dirección visual El banner no debería explicar todo. Tiene que instalar un clima y una categoría. No usaría robots, cerebros digitales ni estética genérica de IA. Eso te vuelve uno más. Usaría el canon visual que ya venimos trabajando: ```text Agentic Canon / Multi-Tedi Neomorphic Editorial ``` La imagen debería sentirse como: - hoja técnica viva; - sistema de conocimiento ordenado; - wiki/canon como centro; - agentes/harnesses como nodos conectados; - evidencia como cierre; - estética editorial, táctil, precisa. ### Texto visible recomendado Idealmente, poco texto. Si GPT Image 2 maneja texto bien, probaría uno de estos: 1. **Wiki-First Agentic Engineering** 2. **The wiki governs. The harness executes.** 3. **Canon → Contracts → Workers → Evidence** Mi recomendación: **no poner mucho texto dentro de la imagen**. Es mejor generar un banner limpio y agregar el texto en Canva/Figma después, para evitar errores tipográficos. --- ## 5. Prompt para GPT Image 2 — banner LinkedIn Usaría este prompt en inglés, porque suele dar mejores resultados visuales: ```text Create a LinkedIn profile banner, aspect ratio 4:1, clean editorial technical style. Concept: Wiki-First Agentic Engineering. A warm off-white paper-like background with subtle texture. In the center-left, a tactile neomorphic “canonical wiki” object: layered white cards or pages, softly rounded, with tiny technical labels such as canon, decisions, contracts, evidence, learning. Around it, small abstract nodes representing AI agents, harnesses and workers connected by thin graphite lines. The wiki/canon should feel like the source of truth, while the agents orbit it as consumers. Visual mood: calm, precise, warm, high-end technical editorial, not corporate SaaS, not generic AI. Use soft shadows, pearl white surfaces, graphite text accents, very subtle cyan-blue highlights for system/canon, very subtle green for evidence/pass. Lots of negative space. Elegant, minimal, thoughtful. Composition: leave safe empty space on the left and bottom-left for a LinkedIn profile photo overlay. Main conceptual object should sit slightly right of center. Add a discreet flow motif: Canon → Contracts → Workers → Evidence, represented visually with small connected capsules, not large readable text. Style keywords: neomorphic editorial, paper sheet agentic, technical notebook, living documentation, system map, calm precision, premium minimalism, human-agent workflows. Avoid: robots, humanoid AI, digital brains, neon cyberpunk, purple-blue generic AI gradients, fake dashboards, clutter, stock icons, excessive text, busy background, corporate SaaS illustrations. No large text. If any text appears, it must be minimal and perfectly spelled: “Wiki-First Agentic Engineering”. ``` ### Variante más conceptual ```text Create a LinkedIn banner in a warm neomorphic editorial style. Show a quiet technical landscape where scattered memory fragments, chat bubbles and code snippets flow through a soft paper-like filter into a stable canonical wiki. From that wiki, clean lines connect to abstract agent nodes, a harness module, worker capsules and an evidence stamp. The story should be: raw memory becomes canon; canon guides agents; evidence closes the loop. Use off-white paper, pearl surfaces, soft shadows, graphite lines, subtle cyan for canon, subtle green for evidence, tiny amber accents for ambiguity. Elegant, calm, precise, lots of negative space. No robots, no AI clichés, no neon, no fake dashboards. LinkedIn banner ratio 4:1. Keep the left side visually safe for profile photo overlay. No large text. ``` ### Texto para agregar encima después Si después lo editamos manualmente, pondría: ```text Wiki-First Agentic Engineering Canon · Contracts · Workers · Evidence ``` O más fuerte: ```text The wiki governs. The harness executes. ``` --- ## 6. Cómo continuar después del primer post de Naur El primer post ya instaló una idea muy buena: > Naur decía que el valor del software vive en la teoría compartida del equipo. Con agentes, esa teoría tiene que hacerse explícita; si no, el agente la simula. No conviene repetir esa misma idea. Conviene avanzar un escalón. La próxima publicación debería responder: > Si la wiki es teoría compartida, ¿qué tiene que tener para ser operativa para agentes? Ese es el puente perfecto. --- ## 7. Siguiente publicación recomendada ### Post 2 — “Una wiki no alcanza si no gobierna” **Tesis:** > Una wiki no se vuelve útil para agentes por existir. Se vuelve útil cuando distingue canon, decisiones, contratos, evidencia y aprendizaje. **Hook:** > Después de publicar sobre Naur y la teoría compartida del software, me quedé pensando en algo: > > no alcanza con tener una wiki. > > La pregunta es si esa wiki puede gobernar trabajo real. **Estructura:** 1. Muchas wikis son cementerios de notas. 2. Para agentes, eso no alcanza. 3. Un agente necesita saber qué está vigente, qué está decidido, qué está abierto y qué evidencia cuenta. 4. Ahí la wiki deja de ser documentación y se vuelve canon operativo. 5. La cadena: memoria → canon → decisión → contrato → worker → evidencia → aprendizaje. 6. Cierre: la wiki no reemplaza criterio; lo hace transmisible. **CTA:** > Si mañana un agente entra a tu repo, ¿encuentra documentación o encuentra una fuente de verdad ejecutable? Este post mantiene la línea de wiki, pero agrega profundidad. --- ## 8. Publicación para presentar `mi-lsp` No presentaría `mi-lsp` como “un LSP para agentes”. Eso puede quedar demasiado técnico al principio. Lo presentaría así: > Estoy construyendo una herramienta para que los agentes no naveguen repos como turistas perdidos. ### Post 3 — “Los agentes necesitan un mapa del repo” **Tesis:** > Si queremos que los agentes trabajen bien, no alcanza con darles acceso al repo. Necesitan una forma confiable de encontrar canon, código, contratos y evidencia. **Hook:** > Darle un repo entero a un agente no es darle contexto. > > Muchas veces es darle un laberinto. **Estructura:** 1. Los agentes pueden leer archivos, pero eso no significa que entiendan el sistema. 2. En un repo real hay código, docs, decisiones, tickets, tests, scripts, raw notes y material obsoleto. 3. Sin navegación, el agente confunde fuente de verdad con ruido. 4. Por eso estoy construyendo `mi-lsp`: una capa de navegación para que agentes y humanos encuentren lo importante más rápido. 5. No reemplaza la wiki. La hace más usable. 6. No reemplaza el criterio. Reduce el costo de encontrar contexto correcto. **CTA:** > Estoy preparando una landing pública del proyecto. Si te interesa Agentic Engineering, te va a gustar ver cómo estoy pensando esta capa. ### Frase clave para `mi-lsp` > `mi-lsp` es un mapa operativo para agentes: ayuda a encontrar canon, código y contexto sin convertir todo el repo en un prompt gigante. --- ## 9. Landing de `mi-lsp` dentro del dominio TEDI La landing debería cumplir dos objetivos al mismo tiempo: 1. Explicar `mi-lsp` como proyecto open source. 2. Llevar gente hacia la futura suite TEDI sin vender humo. ### Mensaje principal de landing > **mi-lsp helps AI agents navigate real software projects.** Subheadline: > A local semantic navigation layer for codebases, docs and wiki-first agentic workflows. Built to help humans and agents find the right context before they execute. ### Versión más Gabriel/TEDI > **Un mapa local para que agentes entiendan repos reales.** > > `mi-lsp` ayuda a navegar código, documentación, wiki canónica y contexto operativo para que el trabajo con agentes no dependa de prompts gigantes ni búsquedas a ciegas. ### Secciones de la landing 1. **Hero** - Qué es. - Para quién es. - CTA a GitHub. - CTA a “learn the Wiki-First Agentic Engineering approach”. 2. **Problema** - Repos grandes. - Contexto disperso. - Docs y código separados. - Agentes navegando sin brújula. 3. **Qué hace mi-lsp** - Workspace status. - Navegación por intención. - Búsqueda semántica/documental. - Pack de lectura. - Superficies wiki-first. 4. **Por qué importa para agentes** - Menos prompt stuffing. - Menos confusión entre raw y canon. - Mejor handoff. - Mejor validación. 5. **Open source** - GitHub. - Instalación. - Ejemplos. - Estado del proyecto. 6. **Parte de TEDI** - TEDI como suite futura para workflows humano-agente. - mi-lsp como capa de navegación/contexto. - Próximas piezas: memoria, canon, workers, evidencia. ### CTA recomendado Primario: > View on GitHub Secundario: > Read the Wiki-First Agentic Engineering notes Tercero, si querés capturar interés: > Follow the build in public --- ## 10. Serie de publicaciones recomendada Yo haría esta secuencia durante las próximas 3-4 semanas. ### 1. Ya publicado — Naur, teoría compartida y wiki **Rol:** pieza fundacional. **Objetivo:** instalar que la wiki no es documentación muerta; es teoría compartida externalizada. No lo repetiría. Lo usaría como base. ### 2. Wiki operativa **Título:** Una wiki no alcanza si no gobierna. **Objetivo:** pasar de teoría compartida a canon operativo. ### 3. mi-lsp **Título:** Los agentes necesitan un mapa del repo. **Objetivo:** presentar el problema que `mi-lsp` resuelve y preparar tráfico a la landing. ### 4. Prompt-first vs wiki-first **Título:** Prompts largos no escalan. Canon sí. **Objetivo:** instalar frase memorable. ### 5. Decision lock **Título:** Un agente no debería ejecutar sobre una intuición. **Objetivo:** mostrar criterio operativo y diferenciar discovery de ejecución. ### 6. Evidence-closed **Título:** “El agente terminó” no significa nada. **Objetivo:** atacar el teatro agentic y mostrar estándar de ingeniería. ### 7. Building in public de TEDI / suite futura **Título:** Estoy construyendo una suite para workflows humano-agente. **Objetivo:** conectar marca personal, open source y producto. --- ## 11. Calendario simple de 2 semanas ### Semana 1 **Día 1:** actualizar banner y headline. **Día 2:** publicar “Una wiki no alcanza si no gobierna”. **Día 4:** publicar mini-post sobre la cadena `memoria → canon → evidencia`. **Día 6:** teaser de `mi-lsp`: “darle un repo a un agente no es darle contexto”. ### Semana 2 **Día 1:** publicar post principal de `mi-lsp`. **Día 3:** compartir screenshot/landing preview de `mi-lsp`. **Día 5:** publicar “Prompts largos no escalan. Canon sí.” **Día 7:** cerrar con reflexión building-in-public: qué estoy aprendiendo construyendo esto. --- ## 12. Borrador listo para el próximo post Este sería el próximo post que publicaría: ```text Después de escribir sobre Peter Naur y la teoría compartida del software, me quedó dando vueltas una idea: no alcanza con tener una wiki. Muchas wikis son cementerios de notas. Tienen decisiones viejas, contexto mezclado, documentación incompleta, páginas que nadie sabe si siguen vigentes y aprendizajes que nunca vuelven al proceso. Para trabajar con agentes, eso no alcanza. Un agente necesita saber: - qué está decidido; - qué está abierto; - qué es contexto histórico; - qué es fuente de verdad; - qué evidencia cuenta como suficiente; - qué puede tocar y qué no. Ahí la wiki deja de ser documentación y empieza a ser canon operativo. La diferencia es importante: Documentación posterior = memoria. Canon operativo = control de ejecución. La cadena que estoy explorando es esta: memoria → canon → decisión → contrato → worker → evidencia → aprendizaje La wiki no reemplaza el criterio humano. Lo hace transmisible. Y con agentes, eso cambia mucho: si la teoría del sistema no está escrita en un lugar consumible, el agente no la hereda. La simula. Por eso estoy trabajando en Wiki-First Agentic Engineering: una forma de diseñar proyectos donde humanos y agentes puedan trabajar sobre verdad compartida, no sobre prompts cada vez más largos. Pregunta para equipos que ya usan IA: si mañana un agente entra a tu repo, ¿encuentra documentación o encuentra una fuente de verdad ejecutable? ``` --- ## 13. Borrador listo para el primer post de `mi-lsp` ```text Darle un repo entero a un agente no es darle contexto. Muchas veces es darle un laberinto. En un proyecto real hay código, documentación, decisiones, tests, scripts, convenciones, notas raw, material obsoleto, issues, handoffs y evidencia. El problema no es solo que el agente pueda leer archivos. El problema es que pueda encontrar qué importa. Qué es canon. Qué es histórico. Qué está vigente. Dónde vive una decisión. Qué archivo implementa una regla. Qué evidencia valida un cambio. Qué debería leer antes de ejecutar. Por eso estoy construyendo `mi-lsp`. La idea es simple: un mapa operativo para que humanos y agentes naveguen repos reales sin convertir todo el proyecto en un prompt gigante. `mi-lsp` no reemplaza la wiki. La hace más navegable. No reemplaza el criterio técnico. Reduce el costo de encontrar el contexto correcto. No promete magia. Ataca un problema aburrido pero central: antes de que un agente ejecute, tiene que saber dónde está parado. Estoy preparando una landing pública del proyecto como parte del ecosistema TEDI. Mi objetivo es ir mostrando cómo encaja dentro de una visión más grande: Wiki-First Agentic Engineering. ``` --- ## 14. Qué publicaría como carrusel después ### Carrusel 1 — Prompts largos no escalan. Canon sí. 1. Prompts largos no escalan. Canon sí. 2. El problema no es meter más contexto. 3. El problema es saber qué contexto gobierna. 4. Una wiki común no alcanza. 5. Una wiki operativa distingue memoria, canon y evidencia. 6. El harness ejecuta. 7. La wiki gobierna. 8. La evidencia cierra. 9. El aprendizaje vuelve al sistema. 10. ¿Dónde vive la verdad de tu sistema agentic? ### Carrusel 2 — Los agentes necesitan un mapa 1. Darle un repo a un agente no es darle contexto. 2. Un repo real es un laberinto. 3. Código, docs, tests, scripts, raw notes, decisiones. 4. Sin mapa, el agente confunde ruido con fuente de verdad. 5. La wiki da canon. 6. `mi-lsp` ayuda a navegar. 7. Menos prompt stuffing. 8. Más contexto correcto. 9. Mejor ejecución. 10. Primero ubicarse. Después actuar. --- ## 15. Recomendación final Mi recomendación concreta: 1. **Actualizar banner + headline primero.** Eso prepara el perfil antes de que los posts lleven tráfico. 2. **Publicar el post “Una wiki no alcanza si no gobierna”.** Es la continuación natural del post de Naur. 3. **Después presentar `mi-lsp`.** No como herramienta aislada, sino como una pieza de la tesis: los agentes necesitan navegación, canon y evidencia. 4. **Usar TEDI como paraguas suave.** Todavía no vender la suite completa. Mostrar que `mi-lsp` es una pieza de una visión mayor. La frase que debería sostener todo: > **No estoy construyendo contenido sobre IA. Estoy construyendo una forma de trabajar con agentes sin perder control, contexto ni evidencia.** Ese es el diferencial.