- Takes in your (potentially very large) project description, acts in an agentic loop
- Agrees on every action through a multi-model consensus technique. 3 models, or just one, or 10... however many you want to use, really.
- Each choice is from a list of action primitives, e.g. web fetch, file ops, MCP, etc. One of them is spawning a child (clone of itself) to tackle some part of the task -- hence, "recursive."
- Uses skills from other tools, e.g. Claude Code
What it does not do:
- Be fast or cheap
How it works:
Each "agent" is really just an Elixir process. It turns out OTP's free supervision/message-passing/fault tolerance map very well to a multi-agent domain. Actions run in their own ephemeral processes so agents can respond to messages and do other work while waiting on long-running commands. Parent agents and child agents communicate back and forth in a tree hierarchy similar to human organizations. (I thought about letting siblings communicate too, but that can get risky with signal-to-noise. Better to rely on the parent to split work into non-overlapping pieces.) Budgets propagate similarly; there's an escrow tracking system so children can't blow their parents' budgets. State persists in the DB; you can pick right back up after pausing a task or restarting the server.
Through a library called ReqLLM it supports (in theory) any model listed on models.dev. Each model in a pool maintains its own conversation history, so it can condense when it wants to and keep the memories it feels are important -- and the other models can "remind it" of memories it did not hold on to. The consensus mechanism itself handles ties conservatively (do the "least impactful" thing), which also has an interesting security side effect: Any prompt injection attempt has to break a majority of models, not just one. (And untrusted input is tagged as such, with random IDs, which also helps.)
And it's all wrapped up in a shiny, beautiful, Phoenix LiveView UI, so you can watch your money burn in real time! (Just kidding. No, not about the money, that's real. About the UI -- that's a mess. But it is Phoenix LiveView, and it does work.) I personally use a hacked-together spec-driven+TDD process, so test isolation and reliability has been a major focus, too. I could probably write another whole damn post just about that.
So yeah, Quoracle is not a chatbot. It's meant for big hairy important stuff where you really want optimal results. I would call it "industrial-strength" but it's in beta, so that would be a lie.
What it does:
- Takes in your (potentially very large) project description, acts in an agentic loop
- Agrees on every action through a multi-model consensus technique. 3 models, or just one, or 10... however many you want to use, really.
- Each choice is from a list of action primitives, e.g. web fetch, file ops, MCP, etc. One of them is spawning a child (clone of itself) to tackle some part of the task -- hence, "recursive."
- Uses skills from other tools, e.g. Claude Code
What it does not do:
- Be fast or cheap
How it works:
Each "agent" is really just an Elixir process. It turns out OTP's free supervision/message-passing/fault tolerance map very well to a multi-agent domain. Actions run in their own ephemeral processes so agents can respond to messages and do other work while waiting on long-running commands. Parent agents and child agents communicate back and forth in a tree hierarchy similar to human organizations. (I thought about letting siblings communicate too, but that can get risky with signal-to-noise. Better to rely on the parent to split work into non-overlapping pieces.) Budgets propagate similarly; there's an escrow tracking system so children can't blow their parents' budgets. State persists in the DB; you can pick right back up after pausing a task or restarting the server.
Through a library called ReqLLM it supports (in theory) any model listed on models.dev. Each model in a pool maintains its own conversation history, so it can condense when it wants to and keep the memories it feels are important -- and the other models can "remind it" of memories it did not hold on to. The consensus mechanism itself handles ties conservatively (do the "least impactful" thing), which also has an interesting security side effect: Any prompt injection attempt has to break a majority of models, not just one. (And untrusted input is tagged as such, with random IDs, which also helps.)
And it's all wrapped up in a shiny, beautiful, Phoenix LiveView UI, so you can watch your money burn in real time! (Just kidding. No, not about the money, that's real. About the UI -- that's a mess. But it is Phoenix LiveView, and it does work.) I personally use a hacked-together spec-driven+TDD process, so test isolation and reliability has been a major focus, too. I could probably write another whole damn post just about that.
So yeah, Quoracle is not a chatbot. It's meant for big hairy important stuff where you really want optimal results. I would call it "industrial-strength" but it's in beta, so that would be a lie.