Meringue

Meringue in action

Inspiration

At the highest level of software engineering, the bottleneck is shifting.

As LLMs become better at generating code, they start to feel less like autocomplete and more like natural language compilers: you describe the behavior you want, and the system translates that intent into implementation. In that world, the limiting factor is no longer only how fast code can be written or how much you have to hand hold your agent. It becomes how efficiently a developer can manage intent, context, feedback, and parallel work.

Today, developers often run multiple coding agents across multiple terminals, branches, and issues. Each agent may be productive, but the human has to constantly switch contexts: read the last output, remember what the task was, decide what to say next, jump to another terminal, make a new worktree, and repeat.

Meringue was inspired by that friction. I wanted to build an interface for managing many coding agents at once without forcing the developer to mentally reload a different project or issue every few minutes.

What it does

Meringue is an orchestration layer for coding agents.

Instead of working with one agent in one terminal, Meringue lets a developer manage multiple agents, issues, and projects from a single interface. It provides:

A chat interface where the user can continuously send prompts without waiting for one agent to finish.
A kernel that decides how to route work, spawn agents, track state, and validate commands.
An AgentTree that organizes projects, issues, head agents, and worker agents in a filesystem-like view.
Structured logs that summarize what agents are doing, what changed, and what needs attention.
A foundation for connecting to real coding harnesses like Pi, with the architecture designed to support more backends in the future.

The goal is to reduce context switching and let developers supervise many streams of work without losing the thread.

How I built it

We built Meringue in Ruby with a simple terminal-first architecture.

The core of the system is the Meringue kernel. The kernel owns orchestration state, validates commands, creates issues, spawns workers, tracks agents, and writes durable JSON state. We designed this so that agents do not directly mutate Meringue’s state. Instead, heads and slash commands produce structured kernel commands, and the kernel decides what is valid.

I separated the system into a few major pieces:

Chat input for natural language prompts and slash commands.
Head agents that interpret user intent and decide what work should be created or routed.
Worker agents that perform implementation work inside assigned workspaces.
Kernel commands as the shared interface between natural language, slash commands, and state mutation.
Harness integration so any ai harness can plug right into the app.
JSON persistence so Meringue can reload and explain previous sessions.

At a high level, the flow looks like this:

   User prompt
     -> Head agent interprets intent
     -> Head returns structured commands
     -> Kernel validates commands
     -> Kernel mutates state
     -> Workers are spawned or prompted
     -> AgentTree and logs update

This gave me a clean separation between user intent, orchestration logic, and actual agent execution.

Challenges I ran into

The hardest challenge was designing the boundary between autonomy and control.

If agents can do everything directly, the system becomes hard to trust. If the kernel controls everything too tightly, the system becomes rigid and less useful. I had to design a command layer where agents can propose actions, but the kernel remains the source of truth and acts deterministically

Another challenge was thinking through concurrency. Meringue is built around the idea that many agents may work at once, which means the architecture has to account for isolated workspaces, independent statuses, resumable sessions, and clear logs. Even for an MVP, the data model needed to support multiple projects, issues, agents, and questions without becoming tangled.

Accomplishments that I'm proud of

I am proud that Meringue is not just another chat wrapper around an LLM. It is an attempt to rethink the developer workflow around a future where many agents are working in parallel.

Some accomplishments I'm especially proud of:

Designing a kernel-first architecture where state mutation is centralized and auditable.
Creating a model for stateless head agents and long-lived worker agents.
Building around structured commands instead of relying only on freeform chat.
Treating logs and agent state as first class parts of the developer experience.
Keeping the harness integration isolated so Meringue can plug and play with any agent harness.
Designing the AgentTree metaphor to make parallel agent work easier to understand at a glance.

What I learned

We learned that the hard part of AI-assisted development is not only code generation. It is coordination.

As models become more capable, the developer’s role shifts toward planning, supervising, reviewing, and redirecting work. That means the interface around the model matters just as much as the model itself.

I also learned that multi-agent systems need strong boundaries. Without a kernel, command validation, persistent state, and clear logs, it becomes very easy for parallel work to become confusing or unsafe.

Most importantly, I learned that context is the scarce resource for humans and llms alike. Meringue is built around the idea that preserving human context may become one of the most important problems in AI driven software engineering.

What's next for Meringue

Next, I want to make Meringue feel like a complete operating environment for agentic development and long term, I want Meringue to become the control panel for parallel AI software engineering. One place where developers can work, supervise agents, review progress, and stay in flow all in the same window.