|9 min read

Loki Mode is Born: Building a Multi-Agent Autonomous System

Introducing Loki Mode — a multi-agent autonomous system for Claude Code with 41 agent types across 8 swarms

aiagentsmcpopen-source

I have been building something for the past several months that I am finally ready to talk about. It is called Loki Mode, and it is a multi-agent autonomous system designed to bring structure, verification, and quality gates to AI-powered software development.

This is not a wrapper around an LLM. It is an orchestration layer that coordinates dozens of specialized agents to plan, execute, review, and verify software engineering work, autonomously, but with discipline.

The Problem

AI coding assistants are powerful. Claude, GPT, Gemini: they can all write code, debug issues, and reason about architecture. But if you have spent any real time using them for production work, you have noticed the gaps.

A single-agent approach hits walls quickly:

  • No verification loop. The agent writes code but does not systematically validate it against requirements.
  • No separation of concerns. The same context window handles planning, coding, testing, documentation, and review. That is a lot of cognitive load for one agent, and things get dropped.
  • No quality gates. There is nothing stopping bad code from flowing downstream. The agent generates, you accept or reject, and that is the entire quality process.
  • No structured reasoning. Without explicit planning phases, agents tend to jump straight into implementation, missing edge cases and architectural considerations.

I wanted something better. Not a smarter single agent, but a structured system of agents that mirrors how high-functioning engineering teams actually operate.

The RARV Cycle

At the core of Loki Mode is the RARV cycle: Reason, Act, Reflect, Verify.

Every significant task flows through these four phases:

  1. Reason: Plan the approach. Analyze requirements, identify risks, break work into subtasks, consider edge cases. This happens before any code is written.
  2. Act: Execute the plan. Write code, modify configurations, create tests. This is where the actual implementation happens.
  3. Reflect: Review the work. A separate agent examines what was produced, checks for issues, evaluates quality, and identifies gaps.
  4. Verify: Validate the results. Run tests, check linting, verify that the implementation meets the original requirements.

The key insight is that these phases are handled by different agents with different responsibilities. The agent that plans is not the same agent that codes, and the agent that reviews is not the same agent that built it. This mirrors the separation you see in mature engineering organizations: architects plan, developers build, reviewers critique, QA validates.

# The RARV cycle in action
loki-mode run --task "Add user authentication to the API"

# Phase 1: REASON - Planning agent analyzes the task
# [planner] Analyzing requirements...
# [planner] Identified 4 subtasks, 2 risks, 3 edge cases

# Phase 2: ACT - Implementation agents execute
# [coder] Implementing JWT middleware...
# [coder] Adding user model and routes...

# Phase 3: REFLECT - Review agent examines the work
# [reviewer] Checking code quality...
# [reviewer] Found: missing rate limiting on login endpoint

# Phase 4: VERIFY - Verification agent validates
# [verifier] Running test suite... 23/23 passed
# [verifier] Checking coverage... 94%
# [verifier] Linting... clean

41 Agents, 8 Swarms

Loki Mode defines 41 specialized agent types organized into 8 swarms. Each swarm handles a domain of software engineering work:

  • Planning Swarm: Requirements analysis, task decomposition, risk assessment, architecture decisions
  • Implementation Swarm: Code generation, refactoring, API design, database schema work
  • Review Swarm: Code review, security audit, performance analysis, best practices enforcement
  • Testing Swarm: Unit tests, integration tests, end-to-end tests, test strategy
  • Documentation Swarm: API docs, architecture docs, runbooks, inline documentation
  • DevOps Swarm: CI/CD pipelines, infrastructure as code, deployment strategies, monitoring
  • Debug Swarm: Root cause analysis, log analysis, reproduction steps, fix verification
  • Research Swarm: Technology evaluation, pattern research, dependency analysis, migration planning

Each agent type has a defined role, specific capabilities, and constraints. A security audit agent knows to check for injection vulnerabilities, insecure dependencies, and authentication gaps. A performance analysis agent looks for N+1 queries, unnecessary allocations, and missing indexes. Specialization matters.

Architecture: Shell-Based and Provider-Agnostic

One of the design decisions I am most satisfied with is the architecture. Loki Mode is built on shell scripts. Not Python. Not TypeScript. Shell.

This was deliberate. The system orchestrates CLI-based AI tools: Claude Code, Codex, Gemini CLI. These are all command-line programs. Shell is the natural orchestration layer for command-line programs. No dependency installation, no virtual environments, no build steps. Clone the repo and run it.

# Provider configuration is shell-sourceable
# providers/claude.sh
export LOKI_PROVIDER="claude"
export LOKI_CLI="claude"
export LOKI_AUTO_FLAG="--dangerously-skip-permissions"
export LOKI_MODEL="claude-sonnet-4-20250514"

invoke_provider() {
    local prompt="$1"
    $LOKI_CLI $LOKI_AUTO_FLAG -p "$prompt"
}

The provider-agnostic design means Loki Mode works with Claude Code today, and can work with Codex or Gemini CLI with a configuration change. The orchestration logic does not care which LLM is doing the work. It cares about the structure: was the planning phase completed, did the review find issues, did the tests pass.

# Switch providers with a single variable
export LOKI_PROVIDER="claude"   # Use Claude Code
export LOKI_PROVIDER="codex"    # Use OpenAI Codex
export LOKI_PROVIDER="gemini"   # Use Google Gemini CLI

Quality Gates

Every piece of work that flows through Loki Mode passes through quality gates. These are not optional suggestions; they are hard requirements that block progression.

# Quality gate configuration
# config/quality-gates.sh

GATE_PLANNING_REQUIRED=true      # Must have a plan before acting
GATE_REVIEW_REQUIRED=true        # Must pass review before merging
GATE_TESTS_REQUIRED=true         # Must pass tests before verification
GATE_MIN_COVERAGE=80             # Minimum test coverage percentage
GATE_LINT_CLEAN=true             # Must pass linting
GATE_SECURITY_SCAN=true          # Must pass security checks
GATE_PEER_REVIEW_COUNT=1         # Number of review agents required

If the review agent finds issues, the work goes back to the implementation phase. If tests fail, the debug swarm investigates. The system does not silently pass through broken work. It is opinionated about quality because quality matters.

I also implemented parallel Opus feedback loops: three independent review agents examine the same work and their findings are aggregated. This catches issues that a single reviewer might miss and reduces false negatives in the review process.

The MCP Connection

Loki Mode does not exist in isolation. It connects to a broader ecosystem through the Model Context Protocol.

I have been building LokiMCPUniverse, a collection of 25+ enterprise-grade MCP servers that give agents access to real tools and services: GitHub, Slack, databases, monitoring systems, CI/CD pipelines. When a Loki Mode agent needs to create a pull request, it does not simulate it; it calls the GitHub MCP server and creates an actual PR.

This is where autonomous systems get interesting. An agent that can reason about code, write implementations, run tests, and interact with real infrastructure starts to feel less like a tool and more like a team member. Not a replacement for human engineers, but a collaborator that handles the mechanical aspects of software engineering while humans focus on the creative and strategic work.

Why Open Source

Loki Mode is open source because the alternative does not make sense to me.

The problems it solves (agent coordination, quality verification, structured reasoning) are not proprietary advantages. They are infrastructure problems. The more people who use, test, and improve these patterns, the better the entire ecosystem of AI-assisted development gets.

There is also a practical reason: trust. If you are going to let an autonomous system make changes to your codebase, you need to be able to read every line of its orchestration logic. Black-box agent systems are a non-starter for serious engineering work. You need to know what it is doing, why it is doing it, and how to stop it.

Open source provides that transparency by default.

What I Learned Building This

Building Loki Mode taught me things about AI agent systems that I would not have learned from reading papers or using existing tools.

Specialization beats generalization. A focused agent with clear constraints produces better results than a general-purpose agent trying to do everything. This mirrors what we already know about software architecture: single responsibility works.

Structure is not the enemy of autonomy. Early versions of Loki Mode were more free-form, letting agents decide their own workflow. The results were inconsistent. Adding structure (the RARV cycle, quality gates, defined swarms) made the system more autonomous, not less, because it could operate with confidence within well-defined boundaries.

Shell is underrated. The software industry has a bias toward "real" programming languages. But for orchestrating command-line tools, shell scripts are expressive, portable, and have zero dependencies. Every machine that can run Claude Code can run Loki Mode.

Verification is the hard part. Getting an agent to write code is easy. Getting an agent to reliably verify that the code is correct is the actual engineering challenge. The verification phase of the RARV cycle took more iteration than all other phases combined.

What Comes Next

Loki Mode is functional today, but the roadmap is long. I am working on:

  • Adaptive swarm sizing: dynamically adjusting the number of agents based on task complexity
  • Cross-project learning: letting the system learn patterns from previous tasks and apply them to new projects
  • Human-in-the-loop breakpoints: configurable points where the system pauses for human input on high-risk decisions
  • Metrics and observability: understanding how agents perform, where bottlenecks occur, and how to optimize the pipeline

If you are interested in multi-agent systems, AI-assisted development, or just want to see what happens when you give structure to autonomous agents, check out the project. Contributions, feedback, and criticism are all welcome.

The future of software engineering is not AI replacing developers. It is AI and developers working together in well-structured systems that play to each other's strengths. Loki Mode is my attempt at building that system.

Let us see where it goes.

Share: