Credenciales incorrectas
Comparison of github.com/garrytan/gstack against the IKA Concierge Architecture (current state + planned). Companion to /ika-pro-architecture. Compiled 2026-04-25.
gstack is a 23-skill prompt framework for solo or small developer teams shipping software through Claude Code: think → plan → build → review → test → ship → reflect. Heavy on PR workflow, code review, design exploration, security audits, real-browser QA. CLI-first, no UI, no multi-tenant, no client-facing surface. MIT, by Garry Tan (YC).
IKA is a client-facing prosumer product (BI + Operations) with a fractal-neuron UI, drag-drop entities, multi-tenant per-IKA isolation, Pomodoro + permissions + phases + integrations. Different problem.
Where they overlap: both are meta-tools driving Claude Code. IKA's Builder shell is the comparable surface — that's where to apply gstack lessons.
Steal: sprint-chained skill output, Conductor-style parallel orchestration, /codex-style multi-vendor second opinion, design-shotgun (4–6 mockup variants for design iteration), GBrain-shaped persistent knowledge, prompt injection defense, smart review routing, /qa with auto-regression-test generation.
Skip: the sidebar agent in headed Chromium (we have our own UI), gstack's git-repo-as-knowledge-sync (we have Postgres), the OWASP/STRIDE skill (overkill for our scope today), the cross-machine session sync (we're hosted).
| Project | One-sentence | Domain |
|---|---|---|
| gstack | "Virtual engineering team" of 23 skills that orchestrate sprint-based PR shipping through Claude Code. | Developer workflow / code shipping |
| IKA today | Vanilla HTML+JS+Three.js BI dashboard at msp.ika.ai with an embedded Builder side panel for me/Mats to coordinate work. | Client BI + internal meta-tool |
| IKA planned | React+Vite+TS prosumer app with BI shell + Operations shell (fractal neurons, drag-drop, projects/tasks/people/events/notes/docs/automations, MCP integrations, multi-IKA isolation), backed by a forked Paperclip harness. | Client-facing AGI-UX for an AI-first company / AI-managed life |
| Capability | gstack | IKA today | IKA planned |
|---|---|---|---|
| Target user | Tech founders / small dev teams | Mats + clients (BI demos) | Prosumers (business owners + their personal life) |
| Domain | Software shipping | BI dashboard + builder ops | Operations OS + BI |
| UI shape | CLI + headed Chromium sidebar agent | Web (vanilla HTML) | Web (React+Vite+TS) + voice |
| Multi-tenant | Per-repo trust tier; not user-tenant | Per-tenant feed/tasks (msp/main scopes) | N IKAs per user, separate Postgres DB per IKA |
| Org chart / departments | No | No | Yes — fractal neurons (recursive) |
| Tasks | Implicit per PR + checkpoint commits | First-class (ika-tasks.json + UI) | First-class with subtasks (recursive) + Pomodoro + priority |
| Projects | One per repo | No | First-class with phases (Initiation→Follow-up) |
| People (humans) | No (single user) | No | First-class entity with role/email/avatar/permissions |
| Events / calendar | No | No | First-class (FullCalendar) + countdown radial |
| Notes | CLAUDE.md, design docs, GBrain pages | No | Block editor (BlockNote) + permissions per note |
| Documents (Drive integration) | No | No | @uppy/react + Companion + Drive OAuth |
| Drag-drop matrix between entities | No | No | Yes — every entity, polymorphic container_type/id |
| Automations | Checkpoint mode, auto-doc-sync, /ship pipeline | No | Per-neuron + global, triggered by events/state/schedules |
| Phases (project structure) | Sprint stages (think→plan→build→…) but per-skill, not per-project | No | First-class, customizable per project |
| Priority | No (PR-level only) | No | High/Medium/Low on Task/Project/Event |
| Permissions / ACL | Per-repo GBrain trust (rw/ro/deny) | No | 5-level per-entity ACL (Full/Edit/Comment/Read/None) |
| MCP integration | GBrain as MCP server; /pair-agent for cross-vendor | No | Operations layer connects Slack/Gmail/Drive/Premiere/Photoshop/etc through agents |
| Multi-vendor agent coordination | /codex (OpenAI), /pair-agent (Hermes/Cursor/Codex/OpenClaw, shared browser) | No | Paperclip is multi-provider but no /pair-agent equivalent yet |
| Knowledge persistence across sessions | GBrain (PGLite or Supabase) + /learn skill + checkpoint commits | ~/.claude/projects/.../memory/MEMORY.md (auto-memory) | Same as today + per-IKA Postgres for richer recall |
| Browser automation / QA | /qa opens Chromium, finds bugs, fixes, regression tests, re-verifies | Playwright installed (~/browse.py), used ad-hoc | Playwright as mandatory e2e for both v3.0 / v3.5 tracks |
| Design exploration | /design-shotgun — 4–6 mockup variants + taste-learning + comparison board | No | No (could steal — see below) |
| Code review | /review (staff engineer) + /codex (second opinion) + /cso (security) | No | Out of scope (we're not a dev workflow product) |
| Prompt injection defense | 22MB ML classifier + DeBERTa ensemble + canary tokens | No | Worth considering for Operations agents touching email/docs |
| Cross-machine session sync | Private git repo as memory store | N/A (hosted) | N/A (hosted, multi-tenant) |
| Mobile | No (CLI only) | Mobile Safari/Chrome work | Mobile-first design priority |
| Voice | No | Already built into Builder | Carried into Operations shell |
| Maturity | v0.19, MIT, very active (2026), YC president authored | Internal, no public release | Plan only |
The 8 items below in "What to steal from gstack" are the canonical action list. The later section "What gstack does better than us" is a descriptive gap analysis — its items overlap with the steal list but it's not a separate ranked queue. We work from the steal list (now 7 active + 1 dropped after v12.3).
Each gstack skill produces structured output that the NEXT skill consumes — "no handoff gaps." Today our sub-agent dispatch is parallel but flat (each agent gets a prompt, returns a result, main agent synthesizes). Adopting structured chains for Operations automations: e.g. an agent investigates → drafts plan → human approves → another agent executes → third agent verifies. Maps cleanly to Paperclip's heartbeat + governance model.
gstack's Conductor runs 10–15 parallel Claude Code sessions, each on its own sprint. For us this maps to: parallel sub-agent dispatch (which we already do) BUT with structured sprint state per agent (current step, pending dependencies, output artifact). Useful for our v3.0 + v3.5 build where Claude and Codex are both running independent tracks — adopt the orchestration pattern even though we won't use Conductor literally.
For Operations actions with high stakes — second-opinion review by a different model before execution. gstack uses OpenAI Codex CLI as the cross-checker; we'd use the same. Pairs with Paperclip's approval gate: high-priority automations require both Claude Sonnet AND a second model to approve.
Per-IKA setting exposed in the chrome's settings panel: "Require second-opinion review when… [checkboxes]". Combined OR (any one trigger fires the second opinion). Sensible defaults shipped:
| Trigger | Default threshold | Rationale |
|---|---|---|
| Spend per call | > $25 (one-shot) OR > $100/day cumulative for that automation | Catch costly LLM/API calls, agent loops, paid integrations |
| External recipients | Any message to a person NOT in this IKA's people list (= someone outside the org/family) | Anything leaving the tenant boundary deserves a check |
| External recipients (mass) | > 5 recipients in a single send, regardless of in/out | Mass-blast guardrail |
| Entity priority chip | Always for High; Medium = configurable; Low = never | Priority is the user's own signal; respect it |
| Money movement | Always (Stripe/QuickBooks/Plaid/banking integrations) — no threshold opt-out | Hard rule, not configurable per-IKA |
| Identity / permissions changes | Always | Adding people, changing ACL, removing entities — non-bypassable |
| External-content ingest | Sample at 1/10 calls (cheaper sanity check) | Cost-managed coverage, not full duplicate-cost on every read |
UX in chrome: a toggle list in Settings → Governance → Second Opinion. Each row's threshold is editable; some are non-bypassable (greyed-out toggle with tooltip explaining why).
Mats's call: do not implement. Strikethrough kept for traceability.
For IKA Concierge UI iteration: when designing a new neuron-shell screen, generate 4–6 mockup variants in parallel (different layouts, typography, color treatments), display in a comparison board, user picks one. Taste memory remembers preferences with 5%/week decay so future variants bias toward what we've approved.
gstack's GBrain is an MCP-served knowledge base scoped per-repo with trust tiers (read-write / read-only / deny). For Operations we want similar: per-tenant agent memory, scoped, with trust gates (an agent in the family-department can read family notes but not finance). Implement as an MCP server backed by per-IKA Postgres. Composes with the rest of our MCP integrations.
Mats's call: launch blocker. No Operations agent ingests external content without this. Operations agents will read external data (emails, scraped pages, Drive docs, Slack messages) — every one is an injection vector. gstack ships a 22MB local ML classifier + Haiku transcript vote + canary tokens + optional 721MB DeBERTa-v3 ensemble. We integrate the lightweight classifier (start with 22MB local) plus canary tokens in every agent system prompt; the heavy 721MB ensemble is opt-in for high-risk tenants.
gstack auto-detects diff type and skips irrelevant reviews (backend changes don't need design review). For Operations: different governance for different automation types. A Slack-message automation needs lighter review than a Stripe-refund automation. Encode the routing rules in Paperclip's approval pipeline.
gstack's /qa opens a real browser, finds bugs, fixes them, AUTO-WRITES a regression test, re-verifies. We already plan Playwright as mandatory e2e — adopt the auto-regression-on-fix pattern so every bug becomes a permanent test. Reduces drift between v3.0 and v3.5 because the same auto-generated tests run against both.
gstack has zero UI for end-users. It's a CLI tool for the developer who installed it. IKA Concierge is a full client-facing product with a neuron shell, drag-drop, mobile, voice, real-time. Different category entirely.
gstack is single-user-single-machine. IKA does N IKAs per user, separate Postgres DB per IKA, plus tenant resolution via Host header. Built for a SaaS shape; gstack isn't.
Recursive neurons (no depth cap), every entity draggable into every other entity, polymorphic container_type/id. gstack has no comparable structure — its entities are skills, sprints, PRs.
Humans-in-the-loop with permissions, avatars, calendars, message threads. gstack treats only agents. For a prosumer-facing product where the user runs their family/team/business, this is fundamental.
gstack's MCP usage is for knowledge (GBrain) + cross-vendor agent routing. IKA Operations connects Slack/Gmail/Drive/Premiere/Photoshop/Stripe/CRM — agents call them to EXECUTE tasks. Different MCP usage pattern.
Our Builder workflow is loose: work.sh, done.sh, snapshot.sh, sub-agent dispatch on demand. gstack's structured think→plan→build→review→test→ship→reflect with each step's output feeding the next is genuinely better engineering. We should adopt that shape for our Operations automation pipelines.
gstack ships a custom Chromium wrapper with an in-browser sidebar that takes natural-language commands and executes against the page. We have voice and Builder side-panel, but a "browser sidebar that drives any web page" is a distinct UX gstack nailed.
Multiple agents from different vendors (Claude, Codex, Cursor, Hermes, OpenClaw) sharing one browser session with tab isolation and scoped tokens. Our Paperclip is multi-provider on the backend but doesn't compose them in a single session like this.
Per-repo trust policy (read-write / read-only / deny), MCP-served, optional cross-machine sync via private git repo. Our auto-memory is grep over markdown — much weaker.
4–6 variants, comparison board, persistent taste memory with decay. We iterate by you giving feedback in feed; gstack's pattern is more efficient when you don't yet know what you want.
/qa is a one-command pipeline: open browser → find bugs → fix → write regression test → re-verify. We have Playwright but use it ad-hoc. Their integration is cleaner.
While auditing Garry Tan's github we found gbrain (11.4k★, MIT, TypeScript/Bun) — separate from gstack but in the same author's ecosystem. This is the canonical implementation of the GBrain pattern referenced in steal-item #5. Worth a separate look because the pattern we wanted to "build inspired" already has a working reference.
| Property | Value |
|---|---|
| Pitch | "AI agents are smart but forgetful." gbrain gives them persistent memory through a self-wiring knowledge graph + hybrid search + 29 operational skills. |
| Stack | TypeScript/Bun · PGLite (default) or Supabase Postgres · pgvector + recursive CTEs · OpenAI embeddings + tsvector keyword search + RRF fusion |
| Hybrid-search benchmark | P@5 = 49.1% (hybrid) vs 22.1% (vector-only) — significant precision gain |
| Self-wiring graph | Auto-extracted typed links with NO LLM calls: attended · works_at · invested_in · founded · advises |
| Compiled-truth pattern | Immutable evidence trail beneath assertions; assessments outrank timeline noise in retrieval |
| Backlink-boosted ranking | Well-connected entities rank higher in search (PageRank-shape signal) |
| 29 skills | Signal detection · enrichment · ingestion · cron scheduling · reports · data research · task management · skill audit |
| MCP server | 30+ tools (search · graph-query · put_page · ingest · extract links · job submission · skill audit) · stdio + HTTP modes |
| Multi-source ingestion | Meetings · emails · tweets · articles · PDFs · voice calls · GitHub repos |
| Operational | "Minions" durable job queue (survives crashes, no token cost vs sub-agents) · skillify pipeline (turn bugs into tested skills) · nightly "dream cycle" (enrichment + citation audit + orphan detection) |
| License | MIT |
| Approach | Verdict |
|---|---|
| Adopt gbrain wholesale | No — single-user (PGLite) by default; multi-tenant adaptation needed; Bun in our stack adds complexity (we're Node + React) |
| Adopt gbrain via Supabase mode | Possible but commits us to Supabase + Bun — a stack divergence we'd rather avoid |
| Study gbrain as the canonical reference; vendor specific modules; build our own on per-IKA Postgres + pgvector | Pick this. Lift the algorithms (typed-link extraction without LLM calls; hybrid-search RRF fusion; backlink boosting; compiled-truth pattern) and implement on our existing infra. |
Mats greenlit all six. Here is the why-we-adopt rationale per item — token math, infra fit, and where it slots into our per-IKA Postgres + ltree + pgvector implementation.
| Lift | What it does | Why we adopt it (the rationale) | Where it lives in our stack | Effort |
|---|---|---|---|---|
| 1. Typed-link extraction without LLM calls | Deterministic markdown parser that detects relationship verbs (attended, works_at, reports_to, blocks, mentions, etc.) and writes typed edges to the graph. Pure regex + grammar — no model call. |
Cost. Every alternative (LLM-driven entity-relation extraction) costs ~500–2000 tokens per chunk and runs on every ingest. At an active-IKA scale of ~5k notes/month that's $30–120/month/IKA in extraction alone. gbrain's pattern is free, deterministic, and audit-friendly. Latency. Synchronous at ingest time vs queueing for an LLM pass. Multi-tenant safety. No prompt-injection surface — the parser can't be tricked by hostile note content into "extracting" arbitrary relations. Cap on weirdness. Typed-link vocabulary is finite and documented; LLM extraction drifts. | Paperclip ingest pipeline (Node side, before the Postgres write). Edges land in a links(src_neuron, dst_neuron, type, source_chunk) table. |
~2 days port + adapt vocabulary to our 13-entity model |
| 2. Hybrid-search RRF fusion | Reciprocal Rank Fusion: run vector search (pgvector) and keyword search (tsvector) independently, then merge ranks with the formula score = Σ 1/(k + rank_i). ~50 lines. |
Recall. Vector alone misses exact-match queries ("show me the Q3-2026 forecast"); keyword alone misses semantic queries ("what did we decide about pricing"). RRF gets both for free. No tuning knobs that drift. Unlike weighted-sum fusion (where weights need re-tuning per corpus), RRF is parameter-free in practice (k=60 is the published default and just works). Battle-tested. RRF is the de-facto standard in Elastic/OpenSearch hybrid retrieval — gbrain's port is one of the cleanest small implementations in the wild. Portable. 50 lines of TS → 50 lines of Go in the Paperclip retrieval handler. | Paperclip retrieval endpoint (Go). Used by every neuron's "ask" + every BI prompt that pulls user context. | ~1 day port to Go + tests |
| 3. Backlink-boosted ranking | Count incoming typed-links per neuron; multiply retrieval score by log(1 + backlink_count). Promotes "popular/canonical" nodes in retrieval. |
Free signal. The graph already exists (from lift #1). Backlink count is one Postgres aggregate — zero new infra. Mirrors PageRank intuition. If 12 notes reference a single "Q3 strategy" neuron, that neuron is the canonical answer to most strategy queries — boost it. Better than recency-weighting alone. Recency surfaces noise (today's scratchpad); backlink surfaces structure (the document everyone cites). Combines naturally with RRF. Apply boost after fusion so it nudges, doesn't override semantic match. | Postgres view + a multiplier in the retrieval handler. Same place as RRF. | ~½ day |
| 4. Compiled-truth schema convention | Two-tier storage: events (raw timeline — every meeting, every message, every action) vs assessments (curated, high-trust statements — "Mats decided X on date Y because Z"). Retrieval prefers assessments; falls back to events. |
Signal-to-noise. Without this split, retrieval drowns in raw timeline. With it, the agent answers "what did we decide about pricing" with the assessment ("on 2026-04-12 we set $99/mo") instead of pasting six Slack threads. Audit trail intact. Events stay forever — assessments link back to the events that justified them. Schema convention is cheap to enforce. Two tables, one foreign key. The hard part is the discipline of writing assessments — gbrain's dream-cycle (lift #5) does this automatically. Maps cleanly to our Timeline tab vs Data tab per neuron. | Postgres schema in the per-IKA DB. events + assessments tables exist in every IKA's namespace. |
~1 day schema + migration helper |
| 5. Nightly dream-cycle as Paperclip heartbeat | A scheduled job that, per IKA, walks new events since last run and: (a) writes/updates assessments, (b) audits citations (assessment must cite ≥1 event), (c) enforces backlinks (every typed-link has reciprocal), (d) detects orphan neurons (no in/out edges). | This is what makes the graph self-healing. Without it, the graph degrades silently — orphans accumulate, assessments go stale, citations break. Off-peak token spend. The single biggest LLM cost in the whole system (the assessment-writer pass) runs at 3am, not in the request path. Per-IKA isolation matches our infra. Each IKA's heartbeat runs against its own Postgres — no cross-tenant leakage. Operational visibility. Heartbeat output → Builder feed entry per IKA per night ("dream-cycle: 47 events → 12 assessments, 0 orphans, 1 broken citation flagged"). Cron-shape fits Paperclip. Paperclip already has a cron primitive; this is a job definition, not a new subsystem. | Paperclip cron job. Runs per-IKA. Writes back to that IKA's Postgres + posts a summary to Builder feed. | ~3 days (cron registration + assessment-writer prompt + audit checks + feed integration) |
| 6. Skillify pipeline (bug → permanent skill) | 10-item checklist for converting a one-off agent fix into a reusable, tested skill: scaffold → write → audit → route → register → test → document. gbrain ships a working version. | Compounding leverage. Without this, every bug-fix is a one-shot — next week the agent makes the same mistake. With it, the fix becomes a skill that prevents the class of bug forever. Pairs perfectly with our v19.5 skill-creator meta-skill. Skill-creator is the primitive ("how do I author a new skill"); skillify is the workflow ("when do I author a new skill, and how do I close the loop"). Forces test-coverage discipline. A skill without a test fails the audit step → can't be registered. This is how we make the skill catalog trustworthy at scale. Routes through our existing Skills tab per neuron — registered skills become discoverable assets. The 10-step checklist is the asset. The code that runs it is small; the value is the checklist's coverage of failure modes (gbrain's authors learned these the hard way). | Lives as a meta-skill in the global Skills catalog. Triggered by the user (or the Builder) saying "skillify this fix" after any agent-resolved bug. | ~2 days (meta-skill definition + audit-step prompts + register-step wiring into our Skills catalog) |
Total adopt-cost: ~9.5 days. Every lift earns its place on a different axis: #1 = cost, #2 = recall, #3 = signal, #4 = schema discipline, #5 = self-healing, #6 = compounding leverage. None overlap; none are "nice to have."
What we are explicitly NOT taking from gbrain: Bun runtime, PGLite, Supabase shim, OpenClaw/Hermes coupling, Twilio voice. These are stack-divergence not capability-gaps — covered in the "What to skip" section below.
Adding gbrain pattern lifts to the existing gstack #5 plan (~1 week per the original) probably makes it ~10 days total: +3 days to study gbrain code + extract the specific algorithms + adapt to our Postgres + Go schema. Worth it — the typed-link extraction without LLM calls alone could save real token cost across a large IKA.
You asked. My read is split — pick per item, not per project.
| What to lift | Why |
|---|---|
| Prompt-injection ML classifier (22MB) + canary token format | Trained model weights are an artifact, not workflow code. Re-training would cost weeks + GPU; their model is already tuned and battle-tested. MIT license = lift outright with attribution. |
| Anti-bot stealth modules (if we ever scrape on agents' behalf) | Empirical fingerprinting evasion that takes months to discover; lift the existing patterns. |
| OWASP/STRIDE prompt templates from /cso | If we ever need security review automations, their prompts encode hard-won expertise. Cheap to copy. |
| What to write fresh | Why |
|---|---|
| Sprint chaining (#1) | Their chains are bound to Claude Code's skill system. Our runtime is Paperclip + React. Forking the code = fighting their abstractions. Pattern transfers; code doesn't. |
| Multi-vendor second opinion (#3) | gstack invokes a separate CLI process. We invoke via Paperclip's agent dispatch (in-process). Different shape; pattern is enough. |
| GBrain-shaped knowledge (#5) | Their backend = PGLite or Supabase, abstracted through their own shim. We have Postgres already; we want pgvector. Different storage; same idea. |
| Smart review routing (#7) | Trivial logic, ~50 lines. Faster to write than to extract from their codebase. |
| /qa auto-regression-test (#8) | Their /qa is bound to their browser wrapper. We use plain Playwright. Pattern: fix bug → write test → re-verify; ~100 lines in our test harness. |
| Conductor orchestration (#2) | Their Conductor manages Claude Code session multiplexing. Our equivalent is parallel sub-agent dispatch through Paperclip. Conceptual lift. |
/vendored/gstack/) with a README pointing to the source commit + license.For #6 (the launch blocker): lift their classifier + canary format on day 1. We integrated in 2 days vs 2 weeks of training our own.
For everything else (#1, #3, #5, #7, #8, #2): write our own, with their code open in another tab as reference. Faster long-term — no fork-drift, no API impedance, fits our runtime.
This matches the Paperclip decision (we picked Paperclip because it IS our domain shape; we rejected RuFlo because it WASN'T). gstack lands in between: domain is dev workflow, ours is prosumer ops; lift the rare artifact, write the rest.