AI Manifesto — a stack for turning ideas into code

AI collapsed the cost of turning a rough thought into a working prototype. That part is real, and it's already happening. But "everyone can build now because LLMs exist" is only half true. The half that's missing is this: raw chat access is a transaction. What actually turns rough ideas into shipped software is a stack you own around the model.

This page is the opinion Ideafy is built on. The Philosophy page that follows explains how the kanban board embodies it. Read this first.

The stateless trap

The defining frustration of a first year with AI coding agents is a sentence you've already said out loud: "I already told it this." Every new chat starts from zero. Every decision gets re-argued. Every project convention gets re-introduced. Every preference gets re-stated. The model happily answers the same question the sixth time — but each time at full price, in your attention.

Gartner's prediction that 40% of agent projects fail by 2027 is not about the model. It's about the fact that nobody builds the memory layer underneath.

emergingai.substack, The AI Agent Stack You Actually Need

The model is no longer the bottleneck. The context around the model is. And "context" isn't just whatever you paste into the prompt; it's everything the agent can reliably reach: what it remembers, what recipes it can invoke, what tools it can call, what rules are enforced before it ever gets a turn.

That surface has a name. It's a stack.

Five layers, owned by you

An idea evolves left-to-right: from a rough thought into something worth doing, into a scoped plan, into built code, into a verified build, into a shipped release. The team that carries it runs top-to-bottom — and the team is literally five things: agents, memory, skills, tools (MCP), and hooks. Each layer does something slightly different at each stage of the idea's journey, and it's the intersection of the two axes that matters — not either one alone.

idea-stack-editorial

Read a column to see how the five layers conspire to carry one stage of an idea — who's driving, what gets remembered, which moves the agent knows, which tools commit the decision, which hooks enforce the norm. Read a row to see how one layer shows up at every stage — how memory starts as a product narrative and ends as a frozen chain of thought, or how the agent starts as a listener and ends as an orchestrator.

The five layers, briefly:

  1. Agentswho's driving. The role and mode the agent takes at each moment: evaluator, planner, autonomous builder, interactive collaborator, orchestrator. Not one agent — a cast. Subagents for parallel exploration, primary agents for the conversation, specialist skills invoked for scoped jobs, autonomous runs for well-planned work. Sometimes three worktrees run three agents at once; sometimes a single session binds to a single card. Picking the right mode at the right stage is a design decision, not an accident.

  2. Memorywhat we remember between sessions. Not just "data the model can see," but the shared context a team holds between itself: project rules, past verdicts, the card's full history, the conversation log no one had to take notes on.

  3. Skillsthe moves the agent already knows. Named recipes for recurring kinds of thought — evaluating, planning, writing acceptance criteria — so the same pattern produces the same quality every time.

  4. Tools (MCP)the agent's hands on the real board. The thing that turns a decision into state: an opinion committed, a plan committed, a card moved, a worktree opened. Thoughts evaporate; state doesn't.

  5. Hooksthe room's norms, enforced by the room. The right nudge at the right column, the branch discipline you don't have to remember, the reminders that arrive on time and silently.

And the chain across the top of the picture — rough thought → worth doing? → scoped → built → verified → shipped — is what the five layers are for. Lower layers don't exist for their own sake. They exist to make the next stage of the idea cheap.

Layer by layer — what Ideafy actually ships

Agents — a cast, not a soloist

The single most common mistake in AI tooling is assuming the agent is one thing. It isn't. The useful framing is a cast of agent modes, each scoped to a specific stage:

ModeWhen it runsWhat it does
ListenerA card is opened; the user is thinking out loudThe agent reads the card, the product narrative, the conversation log. No autonomy, no side effects. Just presence.
EvaluatorAn Ideation card needs a verdictA scoped role that produces one thing — an opinion with reasons — and commits it. See Opinion tab.
PlannerA Backlog card is being scopedPlan mode: the agent sketches an approach, pulls docs via @ and cross-references via [[, and commits a plan when you accept it.
Autonomous builderAn In Progress card with a committed planThe agent works inside an isolated worktree with its own dev server, implementing the plan without you in the loop. See Autonomous vs quick-fix.
Quick-fixA small, well-understood bugA tight, one-pass loop: read, patch, test, commit. Fading support for repetitive work.
Interactive collaboratorA card in Human Test that needs adjustmentsThe agent drives an interactive terminal session the user steers turn-by-turn. No full autonomy — shared cursor.
SubagentA scoped research or implementation job inside any of the aboveA child agent with its own context window, spawned to protect the parent's context. Returns one result, then disappears.
OrchestratorA card is ready to mergeRebase onto main, surface conflicts, clean up the worktree, archive the conversation.

Two design decisions live inside this cast:

  • Mode selection is per-stage, not per-session. You don't pick "autonomous" once; the stage of the card picks the mode. An Ideation card doesn't get a builder; a Human Test card doesn't get a planner.
  • Parallelism lives in worktrees, not in the agent. Three features in flight means three worktrees, three isolated dev servers, three agents — not one agent juggling three contexts. See Three features in parallel worktrees. The blast radius of autonomy is a git worktree, not your main branch.

Picking the right mode is where most "my agent went off the rails" stories are actually a casting mistake — an autonomous builder given a rough thought, or a planner asked to merge.

Memory — the foundation

Memory is the thing that stops the agent starting from zero. In Ideafy it's plaintext, in git, readable by you:

  • CLAUDE.md — project rules. Write once; every session from now on inherits them.
  • MEMORY.md + auto-memory files — cross-session facts about you, your preferences, corrections, references. Indexed and loaded on every turn.
  • Product Narrative — vision, users, constraints, non-goals. Generated via the /product-narrative skill from a short interview; read by the agent on every Ideation evaluation.
  • Card fieldsDetail, Opinion, Solution, Tests. A structured chain of thought preserved inside the card. These aren't form fields; they're the memory of how this idea evolved.
  • Conversation log — per-card, per-section. You never reconstruct what was said: the log was already written while you were saying it.

Why plaintext. A memory you can't read by hand is a memory you can't correct. Vector DBs and graph stores belong later in the lifecycle; at the layer that decides whether your agent gets its first five moves right, readable files win.

Skills — reusable recipes the agent can invoke by name

If you've explained something to the agent twice, it should be a skill. Ideafy ships three, installed into .claude/skills/ for every registered project:

SkillWhat it does
/ideafyCard CRUD and pool ops from any Claude Code session
/human-testWrites acceptance criteria before the finish, so "done" has a definition
/product-narrativeGenerates the project memory file from a short interview

Plus your own. Any markdown file in .claude/skills/ becomes a named capability the agent can invoke — a well-scoped prompt, enumerating its allowed tools, committed to the repo, shared with your team. Skills are how a pattern graduates from "something you say each time" to "something you say once."

MCP — tools that reach out to real systems

The Ideafy local server exposes a Model Context Protocol server so the agent doesn't simulate the board — it operates it:

create_card · list_cards · get_card · move_card · update_card · save_plan · save_opinion · save_tests · bind_session_to_card · pool_push · pool_pull · pool_claim

See MCP tools reference for the full catalog. The design rule: every step in the chain of thought has a tool that commits the step. When the agent finishes a plan, it doesn't say "here's the plan" — it calls save_plan, which writes the Solution tab, moves the card to In Progress, and opens an isolated worktree. The thought doesn't evaporate between turns because the tool made it real.

Hooks — rules the harness enforces, not you

Two hooks, wired into every registered project's .claude/settings.json:

  • UserPromptSubmit — fires on every turn. The Ideafy local server responds with a phase-aware policy tailored to the bound card's column ("this is an Ideation card — propose save_opinion" / "this is In Progress on the wrong branch — don't edit"). Also handles the one-time creation offer at the top of a fresh session.
  • PreToolUse (matcher: Edit|Write|MultiEdit|NotebookEdit) — blocks an edit-family call when you're bound to an in-progress card but on the wrong branch. Fails open. See Bundled hooks.

Fail open, always. A hook that can wedge your editor is a hook that will get disabled and then forgotten. The right failure mode is "Ideafy isn't running, so tracking is off, but your editor still works." Governance that outlives its usefulness is governance you don't own anymore.

The ideology — AI as a team member, not an oracle

The popular framing is "AI assistant." The word assistant pretends the thinking is already done and the agent's job is clerical. The word oracle pretends the thinking is outsourced and you just consume the output. Both get the relationship wrong.

The useful framing is team. A team member has memory of what's happened. A team member follows team norms because the team encoded them, not because they invented them for each conversation. A team member can be interrupted, corrected, paired with, handed context, and trusted with scoped ownership. A team member pays the cost of turning rough thoughts into structured ones so their collaborators can pay the cost of judgement.

Two principles follow from taking the team framing seriously:

  1. Divergent / convergent split. Agents are good at divergence — generating options, filling forms, expanding a sketch into a plan. Humans are good at convergence — picking, rejecting, cutting, deciding when it's done. Research on AI-assisted creative ideation is consistent about this: AI doesn't reduce fluency, flexibility, or originality, and it doesn't homogenize output — if humans stay in the convergent role. (Enhancing the effect of AI-assisted learning, 2026; Evaluating AI-Assisted Creative Ideation, 2025.) A workflow that hands the convergent decisions back to the agent is the workflow that produces slop.

  2. Scaffolding, then fading. Good scaffolding — the Zone of Proximal Development framing — gives support in the zone the learner can't handle alone and progressively withdraws it. The Ideafy equivalent: quick-fix for repetitive, well-understood work (fade the support, let it run); autonomous mode for a planned card inside a worktree (structured support, limited blast radius); Human Test as the gate that never fades, because irreversible decisions are where humans keep the verdict.

These aren't nice-to-haves. They're what separates a team with an AI member from a person with a chat tab open.

Best practices — what to actually do

Eight rules that come out of using the stack, not theorizing about it.

  1. Own your stack in plaintext + git. Memory, skills, hook commands, agent mode configs — all in the repo. Vector DBs and graph stores optional, later, once you have volume that justifies them. Readable beats clever until the clever one is load-bearing.

  2. Cast by stage, not by session. The agent's mode (listener / evaluator / planner / autonomous builder / interactive collaborator / orchestrator) is picked by the stage of the card, not by a preference you set once. A rough thought doesn't get an autonomous builder; a merged card doesn't need a planner. Most "the agent went off the rails" stories are a casting mistake.

  3. One skill per recurring job. If you've explained it twice, it's a skill. Write the markdown, commit it, let the agent invoke it by name. The moment a pattern has a name in your team's vocabulary, it should have a file in .claude/skills/.

  4. MCP commits the thought. A turn that produces text but no side effect is a turn the next session won't remember. If the agent makes a decision, it should end in a tool call that writes the decision somewhere the stack can read later — save_plan, save_opinion, update_card, pool_push. The chain of thought is durable because the tools make it durable.

  5. Parallelism lives in worktrees. When you want three things in flight, spawn three worktrees with three agents — not one agent juggling three contexts. Blast radius is a branch, not main. Subagents further isolate sub-jobs; each gets its own context window and disappears when done.

  6. Hooks fail open. Governance that can wedge the editor will be disabled and then forgotten. Every hook should have a path where "Ideafy isn't reachable" means "no tracking, but nothing else breaks."

  7. Never delete what you thought about. Cards you rejected go to Withdrawn, not the trash. Conversation logs are preserved per-section. Git branches on merged cards stay. Three months later, when the same idea walks in dressed differently, you'll have the receipts.

  8. Compound, don't start over. When a pattern grows load-bearing, it graduates: one-off hint → CLAUDE.md rule → named skill → MCP tool → hook → agent mode. Each graduation moves the thing further down the stack, closer to the foundation, further from improvisation. That's what compounding means here — the floor rises.

Who this is for

The architects and senior engineers who could previously hold an entire product in their head were the exclusive custodians of a structured, disciplined, durable chain of thought. Everyone else — founders, analysts, domain experts, first-time builders — was locked out, not for lack of ideas, but for lack of the infrastructure to carry an idea from rough thought to production code without the thread snapping.

AI didn't dissolve that lock by itself. Raw chat handed out a model without a stack, which is a little like handing out a saw without a workbench. What dissolves the lock is a surface — columns, cards, plans, tests, memory, skills, hooks — that turns enterprise-grade chain-of-thought work into something a product owner, an analyst, or a first-time builder can inhabit.

Ideafy's bet is that if you ship that surface, the idea tells you itself whether it deserves to become code. The rest of this guide is how the surface is built.

Where to go next


Prev: Overview Next: Philosophy Up: User guide index

Last updated: 2026-04-22