Skip to main content

Platform Architecture

Lovelace isn't a single monolithic application—it's a platform of interconnected products designed to work together seamlessly. Understanding this architecture helps you use the platform effectively.

The Core Insight

Most platforms give you either tightly coupled components (fast but inflexible) or loosely coupled services (flexible but complex). Lovelace takes a middle path: products are independent but share common foundations.

This means you can use just the CLI for local development, or run the full stack in production. Components work together when you need them to, but don't force coupling when you don't.

Product Relationships

Lovelace Accounts Service is the authentication foundation. Every product trusts it for identity, so you authenticate once and access everything. It handles users, accounts, organizations, OAuth flows, API keys, and session management.

Lovelace Studio is the visual development environment. It's a web application authenticated through Accounts. You design workflows, configure integrations, and test agents visually. Studio stores workflow definitions that can be exported to CLI or deployed to Agents Cloud.

Lovelace CLI is the developer's tool for code-first workflows. It authenticates through device authorization flow, stores credentials locally, and can create agents, manage deployments, and interact with all platform services. CLI and Studio are different interfaces to the same underlying agent system.

Lovelace Agents Cloud is the production runtime. It runs agents at scale with managed infrastructure. Agents Cloud authenticates service-to-service with Accounts and can pull workflows from Studio or CLI definitions. It provides monitoring, logging, scaling, and operational controls.

Lovelace Memory Platform provides persistent context storage. All products can use it—CLI for local memory, Agents Cloud for production context, Studio for knowledge base management. It's optional but becomes essential for agents that need to remember across sessions.

Lovelace Assistant is integrated throughout other products. It's not a separate application—it's AI help embedded in Studio, CLI, and the web interface. Assistant uses the same authentication and agent infrastructure as everything else.

Data Flow

User identity flows from Accounts Service to all products. You authenticate with Accounts (typically using a passkey), receive tokens, and use those tokens to access other services.

Agent definitions can be created in Studio or CLI, stored centrally, and deployed to Agents Cloud. The definition format is the same—it's just the creation interface that differs.

Memory flows through the Memory Platform. Agents running in Cloud, CLI, or Studio all access the same memory stores (though with appropriate permission boundaries).

Integrations are connected through OAuth flows managed by Accounts. Once connected, integration tokens are available to agents across products.

Organizational Hierarchy

The platform has a clear hierarchy:

Organizations are top-level containers representing companies or teams.

Accounts belong to organizations and contain users and resources.

Workspaces within accounts organize related projects and agents.

Projects within workspaces contain specific work items.

Agents run within the context of a project and workspace.

This hierarchy provides natural isolation and access control. An agent in one workspace can't access another workspace's data unless explicitly granted permission.

Deployment Models

Cloud-only - Use Studio and Agents Cloud, never run anything locally. Everything is managed, simple to operate, but requires internet connectivity.

Local-only - Use CLI exclusively, run agents on your machine. Full control, works offline, but you handle all operational concerns.

Hybrid - Develop locally with CLI, design in Studio, deploy to Agents Cloud. Most flexibility, best of all approaches, typical for production use.

Air-gapped - Run Accounts and Agents Cloud in your infrastructure. Maximum control and security, but you manage everything.

Security Boundaries

Products communicate over authenticated HTTPS. Service-to-service authentication uses client credentials. User authentication uses OAuth tokens.

Each product validates tokens independently—there's no "super admin" that bypasses checks. This defense-in-depth approach means compromise of one component doesn't automatically compromise everything.

Memory access is controlled by workspace and project boundaries. Agents can only access memory they're explicitly granted permission to use.

Integration tokens are scoped to specific capabilities. An agent with GitHub read access can't suddenly start deleting repositories.

The Bigger Picture

This architecture enables several important properties:

Composability - Use just what you need. Start with CLI, add Studio later, deploy to Cloud when ready.

Reliability - Products are independent. If Agents Cloud has issues, CLI still works.

Security - Clear boundaries with explicit authentication between components.

Scalability - Each product scales independently based on its load.

Evolution - Products can evolve without breaking others, thanks to versioned APIs and clear interfaces.

The result is a platform that feels cohesive when you use it, but maintains the flexibility and reliability of well-designed distributed systems.

Related Concepts