The Sleeve Pattern: Why Your AI Agent Needs a Wardrobe

You don't talk the same way to your CEO as you do to your best friend. You don't write code reviews the same way you write marketing copy. Your vocabulary shifts, your risk tolerance changes, your entire mode of thinking adapts to the context. But your AI assistant? It has one personality, one set of instructions, one mode of operation for everything you throw at it.

We think that's fundamentally broken. An agent configured for deep research makes a terrible pair programmer. A blunt, fast coding assistant makes a terrible executive ghostwriter. The solution isn't to find one personality that's mediocre at everything. It's to let the same user have multiple agent identities, each purpose-built for a context.

We call them sleeves.

The "one prompt fits all" problem

Most AI tools give you one system prompt per workspace, project, or account. You tune it for your most common use case and accept that it'll be wrong for everything else. Some people cope by maintaining a library of prompt snippets they paste in. Some switch between different chat windows with different instructions. Some just accept the mediocrity.

The underlying assumption is that an AI assistant's personality is singular — you are one person, so your AI should be one thing. But you're not one thing. You operate in different modes. You have different standards of quality for a Slack message and a technical design document. You want different levels of autonomy when you're brainstorming versus when you're debugging a production issue.

A single system prompt can't express these distinctions because it can't be context-aware about which version of you is showing up.

What a sleeve is

A sleeve is a named behavioral configuration that bundles three things: a personality profile defined by measurable behavioral dimensions, a dedicated memory corpus, and a set of skills. Each sleeve belongs to a single user, but a user can have as many sleeves as they need.

Think of it as a role, but deeper than a role label. When you activate a sleeve called "Research," you're not just telling the agent "act like a researcher." You're giving it a specific position on every behavioral axis — how thorough it should be, how much it should challenge your assumptions, how verbose its output should be, how much initiative it should take. Those positions are measurable and calibratable, not vibes.

The memory corpus is the part that surprised us most. Each sleeve maintains its own memories, independent of the others. Your Research sleeve remembers your research methodology, the papers you've discussed, the hypotheses you're tracking. Your Drafting sleeve remembers your writing voice, your preferred structure, the feedback your editor always gives. Same user, completely different knowledge bases.

This separation emerged from a practical observation: memories that are invaluable in one context are noise in another. Your coding sleeve doesn't need to know about your marketing strategy. Your brainstorming sleeve doesn't need to know about your deployment pipeline. Shared memories across contexts means lower signal-to-noise in every context.

Native versus connected

A sleeve can operate in two modes. A native sleeve runs directly inside systimus.io — conversations happen in the web app, and the agent reasons through the full behavioral configuration on every turn. A connected sleeve works with external clients. Claude Code, Cursor, any MCP-capable tool can connect to the systimus.io server and access a sleeve's personality, memory, and skills through the protocol.

The connected mode is what makes sleeves portable rather than locked into a single interface. You configure once in systimus.io, and the configuration follows you to whatever tool you're working in. The agent in Claude Code gets the same behavioral guidance, the same memory recall, the same skill definitions as the agent in systimus.io itself.

This portability constraint drove several architectural decisions. The personality format had to be self-describing — any client needs to be able to render and interpret it without knowing systimus.io internals. The memory recall tool had to work over MCP without assumptions about the local environment. The skills had to be advertisable remotely even when they execute locally.

The identity boundary

One of the trickiest design decisions was where to draw the identity boundary between sleeves. Early on, we considered making sleeves share a base memory corpus with per-sleeve overrides. It seemed efficient — why store the fact that a user prefers Ruby in every sleeve separately?

In practice, shared memory created more problems than it solved. Conflicts between sleeves about which facts mattered, confusion about which sleeve had written a memory and whether it applied broadly, edge cases where one sleeve's ephemeral context leaked into another sleeve's recall. The complexity of managing shared-with-overrides exceeded the complexity of just letting each sleeve maintain its own corpus.

The current model is clean isolation with an explicit mechanism for cross-sleeve insight when you want it. Sleeves don't automatically share. But the user can configure a sleeve to draw from patterns observed across their other sleeves — a deliberate choice rather than an implicit default.

Switching cost and the wardrobe metaphor

The wardrobe metaphor isn't just branding. It captures something important about the interaction model. When you get dressed in the morning, you don't agonize over a configuration file. You pick the outfit that fits the context. The switching cost is near zero because the options are visible, named, and understood.

Sleeve switching works the same way. You pick the sleeve that fits the task. Via MCP, an external client can switch sleeves with a single tool call. In the web app, it's a selection. The agent's entire personality, memory, and skill set reconfigures instantly. No prompt rewriting, no context re-explanation, no starting over.

Low switching cost matters because it changes behavior. If switching contexts is expensive, people don't do it — they stick with their general-purpose configuration and accept the compromise. If switching is free, people actually use the right tool for the job. We've found that users who create their second sleeve almost always create a third. Once the pattern clicks, the use cases multiply.

What we didn't build

We deliberately avoided making sleeves hierarchical. No inheritance, no parent-child relationships, no template system where a "base" sleeve's settings cascade into derived ones. Every sleeve is fully specified and self-contained.

Hierarchy sounds elegant but creates debugging nightmares. When an agent behaves unexpectedly, you need to know exactly what configuration it's working from. With inheritance, that means tracing through a chain of overrides to figure out where a value came from. With flat, independent sleeves, the answer is always right there. The configuration is the configuration.

We also avoided automatic sleeve selection — the system suggesting which sleeve to use based on conversation content. It's tempting, but it introduces a meta-decision that's hard to get right and jarring when it's wrong. The user knows their context better than any classifier. Explicit selection keeps the user in control.

The compound effect

The sleeve pattern compounds with every other feature in the system. Behavioral calibration runs per-sleeve, so you get accuracy data specific to each context. Memory distillation feeds the right sleeve's corpus based on which sleeve was active during the conversation. Skills can be scoped to sleeves, so your research sleeve has access to tools your coding sleeve doesn't.

Most importantly, the sleeve pattern reframes what "personalizing your AI" means. It's not about finding the one perfect configuration. It's about building a wardrobe — a collection of purpose-built identities that you switch between as naturally as changing clothes. The agent isn't one thing. It's as many things as you need it to be.