What Is Ikigai?

Ikigai is an agent orchestration platform we’re building. It will pair with the user, not with a project or a machine. It will sit above your projects as an umbrella you work through, aware of all of them.

It will have a one-to-one relationship with you. You’ll work through it across all your projects.

But that’s not the most important thing to understand about Ikigai.

The Central Idea: Human/Code Parity

We’re nine releases into building Ikigai, and a clear direction has emerged. The exact implementation will evolve, but the principle guiding our decisions has become clear: anything a human can do, code should be able to do too. And anything code can do, a human should be able to do. Same environment, same capabilities, same controls.

When we build a feature, we build it for both. A human types /fork to spawn a child agent. External code calls cmd_fork. A human uses /send to mail another agent. Code calls cmd_send. There’s no separate “automation API” bolted on later. Both paths invoke the same underlying operations.

This matters because we can’t predict what users will want to build. The agentic space is moving too fast. Someone might want a human-in-the-loop workflow where they supervise every decision. Someone else might want fully autonomous agents running for days. Most will want something in between, and that something will change as they learn what works.

By maintaining parity, we give users maximum flexibility. They can start hands-on and gradually automate. They can build custom orchestration that mixes human judgment with autonomous execution. They can experiment without hitting walls where “the API doesn’t support that.”

We use this principle in our development environment today. Ralph is an external script that drives Claude Code in a loop, issuing the same commands a human would type. It works because parity exists. As Ikigai matures, orchestration like Ralph will be straightforward to build, not because we’ll add special automation features, but because the standard interface will already support it.

The Structure That Makes This Work

Several architectural decisions support this parity.

Permanent History

Every action is stored in a PostgreSQL database. User messages, assistant responses, tool calls, commands, agent creation, mail, all of it. This history is never lost.

The database is an immutable event log. When you restart Ikigai, it replays your session from these events. When an agent forks, the child inherits the parent’s history through a reference to the fork point, not a copy.

This permanence matters for autonomous agents. A long-running agent can be interrupted and resumed. It can be analyzed after the fact. Its decision-making is auditable.

Sub-Agent Process Tree

Agents can fork child agents. Each agent has a UUID, an optional name, and a parent reference. The database tracks them all.

A human creates a child with /fork. Code does the same. The child inherits the parent’s conversation history up to the fork point, then diverges. Parents can send mail to children. Children can send mail back. Siblings can coordinate if they share UUIDs.

This tree structure lets you decompose complex work. Fork a researcher to explore one approach while you explore another. Fork workers to process items in parallel. The structure is simple (parent-child relationships, mail for communication) but the patterns you can build are not.

Inter-Agent Mail

Agents communicate through mailboxes. /send <uuid> "message" delivers mail. /check-mail lists your inbox. It’s a pull model (agents check when ready) with no push notifications.

Mail is stored separately from conversation history, so it doesn’t pollute context.

Context Control

Context is what gets sent to the LLM. It’s distinct from history (everything that happened) and can be shaped independently.

Commands like /clear, /mark, and /rewind let you manage context directly. /mark creates a checkpoint. /rewind rolls back to it. /clear starts fresh.

We’re building toward more sophisticated context management. The plan includes pinned documents and layered summarization.

Pinned documents are markdown files that get included in every LLM request. Think of them as a layered, constructable system prompt. The key is that they’re rebuilt every turn. If you modify a pinned document between messages, the next request sees the new version. This makes them useful for living memory, goals, knowledge, and skills. A human can edit them. Code can edit them. The agent sees the current state on every turn.

Layered summarization will reserve token budgets for different time horizons: this conversation, today, this week, all time. Message history gets whatever space remains after pinned documents and summary. The internal file system landed in rel-09, which was a prerequisite for pinned documents.

Tool Control

Context isn’t just what the model knows. It’s also what the model can do.

The plan is to expose tool availability through commands like /available-tools. You’d use it to set exactly which tools the model sees:

/available-tools file_read, file_write, glob, grep

This lets you shape an agent’s capabilities for the task at hand. A research agent might only need web search and file reading. A coding agent needs file operations but maybe not web access. A review agent might be read-only.

The same command works for humans and code. A human can type it interactively. An autonomous orchestrator can issue it before delegating work to a sub-agent. The flexibility compounds: you control not just what an agent remembers, but what it can do.

The Common Thread

Both context control and tool control follow the same principle: give users and code fine-grained control over what goes into each LLM request. Memory, capabilities, system prompts, all of it tunable through the same interface whether you’re typing commands or writing automation.

What’s Implemented vs. What’s Coming

We’re nine releases in. Here’s what works today:

• Multi-agent system: Fork, kill, navigate between agents, agent hierarchy display
• Inter-agent mail: Send, receive, filter, delete messages between agents
• Permanent history: PostgreSQL storage, session replay, fork history
• External tools: Bash, file operations, glob, grep, web search, web fetch
• Context commands: Clear, mark, rewind
• Multiple providers: Anthropic, OpenAI, Google (with extended thinking support)

What’s coming:

• Pinned documents: Living markdown files rebuilt every turn (memory, goals, knowledge, skills)
• Layered summarization: Automatic context compression with configurable time horizons
• Tool availability control: Dynamic control over which tools the model can use
• External agent API: Programmatic access to drive agents, developed in parallel with the client

Why This Approach

Most agent tooling optimizes for a specific workflow. Ikigai optimizes for flexibility.

We don’t know what patterns will emerge as people get better at working with agents. We don’t know what you’ll want to build. So we build primitives that work the same way whether a human is driving or code is. We build persistence so nothing is lost. We build communication so agents can coordinate.

Then we get out of the way and see what people do with it.

Co-authored by Mike Greenly and Claude Code