EVE Technical Reference Manual

Overview

EVE supports real-time and asynchronous multiplayer collaboration. Every action—edits, commands, tool uses—performed by any user in a session is automatically tracked, attributed, and stored. This enables seamless teamwork, full project history, and robust audit trails.

How It Works

• All collaborative actions are logged as Multiplayer Actions in the project database.
• Each action is attributed to a user and session, with full details and timestamps.
• History can be reviewed, filtered, and exported for audit or teamwork review.

How to Use

1. Run the full agent: ./agent or go run agent.go
2. Invite teammates to join the same project/session (via shared environment or remote access).
3. All actions are tracked automatically—no extra setup required.
4. To review collaboration history, use the multiplayer history tool or view the multiplayer/ directory in the project database.

Demonstration

You: Start a new coding session with my teammate.
EVE: Multiplayer session started. All actions will be tracked.
You: Edit main.go to add a new function.
Teammate: Refactor utils.go for performance.
EVE: Actions recorded for both users in the session.
You: Show multiplayer action history.
EVE: [Displays a list of actions, who performed them, and when.]

Technical Details

• Actions are stored in eve_project_data/multiplayer/ as structured records.
• APIs and CLI tools are available for advanced filtering and export.
• See Build Guide for more on multiplayer internals.

1.1 Purpose and Scope

EVE (Enhanced Virtual Environment) is a sophisticated AI-powered coding assistant designed to provide intelligent, context-aware assistance for software development tasks. The system implements a multi-provider architecture that enables seamless integration with various LLM services while maintaining a consistent interface and behavior.

1.2 Key Design Principles

• Provider Agnosticism: Abstract interface allowing transparent switching between LLM providers
• Tool-Driven Architecture: Extensible tool system for executing complex operations
• State Persistence: File-based database system for project state management
• Modular Design: Clean separation of concerns with well-defined interfaces
• Resilient Operation: Comprehensive error handling and graceful degradation

1.3 System Boundaries

2.1 Component Hierarchy

┌─────────────────────────────────────────────────────────────┐
│                    GenericAgent                            │
│  ┌─────────────────────────────────────────────────────┐    │
│  │              LLMProvider Interface                 │    │
│  │  ┌─────────────┬─────────────┬─────────────┐       │    │
│  │  │ Anthropic   │   OpenAI    │   Gemini    │       │    │
│  │  │ Provider    │ Provider    │ Provider    │       │    │
│  │  └─────────────┴─────────────┴─────────────┘       │    │
│  └─────────────────────────────────────────────────────┘    │
│                                                             │
│  ┌─────────────────────────────────────────────────────┐    │
│  │                 Tool System                        │    │
│  │  ┌─────────────┬─────────────┬─────────────┐       │    │
│  │  │ File Ops    │ Terminal    │ Code Search │       │    │
│  │  │ Tools       │ Tools       │ Tools       │       │    │
│  │  └─────────────┴─────────────┴─────────────┘       │    │
│  └─────────────────────────────────────────────────────┘    │
│                                                             │
│  ┌─────────────────────────────────────────────────────┐    │
│  │            Project Database                        │    │
│  │  ┌─────────────┬─────────────┬─────────────┐       │    │
│  │  │ File Store  │ Checkpoints │ MCP Config  │       │    │
│  │  └─────────────┴─────────────┴─────────────┘       │    │
│  └─────────────────────────────────────────────────────┘    │
└─────────────────────────────────────────────────────────────┘

2.2 Core Data Structures

Message Flow

type Message struct {
    Role    string      // "user", "assistant", "system", "tool"
    Content interface{} // string or []ContentBlock
}

type ContentBlock struct {
    Type       string      // "text", "tool_use", "tool_result"
    Text       string
    ToolUse    *ToolUse
    ToolResult *ToolResult
}

Tool Definition

type ToolDefinition struct {
    Name        string
    Description string
    InputSchema anthropic.ToolInputSchemaParam
    Function    func(input json.RawMessage) (string, error)
}

2.3 Execution Model

1. Input Reception
2. Message Processing
3. Provider Dispatch
4. Tool Execution
5. Response Integration
6. Output Rendering

3.1 Interface Definition

type LLMProvider interface {
    SendMessage(ctx context.Context, conversation []Message, tools []ToolDefinition) (*LLMResponse, error)
    Name() string
    AvailableModels() []string
}

3.2 Provider Implementations

• Anthropic: Claude 3.x family, tool calling, streaming
• Gemini: Function calling, multimodal support
• OpenAI: Interface defined, implementation planned

3.3 Message Format Conversion

Each provider implements conversion logic between the generic Message format and provider-specific formats (Anthropic content blocks, Gemini parts, OpenAI chat completions).

3.4 Error Handling Strategy

• API/Network errors normalized
• Format/schema validation
• Provider-specific mapping

4.1 Tool Categories

4.2 Execution Pipeline

User Request → LLM Processing → Tool Selection → Input Validation → Execution → Result Processing → Response Generation

Includes schema validation, sandboxed execution context, and result normalization.

5.1 Architecture Overview

• Version control with hash integrity
• Checkpoint-based snapshots
• MCP configuration storage

5.2 Data Structures

ProjectFile

type ProjectFile struct {
    ID int; Path string; Content string; Hash string; Version int;
    CreatedAt time.Time; ModifiedAt time.Time; IsActive bool
}

Checkpoint

type Checkpoint struct {
    ID int; Name string; Description string; Timestamp time.Time; FileCount int
}

MCPIntegration

type MCPIntegration struct {
    ID int; Name string; Type string; Config map[string]interface{}; CreatedAt time.Time; IsActive bool
}

5.3 Storage Implementation

eve_project_data/
├── files/
├── checkpoints/
├── integrations/
├── multiplayer/
└── next_ids.json

6.1 Sources

# Provider Selection
LLM_PROVIDER=anthropic|openai|gemini

# API Keys
ANTHROPIC_API_KEY=sk-ant-api03-...
OPENAI_API_KEY=sk-...
GEMINI_API_KEY=...

# Model Selection
LLM_MODEL=claude-3-5-sonnet-20241022

# System Configuration
EVE_DATABASE_PATH=./eve_project_data
EVE_LOG_LEVEL=info|debug|warn|error
EVE_MAX_WORKERS=10
EVE_CACHE_SIZE=100MB
EVE_TIMEOUT=30

6.2 Validation

• Key format checks and connectivity tests
• Go version and dependency verification
• File system permissions

7.1 Conversation Management

Input → Tokenization → Context Window Management → Provider Dispatch → Response Processing → State Update

• Token counting and message pruning
• Summarization and persistence

7.2 Tool Execution State

• Request IDs, progress monitoring, timeout management
• Retry logic and fallback mechanisms

8.1 Classification

• Provider, tool execution, and system errors

8.2 Recovery Strategies

• Exponential backoff, circuit breaker
• Graceful degradation and user notification

8.3 Monitoring

• Health checks, structured logging, rotation

9.1 Latency

• Providers: Anthropic 2–5s, Gemini 1–3s, OpenAI 1–4s (typical)
• Tools: file ops < 100ms, network 100ms–2s

9.2 Throughput & Memory

• Up to 10 concurrent tool executions
• ~50MB base, +1MB/1000 messages

9.3 Scalability

• Stateless instances, shared storage, load balancing

10.1 API Key Management

• Env var storage; no persistence to disk
• TLS 1.3, cert validation, key rotation

10.2 File System Security

• Path validation, permission checking
• Optional encryption, integrity checks

10.3 Command Execution Security

• Whitelisting, escaping, isolation, resource limits

11.1 Provider Extension

// Provider registration
const ProviderNewProvider ProviderType = "newprovider"

// CreateProvider switch case
case ProviderNewProvider:
    return NewNewProvider(c.APIKey, c.Model), nil

11.2 Tool Extension

var NewToolDefinition = ToolDefinition{
    Name:        "new_tool",
    Description: "Description of new tool functionality",
    InputSchema: GenerateSchema[NewToolInput](),
    Function:    NewToolFunction,
}

11.3 Integration Points

• MCP: server discovery and config
• Plugin lifecycle and sandboxing

12.1 Build Process

# Standard build
go build -o eve .

# Optimized build
go build -ldflags="-s -w" -o eve .

# Cross-platform
GOOS=linux GOARCH=amd64 go build -o eve-linux .
GOOS=darwin GOARCH=amd64 go build -o eve-mac .
GOOS=windows GOARCH=amd64 go build -o eve.exe .

12.2 Runtime Requirements

• OS: Linux/macOS/Windows; Arch: x86_64/ARM64
• Memory: 4GB min (8GB rec.); Storage: 500MB+
• Outbound HTTPS; DNS; firewall 443

12.3 Monitoring and Observability

• Performance metrics and provider usage
• Structured JSON logs; aggregation

12.4 Backup and Recovery

• Automated, incremental backups; offsite storage
• Disaster recovery and failover support

EVE delivers a provider-agnostic, extensible assistant with robust tooling and resilient operations. Use this reference alongside the source code for implementation details and future extensions.