How Lattice Works

System Overview

Lattice follows a client-daemon architecture:

The Daemon Process

What is the Daemon?

The daemon is a long-running background process that:

• Runs continuously (even when you close your terminal)
• Accepts connections from multiple clients (terminal, VS Code, your apps)
• Manages agent lifecycle (create, run, monitor, stop)
• Maintains state (which agents exist, what tasks are queued)
• Persists data (sessions survive daemon restart)

How It Starts

lattice-ctl daemon start

This:

1. Launches the daemon binary in the background
2. Sets up fast local communication with clients
3. Registers as a system service (launchd/systemd/Windows Service)
4. Begins listening for client connections

After this, it runs continuously until you stop it or reboot.

How It Communicates

The daemon communicates with clients (the CLI, your apps, IDE extensions) using fast local inter-process communication. This is internal to how lattice works—you don't need to worry about the details. Instead, use:

• CLI: ada commands (ada chat, ada agents start, etc)
• Client Libraries: TypeScript/Python/other language bindings for programmatic access

The communication layer is optimized for performance (sub-millisecond response times) but abstracted away from you.

Agents and Sessions

Agents: Autonomous Workers

An agent is an autonomous AI worker that executes tasks independently:

ada agents start "Analyze this codebase and find performance issues"
# Returns: agent_abc123

The agent runs in the background and can:

• Execute tasks autonomously
• Access local tools and models
• Store results for later retrieval

View and manage agents:

ada agents list                      # See all agents
ada agents status agent_abc123       # Check status
ada agents stop agent_abc123         # Stop if needed

Sessions: Conversations

A session is an interactive conversation with context history:

ada chat
# You: What is lattice?
# Assistant: Lattice is your personal AI infrastructure...
# You: Can I use it offline?
# Assistant: Yes, with local models like Ollama...

Sessions automatically persist, so you can resume later:

ada sessions list                    # See all conversations
ada sessions resume session_abc123   # Continue a conversation

The Key Difference

Persistence

All agents and sessions are stored in SQLite (a local database):

• If you restart the daemon, agents and sessions are recovered
• If you reboot, everything persists
• No cloud needed—everything is local

How Work Flows Through Lattice

Interactive Chat Workflow

1. You run: ada chat
2. Daemon creates a session
3. You type: "What is lattice?"
4. Message sent to configured LLM provider
5. Provider generates response tokens
6. Response streams back to your terminal
7. Full conversation saved to local SQLite database
8. You can resume later with: ada sessions resume

Autonomous Agent Workflow

1. You run: ada agents start "Task description"
2. Daemon creates an agent with unique ID
3. Agent executes the task using the configured provider
4. Results stored in local database
5. You can check status anytime: ada agents status <agent-id>
6. Task completes, agent finishes
7. Results persist indefinitely in local storage

Resource Management

Memory Efficiency

All clients share the same connection pool to each LLM provider:

Without the daemon (if each client connected directly):

The daemon saves 80% memory usage with multiple clients.

Concurrency

The daemon uses concurrent programming to handle:

• Multiple clients simultaneously
• Multiple agents running at once
• Multiple tasks in queue
• Network requests to cloud APIs

All without blocking—one client's slow request doesn't block others.

Session Persistence

What Gets Persisted?

Lattice Storage (~/.lovelace/lattice/)
├── config.toml          ← Your settings
├── daemon.sock          ← IPC socket (temporary)
├── lattice.db         ← SQLite database
│   ├── agents          ← Agent definitions & status
│   ├── sessions        ← Conversation history
│   ├── tasks           ← Task queue & results
│   └── metadata        ← Various metadata
└── logs/                ← Execution logs

Session Recovery

If the daemon crashes or restarts:

1. Daemon starts up
2. Reads lattice.db
3. Recovers all agents and their state
4. Clients reconnect
5. Everything continues (agents resume if possible)

This is why Lattice is reliable even without cloud backup.

Daemon Lifecycle

Starting the Daemon

lattice-ctl daemon start

Daemon starts → Sets up local communication → Ready for requests

Using Lattice

Once the daemon is running, all your lattice commands work:

ada chat                               # Start interactive chat
ada agents start "Task description"    # Start autonomous agent
ada agents list                        # View all agents
ada sessions list                      # View all conversations

Each command communicates with the running daemon in the background.

Stopping the Daemon

lattice-ctl daemon stop

Daemon receives stop signal → Gracefully shuts down → Persists all state to database → Exits

Important: When you stop the daemon, all your agents and sessions are preserved in the local database.

Handling Daemon Restarts

If the daemon crashes or you restart your computer:

lattice-ctl daemon start
# Daemon restarts and automatically recovers:
# - All agents and their status
# - All conversation sessions
# - All configured providers and settings

# Everything continues from where it left off

Scaling Across Devices

Lattice can extend beyond a single machine using P2P networking:

Agents communicate directly across devices without cloud intermediaries. This is the "decentralized agentic mesh" vision.

See Connecting Devices → for how to set this up.

Summary: Why This Architecture?

Lattice's design provides several key benefits:

Simplicity

• ✅ One daemon process per machine
• ✅ Simple local storage (SQLite)
• ✅ No complex distributed systems
• ✅ Fast installation and setup

Reliability

• ✅ Everything persists locally
• ✅ Works offline (with local models)
• ✅ Data never leaves your machine unless you choose
• ✅ Recovery from crashes automatic

Performance

• ✅ Sub-millisecond response times
• ✅ Shared connection pool saves memory
• ✅ Concurrent task execution
• ✅ Streaming responses for real-time feedback

Flexibility

• ✅ Choose your LLM provider (local or cloud)
• ✅ Scale to multiple devices with P2P
• ✅ Use via CLI, libraries, or IDE extensions
• ✅ Optional cloud sync when needed

This gives you a production-grade agent platform optimized for local-first development.