Fourteen months ago, I published [Agents Deserve Better than Retrofitted Frameworks](/post/agents-deserve-better-than-retrofitted-frameworks).

The argument was simple:

> We are trying to build a new kind of software using infrastructure designed for the old kind.

Most agent frameworks started as LLM wrappers. Then they added tools. Then memory. Then multiple agents. Then deployment. Then observability. Each new production requirement became another abstraction bolted onto a foundation that was never designed to carry it.

I knew what I wanted instead. Agents as native primitives. Memory as infrastructure. Orchestration below the application layer. A complete AI system you can define, version, deploy, operate, and connect to from any application.

At the time, that was a thesis.

Today it is a working stack, and every item on the 1.0 roadmap is shipped.

[MUXI 1.0 is here](https://muxi.org).

## This is not another agent framework

Nobody builds their own Nginx to deploy a website.

Nobody starts a web project by writing process management, routing, TLS termination, health checks, deployment, logging, and rollback from scratch. We have infrastructure for that.

But this is exactly what developers are still doing with AI. They pick a framework, write orchestration code, stitch together memory, add a vector database, build authentication, figure out multi-tenancy, bolt on observability, invent a deployment model, and pray the demo survives contact with production.

The model call was never the hard part.

Everything around it was.

MUXI is the **AI application server**. You do not import it into your application. You deploy your AI system to it, then build your product on top through APIs, MCP, or an SDK.

Think Flask versus Nginx. One is a framework you write code with. The other is the infrastructure you deploy to.

MUXI is the second thing.

## The formation is the unit of software

The first real decision was that an AI system needs a portable deployment unit.

I call it a **formation**: a version-controlled directory anchored by a declarative `.afs` file, describing the entire intelligent system rather than a single agent.

```yaml
# [PLACEHOLDER - swap in a real .afs before publishing]
formation: support-desk
version: 1.0.0

models:
  default: gpt-5
  fallback: [claude-sonnet-5, llama-4-70b]

agents:
  triage:
    role: Classify and route inbound tickets
    tools: [zendesk, search_kb]
  resolver:
    role: Draft and send resolutions
    tools: [zendesk, artifacts]

memory:
  scopes: [user, group, formation]
  retention: 90d

knowledge:
  - source: s3://acme-docs/handbook/
    retrieval: hybrid
```

A formation carries agents and their responsibilities, models and fallback chains, memory and knowledge, MCP tools and A2A services, Standard Operating Procedures, skills and sandboxed scripts, triggers and schedules and outbound channels, access-control rules, proactive behavior, self-tuning state, and secret references.

Like a Dockerfile describes a container, a formation describes an AI system.

That idea became the independent [Agent Formation Standard](https://agentformation.org), with MUXI as its reference implementation.

It mattered more than I expected. Once the formation became the unit, everything else got clearer. Deployment stopped being "run this Python script" and became "deploy this formation." The registry stopped being a collection of prompts and became a registry of complete AI systems. Updates, rollbacks, validation, local development, and CI could all operate on the same artifact.

The system finally had a shape.

## MCP without destroying the context window

I wrote earlier this year that people were using MCP wrong. (MCP - Model Context Protocol - is how models talk to external tools.)

The problem was never MCP. The problem was injecting every tool definition into every prompt.

MUXI fetches and indexes MCP tool definitions once, then selects only the tools relevant to the current request. Formation, group, server, and agent policies narrow the surface further. You can connect large tool catalogs without making the model carry all of them on every turn.

MUXI also works in the other direction. Every formation exposes its own MCP server. Connect it to Claude Desktop, Cursor, or any MCP-compatible client, and the formation's agents, memory, tools, and authentication become an AI-native tool surface.

The same system, through REST, SSE, twelve SDKs, or MCP.

No adapter layer. No second implementation.

## Then the real work started

Declaring an agent is easy.

Running one reliably for many users, over time, while it calls external tools and modifies real systems, is not.

MUXI grew into a coordinated stack:

1. **MUXI Server** (Go) - deployment, authentication, routing, lifecycle, health checks, versions, isolated runtime processes.
2. **MUXI Runtime** (Python) - loads formations; handles orchestration, model calls, memory, tools, workflows, streaming, observability.
3. **MUXI CLI** - the development and deployment lifecycle.
4. **Twelve SDKs** - Python, TypeScript, Go, Ruby, PHP, C#, Java, Kotlin, Swift, Dart, Rust, C++.

Plus OneLLM for provider-agnostic model access, FAISSx for local vector infrastructure, schemas, examples, the registry, the docs, and the Agent Formation Standard itself.

That sounds obvious as a list. It was not obvious while building it.

Every layer exposed assumptions in the layer below. Authentication affected streaming. Streaming affected SDK design. Per-user credentials affected MCP connection pooling. Memory scopes affected access control. Rollbacks affected self-tuning state.

A feature was never finished when it worked in one repository. It was finished when the Runtime, Server, CLI, schemas, docs, and twelve clients agreed on what it meant.

That is what 1.x represents. Not "we added enough features to call it 1.0."

A stable contract across the entire stack.

## Memory had to become a platform

Most agent memory is chat history with embeddings. That works in demos. It is not enough for a system expected to run for months, serve many users, learn from experience, and explain why it believes something.

MUXI 1.x has layered memory: recent conversational context, semantic working memory, long-term persistent facts, derived user synopses, and user, group, and formation scopes.

But the layer count is not the point.

The point is that every memory write can be captured as an immutable event with provenance. The stores become rebuildable projections.

That unlocks questions normal agent memory cannot answer:

- Why does the system believe this?
- Where did this fact come from?
- What changed?
- Can I rebuild the index?
- Can I forget one subject without deleting everything?
- Can old information decay?
- Can two contradictory facts coexist, with a record of which superseded which?

On that event substrate, MUXI builds a knowledge graph, temporal Captain's Logs, reusable lessons, compaction, pruning, and lifecycle controls.

There is also a signed **memory distillery** protocol. An organization can process raw information inside its own perimeter and send only pre-processed memory events to a formation. Registrations are scoped, authenticated with Ed25519 signatures, quota-controlled, trust-labeled, and revocable.

Memory stopped being a feature. It became infrastructure.

## RAG needed to reason

Vector retrieval finds similar chunks. It does not understand the shape of a document.

Ask a question whose answer depends on a definition in chapter two, a constraint in chapter seven, and an exception in an appendix. A similarity search returns three locally relevant fragments and no idea how they fit together.

MUXI supports reasoning RAG over hierarchical document trees. Large documents are indexed as structures agents navigate at query time, using tree, tree-vector, or hybrid retrieval. Fast vector lookup when that is enough; hierarchical reasoning when the question demands it.

Knowledge does not have to live beside the formation either. Sources sync from HTTP, S3, Google Cloud Storage, Azure, rsync, FTP, SFTP, or local files. Archives extract, changes re-embed incrementally, syncs run on a schedule.

RAG should not mean "put PDFs in a vector database."

It should mean giving an intelligent system a way to navigate knowledge.

## One formation, many users, different permissions

Multi-tenancy cannot be an afterthought. If two users share a formation, they must not share sessions, memory, credentials, or unauthorized tools.

MUXI isolates users throughout the stack. OAuth tokens and API keys are stored per user, encrypted at rest, and resolved automatically when an agent calls a tool on that user's behalf.

1.x adds group-based **RBAC** (Role-Based Access Control). Groups support inheritance. Policies control access to agents, MCP servers, and individual tools using allow and deny patterns. Membership can come from external middleware, and it fails closed when it cannot be resolved.

The same formation can serve finance, support, engineering, and leadership - exposing a different intelligent surface to each group.

One system. Many users. Different memory, credentials, capabilities, and boundaries.

## Formations can act before you ask

Most agents sit behind a chat box waiting for a prompt.

That is not agency. That is a request-response API with a personality.

MUXI formations initiate contact. They run heartbeats, respect active hours, inspect their environment, and notify users through per-user channels. Slack, Telegram, Discord, email, and custom destinations are all outbound transformers.

A `SOUL.md` document gives the formation durable guidance on how it should behave. Built-in slash commands let users control channels, status, help, memory, and proactive behavior without every application inventing its own command system.

The crucial part is restraint.

A proactive agent that constantly says "everything is fine" is worse than a passive one. MUXI supports `HEARTBEAT_OK` suppression, so healthy checks disappear instead of becoming noise.

The formation acts when there is something worth saying.

## Formations can improve themselves

This is the feature I find hardest to describe without sounding like science fiction.

Formations observe how they are used, analyze operational evidence, identify recurring patterns, and distill what they learn into candidate revisions of their operating guidance - `MUXI.md`, the formation's tunable behavior document, distinct from the human-authored `SOUL.md`.

Not source-code rewrites. Not an AI silently changing production.

Reviewable behavioral improvement.

The tuning loop reads accumulated activity, combines it with past experiments and watched metrics, retires learnings that did not produce a measurable improvement, and proposes a new version. You inspect it, apply it, or dismiss it:

```bash
muxi tuning show
muxi tuning pending
muxi tuning apply
muxi tuning dismiss
```

The Server preserves `MUXI.md` and `PENDING-MUXI.md` across updates and rollbacks, alongside persistent memory. Deploying new code does not erase what the formation learned.

This is not "the model gets smarter."

The system gets better at being itself.

## Work outlives the turn

Some tasks should not happen inside a chat turn. Coding is the obvious example.

MUXI delegates coding tasks to Claude Code, Droid, OpenCode, Pi, or a custom headless adapter. The job runs asynchronously in an isolated workspace and returns structured status, progress, and results. Formations also watch long-running MCP jobs - video generation, batch processing, remote builds. Polling is deterministic and uses no LLM, so waiting costs zero tokens. When the job finishes, the formation re-enters and continues under the original user's permission context.

Without this, long-running tools either block a request, get forgotten, or burn tokens asking "are we there yet?"

Agent systems need a job model, not just a tool-call model.

The same logic applies to output. Agents produce spreadsheets, presentations, reports, charts, code, images, data files - and most agent systems lose the file when the response ends.

In MUXI, generated artifacts become persistent memory. Versioned, encrypted, checksummed, user-scoped, recallable. An agent retrieves a previous report, inspects its history, modifies it, and produces a new version.

The output of yesterday's work becomes input to tomorrow's.

## The rest of the stack

Headline features get the attention. Production systems live or die in the unglamorous details.

**Intelligence and execution**

- Multi-agent orchestration with dynamic task decomposition
- SOP-guided workflows agents reason over instead of blindly following
- Optional workflow replanning when intermediate results change the best path
- Model selection at formation, agent, SOP, trigger, skill, and step level
- Model aliases and fallback chains
- A2A communication between formations and external agent systems
- Native multimodal processing for images, PDFs, audio, and video
- A bundled compute skill for code-as-reasoning inside an isolated sandbox
- Local semantic classification for decisions that do not need a cloud LLM
- Typed UI widgets in responses - options, action links, MCP resources - rendered by clients that understand them, ignored by those that do not, with text always usable as the fallback

**Tools and automation**

- Agent Skills using the open `SKILL.md` format with progressive disclosure
- Sandboxed script execution with resource and timeout controls
- Natural-language scheduling for one-time and recurring jobs
- Webhook and event triggers
- Outbound transformers with templates, authentication, retries, and fallbacks
- Per-user MCP credentials
- Tool filtering at multiple levels
- Built-in tools for artifact recall, history recall, lesson recording, coding delegation, and background-job monitoring

**Production operations**

- One-command deployment with `muxi deploy`
- Draft runtimes for local development and pre-production testing
- Versioned formations, updates, and rollbacks
- Isolated runtimes using Apptainer/SIF on Linux, and a Docker-based runner on macOS and Windows
- Circuit breakers, exponential backoff, model fallbacks, graceful degradation
- Idempotency keys for retry-safe chat, trigger execution, and scheduled-job creation
- Real-time SSE streaming for text, progress, planning, tools, UI, and lifecycle events
- Hundreds of typed observability events
- Secret and entity-based PII redaction before telemetry reaches exporters
- Stable APIs and typed errors across every SDK

This is why I keep calling MUXI infrastructure.

Any individual feature can be built in a framework. The product is that they already work together.

## Why 1.0 took this long

I could have shipped a 1.0 label months ago. The software already did impressive things.

But 1.0 should mean something. It should mean a developer can build on the contract instead of chasing it. It should mean the same concepts survive the journey from YAML schema to Runtime behavior, through the Server proxy, into every SDK. It should mean deploy, update, rollback, stream, retry, authenticate, and recover are not separate stories.

And it should mean we were willing to remove old ideas when they stopped fitting.

That last part matters. Getting here was not just adding features. It was deleting pre-1.0 shortcuts, unifying naming, tightening identifiers, making authorization fail closed, standardizing response envelopes, formalizing idempotency, and syncing public API specs with actual runtime behavior.

The hardest work in infrastructure is rarely inventing the feature.

It is making the feature boring enough to trust.

Server, Runtime, CLI, and all twelve SDKs now move together on the 1.x line. Stable formation contracts. Stable API behavior. Consistent authentication, streaming, errors, idempotency, response envelopes.

I have been calling this **the prime time release**, and I mean it literally. Not "look what it can do." Ready for the thing you actually depend on.

## What is left

The 1.0 roadmap is cleared. One thing on it is not: the **web console**.

Everything MUXI does today is available through the CLI, the APIs, MCP, and twelve SDKs. But there is no browser UI yet for deploying formations, inspecting memory, reviewing tuning proposals, or watching observability events in a "nice" way. That is the next thing I am building.

Infrastructure is never finished. The foundation is stable enough to build on.

## How this got shipped

Worth saying plainly, because it is the thesis eating its own cooking.

A stack this wide - Server, Runtime, CLI, twelve SDKs, schemas, docs, all held to one contract - is not a solo-human amount of work. The last stretch leaned on **Claude Fable 5**, **GPT-5.6 Sol**, and [**Droid**](https://app.factory.ai/r/FM8BJHFQ).

Droid is one of the same headless coding agents MUXI delegates to. I built the infrastructure for agent-delegated work by delegating the work to agents.

That is not a cute detail. It is the whole argument.

And there is a sharper point buried in it. Both frontier models I leaned on hardest shipped *during* this build. The models underneath me changed while I was standing on them - and the formations, the contracts, the memory scopes, the deployment model did not have to change at all.

Swapping the engine did not require rebuilding the car.

Models will keep getting better and cheaper. That is exactly why they are not the moat.

## What I learned

The original thesis was right, and incomplete.

Agents did deserve better than retrofitted frameworks. What I underestimated was how much "better" actually required.

It was not a smarter orchestrator.

It was a complete operational model. Identity. Memory. Permissions. Jobs. Artifacts. Deployment. Compatibility. Failure. Recovery. Interfaces. State that survives a release. Knowledge that can explain itself. Improvement that stays under human control.

The interesting part of agentic AI is moving away from the model call. The durable value is the system around it.

That is what MUXI is. Not an agent. Not a framework.

I called it the server that runs intelligence at the top of this post. Fourteen months of work is what it took to earn the sentence.

## Try it

MUXI is free to self-host, with public source across the stack. Server and Runtime use the Elastic License 2.0. CLI, SDKs, schemas, and formations use Apache 2.0.

macOS:

```bash
brew install muxi-ai/tap/muxi
```

Linux:

```bash
curl -fsSL https://muxi.org/install -o muxi-install.sh
# read it, check the checksum at https://muxi.org/install.sha256, then:
sudo bash muxi-install.sh
```

Windows:

```powershell
powershell -c "irm https://muxi.org/install | iex"
```

Then run the [five-minute quickstart](https://muxi.org/docs/quickstart).

Code on [GitHub](https://github.com/muxi-ai). Docs at [muxi.org/docs](https://muxi.org/docs). The standard at [agentformation.org](https://agentformation.org).

Fourteen months ago I wrote that the multi-agent future needed purpose-built infrastructure.

Now you can deploy to it.

**MUXI 1.0 is here.**