Thinklio Reference¶
Document 14 | Version: 1.0.0 | Date: April 2026 | Status: Active
This document is the authoritative single-source reference for the Thinklio platform. It synthesises the full product design, architecture, data model, governance, security, API strategy, pricing, implementation status, and key decisions into a format suitable for marketing, positioning, user acquisition, feature planning, copywriting, LLM context, and any other product-adjacent work.
This reference is regenerated from the canonical documentation set (docs 01 through 13) and should be treated as a derived artefact. If this document and a numbered source document disagree, the source document is authoritative.
For the detailed treatment of any topic, follow the cross-references into the canonical set.
Table of Contents
- What Thinklio Is
- Product Principles
- Target Users
- Core Concepts
- Architecture Summary
- Data Model
- Security Model
- Plans and Pricing
- Implementation Roadmap
- Key Architectural Decisions
- Competitive Positioning
- Example Scenarios
- Document Lineage
- Revision History
1. What Thinklio Is¶
Thinklio is an AI agent platform. It lets individuals, teams, and accounts deploy intelligent assistants that think, act, and learn on their behalf, across any communication channel, within guardrails they control.
Unlike simple chatbots that respond to prompts, Thinklio agents reason through problems. They combine domain knowledge, access to tools, and awareness of context to carry out tasks that would otherwise require human time and attention. An agent might research a topic and prepare a briefing, triage incoming requests according to account policy, coordinate a workflow across team members, or serve as a knowledgeable assistant that remembers what matters to you.
What sets Thinklio apart is what happens underneath. Every action an agent takes is governed, tracked, and accounted for. Accounts set policies about what agents can and cannot do. Every reasoning step is auditable. Costs are metered and attributed to the correct user, team, or department. This is AI as reliable infrastructure that an account can trust with real work, not a novelty.
The name: "Think" connects to the core function (agents that think on your behalf) and echoes the internal execution pattern (think, act, observe). The "-lio" suffix is modern and distinctive.
Domains: thinklio.com, thinklio.ai, thinklio.io.
See 01 Product & Strategy for the full product overview.
2. Product Principles¶
- Agents are trustworthy by design. Governance, cost controls, and auditability are core to every interaction, not afterthoughts.
- Architecture enables the business model. Multi-tenancy, billing, and plan management are structural, not bolted on.
- Simple things are simple, complex things are possible. A personal assistant agent is easy to set up. A multi-agent account deployment with custom policies is possible.
- Channel does not matter. Users interact through whatever tools they already use. Agents are unaware of channels.
- Knowledge compounds. Every interaction makes the system more valuable through structured knowledge extraction and agent learning.
- Simple agents pay no complexity tax. An agent that answers questions and calls a quick API tool never touches the job system or delegation machinery. Advanced features exist only when needed.
3. Target Users¶
Primary Personas¶
Individual professional (solo user). Creates a personal agent for task management, research, and general assistance. Wants it to learn their preferences and context over time. Values privacy. Entry point for the platform; may later bring it to their team.
Team lead or manager. Deploys a shared agent for their team (5 to 50 people). Wants the agent to hold institutional knowledge about projects, clients, and processes. Needs visibility into agent usage and costs. Values team knowledge growing organically without manual curation. May compose agents from specialist delegates using Agent Studio.
Account administrator. Manages multiple agents across departments. Sets policies governing agent behaviour, tool access, delegation limits, and cost controls. Requires audit trails for compliance. Needs usage reporting and cost attribution by department and team.
Service provider or builder. Builds on Thinklio to deliver AI-powered services to their own clients. Needs agent templates, client isolation, and white-labelling. Values the Platform API and programmatic management capabilities. May deploy agents across multiple client accounts. Integrates external systems as tools via the Integration API.
Secondary Personas¶
End user (non-admin). Interacts with agents assigned to their team. Does not configure or manage agents. Expects the agent to be helpful, fast, and to remember context. Should never see platform complexity.
Technical evaluator. Assessing Thinklio for account adoption. Needs to understand architecture, security, compliance, and integration capabilities.
4. Core Concepts¶
4.1 Agents¶
An agent is a first-class platform entity: an AI assistant with its own identity, knowledge, skills, and behavioural rules. Agents exist independently and are assigned to contexts (accounts, teams, users) with specific access grants, knowledge scoping, and per-assignment tool restrictions.
Key properties: agents can be created by any entity (user, team, account). A solo user can create a personal agent without needing an account. An agent can serve multiple contexts simultaneously with isolated knowledge per context. Agents are created from scratch or from templates. Agent configuration includes name, personality and system prompt, domain knowledge, tool assignments (including delegations), capability level, and behavioural policies. Lifecycle states: active, paused, archived. Pausing stops all interactions and cancels pending jobs but preserves knowledge and configuration.
Capability levels (configurable per agent, enforced by the harness): tools_only (can use assigned tools, no workflow composition), workflow (can compose multi-step workflows using tools), experimental (can try novel combinations of tools and workflows), learning (can codify successful workflows as reusable patterns).
See 03 Agent Architecture & Extensibility for the full agent model.
4.2 Agent Composition and Delegation¶
Agents work together through an agent-as-tool model. Agents are registered in the tool registry as a tool type, so from the invoking agent's perspective, delegating to another agent is the same as calling any other tool: it goes through the same harness act step, policy evaluation, cost tracking, and audit trail.
Agent Studio is the visual interface for composing agents. It lets team leads and administrators define delegation relationships, assign tools, configure per-delegation restrictions, and view the delegation graph. Templates for common compositions (for example, "Personal Assistant with Scheduler and Research") allow non-technical users to build useful composite agents.
Delegation governance: delegation can only narrow permissions, never widen them. Delegation depth limits are configurable at the account level (default: 3). Cycle detection runs at configuration time and at runtime. Knowledge isolation is maintained: the delegate assembles its own context and does not receive the invoking agent's full context or chat history. Costs from delegate agents roll up to the originating user and team.
4.3 Four-Layer Knowledge Model¶
Every agent interaction draws from up to four knowledge layers:
| Layer | Owner | Mutability | Visibility | Examples |
|---|---|---|---|---|
| Agent | Platform or agent creator | Configured at setup, updated via learning | All users of this agent | Domain expertise, skills, system prompt, learned workflows |
| Account | Account admins | Curated, mostly static | All account members using this agent | Policies, procedures, compliance rules, brand guidelines |
| Team | Collective (team members) | Grows organically from interactions | Team members only | Project context, client details, shared decisions |
| User | Individual user | Grows from user's interactions | Private to that user only | Personal preferences, individual context, private notes |
Precedence: Account policies override all other layers. Then agent knowledge, team knowledge, and user knowledge in descending priority.
Privacy: User knowledge is never visible to other users, even within the same team. Team knowledge is isolated between teams within the same account.
Portability: When a user leaves a team, their user knowledge goes with them. Their contributions to team knowledge remain with the team.
Delegation isolation: Knowledge extracted during a delegate's interaction is scoped to the delegate's assignment context, not the invoking agent's.
Knowledge facts are structured as subject/predicate/value triples with scope, confidence scoring, and semantic embeddings for vector similarity search. Token-budgeted context injection ensures relevant facts fit within model limits while preserving the most relevant information.
See 04 Data Model for entity definitions and 05 Persistence, Storage & Ingestion for retrieval implementation.
4.4 Messaging-First Architecture¶
Thinklio's core abstraction is messaging. A channel is a chat space with participants, and users and agents are both first-class participants in channels. A direct chat with an agent, a team room where an agent observes and contributes, and an organisation-wide agent service are all the same structural thing: messages in a channel. This unifies user-agent interaction, agent-to-agent delegation, and team collaboration under a single model.
Agents are unaware of which channel is in use. Chats maintain context across channels. Rich responses degrade gracefully on limited channels. Initial channel types include web chat, Telegram (text, images, documents, voice messages), HTTP/API (Channel API surface), and email (via Postmark).
See 06 Events, Channels & Messaging for the full messaging architecture.
4.5 Tools¶
Agents use tools to take actions beyond chat. Tools come in three types: internal (platform-provided capabilities such as web search, task management), external (integrations with third-party services via MCP servers, including dynamically registered tools via the Integration API), and agent (other agents registered as tools via the agent-as-tool delegation model).
Tool access is controlled by trust levels (read, standard, elevated, admin) and policy evaluation. Per-assignment tool restrictions allow the same agent to have different effective capabilities in different contexts. In shared channels, an agent's effective tool set is the intersection of all human participants' tool permissions, preventing privilege escalation.
Three production MCP servers are maintained in the thinklio-services repository: Cliniko (6 read-only tools, Go), Notion (15 tools across 5 groups, Go), and Xero (18 tools across 8 groups, Go). All use Streamable HTTP transport.
See 09 External API & Tool Integration for the tool developer guide and MCP server reference.
4.6 Jobs and Deferred Work¶
The job system manages work that outlives a single interaction: long-running workflows, human handoffs, research tasks that take minutes or hours.
Three execution modes for act steps: immediate (synchronous within the interaction, default for quick API calls and lookups), deferred (dispatches work and completes immediately with a job reference; results arrive in a follow-up interaction), and interactive (multi-turn within a single interaction where each step depends on the previous outcome). A single interaction can use different modes for different steps (mixed mode).
Job entity structure: jobs contain subjobs (discrete units of work), are watched by observers (agents or system processes), and carry a context bundle that preserves state for follow-up interactions. Jobs progress through: pending, dispatched, in_progress, resolved, failed, cancelled, timed_out.
4.7 Governance¶
Every agent operates within a governance framework. Policies define rules about what agents can and cannot do, including tool access, content rules, delegation limits, and approval requirements. Cost controls enforce budgets at the account, team, and user level, checked pre-execution. Trust levels provide graduated permissions controlling tool access: read-only broadly available, write tools require higher trust, high-risk actions require explicit approval. Audit trails log every reasoning step, tool call, delegation, job dispatch, and decision immutably.
The governance policy framework provides eight categories of declarative, data-driven rules: action permissions, cost limits, data boundaries, temporal constraints, delegation constraints, content policies, audit requirements, and approval gates. Policies layer as account, team, and user, with the most restrictive wins rule. Industry template packs for healthcare, finance, and legal layer atop a safe default baseline.
See 07 Security & Governance for the full security model and policy framework.
4.8 Durable Execution Harness¶
Every agent interaction runs inside a durable execution harness that tracks each reasoning step independently. The harness follows a think, act, observe loop:
- Context -- assemble multi-layered knowledge context
- Think -- LLM call for reasoning and decision-making
- Act -- tool execution (immediate, deferred, or interactive mode)
- Observe -- LLM call to synthesise tool results
- Respond -- deliver response to the user
- Extract -- queue background knowledge extraction
Each step has an independent state machine (created, running, success or failed) and is persisted before execution. This provides crash recovery, granular cost tracking, retry at the step level, and a complete audit trail.
The execution model is tiered. Interactive work (any channel where a human is waiting) runs on a fast path using direct Convex mutations and actions. Durable work (delegation chains, document ingestion, multi-step workflows) runs on the Convex Workflow component. Background volume that exceeds the Convex slot ceiling migrates to an external queue. The three tiers together provide a concrete growth path from hundreds to millions of interactions.
4.9 Three External API Surfaces¶
Thinklio exposes three distinct API surfaces, each serving a fundamentally different integration pattern:
Channel API -- Chatal Access. An external system sends messages to an agent and receives responses, the same way a user would interact via Telegram or web chat. Use cases: mobile apps with in-app assistants, SaaS products offering AI-powered support, internal tools with chat widgets.
Platform API -- Orchestration and Management. Programmatic access to Thinklio's orchestration capabilities: creating agents, dispatching jobs, registering observers, managing knowledge, querying usage, and controlling the full agent lifecycle. Use cases: service providers automating deployment, CI/CD pipelines deploying agent configurations, external workflow engines coordinating with Thinklio agents.
Integration API -- Bidirectional Capability Exchange. External systems register their capabilities as tools available to Thinklio agents, and subscribe to platform events via webhooks. Conversely, external systems can invoke Thinklio agents as capabilities within their own workflows. Use cases: CRM systems registering as tools, project management tools, ERP systems, healthcare platforms.
All three surfaces resolve to the same authorisation model, governance framework, cost attribution, and audit trail. Each surface is versioned independently.
See 09 External API & Tool Integration for the full API reference.
4.10 Core Data Structures¶
Beyond chats and knowledge, the platform provides structured data that agents can create, query, update, and relate: tasks (units of work with due dates, priorities, recurrence, and assignments), contacts (people and organisations with interaction histories), items (externally-initiated requests that need processing, such as support tickets or intake forms), notes (freeform captured information with markdown support, granular sharing, and @ mentions), and tags (cross-cutting categorisation applicable to any entity). These structures are agent-accessible via native tools and REST APIs, scoped by the same visibility model as all other platform data.
Tasks, items, and notes all follow the same extensibility pattern: a type table with system-reserved types (seeded by the platform, immutable) and account-custom types (created by admins), providing consistent categorisation without schema changes.
4.11 Predictive Planning¶
The platform collects execution outcomes (which plans succeeded, which failed, how long they took, what they cost) and uses this data to improve future plan selection. A Bayesian Beta-Binomial scoring system with hierarchical priors evaluates candidate plans based on historical performance, context similarity, and cost efficiency. Over time, agents learn which approaches work best for specific types of requests, reducing cost and improving reliability without manual tuning.
See 08 Agents Catalogue & Platform Services for the full planning specification.
4.12 Unified Capability Model¶
Tools and agents share a single manifest format and execution contract. From the platform's perspective, invoking an external tool, calling a built-in function, or delegating to another agent all follow the same pattern: a capability is described by a manifest, executed through the harness, and tracked with identical governance, cost attribution, and audit trails. This unification simplifies composition and eliminates special cases.
4.13 Starter Agent Catalogue¶
The platform ships with 23 pre-configured agent templates organised into four groups: core specialists (standalone agents that do one thing well), coordinator agents (orchestrate specialists for multi-step workflows), data and knowledge agents (handle structured and unstructured information), and organisational specialists (vertical agents suited to specific business functions). Each template is deployable immediately, customisable, and composable via Agent Studio.
See 08 Agents Catalogue & Platform Services for the full catalogue.
5. Architecture Summary¶
Platform Stack¶
| Layer | Technology | Purpose |
|---|---|---|
| Auth and identity | Clerk | User auth, organisation management, RBAC, SSO, pre-built UI components |
| Application platform | Convex (Cloud, Ireland) | Database, server functions, reactive queries, real-time subscriptions, vector search, full-text search, scheduling, durable workflows, HTTP endpoints |
| File storage | Cloudflare R2 | Document uploads, generated files, media. Accessed via presigned URLs. |
| Client, web | Next.js 15, React 19, TypeScript, Tailwind CSS 4 | Web application at app.thinklio.ai |
| Client, mobile | Flutter | iOS/Android app (planned) |
| LLM providers | OpenRouter / Anthropic API | Called from Convex actions via HTTP |
| Observability | Axiom (via Convex log streams) | Function execution logs, performance metrics, alerting |
| Analytics archive | Postgres or data warehouse (via Fivetran CDC) | Long-term audit trail, usage analytics, compliance archive |
| Email delivery | Postmark | Transactional email, inbound email channel |
What Changed from the Original Design¶
The original architecture was a distributed Go service architecture (Gateway, Agent, Context, Tool, Queue, Usage services) over Supabase Postgres and Redis Streams. That design was deployable and correct but carried structural weaknesses: the agent hot path crossed seven network hops, a six-tier caching strategy existed to mitigate the latency, and custom infrastructure replicated functionality available in purpose-built platforms. A two-plane migration proposal (Convex for the hot path, Go for governance and billing) was analysed and superseded. The current architecture is a greenfield rebuild on Convex, Clerk, and Cloudflare R2, eliminating Redis, Go services, Supabase, and custom event bus infrastructure entirely.
Design Principles¶
Messaging-first. Every interaction flows through the messaging system. Agents are first-class participants in channels alongside users. This unifies user-agent interaction, agent-to-agent delegation, and team collaboration.
Reactive by default. Convex's reactive query engine means every client subscription automatically updates when underlying data changes. No caching layer, no pub/sub system, no event bus to build or maintain.
Single source of truth. All application state lives in one Convex project. One schema, one set of functions, one type system from database through to client.
Managed infrastructure. Authentication (Clerk), application logic and data (Convex), and file storage (R2) are all managed services. No servers to provision, patch, or monitor on the hot path.
Governance as middleware. Policy enforcement, tenant isolation, cost controls, and audit logging are implemented as Convex custom function middleware executing in-process on every function call.
Event-sourced audit. Every significant mutation produces an immutable audit record. Records stream out via Fivetran CDC for long-term retention and compliance.
Channel agnosticism. A universal internal message format means a message from the web app, a Telegram webhook, an email, and an API call all become the same kind of message once they enter the system.
Multi-tenancy by design. Every table, every index, every function is scoped to an account (Clerk organisation) or a sub-scope within one. Isolation is enforced at the application layer via accountQuery/accountMutation wrappers.
Execution Tiers¶
The execution model divides into three tiers to manage the Convex Professional plan's 100-slot ceiling on concurrent Workflow and Workpool executions:
Tier 1 (interactive fast path). Chat-like interactions where a human is waiting. Direct Convex mutations and actions with the Action Retrier wrapping the LLM call. Zero Workflow slots consumed. Preserves responsiveness.
Tier 2 (durable workflow). Work that genuinely needs step-by-step journalling and crash recovery: delegation chains, inbound email processing, multi-step document ingestion, scheduled agent turns. Uses the Convex Workflow component. Slotted and budgeted.
Tier 3 (external queue). Background volume that outgrows the Convex slot ceiling. Migrates to an external queue (Google Cloud Tasks or BullMQ on Hetzner) that calls back into Convex. Added only when monitoring shows it is needed.
Convex Component Ecosystem¶
The platform leverages the Convex component ecosystem for infrastructure that would otherwise be custom-built: Agent (LLM round-trip, prompt assembly, tool call loop, streaming), Workflow (durable step-by-step journalling), RAG (namespaced retrieval with embeddings), Workpool (managed parallelism), Rate Limiter (API throttling), Persistent Text Streaming (token-by-token LLM output over WebSocket), Crons (scheduled work), Aggregate and Sharded Counter (real-time usage counters), Action Retrier (resilient external API calls), Migrations (schema evolution on live data). Community components fill specific needs: Audit Log, Webhook Sender, LLM Cache, Expo Push Notifications.
See 02 System Architecture for the full architecture reference and 11 Convex Reference for the Convex platform details.
6. Data Model¶
The data model spans several functional domains. All entities follow a consistent scoping model (user, team, or account) with account policies acting as the ceiling that no lower layer can loosen. Singular table names are used throughout per project convention. The conceptual model targets Convex; the schema lives at /convex/schema.ts.
Core platform entities. user_profile (platform users, synced from Clerk), account (accounts mapped to Clerk organisations, the tenancy boundary), account_user (account membership with role: owner, admin, editor, viewer), team (teams within an account), team_member (team membership with role), invitation (account and team invitations with token and expiry).
Agent entities. agent (agent definitions: name, model, system prompt, config), agent_assignment (agent-to-context assignments with scope configuration and per-assignment tool restrictions), agent_template (reusable templates for one-click creation), agent_tool (agent-to-tool assignments with per-assignment config), agent_library (agent-to-library assignments for knowledge access), agent_channel (agent-to-channel assignments: which agents respond on which channels).
Execution entities. session (chat sessions), interaction (tracked units of work within a session), step (individual execution steps with state machine: created, running, success, failed), event (immutable event log, event-sourced core), delivery (message delivery status tracking).
Core data structures. task, task_list, task_type (work management with extensible types). contact, contact_interaction (people and organisations with interaction history). item, item_type (externally-initiated requests). note, note_type, note_share, note_mention (freeform information capture with sharing and @ mentions). tag, entity_tag (cross-cutting categorisation).
Knowledge. knowledge_fact (structured facts with scope, semantic embedding, confidence scoring, and access tracking). library, library_item (curated document collections for RAG).
Media and storage. media (uploaded files with polymorphic linking), storage_bucket (R2 bucket configurations), media_processor, media_processing_rule, media_processing_job (async media processing pipeline).
Planning. canonical_plan (reusable plan definitions), execution_outcome (recorded outcomes), plan_score (Bayesian scores for plan effectiveness).
Platform services. platform_service (external service registry), llm_model (available LLM models with pricing and capability metadata), account_service_config (account-level overrides), account_llm_preference (model preferences), credit_ledger (credit transaction log), platform_config (global configuration).
Communications. channel_config (channel type configurations), user_channel (user-to-channel identity links), user_comm (outbound notification dispatch queue), notification (in-app notification records), quality_rating (user feedback ratings).
Security and integration. tool (tool registry), api_key (API keys for programmatic access), oauth_token (OAuth tokens for external integrations), webhook_subscription (webhook configurations), budget_limit (budget limits per scope), usage_record (resource consumption records).
Jobs. job (deferred work units), subjob (discrete pieces of work within a job), job_observer (job completion notification subscriptions).
See 04 Data Model for the full entity reference and relationship diagrams.
7. Security Model¶
Principles¶
Defence in depth. Least privilege. Fail closed. Audit everything. Isolation is structural (enforced by architecture, not just policy). Delegation does not escalate (can only narrow permissions, never widen).
Authentication¶
Authentication is delegated to Clerk, which handles email, OAuth, magic links, and session lifecycle. The Convex backend validates Clerk tokens via a first-class integration. The three external API surfaces each have their own authentication mechanism but resolve to the same platform identity and authorisation model: Channel API authenticates as a user, Platform API authenticates as an account or service account, Integration API authenticates as an external system.
Authorisation (Four-Level Model)¶
- Platform level -- can this user or system access this resource at all?
- Agent level -- can this agent perform this action? (tool permissions, capability level, account policies)
- Assignment level -- is this action further restricted for this context? (per-assignment tool restrictions)
- Step level -- can this specific step execute right now? (trust level, budget, rate limits, delegation rules)
Evaluation order: account policies, assignment restrictions, trust level, budget, rate limit, delegation depth and cycle checks, approval gate. Fail-closed: if the policy engine cannot evaluate, the decision is deny.
Role Model¶
Four-tier role structure: owner (full account control, policy setting, billing, user management), admin (manage agents, tools, team settings, and members), editor (create and modify agents, configure tools, manage team content), viewer (read-only access to agents, interactions, knowledge, and reports).
Data Isolation¶
Enforced at multiple layers: application-layer runtime context assertions in every Convex function via accountQuery/accountMutation wrappers, tenant-scoped indexes and queries, network isolation (Convex Cloud manages infrastructure security), and delegation isolation (delegate agents assemble their own context; invoking agent's full context is not forwarded).
Credential Management¶
Three connected mechanisms. Platform secrets (LLM keys, internal service tokens) live in infrastructure secret management. Secrets Vault (a first-class product feature) stores user- and account-facing secrets with fine-grained sharing, access logs, and agent integration; values are never stored in message history, reasoning traces, or knowledge extraction. MCP credential injection delivers credentials per-request as HTTP headers; Thinklio handles OAuth refresh cycles.
MCP Tool Permissions¶
In any channel, an agent's effective tool set is the intersection of all human participants' tool permissions. This prevents privilege escalation via shared channels. Tool access is granted at three levels (organisation, team, user) with most-restrictive-wins resolution. In group chats, tools downgrade to the lowest common permission level; if a participant has no access, the tool becomes invisible to the agent. Delegation chains preserve the intersection rule at every level.
Rate Limiting¶
| Scope | Default |
|---|---|
| Per IP (gateway) | 100 req/min |
| Per user messages | 20 msg/min |
| Per agent tool execution | 10 exec/min |
| Per agent LLM calls | 30 calls/min |
| Channel/Platform API per key | 60 req/min |
| Integration API per tool | 30 exec/min |
| Job dispatch per agent | 10 jobs/min |
Compliance¶
GDPR-ready: data export, anonymisation, deletion, consent, data minimisation, configurable retention. Data residency in EU (Convex Cloud, Ireland). Immutable audit logs streamed via Fivetran CDC to external storage for long-term retention. Privacy by design (user knowledge isolation is structural, not policy-based).
See 07 Security & Governance for the full security model and governance policy framework.
8. Plans and Pricing¶
Billing Model¶
Revenue comes from two components: a monthly platform subscription and execution credits for LLM-powered tasks. Each plan includes a task allowance; additional tasks are purchased via prepaid credits.
LLM costs are handled through managed billing: Thinklio routes all LLM calls via OpenRouter and bills customers at the model's posted rate plus a 2% platform margin. Enterprise customers may supply their own API keys (BYOK) and pay providers directly.
Plan Tiers¶
| Plan | Monthly | Annual | Users | Agents | BYOK | SSO | Custom Policies | Support |
|---|---|---|---|---|---|---|---|---|
| Free Trial | $0 | -- | 1 | 5 | No | No | No | Community |
| Solo | $19 | $190 | 1 | 5 | No | No | No | |
| Team | $99 | $990 | 15 | 20 | No | No | No | Priority |
| Business | $399 | $3,990 | 50 | 50 | No | Yes | Yes | Dedicated |
| Enterprise | Custom | Custom | Unlimited | Unlimited | Yes | Yes | Yes | Dedicated |
Free Trial. A 14-day trial at the Team feature level. Single user only (up to 15 allowed during trial). Full Team feature access during the trial period, with a clear conversion point at expiry. No credit card required. Trial task allowance: 300 tasks.
Solo ($19/month, early bird; $29/month standard). For individual professionals, consultants, and technical founders. 1 user, 300 tasks included per month. Email support.
Team ($99/month, early bird; $149/month standard). For small teams needing shared agents, shared knowledge, and coordination. Up to 15 users, 2,000 tasks included per month. Priority support.
Business ($399/month, early bird; $499/month standard). For organisations with governance, compliance, and scale requirements. Up to 50 users, 8,000 tasks included per month. SSO, advanced governance, and custom policies. Dedicated support.
Enterprise. Dedicated infrastructure, data region selection, on-premises deployment, custom SLAs, or negotiated terms. Pricing by arrangement.
Annual billing discount: 2 months free (approximately 17%). Early bird customers lock in their rate for life.
Subscription Status Lifecycle¶
Accounts progress through: trialing (14 days from creation), active (after upgrade), past_due (payment failure), cancelled (user-initiated or grace period expiry), expired (trial expiry without conversion).
See 01 Product & Strategy for the full pricing specification, enforcement data model, and frontend integration.
9. Implementation Roadmap¶
Built by a single senior developer (part-time) with AI-assisted tooling. Phases are sequential, not calendar-bound. Each phase completes when its success criteria are met.
| Phase | Focus | Key Outcome |
|---|---|---|
| 0: Foundation | Infrastructure | VPS provisioned, monorepo scaffolded, database and Redis running, CI basics |
| 1: Single Agent | Core loop | One agent, one user, Telegram channel. Harness working. End-to-end message to response with cost tracking |
| 2: Knowledge and Tools | Intelligence | Knowledge extraction and retrieval. Tool system with policy. Four-layer knowledge model |
| 3: Multi-Tenancy | Scale | Multiple users, teams, accounts. Assignments, scoping, budget enforcement |
| 4: Jobs and Composition | Advanced | Job system, agent-as-tool delegation, Agent Studio, deferred execution |
| 5: API and Channels | Integration | Three API surfaces. Additional channels. Self-service agent management |
| 6: Production Hardening | Reliability | Monitoring, alerting, backup, security hardening, performance tuning |
Future Phases (Not Yet Planned)¶
Agent learning and workflow codification. Voice and video channels. Multi-agent collaboration (peer-to-peer, beyond delegation). Marketplace for agent templates, tool integrations, and composed agent blueprints. Advanced analytics and delegation chain analysis. Multi-region deployment. White-labelling. Billing integration via Paddle.
See 13 Implementation Plan & Status for the full phase specifications and March 2026 implementation summary.
10. Key Architectural Decisions¶
These are the recorded decisions that shaped the platform's design. They are summarised here; the full ADR records with context, alternatives considered, and implications live in the decision log.
ADR-001: Platform named Thinklio. "Think" connects to core function; "-lio" is modern and distinctive.
ADR-002: Agents as first-class platform entities (not owned by accounts or teams). Agents exist independently and are assigned to contexts via assignments. This provides maximum flexibility: solo users do not need an account; the same agent can serve multiple contexts with isolated knowledge.
ADR-003: Four-layer knowledge model. Agent, account, team, and user layers with clear ownership, privacy, and precedence rules.
ADR-004: Durable execution harness with step-level state machine. Every operation is a step with independent lifecycle, providing crash recovery, granular cost tracking, retry at the step level, and a complete audit trail.
ADR-005: Convex-first greenfield rebuild. Replaced the original Go service architecture and the two-plane migration proposal. Three managed services (Convex, Clerk, Cloudflare R2) eliminate Redis, Go, Supabase, and custom event bus infrastructure. Maximum performance, minimum moving parts.
ADR-006: Clerk for identity and organisation management. Replaces Supabase Auth and the proposed Keycloak migration. Pre-built UI, first-class Convex integration, organisations that map to Thinklio accounts, and a smaller operational surface.
ADR-007: Messaging-first core abstraction. Channels with user and agent participants as the fundamental model. Unifies user-agent interaction, delegation, and team collaboration.
ADR-008: Three-tier execution model. Interactive fast path (Tier 1, no Workflow slots), durable workflows (Tier 2, slotted and budgeted), external queue (Tier 3, escape hatch for volume). Manages the Convex Professional plan's slot ceiling while preserving responsiveness.
ADR-009: Agent capability levels as policy configuration (not code branching). The harness, governance, and accounting infrastructure is the same at every level. What changes is policy configuration.
ADR-010: No calendar-bound timeline. Phases complete when success criteria are met. Quality over velocity.
ADR-011: Built from scratch, not migrated from MyAI. The prior TypeScript prototype informed the design but its single-user architecture does not provide a useful starting point for a multi-tenant platform.
ADR-012: Dedicated job system for deferred and long-running work. Jobs, subjobs, and observers as first-class entities, now modelled as Convex Workflow steps with waitForEvent.
ADR-013: Agent-as-tool composition model. Agents registered in the tool registry as a tool type. Delegation goes through the same execution path, policy evaluation, cost tracking, and audit trail as any other tool call.
ADR-014: Three external API surfaces (Channel, Platform, Integration). Not three versions of the same API. Fundamentally different integration patterns, each designed as a first-class architectural concern from the start.
ADR-015: Per-assignment tool restrictions. Narrow only, never widen. Allows a single agent to serve different contexts with appropriately scoped capabilities.
ADR-016: MCP tool permission intersection in shared channels. An agent's effective tool set in any channel is the intersection of all human participants' tool permissions, preventing privilege escalation.
See decision-log.md for the full ADR records.
11. Competitive Positioning¶
What Thinklio is NOT:
- Not a chatbot builder (agents reason and take action, not just respond)
- Not a prompt management tool (the value is in governance, knowledge, and composition)
- Not a workflow automation platform (agents decide, the platform tracks and governs)
- Not a single-model wrapper (LLM-provider agnostic via abstraction layer)
Differentiators:
- Governance-first: policies, cost controls, audit trails, and trust levels are structural, not bolt-ons
- Knowledge compounds: every interaction makes the system more valuable through structured knowledge extraction
- Agent composition: build sophisticated assistants from specialist delegates, all governed and cost-attributed
- Channel agnosticism: agents are unaware of communication channels; same capability everywhere
- Durable execution: step-level state tracking provides crash recovery, no double-charging, and complete auditability
- Multi-tenancy by design: isolation enforced at application level with Convex reactive caching eliminating custom infrastructure
- Three API surfaces designed in from the start: embed, orchestrate, and integrate
- Managed infrastructure on EU services: Convex Cloud (Ireland), Clerk, Cloudflare R2; no servers to manage on the hot path
- Convex-first reactive backend: real-time by default with no custom caching, pub/sub, or event bus to maintain
Market context: Thinklio sits at the intersection of AI agent platforms, enterprise AI governance, and integration middleware. It is designed for accounts that need AI assistants they can trust with real work in professional and regulated environments.
12. Example Scenarios¶
These illustrate how Thinklio's capabilities work in practice.
Solo professional. A consultant creates a personal agent. Over weeks, the agent learns the consultant's preferences, client details, and working patterns. The consultant chats with it via Telegram and web. It searches the web, manages tasks, and remembers context across chats.
Team deployment. A small team shares a project agent. When a team member asks about a project status or client history, the agent draws on everything the team has discussed, while keeping each member's personal chats private.
Agent composition. A team lead uses Agent Studio to build a "Project Coordinator" by selecting a PA template, attaching scheduler and research agents as delegates, and uploading project documents as knowledge. The PA checks the calendar (immediate), dispatches a research task (deferred), and responds: "You're free Thursday afternoon. I've started researching the standards and will send you a briefing when it's ready."
Customer-facing support. A support agent on a website handles enquiries about aged care services. It looks up a resident's maintenance request (immediate via Cliniko MCP server), creates an escalation to the facilities team (deferred job with human handoff), and responds with context-appropriate information. Account policies restrict what the agent discloses to external users.
Service provider. A consultancy builds on Thinklio via the Platform API to deploy agents for client engagements. The Integration API registers client CRM and project management tools as capabilities available to agents. Full isolation between clients, transparent cost attribution. The consultancy's own admin dashboard orchestrates agent deployment and monitoring across all client accounts.
13. Document Lineage¶
This reference is regenerated from the following canonical source documents (April 2026 consolidation):
Supporting living documents: index.md (doc set homepage), changelog.md (reverse-chronological change history), decision-log.md (ADR-style decision records).
This document supersedes old doc 17 (Thinklio Reference v03, March 2026).
14. Revision History¶
| Version | Date | Description |
|---|---|---|
| 1.0.0 | April 2026 | Regenerated from the consolidated canonical doc set (docs 01 through 13). Supersedes old doc 17 (Thinklio Reference v03). Updated to reflect the Convex-first architecture, Clerk authentication, concrete pricing tiers, MCP tool integration, messaging-first core abstraction, and three-tier execution model. |
This document is suitable for use as LLM context. Thinklio is in active pre-launch development with no public users yet. All features described here represent the designed architecture; implementation is progressing through the phased roadmap.