How it works

The model proposes. Your policy decides.

SuperQwen turns a natural-language goal into a controlled loop: understand, plan, act inside a sandbox, verify with real tests, and repeat only while budget remains. Every step is visible and every risky action can wait for you.

01

The execution loop#

Each task moves through the same nine stages. Steps 4 to 8 repeat for every action until the success criteria pass or a limit is hit.

  1. 01

    Create task

    Your goal becomes a task with an owner, mode, budget and success criteria. Policy for the workspace is loaded.

  2. 02

    Inspect

    The agent walks the repository tree, searches code with ripgrep and reads the relevant files.

  3. 03

    Plan

    The model proposes a structured plan: steps, dependencies and success criteria. It is validated against a schema.

  4. 04

    Check policy

    Every proposed tool call is validated and checked against policy: allow, require approval, or deny.

  5. 05

    Execute

    One permitted action runs inside the isolated workspace, with CPU, memory, disk and time limits.

  6. 06

    Observe

    Output, diff, logs and resource usage are captured as artifacts.

  7. 07

    Validate

    Tests and linters run for real. The agent never claims success without evidence.

  8. 08

    Retry or replan

    If validation fails, the agent revises its patch, but only while budget remains.

  9. 09

    Report

    You get the diff, the test evidence and a final report, or a clear partial or blocked report.

Why one action at a time?

Executing a single validated action, then observing its result, keeps the agent grounded in what actually happened. It also makes every step auditable and lets a budget or a human stop the loop at any point.

02

Execution modes#

Supervised

  • · You review the plan before it runs.
  • · File writes and every protected action wait for your approval.
  • · Approvals are bound to exact parameters; a changed patch is asked again.
  • · Diff and test evidence are shown before handoff.

Bounded autonomous

  • · Routine, explicitly permitted actions run without per-step approval.
  • · Network, dependency installs, destructive ops, pushes and merges still need approval.
  • · The task stops the moment a budget or policy boundary is reached.
  • · Same policy engine: autonomy never disables security checks.

03

Architecture#

Each layer sits behind a clear interface, so the model, the tools and the execution backend can be swapped independently.

Developer UINext.js · TypeScript · Chat, timeline, approvals, diff
Control planeFastAPI · Auth, RBAC, task lifecycle, SSE
Agent runtimePython state machine · Planner, orchestrator, policy engine
Model adapterOpenAI-compatible · Self-hosted Qwen via vLLM, SGLang or Ollama
Tool registryJSON Schema · Permissions, timeouts, error handling
Execution workersHardened sandbox · Non-root, no network, resource limits
StatePostgreSQL · Redis · Tasks, steps, approvals, audit events
ArtifactsS3-compatible · Patches, logs, reports

04

What's guaranteed#

No silent risky actions

Protected actions cannot run without a recorded approval, in either mode.

Hard limits

Steps, tool calls, wall time and retries are capped. The loop cannot run forever.

Your code stays put

Inference runs on your hardware. Changes stay in the task workspace and are never pushed for you.

GuideRun your first task step by stepSecurity modelSandboxing, policy and audit
How it works · SUPERQWEN