Six building blocks

Pipelines are easier to reason about as a graph than as a stack of prompts. Arestrix puts the whole workflow on one canvas: agents, tools, decisions and the edges that connect them.

The canvas is inspired by the Office ribbon, so the first hour feels familiar. Templates give you a working starting point; an empty graph is one click away.

What you can model

• Sequential chains, parallel branches and feedback loops
• Decision vertices that route the flow at runtime
• Agent, tool, MCP and subflow vertices in the same graph
• Generated forms for pipelines that need human input

What is checked

Validation runs before execution: missing models, unresolved variables, unreachable vertices and cycles that cannot make progress are reported on the graph, not discovered halfway through a run.

Arestrix does not interpret the graph at runtime. It generates C++20 source and compiles it with Taskflow, so what you designed is what actually runs.

The generated project is ordinary code. Open it in the embedded Monaco editor, read it, diff it, or compile it outside the Studio with the same toolchain your team already uses.

Why it matters

• The execution model is visible instead of hidden behind a runtime
• Parallel branches become real concurrent tasks
• A compiled pipeline starts without an interpreter or a package manager
• Unchanged builds are reused, so iteration stays fast

Targets

The Studio runs on Windows and Linux. Programs generated from a graph currently target Windows; Linux is on the roadmap.

Press F5 and the Studio compiles the graph, runs it and shows the pipeline working. Completed and active vertices, tool arguments, model output and timing arrive in the same view.

The runtime is built for the unglamorous part of agents: retries, failures, long batches and the question of what actually happened in a run.

Built into the run

• Tool loops with Docker, WSL2 or local sandboxes
• Live telemetry per vertex: latency, throughput and reasoning stream
• Per-vertex model overrides and cost caps
• Batch resume from the last completed vertex
• Persistent sessions for MCP servers, including HTTP and per-server headers

For operators

The same pipeline exports as a standalone runner with a focused progress screen, node indicators and iteration history, without exposing the Studio to the person running it.

Not every prompt should leave the machine. Arestrix can download, verify and start a pinned llama.cpp runtime, then point a pipeline at it without writing environment files by hand.

No model weights are distributed with the product. The catalog pins official sources, sizes, licenses and checksums; downloads are verified before they are used.

What the Studio manages

• RAM, CPU and GPU detection with a recommended model
• Resume-aware downloads with SHA-256 verification
• Vulkan by default, with CPU fallback when the GPU path fails
• A local server bound to 127.0.0.1 with an ephemeral per-run key
• Cleanup when the Studio exits

Bring your own server

Ollama, LM Studio, llama.cpp and vLLM are supported through any OpenAI-compatible endpoint. The address stays on the machine and is never written into the project.

Agent runs produce more than output: they produce lessons. Arestrix keeps them in a local SQLite temporal multigraph that agents can search and update between runs.

The memory model is deliberately conservative. Proposals need evidence before they are promoted, consolidation is deterministic, and every entry keeps its provenance.

How agents use it

• memory_search finds relevant lessons, episodes and playbooks
• memory_record_lesson writes a new lesson with its evidence
• Failure episodes keep the context of what went wrong
• A shared Blackboard coordinates agents inside one run
• Procedural playbooks turn repeated successes into reusable steps

How it is kept honest

Records are injected and tracked when used, hybrid retrieval is optional, and a token-budgeted brief keeps memory from crowding out the actual task. Memory A/B in the Studio shows what changed when memory was enabled.

Once several runners share one provider bill, someone has to answer who spent what. The Arestrix AI Gateway sits between the runners and the providers, keeping the real keys on the server and issuing virtual keys with limits.

It is a separate on-prem executable, not a hosted service. The Studio and the exported runners talk to it through ARESTRIX_AI_GATEWAY_URL and a virtual key.

What the gateway enforces

• Monthly budgets by key, project, user, provider and model
• Rate limits and a usage ledger
• Fail-closed routing when the gateway is required but missing
• /v1/usage, /health and Prometheus /metrics
• An immutable policy that can be locked through GPO or MDM

Local models and custom OpenAI-compatible servers stay direct and are exempt from gateway budgets.