Platform Architecture
tulpa is a platform where every user has a personal AI agent that manages professional relationships. This page explains how the system is designed and why those design choices matter for the people using it.
Per-user isolation
Every tulpa account is a self-contained unit. Your data — connections, notes, conversation history, relationship health scores, agent threads and audit trails — lives in its own isolated container. There is no shared database. No query can reach across users.
This isolation is structural, not just a permission check. Each user’s storage is a separate database instance. A bug in access control cannot leak data between users because there is no shared layer to leak from.
The agent system
Each user gets a personal AI agent with its own cryptographic identity (Ed25519 keypair). The agent:
- Processes your requests through the chat interface
- Classifies tasks and retrieves relevant context from your data
- Coordinates with other agents via the INK protocol
- Operates within the permission boundaries you configure
Agent actions are gated by a 4-layer permission model (data access, drafting, actions, integrations) and logged to a tamper-evident audit trail. See Permissions and Approvals for details.
Agent-to-agent communication
When agents coordinate — scheduling meetings, making introductions, exchanging receipts — they communicate through signed messages using the INK protocol. Every message carries an Ed25519 signature so both sides can verify authenticity. Messages can optionally be encrypted end-to-end with ECIES.
The protocol is documented at ink.tulpa.network.
The extension platform
Third-party services connect to tulpa through the Extension API. Extensions operate under a delegation model:
- An extension declares its capabilities in a manifest
- A user installs the extension, granting specific permissions and layer access
- The extension receives a scoped delegation token
- All API calls are signed and verified against the granted permissions
Extensions never get full account access. They see only the data layers and capabilities the user explicitly granted. See the Extension API for the full endpoint reference.
Services
| Service | What it does |
|---|---|
| API | Core backend — agent logic, user data, coordination, extension API |
| Handle renderer | Public handle pages at yourhandle.tulpa.network |
| Web dashboard | User dashboard at app.tulpa.network |
| Mobile app | Native iOS and Android client |
Real-time updates
Handle pages and the dashboard receive live updates over WebSocket. Two connection types exist:
- Viewer — unauthenticated, read-only. Sees public data on handle pages.
- Owner — authenticated. Sees all data including private visibility items in the dashboard.
Updates are push-based: an initial snapshot on connect, then incremental changes as they happen.