Agent Mindsets — Draft Rewrite

Ten days ago I wrote a blog post about the mindset system. It described a clean architecture: five modes, channel bindings, workspace separation. Very neat. Mostly wrong — not wrong about the facts, but wrong about what mattered.

That post read like a spec sheet. Here's what actually happened.

Day One

The idea was simple. Instead of spinning up multiple agents that negotiate with each other, you give one agent multiple thinking modes. Route messages to the right mode based on which Discord channel they land in. No orchestration framework, no inter-agent protocols — just channel bindings in a config file.

Day one had four mindsets: a main coordinator, an infrastructure mode, a dev mode, and a personal assistant mode. Each got a Discord forum channel and a workspace directory with some markdown files describing how to think. Main was the "Chief of Staff" — it would triage incoming work, break it into tickets, and delegate to the right mindset.

This is the part the original blog post described. It was true for about 48 hours.

What Broke

The Ticket System Collapsed

The original design treated Discord forum threads like Linear tickets. Main would create a thread titled "Set up DNS for blog.justin.vin," assign it to the infrastructure forum, and the infra mindset would pick it up. Clean pipeline. Triage → delegate → execute → close.

The problem: real work isn't a pipeline. A thread about setting up DNS turns into a thread about debugging Cloudflare certificate propagation, which surfaces a question about whether to use Pages or Workers, which requires a design decision about the build system. The thread's "ticket" title is wrong within an hour. The scope mutated three times before lunch.

Treating threads as tickets created a constant grooming burden. Threads needed retitling, re-scoping, splitting, merging. The overhead of maintaining the board ate into the time saved by having the board.

The fix was a mental model shift: threads aren't tickets. They're context windows. A thread is a focused conversation about whatever it's currently about. Its title reflects its current state, not its original assignment. When the focus shifts, the title updates. When it's done, it closes. No backlog, no sprint planning, no status tags.

This sounds like giving up on project management. It's actually giving up on pretending forum threads are Jira. They're not. They're better at what they actually are — persistent, scoped conversations — and worse at everything Jira does. Stop fighting it.

Main Couldn't Be a PM

The original Main mindset was designed as a project manager. It maintained a board, tracked statuses, created and groomed tickets, ran standups. It was the orchestration hub.

This broke for two reasons. First, the PM overhead scaled linearly with the number of active threads. Every new thread meant another thing Main had to track, groom, and update. At fifteen concurrent threads, Main was spending more time managing the board than actually routing work.

Second, PM behavior encourages implementation. A PM who "scopes work and creates detailed tickets" inevitably starts making technical decisions in the ticket description. Main would write things like "use Astro with MDX, deploy to Cloudflare Pages" in the delegation — pre-solving the problem instead of routing it. The mindsets receiving these tickets would follow the spec even when they'd have made better choices independently.

The fix: Main became a router. It reads incoming messages, identifies which mindset should think about them, and opens a thread with minimal context — usually just the original message and a sentence of framing. No prescriptive specs. No board maintenance. No status tracking.

Main's job is now closer to a forum moderator than a project manager. It decides which forum a topic belongs in and creates the thread. The thread takes it from there.

The Code Rule

We needed a bright line for Main. The rule that stuck: if it has a file extension, Main doesn't touch it. Markdown in Main's own workspace is fine. Anything else gets routed. This sounds arbitrary, but it eliminated the entire class of "Main accidentally implemented something it should have delegated" bugs.

The Architecture That Emerged

What we have now looks nothing like a multi-agent system and nothing like a single chatbot. It's one identity running seven thinking modes across Discord forums, managed primarily from a phone.

Forums as Substrate

Each mindset owns a Discord forum channel. When a thread is created in that forum, the mindset activates for that conversation. The routing is pure config:

agents:
  list:
    - id: main
      bindings: ["channel:justin"]
    - id: infra
      bindings: ["channel:infra-forum"]
    - id: design-engineer
      bindings: ["channel:dev-forum"]
    # ...and so on

No code. No middleware. Discord's existing forum structure handles what most agent frameworks build custom infrastructure for: persistent threaded conversations with isolated context.

Threads as Autonomous Contexts

Each thread is its own session with its own context window. When you open a thread about debugging DNS, that thread knows about DNS and nothing else. It can read files, run commands, search the web — but its conversational context is scoped to its topic.

This creates natural parallelism. Five threads in the infra forum can all be active simultaneously, each working on different problems, none polluting each other's context. A thread debugging a gateway crash isn't distracted by a thread setting up a new subdomain.

Threads are autonomous but steerable. If a thread goes off-track, you can redirect it without nuking its context. If it needs to pause while waiting on something external, it says so in the title (⏳ Waiting on DNS propagation). The thread title is always the current state — a glanceable dashboard of what's happening across the system.

Files as the Collaboration Layer

Threads can't talk to each other. There's no inter-thread messaging, no shared memory bus, no pub/sub system. The collaboration layer is the filesystem.

When the infra mindset configures DNS for a new subdomain, it writes the records to the actual DNS provider and the config files on disk. When the dev mindset deploys a site to that subdomain, it reads the same files. They never exchange a message. They share state through the artifacts of their work.

This is simpler than it sounds and more robust than the alternatives. Thread A doesn't need to know Thread B exists. Thread B doesn't need to know who created the files it's reading. The filesystem is the API. Git is the sync layer.

Each mindset also gets its own workspace directory with persistent memory:

~/.openclaw/
  workspace/                    # Main
  workspace-infra/              # Infrastructure
  workspace-design-engineer/    # Dev/build
  workspace-pa/                 # Personal assistant
  workspace-finance/            # Financial admin
  workspace-seeds/              # seed.show project
  workspace-justin-socials/     # Social media
  workspace-wordware/           # Day job context

Inside each: SOUL.md (how to think), MEMORY.md (what to remember), IDENTITY.md (role in the system), and a memory/ directory of daily notes. Operational knowledge is shared via skills that all mindsets load. Working context is isolated.

Voice-First Mobile

This wasn't designed. It emerged.

Discord on mobile supports voice messages. It turns out that talking into your phone while walking to get coffee is a remarkably natural way to manage an AI system. "Hey, check if that DNS propagated yet." "Open a thread in finance for tracking the HMRC payment." "The blog post is outdated, needs a rewrite."

Voice messages get transcribed and processed like any other message. The mindset doesn't know or care whether the input was typed or spoken. But the workflow is fundamentally different. You manage by voice from your phone, check back later to see thread titles updating, tap into the ones that need attention.

Most of the real orchestration happens this way — not sitting at a keyboard composing detailed instructions, but firing off voice notes between meetings and reviewing the results over lunch.

Heartbeats and Steering

Threads are autonomous but they're not unsupervised. Two mechanisms keep them on track:

Heartbeats run every 30 minutes. Each mindset checks its forum for stale threads, unanswered messages, and blocked work. Think of it as a periodic self-review — "am I stuck anywhere? did I miss anything?" Heartbeats also handle background monitoring: checking email, scanning for upcoming calendar events, watching deploys.

Steering is course-correction without context destruction. When a thread is headed in the wrong direction, you inject a message that redirects it. The thread keeps its accumulated context but shifts focus. This is different from closing and reopening — you don't lose the debugging history just because the approach needs to change.

The anti-pattern we learned: never pile unrelated work onto an active thread. If a thread is debugging a crash and you want it to also set up monitoring, you open a new thread. Steering is for course-correcting the same task, not for scope expansion.

What We Actually Use It For

The system runs everything from infrastructure to personal admin. Some real examples from the last ten days:

Financial admin. A thread in the finance forum tracks HMRC tax payments — communicating with the accountant, sending bank transfers via Wise, following up on confirmation. Another monitors prescription pickups, watching for Kaiser pharmacy emails and setting escalating reminders before the order gets canceled. All managed from the phone.

Infrastructure debugging. When the gateway enters a crash loop — which happened several times during the first week — a thread in the infra forum investigates root causes, analyzes logs, proposes fixes, and waits for approval before implementing. One crash loop turned out to be a browser profile plugin writing to the config file, triggering restarts, hitting Discord rate limits during startup, and crashing. The thread traced this across three layers without losing context.

Content production. The socials mindset manages accounts across Reddit, Hacker News, and YouTube. It created the accounts, developed a posting strategy, and now manages engagement — all scoped to its own forum with its own memory of what's been posted, what worked, and what got flagged by HN's spam filter.

Contact management. The PA mindset imported 734 contacts, merged 184 duplicates, added WhatsApp profile photos, created 156 new contacts from messaging apps, and built a CRM with 105,000+ logged interactions. Each cleanup phase was its own thread — parallel execution, no context pollution.

Product work for the day job. The wordware mindset maintains context about the company, the product (Sauna), the team, the roadmap. When work-related questions come in, they route to a mindset that already understands the professional context without needing to re-explain it every time.

The Evolution Pattern

The system started with four mindsets and now has seven. But the number isn't what changed — the architecture did.

Week 1: Main is a PM. Threads are tickets. Linear was briefly considered as the backend. Five mindsets in a hierarchy.

Week 2: Main is a router. Threads are context windows. Discord forums are the only substrate. Seven mindsets, flat structure. Voice messages are the primary input method. Files are the only collaboration mechanism. Heartbeats keep things moving. Steering keeps things on track.

The forces that drove the evolution:

• Scale. Four mindsets with ten threads is manageable as a kanban board. Seven mindsets with thirty concurrent threads is not. The PM overhead that seemed fine at small scale became the bottleneck.
• Mobility. Once voice messages worked, the phone became the primary interface. Phone interfaces reward glanceability (thread titles) over detailed dashboards (board views).
• Failure. Threads that tried to implement prescriptive specs from Main consistently made worse decisions than threads that were given the problem and figured out the approach themselves. Autonomy produced better outcomes.
• Emergence. The finance mindset, the socials mindset, the seeds mindset — none were planned. They were spun up when the existing mindsets were being asked to context-switch too aggressively. The system grew where it needed to.

What Actually Matters

If you're building something like this, here's what I'd focus on:

Boundaries over capabilities. The most important thing in each mindset's configuration isn't what it can do — it's what it won't. "Main never implements" prevents more bugs than any linter. "Dev doesn't touch DNS" prevents more outages than any monitoring. The boundaries are the architecture.

Thread titles are your dashboard. With thirty concurrent threads, the only way to stay oriented is thread titles that reflect current state. 🔧 Gateway crash loop → ⏳ Waiting on deploy → ✅ Stable 4h. If you can't tell what's happening from the title, the system is opaque.

Don't fight the substrate. Discord forums aren't Jira. They're not Linear. They're persistent threaded conversations with titles and archive states. Build around what they are, not what you wish they were.

One identity, many modes. There's no "who am I talking to?" problem because it's always the same entity. Same voice, same personality, same opinions. Different lens. This eliminates an entire class of multi-agent coordination problems.

Files over messages. Inter-thread communication through the filesystem is ugly and simple and it works. Threads don't need to know about each other. They share the world by changing the world.

The Meta Moment

This post was written by the design-engineer mindset. The request came as a voice note. Main routed it to a thread in the dev forum. The mindset read the original post, reviewed memory files across seven workspaces to understand how the system actually works now versus how it was described ten days ago, and wrote this.

One mind. Seven modes. No framework. Just config files and markdown on top of OpenClaw.