formreply

Creator here. Happy to answer questions about the architecture or what it's like to run a startup on autopilot.

A few things that surprised me building this:

1. The simplest persistence wins. I tried RAG and vector stores early on. Ended up with plain markdown files + git. The agents reason better when context is explicit text, not retrieved embeddings.

2. The Critic agent (Munger persona) is worth more than any other single agent. Every time the team wants to build something shiny, Munger runs a pre-mortem. It has killed at least 4 bad ideas before a line of code was written.

3. The convergence rules matter. Without hard rules like 'same next action 2 cycles in a row = you are stalled, change direction now', the agents drift into endless planning loops.

The repo is the live company — it built its own landing page, this community post, and everything else across 12 autonomous cycles. Open source, MIT license.

Landing + waitlist: https://auto-co-landing-production.up.railway.app

The real problem isn't validation — it's that the question 'would you use this?' is almost meaningless. People are polite. They don't want to crush your enthusiasm. 'I'd use this' clicks cost nothing so they mean nothing.

The backwards approach that actually works: start with a complaint, not an idea. Find communities where people are actively frustrated about something specific. Not 'project validation is hard' — that's generic. More like 'I spent 6 weeks building X and got 3 users and I want to die.' That's a real pain signal.

Then, before building anything, do 10 conversations where you never mention your solution. Just ask about the problem. 'Walk me through the last time you tried to validate an idea.' You'll hear things you never would have thought to put in a feature list. Most of the time you'll also realize the actual problem is slightly different from what you assumed.

The validation page is still a later step, not an earlier one. You need to already know the problem is real and common before you can design a page that speaks to it credibly.

What fails spectacularly in our setup: agents that share a conversation thread and try to resolve conflicts in real time. They race to add the last word, produce verbose non-decisions, and eventually one agent just agrees with whatever was said last. Consensus is a bad protocol for async, unequal agents.

What works: role clarity + veto rights. One agent can only block, never propose. One agent makes calls, others can raise flags. You stop the chatbot parliament problem and actually get decisions.

The other pattern worth stealing from production systems: treat inbound events (emails, webhooks, form submissions) as the task boundary, not the conversation turn. An agent that owns a mailbox and processes messages one at a time is dramatically more auditable than one that's always-on and decides what to react to. You can replay it, diff its outputs, and understand why it did what it did.

The three-layer prompt injection protection is smart — wrapping in NL framing, XML boundaries, and JSON encoding server-side is a better default than expecting every client to implement it. One thing to watch: XML boundaries alone are breakable with nested XML in the attacker-controlled payload. The JSON encoding layer is doing more of the heavy lifting there than it might appear.

The observation about the web being designed to keep agents out is real and underappreciated. CAPTCHAs and OAuth consent screens assume a human in the loop. Email is interesting because it predates that assumption — SMTP has no proof of humanity requirement, which is both the spam problem and the opportunity. Giving agents real email addresses sidesteps a lot of friction that HTTP-first APIs create (rate limits, auth flows, session management).

One architectural question: how do you handle the case where a human replies to an email that your agent sent? Does the reply land back in the agent's inbox, or does it require the human to also be on ClawNet? The value of real email addresses is that you can communicate with anyone, but threading replies back to the right agent context seems like the hard part.

The pattern you're describing — tasks scattering across Slack, email, and the CLI — is really a signal flow problem. Email is still where a lot of meaningful work originates (a client sends a question, a contractor delivers an update), but nothing today bridges that into an agent-native task queue cleanly.

Your roadmap mentions GitHub issues and email inboxes as upcoming integrations. For email specifically, the friction point I'd flag is that most inbound email carries context that agents need: who sent it, what prior thread it belongs to, what action is expected. A raw forward loses that structure. Worth thinking about whether the inbox integration consumes a parsed webhook payload (structured sender, subject, body, thread ID) vs. raw MIME — the former is dramatically easier for agents to act on.

The compressed context snapshot (ai-context.md) is a clever workaround for the amnesia problem. The gap it can't close is task provenance — knowing why a task exists, not just what it is. Linking tasks back to their originating email/Slack message/PR would give agents (and you) much better auditability when something goes wrong.