Why aiSlang

Agent frameworks make it easy to demo one agent. Real systems compose many — a router picks a specialist, an orchestrator delegates, a reflector critiques and retries — and those systems need model fallback, spend caps, distributed tracing, scoped secrets, and a real way to serve the agents to users. The gap between a working notebook and a deployed, observable, budget-enforced multi-agent service is where most of the work actually lives, and today there are only two ways to close it.

The first is imperative Python glue — LangChain, LlamaIndex, CrewAI, AutoGen. These are good libraries for expressing agent behavior, but you hand-write and maintain the orchestration code yourself, there's no declarative description of the infrastructure, and turning a notebook into a deployed service is entirely do-it-yourself: you still have to wire up a router, budgets, tracing, and serving by hand. The second is hand-rolled infrastructure — Kubernetes or Compose manifests plus a LiteLLM router plus OpenTelemetry plumbing plus budget enforcement, assembled from scratch. That works, but it's weeks of YAML and boilerplate per project, and it drifts the moment your agents change.

aiSlang is not another agent framework, and it doesn't compete with those tools — it's the layer beneath them. It's the declarative infrastructure layer that turns a described multi-agent system into a running, observable, budget-enforced stack on your own machine or cluster. You declare the agents, models, tools, knowledge, evals, and deploy target in one .ais file; the CLI type-checks it, resolves models against a catalog, and emits a real stack — a LiteLLM router, Jaeger tracing, fail-closed budget enforcement, and your agents — that you apply, chat with, and eval locally or ship to your own Kubernetes cluster. The system is the unit, and the file is the source of truth.