The meta-agent that designs, deploys and corrects AI architectures

The engine behind our own-infrastructure promise. Our own product, in active development.

What is it?

A state graph that designs, generates, deploys, stress-tests, diagnoses and corrects generative AI architectures — RAG, agents, microservices— on local Docker, remote SSH or ephemeral cloud. It's not a template generator: it spins up real containers, injects real traffic, reads real logs and corrects the architecture until it's stable.

Python 3.11+ FastAPI Pydantic v2 Docker SDK asyncssh Terraform

How it works

An eight-step cycle between design, real deployment and self-correction.

1

Preflight

Probes the real target before designing anything: is there Compose v2? An NVIDIA runtime? Free ports? How much VRAM is actually available? Design starts from real capabilities, not what someone declared.

2

Architect

An LLM decides the architecture but doesn't write YAML: it emits a validated blueprint (Pydantic, closed enums) against the target's real capabilities. Code, not the model, translates that into manifests.

3

Sizing

A GQA-aware sizing engine calculates VRAM, KV-cache budget, theoretical throughput and vector-index size. It's a hypothesis, not a verdict: only the load test confirms it.

4

Builder

Deterministic code, no LLM, translates the blueprint into reproducible, testable Docker Compose manifests: the correction cycle spends iterations on architecture bugs, not indentation errors.

5

Deployer

The highest-risk node is, on purpose, the most boring one: zero intelligence, zero decisions. It executes an already-resolved plan on the target —local, SSH or ephemeral cloud— through interchangeable drivers.

6

Load testing

Injects real traffic asynchronously and measures TTFT, TPOT, TPS and latency percentiles. This is what certifies whether the calculated sizing was correct, comparing theoretical against measured.

7

Diagnosis

If something fails, every finding must cite a real log line. Without literal evidence, the finding is discarded before it reaches the report: no speculation about unobserved causes.

8

Correction

The Critic → Builder → Deployer cycle repeats with a bounded number of attempts and never retries a configuration that already failed: every correction moves at least one parameter monotonically.

What we don't negotiate

Four hard rules, enforced in code

These aren't product promises: they're validations that run before any command touches a real server.

Never restarts the host

Rebooting or shutting down the target server is forbidden, enforced across three independent layers: a command validator, a generated-artifact validator, and a final-report sanitizer.

No vision models

The catalog only admits open-weight text models. A model with any other modality is rejected before anything gets designed.

Literal evidence, zero speculation

Every diagnostic finding must cite a real log line, with its file and line number. No evidence, no finding.

Structured Markdown output

Never raw JSON to the frontend: readable headers, tables and code blocks, generated from templates.

Real status, no varnish

Same standard we use across the rest of the site: we'd rather say what's missing than inflate what's there.

H0 through H5 complete, plus API authentication and a CPU deployment profile: 409 tests passing, clean ruff, and mypy strict mode with zero errors across 95 modules.

The asterisk that matters: all of that verification is against test doubles (fakes), not a real Docker daemon yet. The four integration tests against real Docker are already written, but have never been run — that's the next step, and the one that will tell us the most.

How it's used

A request describes the workload, the available hardware and the target. The meta-agent responds immediately and streams progress.

Real example API request
curl -X POST localhost:8080/runs -H 'content-type: application/json' -d '{
  "workload": {"name": "corporate-rag", "kind": "rag",
               "slo": {"concurrent_users": 16, "min_context_tokens": 8192}},
  "hardware": {"nodes": [{"node_id": "srv-b", "role": "server_b", "cpu_cores": 32,
                          "ram_gb": 256, "disk_gb": 2000,
                          "gpus": [{"name": "NVIDIA A100-SXM4-80GB", "vram_gb": 80,
                                    "memory_bandwidth_gb_s": 2039}]}]},
  "targets": [{"target_id": "srv-b", "kind": "ssh", "node_role": "server_b",
               "host": "10.0.0.11", "ssh": {"username": "deploy",
               "private_key": {"provider": "env", "key": "DEPLOY_SSH_KEY"}}}]
}'

Responds with 202 immediately and a run_id. Progress streams over SSE — closing the connection doesn't interrupt the deployment. The final report arrives as structured Markdown.

What you get at the end

Every run ends in a report, not a promise. And if you want it to become real, there's a version that does that.

Included in every run

Feasibility and scope report

At the end of every run, the meta-agent delivers a Markdown report with the architecture evaluated, the calculated sizing, what was measured under real traffic, the deviation between the two, and what it would take to bring it to production. Same standard we use with our clients: show what's there, don't oversell it.

Theoretical vs. measured sizing Literal log evidence Structured Markdown

Why it matters to your company

This is the engine that makes our own infrastructure promise possible: instead of guessing how much VRAM your RAG or agent needs, the meta-agent calculates it, deploys it and certifies it with real traffic, on your own servers.

Want to be one of the first to try it?

It's in active development. If you want early access or to see the full technical report, reach out.