<div align="center">

AItelier

Structured-but-dynamic subagent workflows for AI agents — your agent delegates work to deterministic, fully-audited pipelines it can generate, run, and edit over MCP.

</div>

AItelier makes multi-agent AI pipelines deterministic and fully auditable — define a pipeline (or have your agent generate one), run it, and inspect why it did everything it did. The whole surface is exposed over MCP, so any MCP-speaking agent can use AItelier as its workflow engine: delegate bulk work to cheap, deterministic pipelines and only decide at checkpoints (see Use AItelier from another agent). Under it all is an open engine (SkillFlow, MIT, on PyPI as skillflow-py) plus a flagship software-delivery pipeline; the broader no-code workflow platform is on the roadmap.

Persistent project state, separate from workflow execution

AItelier also provides a State DAG for long-lived goals, revisioned acceptance contracts, dependencies and evidence. SkillFlow continues to own workflow steps, loops, retries and checkpoints; the driver chooses a ready goal and a workflow. A completed workflow produces a candidate, not a verified product capability.

The MCP/internal-driver tools state_graph_help, state_graph_read and state_graph_write expose the same typed contracts as /api/state. State data reads require writer authorization. Existing DPE pipelines and task/project UI remain compatible; legacy tasks are imported only explicitly and never inherit verified status. See architecture, usage, trust boundaries and rollout and the offline real-engine demonstration. The State Project frontend and migration preparation guide covers project DAG browsing, exact-run graph versions, protected historical references and held shadow migration rehearsal. The project-first dashboard guide covers the default State DAG workspace, separate Runs/Pipelines navigation, readable node badges and actual run history.

Use State DAG without workflows

Your own director, subagents, CI or proof-checking harness can register an external attempt, submit a scoped artifact/report and per-criterion evidence, and verify a node without creating a SkillFlow Run. Workflow and external attempts share the same acceptance and invalidation rules. External completion is still only a candidate.

A dedicated authenticated, headless State HTTP/MCP server starts with python -m api.state_only --db /absolute/private/state.sqlite and a configured AITELIER_STATE_TOKEN; it does not import or start SkillFlow, a scheduler, workspace manager or model registry. The package's install dependencies are not yet split into a separate minimal wheel. See the integration/standalone guide and the real own-harness example.

Why AItelier

Most "AI agent" tooling is built for demos, not trust. The tools that build software or automate a workflow for you are non-deterministic black boxes: you can't reproduce a run, audit why the agent did what it did, or insert a human approval where it matters. That's exactly the wall that stops agents from being deployed in anything serious — regulated industries, enterprise, anywhere "it usually works" isn't good enough.

AItelier is built on the opposite premise — that an autonomous pipeline should be trustworthy by construction:

• Deterministic execution rules — workflow graphs are traversed by the engine, not control flow improvised by an LLM. Their conditional outcomes may differ and their retry paths may contain cycles; they are not necessarily DAGs. Loops, gates, retries, and recovery are the engine's job. The separate project-state dependency graph is acyclic.
• Minimal LLM surface (least privilege) — each agent sees only the context it declares, and the SkillFlow engine generates a constrained write tool per declared output (and gates reads to declared context) — so an agent cannot read or write a file outside its contract. Concretely in the software pipeline: the Researcher can only search the web; every other role can write only its own declared output (a design doc, a plan, a review verdict, or the project README) — and only the Implementer's outputs are code. The model makes the judgment calls; the framework and its generated tools do everything deterministic — brain to brain, tools to tools. It's also why cheap models suffice: small, focused, role-scoped context.
• Fully traceable — every run keeps an append-only audit trace that is never deleted: each step, prompt, model response, and tool call. "Why did this run do that?" is one query, not forensic archaeology.
• Human-in-the-loop — approval/reject checkpoints are first-class between stages; review and send work back with feedback at any point.
• Adversarial quality — every step is produced by a Green (Maker) agent and reviewed by a Red (Checker) agent before it advances.
• Config-agnostic — a pipeline can be anything. Nothing about the engine is hardcoded to one workflow; SkillFlow can even generate a new pipeline from a plain-language description.

Where this sits. Classic workflow engines are structured but static — a human authors the graph, and changing it is a deploy. Autonomous agent swarms are dynamic but unstructured — improvised control flow that can't be reproduced or audited. AItelier is deliberately the missing quadrant: structured but dynamic. During a run the graph is fixed and engine-traversed — gates, retries, and the trace are mechanical. Between runs, an agent can generate a new pipeline from a description, drive it, read the trace of what broke, and edit it — all over MCP. Your agent stays the brain; AItelier is the factory floor it can re-tool.

What you can build

The vision (see Project status for exactly what's built today vs. what's planned).

AItelier is meant to be used three ways — the first is the center of gravity:

1. Give your agent a workflow engine (MCP) — ✅ works today. Point any MCP-speaking agent at the /mcp endpoint and it gets the whole surface as native tools: the full generate → run → observe → fix loop, checkpoint answering, the trace, model routing, and pipeline export/import. Your agent delegates the bulk work to deterministic pipelines on cheap models and only decides at the checkpoints (see Use AItelier from another agent).
2. Build your own auditable workflow — just describe it — ✅ works today. Pipelines aren't limited to software. Describe a workflow in chat (or over MCP) and AItelier's grounded generator turns it into a real SkillFlow pipeline — provisioning any missing tools, wiring and gating the graph, and registering it to run by name (see Generate a workflow from a description). You can still hand-author YAML directly; a no-code visual builder and managed workspaces are on the roadmap.
3. Run the flagship software pipeline (DPE) standalone — ✅ works today. Describe a project; it researches, architects, plans, implements, and verifies it end-to-end, with human checkpoints and a complete trace. (That's See it in action below — and the proof that the engine holds up under the hardest workload.)

Why software-delivery is the wedge and the keystone. We lead with autonomous software-building because it's the hardest possible proof the engine works — and because an AI workflow is software (a pipeline is a graph plus tools plus templates). The same deterministic factory that builds software is what will let you trust a workflow you build on AItelier — building a new auditable workflow is itself a software-engineering task. A trusted software pipeline builds trusted workflows.

Open source. SkillFlow is the engine and is embeddable in any agent system; AItelier is the host application around it. Both are MIT (see License); a managed multi-tenant platform is on the roadmap.

Project status

Honest, current state — so nothing here reads as more finished than it is.

Legend: ✅ Available today (built & tested) · 🚧 Roadmap (designed, not built) · 🔭 Long-term vision

| Capability | Status | | --- | --- | | Flagship DPE software pipeline — research → architect → plan → implement → verify | ✅ Available today | | MCP endpoint + DeepSeek Harness plugin — drive AItelier from any MCP-speaking agent: list / edit / run / export / import pipelines as native tools | ✅ Available today | | Green/Red adversarial review · human approve/reject-with-feedback checkpoints · autonomous goal-loop | ✅ Available today | | Append-only trace + trace API · Git event-sourcing · Rich CLI/TUI | ✅ Available today | | Runs on the SkillFlow engine (durable workflow-graph execution, tools, checkpoints, trace) | ✅ Available today | | Persistent State DAG — revisioned goals, dependencies, attempts, evidence, acceptance and driver/API access | ✅ Implemented and tested; private project DAG viewer, no automatic legacy migration | | Generate a pipeline from a plain-language description — grounded generator provisions missing tools, wires + gates the graph, registers it to run by name | ✅ Available today | | Final verifier runs the generated app (runtime smoke-test) | 🚧 Roadmap — today it reviews code statically and can miss runtime bugs | | No-code visual workflow builder · managed multi-tenant SaaS · collaboration & compliance tooling | 🚧 Roadmap | | Horizontal expansion beyond software delivery, on the same engine | 🔭 Vision |

Where the company is: the engine and the flagship pipeline are built and tested; there are no users, revenue, or managed platform yet. This is a working foundation, not a finished product.

See it in action

Browse a live deployment right now: aitelier.linxuhao.app (public read access). Open any run and watch the pipeline graph with the current step highlighted and its trace streaming live beside it — for example, a real game-feature run. Reads are open to anyone; writes require the Cloudflare Access allowlist (how that split works).

A typical run with the flagship DPE pipeline:

1. Describe what you want. Tell the butler your goal. It picks one of two paths automatically:
   • Path A — Pipeline Offload (fast): for small bug fixes or features (~5 files) on existing projects, offloads directly to a subagent/fix_tests/investigate pipeline — no requirements conversation needed.
   • Path B — DPE (safe default): for new projects and non-trivial changes, asks scoping questions, drafts a project brief, and — once you approve — starts the full research → architect → plan → build pipeline.
2. Watch it work, with checkpoints. Research → Architect → PM → per-task Plan/Implement/Review → Final Verification. It pauses at review checkpoints so you can approve or reject with feedback (e.g. "the design is missing input validation") and watch the agent revise.
3. Inspect the trace. Every prompt, response, and tool call is in an append-only audit log — answer "why did it do that?" for any step, after the fact.
4. Run the result. The generated pr