I have a side project graveyard. You probably do too. The pattern is always the same: idea hits at 11pm, I start building immediately, skip the "does anyone actually want this" step, burn a weekend, and abandon it when the next idea shows up.
Incubator is my attempt to fix this. It's a team of 7 specialized Claude agents that take a one-sentence idea through research, build, validation, and shipping — autonomously, with human approval gates between phases. You describe what you want, walk away, and come back to a researched spec, a working MVP, and deployment artifacts.
It's open source: github.com/terrateamio/incubator
The pipeline
Four phases, 7 agents. Each phase has dedicated agents, and the orchestrator pauses between phases to ask you (via Telegram) whether to continue.
Research — competitive analysis, feasibility assessment, market feedback. If the idea is bad, the agent says so. The point is to kill bad ideas early.
Build — takes the spec and produces an MVP in a sandboxed workspace.
Validate — checks the implementation against the spec.
Ship — deployment artifacts and launch materials.
This is intentionally not fully autonomous. I don't want agents deploying code I haven't reviewed. The human-in-the-loop gates are the feature, not the limitation.
Files as the coordination layer
The core architectural decision is how agents coordinate: through a shared filesystem directory per idea. No message passing, no database, no event bus. Just files.
This is the blackboard pattern — a classic from 1970s AI research (Hearsay-II at CMU), where specialist agents collaborate by reading from and writing to a shared workspace.
Why files instead of a database?
Inspectable. You can cat any artifact at any time. When an agent does something weird, you open the file and read what it wrote.
Versionable. Put the ideas directory in git. Diff what changed between runs.
No schema migrations. Agents evolve their output format. With files, a new agent just writes a new file. No migrations.
Natural fit. Claude with MCP filesystem tools reads and writes files natively. The blackboard is the filesystem.
No framework
No LangChain, no CrewAI, no DSL. Each agent is a Claude session with a plain-text system prompt and MCP tool servers. The prompts live in agents/<name>/prompt.py as string constants:
RESEARCH_AGENT_PROMPT = """You are the Research Agent for Incubator.
Your job is to take a raw idea and produce a research package:
1. Competitive analysis — what exists, what's missing
2. Feasibility assessment — can this be built in a weekend?
3. Market signal — would anyone use this?
You have access to the filesystem. Read the idea from idea.md.
Write your outputs to the research/ directory.
Be honest. If the idea is bad, say so. If the market is
saturated, say so. The point is to kill bad ideas early."""
You can read every agent's instructions in 30 seconds. When an agent behaves wrong, the fix is changing a string, not debugging framework internals.
I've tried the framework approach. The abstraction layers feel productive until something breaks and you're three levels deep in someone else's orchestration code trying to figure out why your agent decided to skip a step. Plain prompts are boring. Boring is good.
The worker pool
Multiple ideas run concurrently through a time-boxed scheduler. A priority score determines which ideas get attention first, and a configurable worker pool (default 3 slots) rotates agents across ideas.
Each agent has per-run budgets: maximum turns and token limits. When an agent hits its budget, it wraps up and the slot opens for the next one. You can dump five ideas into the system and come back to find them all at different stages of progress.
Self-improving agents
Each agent has a knowledge/learnings.md file that persists across runs. At the end of a run, agents write down what worked and what didn't. Future runs start by reading this file.
This is crude — append-only text, no retrieval system, no embeddings. The agent just reads the whole file at the start of each run. It works because the files stay small and the context is specific.
There's also an evolution system: periodic retrospectives where agents review their own performance and suggest prompt improvements. These are suggestions for you to review, not auto-applied. I don't trust agents to modify their own prompts unsupervised. (I wrote a whole post about why.)
What's running under it
Incubator runs as a local server with a web dashboard and Telegram notifications for approval gates. Quick start:
git clone https://github.com/terrateamio/incubator.git
cd incubator
# configure your API keys and run
Prior art
The blackboard pattern comes from Hearsay-II (1970s). The idea of specialized agents with shared state isn't new — I'm just implementing it with files instead of a custom data structure, which turns out to be the natural fit when your agents already speak filesystem.
The human-in-the-loop pipeline is influenced by how I think about CI/CD: automated steps with manual approval gates at deployment boundaries. Same principle, different domain.
Limitations
This is early and rough.
The research phase is only as good as what Claude can find and reason about. No proprietary databases, no real user interviews. "Market feedback" is really Claude's assessment based on what it can see.
The build phase produces prototypes, not production systems. The quality ceiling is whatever Claude can produce in a sandboxed workspace with a token budget.
Costs add up. Running 7 agents across multiple ideas is not cheap. I haven't optimized for token efficiency yet.
What I learned
Building Incubator taught me that the boring coordination mechanisms are usually the right ones. I started with plans for a message queue, then SQLite, then a custom state machine. Files won because they removed an entire category of problems — serialization, schema, querying, debugging — and replaced them with ls and cat.
The other lesson: human gates aren't a compromise, they're a design choice. The fully autonomous version would be worse. Not because the agents can't do the work, but because the moments where I look at a research report and say "actually, pivot toward X" are where the value is. Automation handles volume. Judgment handles direction.
The code is MIT licensed. If you have opinions about agent coordination patterns or want to try a different approach to the blackboard, PRs are welcome.