The Full Tutorial: 6 AI Agents That Run a Company — How I Built Them From Scratch

# Multi-Agent System Architecture

## Context
This content provides a comprehensive guide to building a multi-agent system from scratch, focusing on practical architectural patterns, data models, and operational considerations. It's highly relevant for developers looking to implement robust, autonomous AI agent workflows.

## Principles
- **Iterative Development:** Start with a minimal viable system and add features incrementally.
- **Closed-Loop Automation:** Design a continuous feedback loop where agent actions lead to new proposals, ensuring self-sustaining operation.
- **Policy-Driven Control:** Externalize system configurations and rules to a central policy store for dynamic adjustments.
- **Structured Memory:** Treat agent memory as distilled, categorized knowledge rather than raw interaction history.
- **Separation of Concerns:** Distinguish between lightweight orchestration (scheduling) and heavy execution (LLM calls, task processing).

## Implementation Patterns
- **Four-Table Core Data Model:** Implement `ops_mission_proposals`, `ops_missions`, `ops_mission_steps`, and `ops_agent_events` to manage the agent workflow lifecycle.
- **Single Proposal Intake with Cap Gates:** Route all agent requests through a unified proposal service that applies policy-based checks (cap gates) before approval.
- **Heartbeat Mechanism:** Use a periodic scheduler (e.g., cron job) to trigger system evaluations, process queues, and maintain system health.
- **Trigger Rules & Reaction Matrix:** Define conditions (triggers) and inter-agent response logic (reaction matrix) to automate proposal generation and interactions.
- **Conversation Distillation for Memory:** After agent conversations, use an LLM to extract structured memories (insights, patterns, lessons) and relationship drift.
- **Atomic Claiming for Workers:** Implement database-level atomic claiming (e.g., `UPDATE ... WHERE status = 'queued'`) to prevent race conditions and duplicate work among multiple workers.
- **Dynamic Voice Evolution:** Derive agent personality modifiers dynamically from their accumulated memories and inject them into system prompts.

## Configuration Suggestions
- **`ops_policy` Table:** Create a key-value store for all system policies (e.g., `auto_approve`, `x_daily_quota`, `roundtable_policy`, `memory_influence_policy`, `relationship_drift_policy`, `initiative_policy`).
- **Initial Agent Affinity:** Deliberately set up a mix of high and low affinity scores between agents to foster diverse conversation dynamics.
- **Worker Deployment with `systemd`:** Use `systemd` for managing worker processes on a VPS, ensuring auto-restart on crashes and automatic startup.
- **Environment Variables:** Store sensitive information (API keys, database URLs) in `.env` files with restricted permissions (`chmod 600`).

## Warnings
- **Avoid Hardcoding Policies:** Do not embed quotas, feature flags, or other system rules directly into code; use a dynamic policy table.
- **Prevent Task Backlogs:** Implement "cap gates" at the proposal entry point to reject invalid or quota-exceeding requests early, rather than letting them queue up.
- **Don't Overload Heartbeat:** Keep the heartbeat lightweight; offload heavy LLM operations and long-running tasks to dedicated worker processes to prevent timeouts.
- **Memory is Not Chat History:** Do not rely on agents re-reading raw chat logs for learning; distill structured knowledge into a dedicated memory system.
- **Beware of Duplicate Work:** Implement atomic claiming mechanisms for workers to ensure tasks are processed exactly once.
- **Start Initiative Disabled:** Keep agent initiative features disabled until the core system is stable to avoid unexpected behavior.
- **Don't Over-engineer Relationships:** Relationship drift should be gradual (e.g., ±0.03 per conversation) to simulate realistic human interaction.
- **Monitor Costs:** Be mindful of LLM usage, especially during development and scaling, as it's typically the primary variable cost.