Manual del operador — Agent Squad The Operator's Manual — Agent Squad

Página estática más una escena 3D (Three.js vía Threlte) que se renderiza por completo en tu navegador. Sin sesión y sin llamadas al backend. Los 16 agentes y sus historias son contenido de demostración deliberado — por eso esta página, y solo esta, lleva la etiqueta DEMO. Es una decisión de producto: un showroom que se puede enseñar sin fricción, claramente separado del sistema real que empieza en el paso siguiente.

A static page plus a 3D scene (Three.js via Threlte) rendered entirely in your browser. No session, no backend calls. The 16 agents and their stories are deliberate demo content — which is why this page, and only this one, carries the DEMO label. It is a product decision: a showroom you can present without friction, clearly separated from the real system that starts on the next step.

Desde aquí estás en la app real: SvelteKit 5 servida por Vercel — serverless y stateless, sin servidores propios que mantener en esta capa. La identidad del usuario vive en InsForge (un backend-as-a-service: la plataforma que guarda usuarios y su estado). La app le habla solo desde el servidor: el navegador nunca ve llaves privilegiadas.

From here on you are in the real app: SvelteKit 5 served by Vercel — serverless and stateless, no servers of our own to maintain at this layer. User identity lives in InsForge (a backend-as-a-service: the platform that stores users and their state). The app talks to it server-side only: the browser never sees privileged keys.

El SDK de InsForge crea el usuario en auth.users, con la contraseña hasheada por la plataforma — la app nunca almacena contraseñas. Inmediatamente después, la app hace un login server-side (client_type=server) para capturar el refresh token, que el SDK de navegador no expone a propósito: ese token solo debe existir del lado del servidor.

The InsForge SDK creates the user in auth.users, with the password hashed by the platform — the app never stores passwords. Right after, the app performs a server-side login (client_type=server) to capture the refresh token, which the browser SDK deliberately does not expose: that token should only ever exist server-side.

El servidor genera un magic link (un enlace de un solo uso que inicia sesión sin teclear contraseña): un token aleatorio criptográfico (CSPRNG) de 256 bits, registrado en la tabla magic_links con expiración de 15 minutos. El email sale por Resend, SMTP transaccional con dominio verificado.

The server generates a magic link (a single-use link that signs you in without typing a password): a 256-bit cryptographically random (CSPRNG) token, recorded in the magic_links table with a 15-minute expiry. The email goes out through Resend, transactional SMTP on a verified domain.

Lo que ves es el template de producción, no una maqueta. El detalle de ingeniería importante está en el destino del botón: el enlace no inicia sesión con solo abrirse — eso se resuelve en el paso siguiente, y la razón es más interesante de lo que parece.

What you see is the production template, not a mockup. The important engineering detail is in the button's destination: the link does not sign you in just by being opened — that resolves in the next step, and the reason is more interesting than it looks.

El interstitial existe por una razón concreta: los scanners de seguridad de los inboxes corporativos pre-visitan los enlaces de cada email. Si el GET consumiera el token, el scanner lo quemaría antes del clic humano. Por eso el consumo real es un POST atómico de un solo uso: un UPDATE condicional (consumed_at IS NULL) en el que gana exactamente un request. La sesión queda en una cookie httpOnly/secure con access + refresh token; el servidor la renueva solo cuando expira (~15 min) — el usuario no vuelve a ver una pantalla de login.

The interstitial exists for a concrete reason: corporate inbox security scanners pre-visit every link in an email. If the GET consumed the token, the scanner would burn it before the human click. So the real consumption is an atomic one-time POST: a conditional UPDATE (consumed_at IS NULL) where exactly one request wins. The session lands in an httpOnly/secure cookie holding access + refresh tokens; the server renews it on its own when it expires (~15 min) — the user never sees a login screen again.

El gate es una tabla user_access en InsForge con authorized boolean default false. El hook del servidor la lee en cada request con la service key, en modo fail-closed: si la lectura falla por cualquier motivo, el usuario NO está autorizado. Es la mecánica de la beta privada — el default es la puerta cerrada.

The gate is a user_access table in InsForge with authorized boolean default false. The server hook reads it on every request with the service key, in fail-closed mode: if the read fails for any reason, the user is NOT authorized. It is the private-beta mechanic — the default is a closed door.

Solo un founder puede poner authorized=true — no existe autoservicio. Quién entra a la beta es una decisión humana explícita, no un toggle que el usuario pueda activarse a sí mismo. Esta captura muestra esa acción del lado del founder.

Only a founder can set authorized=true — there is no self-service. Who enters the beta is an explicit human decision, not a toggle users can flip on themselves. This screenshot shows that action from the founder's side.

Nova es aquí una guía de interfaz: una conversación estructurada, sin LLM en este paso. Es una decisión deliberada — cero latencia y cero costo en el funnel de entrada, donde cada segundo de espera cuesta conversión. La IA de verdad entra donde aporta: en el trabajo, no en el formulario.

Nova here is a UI guide: a structured conversation, no LLM at this step. A deliberate decision — zero latency and zero cost in the entry funnel, where every second of waiting costs conversion. The real AI enters where it adds value: in the work, not in the form.

Cada respuesta se persiste en el perfil del usuario en InsForge (profile.app_state), siempre vía endpoint server-side — el navegador nunca escribe directo a la base de datos.

Each answer is persisted to the user's profile in InsForge (profile.app_state), always through a server-side endpoint — the browser never writes directly to the database.

El objetivo que eliges aquí no es decorativo: es el insumo del que se deriva el squad que la app te propondrá dos pantallas más adelante (paso 13).

The goal you pick here is not decorative: it is the input from which the squad the app proposes two screens later (step 13) is derived.

Al completar la cuarta respuesta, el flag onboarding_completed se marca en el perfil y habilita el resto de la app. Sin ese flag, las rutas internas redirigen de vuelta al onboarding.

On completing the fourth answer, the onboarding_completed flag is set on the profile and unlocks the rest of the app. Without that flag, internal routes redirect back to onboarding.

El squad propuesto se deriva del objetivo elegido mediante plantillas curadas; "Instalar" guarda el roster en tu perfil. ¿Qué es un agente aquí? Una ficha de identidad — nombre, rol, especialidad — sin ningún programa ni servidor propio detrás. El trabajo real vive en las recetas del motor (PlanTemplates — planos de trabajo predefinidos y probados): cada receta define sus pasos y qué agente firma cada uno; cuando hay trabajo, tu agente es quien aparece haciéndolo. Como en un restaurante: sumar un cocinero al organigrama no construye otra cocina.

The proposed squad is derived from your chosen goal via curated templates; "Install" saves the roster to your profile. What is an agent here? An identity card — name, role, specialty — with no program or server of its own behind it. The real work lives in the engine's recipes (PlanTemplates — predefined, tested work blueprints): each recipe defines its steps and which agent signs each one; when work happens, your agent is the one shown doing it. Like a restaurant: adding a cook to the org chart doesn't build a second kitchen.

La oficina es una escena 3D cuyas zonas por squad se calculan con un layout puro: una función sin efectos secundarios, testeada con vitest. Mismo input, mismo plano — el render es predecible y verificable como cualquier otra pieza de lógica.

The office is a 3D scene whose per-squad zones are computed by a pure layout: a side-effect-free function, tested with vitest. Same input, same floor plan — the render is as predictable and testable as any other piece of logic.

El recap "While you slept · N shipped · M await review" no es decorado: viene de un endpoint del motor que agrega traces (la bitácora paso a paso de cada ejecución) y artifacts (los entregables que produce un SuperSkill) REALES de las últimas 24 horas. Y es fail-soft: si el motor no responde en 2.5 segundos, la página carga igual — el motor nunca puede tumbar la experiencia.

The "While you slept · N shipped · M await review" recap is not decoration: it comes from an engine endpoint that aggregates REAL traces (the step-by-step log of each execution) and artifacts (the deliverables a SuperSkill produces) from the last 24 hours. And it is fail-soft: if the engine does not answer within 2.5 seconds, the page loads anyway — the engine can never take the experience down.

Al guardar, un PUT server-side hace que el motor escriba BRIEF.json (la fuente de verdad) y derive AUDIENCE.md de forma determinista, siguiendo el estándar abierto audience.md. La escritura es atómica (tmp + rename) y el workspace_id se valida como UUID antes de tocar el filesystem (anti path-traversal). Tres PlanTemplates llevan un paso s0_audience — una lectura pura de filesystem — que inyecta el bloque OFFICE BRIEFING en el prompt de los agentes redactores. Verificado con prueba de palabra distintiva: lo que escribes aparece en el prompt del agente y moldea el output.

On save, a server-side PUT makes the engine write BRIEF.json (the source of truth) and deterministically derive AUDIENCE.md, following the open audience.md standard. The write is atomic (tmp + rename) and the workspace_id is validated as a UUID before touching the filesystem (anti path-traversal). Three PlanTemplates carry an s0_audience step — a pure filesystem read — that injects the OFFICE BRIEFING block into the composer agents' prompt. Verified with a distinctive-word test: what you write shows up in the agent's prompt and shapes the output.

Los 4 SuperSkills LIVE forman un catálogo cerrado: el servidor de la app solo acepta lanzar specs que existen en ese catálogo, con inputs tipados y validados. No hay forma de inyectar un SuperSkill arbitrario desde el navegador — el detalle completo de esa validación está en el paso siguiente.

The 4 LIVE SuperSkills form a closed catalog: the app server only accepts launching specs that exist in that catalog, with typed, validated inputs. There is no way to inject an arbitrary SuperSkill from the browser — the full detail of that validation is in the next step.

El navegador manda SOLO {workflowId, input}. El servidor valida contra el catálogo cerrado (tipos, longitudes, URLs http/https únicamente, protección anti prototype-pollution) y construye el Intent completo del lado del servidor (el Intent es la declaración formal del trabajo pedido: qué se quiere, quién lo declara y con qué límites) — declared_by es tu email normalizado al patrón de actores, el workspace y los constraints son constantes del servidor. Va al motor con bearer token. El motor compila el Intent a un Plan (un grafo tipado —DAG— de 8-9 pasos encadenados) y lo ejecuta con Inngest (el runtime de workflows durables: la ejecución sobrevive reinicios). Nada de esto "instala software": declaras una intención y el motor la compila.

The browser sends ONLY {workflowId, input}. The server validates against the closed catalog (types, lengths, http/https URLs only, anti prototype-pollution protection) and builds the full Intent server-side (the Intent is the formal declaration of the requested work: what is wanted, who declares it, and under which limits) — declared_by is your email normalized to the actor pattern; workspace and constraints are server constants. It goes to the engine with a bearer token. The engine compiles the Intent into a Plan (a typed graph —DAG— of 8-9 chained steps) and runs it with Inngest (the durable workflow runtime: executions survive restarts). None of this "installs software": you declare an intention and the engine compiles it.

Cada tarjeta sale de traces reales del motor: un join a plans más la agregación de step_executions, en 4 queries fijas (sin N+1). Ves paso actual/total y el costo acumulado en dólares — la suma de los costos por paso. Los nombres legibles se mapean por template: un template desconocido jamás filtra su id interno a la pantalla. Pause/Abort todavía no existen (van en v2) — por eso no hay botones que prometan lo que no hay.

Each card comes from real engine traces: a join to plans plus an aggregation over step_executions, in 4 fixed queries (no N+1). You see current/total steps and the accumulated cost in dollars — the sum of per-step costs. Human-readable names are mapped per template: an unknown template never leaks its internal id to the screen. Pause/Abort do not exist yet (slated for v2) — which is why there are no buttons promising what is not there.

El feed lee artifacts reales del motor, cada uno con su Trace. El detalle muestra tres capas: el contenido; las "memorias aplicadas" — los claims (piezas de memoria estructurada: hechos tipados que el equipo acumula y consulta) que ese run consultó; y "cómo se hizo" — el timeline humanizado del Trace con el costo en dólares de cada paso.

The feed reads real artifacts from the engine, each with its Trace. The detail view shows three layers: the content; the "applied memories" — the claims (pieces of structured memory: typed facts the team accumulates and consults) that run consulted; and "how it was made" — the humanized Trace timeline with each step's cost in dollars.

Approve/Reject dispara un POST server-side que emite un evento Inngest. Del otro lado hay un gate durable suspendido — un paso (step.waitForEvent) que espera tu decisión hasta 24 horas sin consumir recursos — que resume al instante: el artifact queda aprobado y se escriben ~5 claims tipados (approvedBy, approvalComment…) que los SuperSkills futuros consultan. Si nadie decide en 24 horas, el artifact pasa al estado terminal expired con su claim de expiración — sin huérfanos. Esta es LA tesis del producto: cada decisión humana se vuelve memoria estructurada consultable.

Approve/Reject fires a server-side POST that emits an Inngest event. On the other side sits a suspended durable gate — a step (step.waitForEvent) waiting up to 24 hours for your decision without consuming resources — which resumes instantly: the artifact is approved and ~5 typed claims are written (approvedBy, approvalComment…) that future SuperSkills consult. If nobody decides within 24 hours, the artifact moves to the terminal expired state with its expiry claim — no orphans. This is THE product thesis: every human decision becomes queryable structured memory.

El estado multi-squad se guarda en el perfil del usuario: tus squads te siguen a cualquier navegador o dispositivo. Por detrás, el navegador conserva una copia local como cache (si el perfil aún no sincronizó, se usa la copia local; si tampoco existe, se deriva del roster), y cada cambio se escribe al perfil en orden — nunca dos escrituras en paralelo que puedan pisarse. El servidor re-valida el contenido en cada escritura: datos con forma inválida o basura extra no persisten. Las zonas 3D se recalculan del mismo layout puro del paso 14, y crear un squad dispara la animación de construcción en la oficina.

Multi-squad state is stored in the user profile: your squads follow you to any browser or device. Under the hood the browser keeps a local copy as cache (if the profile never synced, the local copy is used; failing that, squads are derived from the roster), and every change is written to the profile in order — never two parallel writes that could clobber each other. The server re-validates the content on every write: malformed shapes or junk fields do not persist. The 3D zones are recomputed from the same pure layout as step 14, and creating a squad triggers the construction animation in the office.

El alta agrega el agente al roster en tu perfil de InsForge, con su asignación a squad. El "primer workflow" se asigna, no se ejecuta — la ejecución real siempre pasa por la Library, con todas las validaciones del paso 18. Coherente con el modelo: contratar un agente es ampliar el catálogo de identidades, no levantar infraestructura.

The hire adds the agent to the roster in your InsForge profile, with its squad assignment. The "first workflow" is assigned, not executed — real execution always goes through the Library, with all the validations from step 18. Consistent with the model: hiring an agent extends the catalog of identities, it does not spin up infrastructure.

Conversar no requiere un proceso esperándote: requiere memoria + un timbre. Tu mensaje enciende una función serverless, que llama al motor, que arma a Karina EN ESE INSTANTE: su persona + tu briefing + sus últimos trabajos con tus comentarios de aprobación + el hilo de la conversación (persistido en el motor). El modelo responde siendo Karina — no porque estuviera despierta, sino porque su memoria lo sabe. Costo marginal $0 (sesión de suscripción). La continuidad de un agente vive en su memoria, no en un proceso.

Talking requires no waiting process: it requires memory and a doorbell. Your message fires a serverless function that calls the engine, which assembles Karina at that instant: her persona + your briefing + her latest work with your approval comments + the conversation thread (persisted in the engine). The model responds as Karina — not because she was awake, but because her memory knows. Marginal cost $0 (subscription session). An agent's continuity lives in memory, not in a process.

El usuario nunca navega un catálogo: le pide a Nova en sus palabras. Una sola consulta al modelo decide entre tres desenlaces. MATCH: el pedido corresponde a un SuperSkill existente — Nova lo reconoce, extrae el dato del pedido (editable) y lo lanza por el flujo normal. El paso 26 muestra el tercer desenlace (COMPONER). Tercer desenlace no capturado: si el pedido requiere una capacidad que no existe, Nova lo dice honesto y el pedido queda registrado — la lista de "no pude" es demanda real que prioriza qué construir.

The user never browses a catalog: they ask Nova in plain language. A single model call decides among three outcomes. MATCH: the request corresponds to an existing SuperSkill — Nova identifies it, extracts the input (editable), and routes it through the normal flow. Step 26 shows the third outcome (COMPOSE). Third outcome not shown: if the request requires a capability that doesn't exist, Nova says so honestly and the request is logged — the "couldn't do it" list is real demand that prioritizes what to build next.

COMPONER: no hay SuperSkill exacto — Nova arma un plan nuevo combinando SOLO operaciones del catálogo del motor; el servidor lo valida en 4 capas (cada operación debe existir, el grafo no puede tener ciclos, máximo de pasos, y el punto de aprobación humana final es FORZADO por el servidor — el modelo no tiene camino para saltárselo); el costo estimado lo calcula el servidor desde el catálogo (el modelo no puede mentirlo); el usuario ve el plan en humano y decide. Doble control humano siempre: una aprobación al plan, otra al resultado.

COMPOSE: no exact SuperSkill exists — Nova assembles a new plan using ONLY operations from the engine's catalog; the server validates it in 4 layers (each operation must exist, the graph cannot have cycles, step limit, and the final human approval gate is FORCED by the server — the model has no path to skip it); the estimated cost is computed server-side from the catalog (the model cannot lie about it); the user reviews the plan in human language and decides. Double human control always: one approval on the plan, one on the result.

El modelo emite tokens; cada uno viaja hasta tu pantalla sin esperar al resto. La cadena completa: el motor lee el stream del modelo línea a línea y lo re-emite como eventos SSE → nginx con buffering apagado para esa ruta → la función serverless de la app NO acumula: re-transmite el body progresivamente → el navegador parsea los eventos y pinta cada delta en la burbuja. Solo el texto final del modelo se emite — el razonamiento interno jamás llega al usuario. Si el stream se corta antes del primer fragmento, la app degrada al camino clásico (una respuesta completa) con un reintento; la reply se persiste en el historial solo si llegó completa — no quedan respuestas a medias.

The model emits tokens; each travels to your screen without waiting for the rest. The full chain: the engine reads the model's stream line by line and re-emits it as SSE events → nginx with buffering off for that route → the app's serverless function does NOT accumulate: it re-transmits the body progressively → the browser parses the events and paints each delta into the bubble. Only the model's final text is emitted — internal reasoning never reaches the user. If the stream breaks before the first fragment, the app degrades to the classic path (one complete reply) with a retry; the reply is persisted to history only if it arrived complete — no half-written replies remain.

El hilo no vive en tu navegador: vive en el motor (Postgres, una tabla de mensajes por conversación). Al abrir el chat con la sesión vacía, la app le pide al motor el último hilo de ese agente y lo restaura. Fail-soft deliberado: si el motor no responde, el chat abre vacío e igual funciona — recuperar historial nunca bloquea conversar. La memoria en curso siempre manda: la restauración jamás pisa una conversación que ya está abierta. Y enviar un mensaje continúa el mismo hilo — por eso el agente retoma el contexto en vez de empezar de cero.

The thread doesn't live in your browser: it lives in the engine (Postgres, one message table per conversation). When the chat opens with an empty session, the app asks the engine for that agent's latest thread and restores it. Deliberately fail-soft: if the engine doesn't answer, the chat opens empty and still works — history recovery never blocks talking. The in-progress memory always wins: restoration never overwrites an open conversation. And sending a message continues the same thread — which is why the agent picks up the context instead of starting over.

Guardar es promover: el plan compuesto se copia tal cual a un catálogo del workspace en el motor — pero el servidor lo valida OTRA VEZ contra el catálogo de operaciones antes de insertarlo (un plan que dejó de ser válido no entra al catálogo). Guardar dos veces el mismo borrador es imposible: una restricción única en la base lo rechaza, gane quien gane la carrera. El "formulario" del SuperSkill no lo inventa nadie: se deriva mecánicamente de los datos variables que el propio plan declara.

Saving is promoting: the composed plan is copied verbatim to a workspace catalog in the engine — but the server validates it AGAIN against the operations catalog before inserting (a plan that stopped being valid doesn't enter the catalog). Saving the same draft twice is impossible: a unique constraint in the database rejects it, whoever wins the race. The SuperSkill's "form" is invented by no one: it derives mechanically from the variable inputs the plan itself declares.

La library lee tus SuperSkills activos del motor server-side, fail-soft (si el motor no responde, la library carga igual, sin la sección). Nova también los ve: en pedidos futuros puede reconocer "eso ya lo tenés guardado" y ofrecerte tu SuperSkill en vez de componer de cero. Ese reconocimiento se valida server-side contra la lista real del workspace — el modelo no tiene forma de inventar un SuperSkill que no existe, y lo que se muestra viene de la base, nunca del texto del modelo.

The library reads your active SuperSkills from the engine server-side, fail-soft (if the engine doesn't answer, the library loads anyway, without the section). Nova sees them too: on future requests she can recognize "you already have that saved" and offer your SuperSkill instead of composing from scratch. That recognition is validated server-side against the workspace's real list — the model has no way to invent a SuperSkill that doesn't exist, and what's displayed comes from the database, never from the model's text.

Lanzar un SuperSkill propio pasa por EXACTAMENTE el mismo camino que los de fábrica: el servidor compila el plan y verifica estructuralmente que el punto de aprobación humana exista, sea terminal y no tenga escapatoria — también en los planes guardados; ningún plan sin gate humano puede ejecutarse. Los datos que editás se filtran contra los que el plan declara: nada extra viaja al motor. Nota de honestidad: en esta verificación el harness abre el modal, comprueba los datos pre-llenados y CANCELA — encolar trabajo real en cada corrida ensuciaría el feed de outputs. El lanzamiento real está cubierto por la suite E2E y fue verificado en vivo con un trace real al construir la feature.

Launching your own SuperSkill goes through EXACTLY the same path as the factory ones: the server compiles the plan and structurally verifies that the human approval gate exists, is terminal, and has no way around it — in saved plans too; no plan without a human gate can run. The inputs you edit are filtered against those the plan declares: nothing extra travels to the engine. Honesty note: in this verification the harness opens the modal, checks the pre-filled inputs and CANCELS — queueing real work on every run would pollute the outputs feed. The real launch is covered by the E2E suite and was verified live with a real trace when the feature was built.

Esto itera SIN un agente de horizonte largo: cada turno es una llamada acotada (60s, un reintento) y la memoria del diálogo vive en el navegador — el transcript completo viaja en cada request y el servidor es stateless. El modelo solo puede responder de tres formas validadas: proponer SuperSkills de una lista cerrada, repreguntar (cap de 2 por conversación, FORZADO por el servidor: agotado el cupo, el prompt lo prohíbe y la validación rechaza el intento), o decir honesto que no puede. El harness manda deliberadamente un pedido ambiguo: si Nova repregunta, responde y verifica que el hilo llegue a propuesta; si propone directo, el diálogo igual queda probado.

This iterates WITHOUT a long-horizon agent: each turn is one bounded call (60s, one retry) and the dialogue's memory lives in the browser — the full transcript travels with every request and the server stays stateless. The model can only answer in three validated ways: propose SuperSkills from a closed list, ask back (capped at 2 per conversation, ENFORCED server-side: once spent, the prompt forbids it and validation rejects the attempt), or honestly say it can't. The harness deliberately sends an ambiguous request: if Nova asks back, it answers and verifies the thread reaches a proposal; if it proposes directly, the dialogue is proven anyway.

El LLM elige trabajo; el servidor deriva personas. La recomendación pasa una triple whitelist (validación en el motor, re-validación en el proxy, y derivación que ignora ids desconocidos) — un SuperSkill inventado por el modelo no tiene camino físico hasta tu pantalla. El squad se calcula con una función pura y determinista: la unión de los firmantes de los skills elegidos, con Karina siempre primera como chief. Y cada necesidad no cubierta se registra en el motor como demanda real — la lista de "no pude" prioriza qué construir. Esa telemetría se acumula solo en la primera propuesta de cada conversación: pedir ajustes no infla la señal.

The LLM chooses work; the server derives people. The recommendation passes a triple whitelist (engine validation, proxy re-validation, and a derivation that ignores unknown ids) — a SuperSkill invented by the model has no physical path to your screen. The squad is computed by a pure, deterministic function: the union of the signers of the chosen skills, with Karina always first as chief. And every uncovered need is recorded in the engine as real demand — the "couldn't do it" list prioritizes what to build. That telemetry accrues only on each conversation's first proposal: asking for adjustments doesn't inflate the signal.

Instalar es UNA escritura atómica al perfil (squad + skills equipados juntos, por la misma cola serializada que protege todo el estado del usuario — dos escrituras en vuelo jamás se pisan) y funciona multi-dispositivo: el equipo que armaste acá te espera en cualquier navegador. El fail-soft es total por diseño: el panel entero vive COLAPSADO por default y el camino curado no cambió un pixel — los tests del flujo original corren sin tocarse. Contratar a estos agentes no enciende infraestructura: son las mismas fichas de identidad firmando el mismo catálogo del motor.

Installing is ONE atomic write to the profile (squad + equipped skills together, through the same serialized queue that protects all user state — two in-flight writes never clobber each other) and it works multi-device: the team you built here awaits you in any browser. Fail-soft is total by design: the whole panel lives COLLAPSED by default and the curated path didn't change a pixel — the original flow's tests run untouched. Hiring these agents spins up no infrastructure: they're the same identity cards signing the same engine catalog.