How Alex, The AI Systems Builder, Uses WayOfTeams

A step-by-step walkthrough of how a power user who builds local agentic pipelines, runs LLMs on bare metal, and orchestrates multi-tool dev workflows adopts WayOfTeams — and what features stick.

Who Alex Is

Alex doesn't use ChatGPT through a web browser. He runs LM Studio locally for inference, pipes context through custom orchestration harnesses, manages model caches across disk partitions, and treats LLMs as execution units in a larger pipeline. His daily stack includes OpenCode or Claude Code for agentic coding, Ollama for local models, Anchor for semantic memory, and a handful of custom CLI tools he's built himself.

He doesn't need to be told what MCP is. He already knows.

Phase 1: First Contact (Minutes 0–5)

What Alex Does

He signs up with GitHub (one click, done). He sees the onboarding flow and skips most of it — he already knows what he wants.

What Catches His Attention

The AI Engineering Harness is free on every plan. Before he even looks at the dashboard, he sees that the 53 skills, 12 agents, and 5 commands work identically across OpenCode, Claude Code, Codex, Pi, and Wo Code. This is the hook: one harness, every tool he already uses.

What He Does Next

He goes straight to the MCP server setup. He doesn't need the guided journey — he wants the endpoint URL and his token.

https://teamsapp.zerwiz.org/mcp

He signs in, grabs his JWT token, and drops it into his OpenCode config:

{
  "mcp": {
    "wayofteams": {
      "type": "remote",
      "url": "https://teamsapp.zerwiz.org/mcp",
      "enabled": true,
      "timeout": 30000,
      "oauth": false,
      "headers": {
        "Authorization": "Bearer {file:~/.wayofteams-mcp-token}"
      }
    }
  }
}

Restart OpenCode. Done. He types "Show me the available MCP tools" and sees 125 tools appear.

Why This Works for Alex

He's connected 17+ AI tools to MCP servers before. The Streamable HTTP transport, JWT auth, and per-developer tenant scoping are exactly what he expects. No surprise. No friction.

Phase 2: Understanding the Architecture (Minutes 5–15)

What Alex Does

Before he creates anything, he wants to understand the system. He asks his AI:

"What does the MCP server expose? Show me the tool groups."

He sees:

Group Tools What They Do
Tickets tickets_list, tickets_get, tickets_create, tickets_update Full ticket lifecycle
Plans plans_list, plans_get, plans_create, plans_update Implementation plans
Docs docs_list, docs_get, docs_create, docs_update, docs_search Living documentation
Knowledge knowledge_*, knowledge_project_* Global + project knowledge
Rules rules_*, rules_project_* Coding rules, enforced
Kanban kanban_boards, kanban_card_*, kanban_columns Visual work management
Memory memory_store, memory_search, memory_get, context_inject Anchor semantic memory
Collaboration send_message_to_agent, shared_context, workflow Multi-agent coordination
Coordinator coordinator_take_role, assign_work, list_work, conflicts Work orchestration
Versions versions_list, versions_bump, versions_rollback SemVer + CHANGELOG
Harness skills_list, agents_list, commands_list 53 skills, 12 agents

He also discovers the context engine — the thoughts/ directory structure:

thoughts/
├── global/                    # Cross-project concerns
├── shared/
│   ├── tickets/              # WOTEAMS-XXX tickets
│   ├── plans/                # Implementation plans
│   └── research/             # Notes, stack traces, code flows
└── wayofteams/
    ├── docs/                 # Architecture, decisions, guides
    └── shared/               # Project-specific work

This is familiar territory. He's built similar directory-based context systems before. The difference: this one has a Postgres mirror, search, and MCP tools that read/write it automatically.

Why This Works for Alex

He doesn't trust black boxes. Understanding the architecture before using it is non-negotiable. WayOfTeams gives him the full picture — 125 tools, clear tool groups, a directory-based context engine, and a Git-backed f-rr-d system with collision-safe numbering.

Phase 3: Creating His First Ticket (Minutes 15–20)

What Alex Does

He doesn't start with a hello-world. He starts with the actual problem he's trying to solve. He types:

"Create a ticket: 'Build a local context router that picks the right model based on task complexity — simple tasks go to small models, complex tasks go to large models. Priority high, domain backend.'"

His AI calls tickets_create. The ticket lands in the DB and gets pushed to his f-rr-d repo. He sees it in the dashboard immediately.

What He Notices

  • The ticket has a proper namespace: WOTEAMS-XXX
  • It's auto-linked to a kanban card
  • The f-rr-d markdown file was created and pushed — collision-safe, no manual numbering needed
  • The dashboard shows the ticket in his recent activity

Why This Works for Alex

He's used to managing work in markdown files and git. The f-rr-d system does what he'd do manually, but with DB persistence, search, and MCP tools that keep everything in sync. The collision-safe numbering solves a real problem he's hit before when multiple agents write tickets simultaneously.

Phase 4: The Plan → Implement Loop (Minutes 20–30)

What Alex Does

He doesn't want to hand-hold the AI through every step. He wants to hand off a ticket and get working software back. He types:

"Create a plan for WOTEAMS-XXX"

The AI calls plans_create. A phased implementation plan appears — each phase with concrete file changes, success criteria, and commit points.

He reviews it, then:

"Validate this plan"

The AI runs validate_plan — checks feasibility, dependencies, and risks. It comes back clean.

"Implement it"

The AI runs implement_plan. Phase by phase:

  1. Reads the codebase context
  2. Makes changes
  3. Runs tests
  4. Commits after each phase
  5. Updates the ticket status

He watches it happen in real-time on the dashboard — ticket status changes, commits appear, the kanban card moves.

What He Sees in the Dashboard

  • Ticket: status changed from "Planned" → "In Progress" → "Done"
  • Kanban: card moved across columns in real-time
  • Standup: his session entries are being captured automatically
  • Notifications: real-time alerts for each phase completion
  • Git history: clean, phase-by-phase commits with ticket references

Why This Works for Alex

He's built autonomous execution loops before. The difference here is visibility — every step is tracked, every change is committed, and the dashboard shows the full trail. He's not debugging a silent agent; he's watching a transparent pipeline.

Phase 5: Memory and Context Persistence (Day 2–3)

What Alex Does

This is where Alex gets genuinely interested. He's spent months building custom context systems — local RAG, persistent memory logs, dynamic databases. WayOfTeams has all of this built in.

He opens the Memory page and sees the Anchor integration:

  • Memory types: raw_trace, working_state, invariant, decision, review_pattern
  • Semantic search: memory_search finds related memories by meaning, not just keywords
  • Context injection: context_inject pulls recent anchors + chunks + search results
  • PR review context: pr_review_context loads decisions and patterns for code review

He stores his first memory:

"Store this as a decision: 'Use task-based model routing in ai.ex instead of a single model. Simple tasks (ticket creation, status updates) go to small models. Complex tasks (plan generation, code review) go to large models. This keeps costs down while maintaining quality.'"

The memory is stored in Anchor with type decision. Next time he or any agent in his company asks about model routing, context_inject will pull this memory into the session automatically.

What He Discovers

The Knowledge Base (global + project-scoped) is where he stores learned patterns. He creates a project knowledge entry:

"Save to project knowledge: 'When working with Ash Framework resources, always define the domain module first, then the resource. Ash resolves domains at compile time, so the domain must exist before the resource can reference it.'"

Next time an AI agent works on his project, it reads this knowledge before planning. The agent doesn't repeat mistakes he's already solved.

He also creates Rules — enforced coding conventions:

"Add a project rule: 'Never use System.get_env directly in lib/. All environment variables must flow through config/runtime.exs. The only exceptions are boot-time OAuth secrets in o_auth_setup.ex.'"

Rules are project-scoped and enforced by agents during implementation.

Why This Works for Alex

He's built context systems from scratch. He knows the pain of:

  • Context that degrades across sessions
  • Memory that can't be searched semantically
  • Knowledge that lives in one developer's head
  • Rules that exist in a README but nobody follows

WayOfTeams solves all four: Anchor for semantic memory, Knowledge for learned patterns, Rules for enforced conventions, and thoughts/ for the full context engine. All accessible through MCP tools his AI already uses.

Phase 6: Multi-Agent Orchestration (Day 3–5)

What Alex Does

He's running multiple AI tools simultaneously — OpenCode for coding, Claude Code for research, maybe a custom agent for monitoring. He needs them to coordinate without stepping on each other.

He opens the Agent Hub (Collaboration page) and sees:

  • Agent Registry: who's online, what they're working on
  • Work Board: real-time visibility into each agent's files, tickets, branches
  • Messages: durable inter-agent messaging
  • Shared Contexts: versioned workspaces multiple agents can read/write
  • Workflows: ordered multi-step pipelines

He claims the coordinator role:

"Take the coordinator role"

Now every agent in his company sees him as the leader. He can:

  • Assign work to agents via assign_work
  • Check for file conflicts via conflicts
  • Issue FREEZE before merges, GO when safe
  • Track who's working on what via list_work

What He Learns

The coordinator has strict rules (WOTEAMS-404):

  • Must not write code — it's a track/verify/deploy role only
  • Must assign code changes to other agents
  • Can read any file for verification, but never write to source files

This is deliberate. The coordinator is an orchestrator, not another coder. Alex appreciates this — he's seen what happens when coordination and execution blur together.

Why This Works for Alex

He's run multi-agent setups before where agents silently conflicted on the same files. WayOfTeams makes work visible, conflicts explicit, and coordination protocol-driven. The ETS-backed work registry and the coordinator role solve the "who's touching what" problem he's hit repeatedly.

Phase 7: Kanban Across Everything (Day 5–7)

What Alex Does

He creates boards for different niches:

  • Work (scope: work) — his software tickets and plans
  • Personal (scope: private) — his private task board, invisible to teammates
  • Ideas — a lightweight board for things he wants to try

Each board has multiple views:

  • Board view — drag-and-drop cards across columns
  • List view — filterable, searchable card list
  • Calendar view — see deadlines and standups on a shared calendar

He attaches files to cards — a log dump, a diagram, a model config file. The attachment system extracts text content from PDFs and DOCX files, making them searchable.

He uses the Today page to see what's due, what notes need attention, and what reminders are coming up.

Why This Works for Alex

He's tried Jira, Linear, Notion. They're all too heavy for a solo builder or small team. WayOfTeams kanban is fast, real-time, scoped to his needs, and — critically — the same cards show up in his AI tools via MCP. He can say "Move WOTEAMS-XXX to Done" and the card moves in the UI instantly.

Phase 8: Standups Without the Meeting (Ongoing)

What Alex Does

He doesn't like writing standups. But he likes having the history.

The standup system captures his work automatically:

  • Session entries from CLI tools
  • Focus score tracking
  • AI-powered summarization

He runs /standup or checks the Standups page at end of day. The system aggregates what he did, what he plans to do, and any blockers — from git history, ticket changes, and session entries.

If he's on a team, standups are generated automatically. No meeting needed.

Why This Works for Alex

He's a solo builder. Standups feel like ceremony for ceremony's sake. But having a machine-generated record of what he shipped each day — tied to tickets, commits, and plans — is genuinely useful. It's the audit trail without the overhead.

Phase 9: Living Documentation (Ongoing)

What Alex Does

He creates docs through the MCP:

"Create a doc under architecture: 'Model Routing Architecture'"

The doc lives in his f-rr-d repo, searchable through the Knowledge Base, and readable by AI agents as context.

The self-documentation skill answers "How do I...?" from his own docs and flags gaps. The session export skill captures what he solved, changed, and decided in each working session.

Over time, his docs grow with the work — they never go stale because the harness updates them when code, tickets, or architecture change.

Why This Works for Alex

He's written READMEs that were outdated the day he committed them. The self-updating doc model — where documentation is part of the same system that does the work — is something he's wanted but never built for himself.

Phase 10: Advanced — Workspaces, Cloud Sync, Custom Agents (Week 2+)

What Alex Does

He's now comfortable with the core loop. He explores the advanced features:

Hosted Workspaces (OpenChamber):

  • Per-tenant Docker containers with editor + agent terminal
  • GitHub integration, preview pane, session goals
  • Sizes from Starter ($20/mo) to Custom/GPU
  • He can prototype in a clean environment without polluting his local machine

Cloud Sync:

  • Multi-instance sync with hub/edge topology
  • Oplog-based change tracking, LWW conflict resolution
  • Real-time SSE streaming between instances
  • He can run WayOfTeams on his dev machine and his server, kept in sync

Custom Board Templates:

  • Company strategy board: Vision → Mission → Initiatives → Quarterly OKRs → KPIs
  • Marketing board: Idea → Writing → Editing → Scheduled → Published
  • Sales board: Lead → Contacted → Qualified → Closed
  • AI drafts OKRs from mission statements, content from card descriptions

Version Management:

  • SemVer bumps with categorized CHANGELOG entries
  • Git commit tracking, file tracking, rollback support
  • He bumps versions through MCP tools, not manual edits

Telegram Integration:

  • Notifications routed to Telegram
  • Card updates sent to channels
  • He gets alerts on his phone without opening the dashboard

Why This Works for Alex

He doesn't need all of this on day one. But knowing it's there — and that it all connects through the same MCP tools his AI already uses — means WayOfTeams grows with him. He starts with tickets and plans, adds memory and context, layers on multi-agent coordination, and eventually runs his entire workflow through one system.

Feature Adoption Order

Based on Alex's profile, here's what he'd use and when:

Priority Feature Why Alex Cares
1 MCP Server Direct integration with his existing tools
2 Tickets + Plans Structured work management, no ceremony
3 Memory/Anchor Semantic memory — the feature he's built from scratch before
4 Knowledge + Rules Codified patterns, enforced conventions
5 AI Chat (LM Studio) Local inference, per-session settings
6 Kanban Visual workflow, multiple views, real-time
7 Standups Auto-generated, no meeting overhead
8 Multi-Agent Coordination Work visibility, conflict detection, FREEZE/GO
9 Living Docs Self-updating documentation
10 Workspaces Clean prototyping environments
11 Cloud Sync Multi-instance, offline-first
12 Version Management Automated SemVer + CHANGELOG

What Makes WayOfTeams Different for Alex

Problem Alex Has WayOfTeams Solution
"I've built context systems from scratch" Anchor + Knowledge + Rules + thoughts/ — all accessible via MCP
"Agents silently conflict on files" Work visibility registry, coordinator role, conflicts tool
"I lose track of what my AI did" Dashboard shows every ticket, commit, plan, and session
"Documentation goes stale" Self-updating docs tied to the same system that does the work
"Memory degrades across sessions" Anchor semantic memory with type-aware storage and search
"I need to coordinate multiple tools" MCP server with 125 tools, one connection, works everywhere
"Standups are ceremony" Auto-generated from git + ticket history, no meeting needed
"I want to see what my team's AI did" Shared workspace with real-time notifications and review queue

The Core Loop

For Alex, WayOfTeams boils down to one loop:

Ticket → Plan → Implement → Review → Learn → Ticket
   ↑                                              │
   └──────────────────────────────────────────────┘

Every iteration feeds the context engine:

  • Tickets capture what needs to be done
  • Plans capture how it'll be done
  • Implementation produces working code with clean commits
  • Review catches issues before they ship
  • Learning (memory, knowledge, rules) prevents the same mistakes twice

The loop runs through MCP tools his AI already uses. No context switching. No separate dashboards. No manual status updates.

That's the system Alex would actually use.

← Back to all personas