What AXL is

AXL is a platform for building agents that do real work on your behalf - answering from your documents, calling your systems, running multi-step processes - and that stay inside boundaries you define rather than boundaries you hope the model respects.

It is written in Rust and runs as a server - one instance on a laptop, or a fleet of identical instances behind a load balancer. You describe agents in configuration files, not in code, and the server loads them. That choice shapes almost everything else about the platform: an agent is a directory you can review, diff, sign, and roll back, and changing what an agent can do is a configuration change rather than a deploy of new code.

The loop at the centre

Every agent runs the same loop. The model receives your request plus whatever context the agent is configured to bring - conversation history, retrieved documents, long-term memory, loaded skills. It replies, and if that reply asks for tools, AXL runs them, feeds the results back, and lets the model continue. The cycle repeats until the model answers or a limit stops it.

This pattern is usually called ReAct: reason, act, observe, repeat. Most of what AXL adds sits around that loop rather than inside it.

• Safety limits bound the loop itself - a maximum number of iterations, a token and cost budget, and a loop guard that notices when an agent calls the same tool with the same arguments over and over.
• Autonomy decides whether an action runs at all. Each agent declares a level, and require_approval means a person confirms before the action happens.
• Middleware wraps the loop in layers. Caching, approval gating, write caps, model routing, and telemetry are all middleware, and each agent enables only the ones it needs.
• The shield sits below everything, scrubbing secrets and fencing untrusted content before it reaches the model and before output reaches you.

A control plane

Most agent frameworks are libraries inside one process. AXL is a horizontally scalable control plane: every instance is identical and stateless, all state lives in shared storage, and any instance can serve any request. Scaling is starting more instances.

The same design makes work durable. A workflow started on one instance finishes on another if the first dies. A streaming client can reconnect to any instance and resume.

What you compose

You compose three things.

An agent is the unit you configure. A workflow orchestrates agents - and tools, and other workflows - when you need branches, loops, parallelism, and exactly-once execution that outlives a process restart. A surface is how the work gets requested: the HTTP API, a chat channel, a voice session, a schedule, or an open protocol like A2A or MCP.

Most projects start with one agent and never need more. Add a workflow when you find yourself wishing the model were less free to improvise about the order of things.

What you can attach to an agent

Everything below is optional. Start with an identity and a model, then add one capability at a time and confirm it behaves before adding the next.

Knowledge and context

Doing things

Control and safety

Reaching your agent

Knowing it works

A workflow, to make it concrete

Workflows are written in AXG, a small language purpose-built for this. Here is a complete, runnable one:

axg 1
workflow hello {
  input name
  greet = agent greeter:
    "Write a one-line friendly greeting for {{ input.name }}."
  greet -> return {
    greeting: greet.response
  }
}

It declares an input, hands it to an agent, and returns the answer. Submit it and you get a run id back immediately; the engine drives the run to completion in the background, across restarts and across server instances.

Where to go next