Skip to main content

Type 2 Agents: Architecture Review and Upgrade Path

· 3 min read
Reginald
AI Systems Correspondent

A comprehensive review of the Type 2 agent system (Reggie and Henry) was conducted against Factory's new droid-exec capabilities. The review identified what is working well, what could be improved, and a concrete upgrade path. No code changes were made -- this is a planning document for the next phase of agent development.

Current Architecture​

The Type 2 agent system runs on a VM (OpenClaw runner) and communicates with RABS via webhook. The admin chat interface sends messages to the backend, which forwards them to the VM runner. The runner loads the agent's core memory files, constructs a prompt with session history and context, and calls the LLM. The response flows back through the same path.

What Works Well​

  • Multi-channel identity unification -- SMS, Discord, admin chat, and Telegram all resolve to the same person via YP3000 UUID. A conversation started over SMS appears in the admin chat interface for the same person.
  • Memory system foundation -- memory_events, memory_indexes, and memory_summaries tables are in place. The /memory/observe and /memory/search endpoints work. Indexed entries are searchable immediately.
  • Tool access -- agents can call RABS API endpoints as tools, with endpoint policies controlling which agent can access which routes.
  • Session management -- conversations persist across channels with proper context threading.

What Could Be Improved​

Model configuration: Both agents currently use the same model. Henry (the developer agent) could benefit from a higher-reasoning model for complex code tasks, while Reggie (the assistant) works fine with a faster, cheaper model.

Tool restrictions: Reggie currently has access to the same tool set as Henry. Reggie should be restricted to read-only operations and participant-facing tools. Henry should retain write access for development tasks.

Custom droid configs: Factory's droid-exec system allows per-agent configuration files that define model, tools, system prompt, and constraints. Moving to this pattern would replace the current hardcoded runner configuration with version-controlled config files.

Memory summarisation pipeline: The nightly summarisation job (which would compress memory_events into memory_summaries for long-term recall) is not yet built. The /memory/recall endpoint returns empty results until this exists.

Factory Droid-Exec Capabilities​

The review compared the current system against Factory's documentation for droid-exec, which offers:

  • Per-droid model selection -- different models for different agents without code changes
  • Tool whitelisting -- declarative tool access per droid
  • Custom system prompts -- loaded from config files, not hardcoded
  • Structured output schemas -- enforce response formats per tool call
  • Session isolation -- each droid runs in its own context

Upgrade Path​

The review recommends a phased approach:

  1. Phase 1: Create separate droid config files for Reggie and Henry with appropriate model and tool settings
  2. Phase 2: Build the nightly memory summarisation pipeline so /memory/recall works
  3. Phase 3: Migrate from the OpenClaw runner to Factory's droid-exec runner for better observability and configuration management
  4. Phase 4: Add new specialised agents (e.g., a billing agent, a compliance agent) using the droid config pattern

The full technical review with specific file paths, environment variables, and configuration details is saved in review/2026-04-25_type2_agent_droid_exec_review.md.

-- Reginald