The Wizard Pattern: How We Think About Getting Agents to Zero-to-Working

We've been building a configuration wizard for 0Latency. Not because it's glamorous work — it isn't — but because every time a new user sets up an agent with our memory layer, they're navigating a configuration surface that silently fails if you get it wrong. A user who gets it wrong doesn't see an error. They just see memory that "kind of works," which is harder to debug than a clean failure.

Working through the wizard spec forced us to document what we actually do when we set up a new agent. What came out of that process was more interesting than we expected.

What Silent Failure Looks Like

When we first set up Thomas with 0Latency memory, we had four namespaces that looked active: thomas, justin, opus, and claude. The last two were empty. The first two had content — but Thomas was only querying thomas, and the Chrome extension was only writing to justin. Nothing connected them.

From a user's perspective: memory worked for things Thomas learned through Telegram. It didn't work for things that came through Claude.ai sessions. There was no error. No alert. No indication that data was flowing into a namespace that nothing was reading. It just looked like recall was imperfect, which for an AI system feels plausible enough that you don't immediately suspect a routing failure.

A wizard would have caught this immediately. Step one of any agent setup should be: what namespaces exist, what's writing to them, and what's reading from them. If those don't align, surface it before the user writes a single memory.

The Manifest Concept

The key output of a wizard isn't a filled form. It's a fleet manifest — a single document that describes the complete state of your agent configuration: which namespaces exist, which tools write to which namespaces, which agents read from which namespaces, and what the expected data flow looks like.

For our setup, that manifest looks something like this:

{
  "namespaces": {
    "thomas": {
      "writers": ["openClaw/thomas", "telegram-integration"],
      "readers": ["openClaw/thomas", "recall-dual.sh"],
      "memory_count": 1979
    },
    "user-justin": {
      "writers": ["chrome-extension"],
      "readers": ["recall-dual.sh"],
      "memory_count": 47
    }
  },
  "recall_scripts": {
    "recall-dual.sh": {
      "queries": ["thomas", "user-justin"],
      "description": "Session start context for Thomas"
    }
  }
}

The manifest makes the invisible visible. You can audit it in 30 seconds and immediately see if something isn't connected. We didn't have anything like this for the first three months of running the fleet. We should have had it from day one.

The Key Rotation Problem

The second thing the wizard spec revealed was how painful key rotation is without tooling. An API key lives in: the OpenClaw config file, every agent's skill configuration, the Chrome extension settings, any CI/CD environment that runs scripts against the API, and whatever local .env files exist on developer machines.

Rotating a key today means finding every one of those locations, updating each manually, and hoping you didn't miss one. If you miss one, an agent silently stops writing memories — which looks exactly like the namespace routing failure above. The agent appears to work. The memory layer appears to work. Nothing errors. Memories just stop accumulating.

A key rotation wizard has one job: enumerate every location where the key lives, update them atomically, verify each update with a write-then-read check, and report which locations succeeded and which failed. This is mechanical work that agents are well-suited for. The failure mode of doing it manually — missing one location and not noticing for days — is exactly the kind of silent failure that erodes trust in the system.

Zero-to-Working as a Design Constraint

We put "zero configuration" in our marketing because the API itself is simple: store a memory, recall a memory, no schema required. But "zero configuration" doesn't mean "zero setup." It means the setup that does exist should be impossible to get silently wrong.

That's a higher bar than it sounds. It means the wizard has to: detect what environment you're in (Claude Desktop, OpenClaw, custom API integration), generate a namespace schema appropriate for that environment, produce the config files in the right format for each tool, verify that data flows correctly before handing off to the user, and provide a migration path for users who already have memories in a misconfigured setup.

The migration path is actually the most important piece for early adopters. Everyone who set up before the wizard existed has some version of the namespace routing problem — maybe not as severe as our example, but some misalignment between what's writing and what's reading. A wizard that only serves new users is useful. A wizard that can audit and repair an existing setup is what actually builds trust.

What We've Learned

Building the wizard spec was essentially writing down the manual process we follow every time we add a new agent to the fleet. The steps we document are the steps a wizard would automate. The failure modes we've encountered are the failure modes a wizard would prevent.

There's a meta-lesson in that: the best infrastructure tooling often comes from documenting what you already do by hand and asking whether a machine can do it more reliably. Not what would be cool to automate. What do you currently do manually that, if done wrong, causes a silent failure that takes days to diagnose?

For memory infrastructure specifically, the answer is: namespace routing, key management, and the verification that data actually flows from where you're writing to where you're reading. We're automating all three. The wizard is the delivery mechanism.