I’ve been working on an open-source project called QonQrete and would like feedback from HN.

What it is

QonQrete is a local-first, agent-based orchestration system for code generation. It coordinates multiple LLM “agents” to plan, write, and review code, while keeping execution inside a sandbox on your own infrastructure. Think of it as a construction yard for AI-assisted development that you run yourself.

Why I built it

Most multi-agent demos I saw had two issues:

– Security: generated code often runs in the same environment that’s orchestrating it.

– Observability/control: long agent chains become opaque, and it’s hard to insert human checkpoints cleanly.

I wanted a setup where:

– Agent-produced code runs in isolated containers.

– The orchestration layer never directly executes that code on the host.

– You can choose between fully automatic cycles and human-in-the-loop approval.

Architecture

Current pipeline:

– InstruQtor: takes a high-level task and breaks it into an execution plan.

– ConstruQtor: follows the plan and generates code/artifacts.

– InspeQtor: reviews outputs, flags issues, and can request another iteration.

Under the hood, each agent is just an LLM API call with a different role. Execution happens in containerized “microsandboxes” (Docker today). The host only sees artifacts that passed through the review step.

Security model (current state)

The prototype:

– Runs generated code in throwaway containers with specific volume mounts.

– Keeps orchestration separate from the execution sandbox.

– Treats all agent-generated code as untrusted.

It’s not a formal sandbox or a security product; it’s a pragmatic attempt to avoid “let the LLM directly edit your repo and run scripts on your laptop”. I’d be very interested in feedback from people with stronger threat models or prior art here.

Execution modes

Two modes:

– Autonomous: agents can run through multiple cycles without input until a stopping condition.

– User-gated: the system pauses at checkpoints (after plan, first implementation, etc.) and waits for you to approve, adjust instructions, or stop.

LLM providers

The orchestration layer is provider-agnostic. You can configure different providers per agent (e.g. smaller model for planning, stronger model for implementation, reasoning-focused model for review). It currently supports OpenAI, Gemini, Claude, and DeepSeek via API keys.

Local-first

QonQrete doesn’t host anything. You run it on your own machine or server:

– No external service or managed backend.

– Your API keys stay local.

– Artifacts live in your filesystem/Git.

The repo includes a basic CLI and example flows.

Status

Early-stage:

– Core three-agent pipeline works.

– Microsandbox execution is functional but evolving.

– A TUI for inspecting cycles is in progress.

I’m not claiming this is the right way to do multi-agent systems; it’s an experiment in making them more observable and less risky to run.

What I’d like feedback on

– Does the orchestration vs execution separation make sense?

– Are the agent roles (plan → build → review) structured in a sane way?

– Thoughts on the sandboxing approach and likely failure modes?

– Does this add enough value over simpler “single-agent with tools” setups?

Repo

Code, setup instructions, and examples:

https://github.com/illdynamics/qonqrete