Skip to content

Product & Strategy

Document 01 | Version: 1.0.0 | Date: April 2026 | Status: Active

This document defines what Thinklio is, who it serves, what it does, and how it is priced. It consolidates the product overview, the product requirements document and functional specification, the pricing model and plan definitions, subscription enforcement, and the feature ideas backlog.

The product overview (section 2) is written for non-technical stakeholders: executives, managers, prospective users. The functional specification (section 3) provides the complete requirements reference for development and architecture. The pricing and plans section (section 4) defines the billing model, plan tiers, enforcement logic, and frontend integration. The feature backlog (section 5) captures ideas that are worth remembering but not yet committed to the roadmap.

For the system architecture that implements these requirements, see 02 System Architecture. For the agent architecture and composition model, see 03 Agent Architecture & Extensibility. For the data model, see 04 Data Model. For security, governance, and policy enforcement, see 07 Security & Governance. For the external API surfaces, see 09 External API & Tool Integration. For the implementation roadmap, see 13 Implementation Plan & Status.

Table of Contents

  1. Product Vision
  2. Product Overview
  3. Functional Specification
  4. Non-Functional Requirements
  5. Pricing, Plans & Enforcement
  6. Feature Ideas Backlog
  7. Constraints
  8. Success Criteria
  9. Revision History

1. Product Vision

Thinklio is an AI agent platform that enables individuals, teams, and accounts to deploy governed, intelligent assistants across any communication channel. The platform provides the infrastructure to create, configure, deploy, and manage AI agents with built-in governance, cost accounting, durable execution, and multi-layered knowledge management.

Product Principles

  1. Agents are trustworthy by design. Governance, cost controls, and auditability are not afterthoughts. They are core to every interaction.
  2. Architecture enables the business model. Multi-tenancy, billing, and plan management are structural, not bolted on.
  3. 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.
  4. Channel does not matter. Users interact through whatever tools they already use. Agents are unaware of channels.
  5. Knowledge compounds. Every interaction makes the system more valuable through structured knowledge extraction and agent learning.
  6. 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.

2. Product Overview

What Is Thinklio?

Thinklio is an AI agent platform that 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 simply serve as a knowledgeable assistant that remembers what matters to you.

What makes Thinklio different from other AI tools 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 not AI as a novelty. It is AI as reliable infrastructure that an account can trust with real work.

Who Is It For?

Individuals. A solo professional, whether a consultant, practitioner, or freelancer, can create a personal agent that learns their preferences, manages their tasks, and has access to the tools they use daily. The agent remembers context across chats and gets better over time as it learns what you care about and how you work.

Teams. A small team can share an agent that holds collective knowledge about their projects, clients, and processes. When a team member asks the agent about a project status or a client history, the agent draws on everything the team has discussed, while keeping each member's personal chats private. As the team works with the agent, the shared knowledge base grows organically.

Accounts. An account can deploy multiple agents across departments, each configured with different domain knowledge, tool access, and behavioural policies. A customer service agent has access to the knowledge base and ticketing tools. A legal compliance agent knows the relevant regulations and can review documents. An HR onboarding agent guides new employees through processes. All of these operate under account policies that govern what they can do, how much they can spend, and what requires human approval.

Service providers. A consultancy, managed service provider, or SaaS company can build on Thinklio to deliver AI-powered services to their own clients. Agents can be configured and deployed for specific client engagements, with full isolation between clients and transparent cost attribution. External systems can register their capabilities as tools available to Thinklio agents, and invoke Thinklio agents as capabilities within their own workflows.

Target 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: their data is theirs alone. 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 (scheduler, research, domain experts) 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.

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.

How It Works

Agents. An agent is an AI assistant with its own identity, knowledge, skills, and behavioural rules. Agents are created on the platform and can be assigned to serve individuals, teams, or entire accounts. Some agents are simple, answering questions from a specific knowledge base. Others are sophisticated, composing multi-step workflows, using tools, delegating to specialist agents, and learning from successful problem-solving. Agents are not generic. They are configured for specific purposes. A well-configured agent with deep domain knowledge and appropriate tool access becomes a genuine force multiplier for the people it serves.

Agent composition. Thinklio supports building sophisticated assistants by composing specialist agents. A personal assistant agent can delegate to a scheduler agent for calendar management, a research agent for information gathering, and domain-specific agents for specialised tasks. Each delegate has its own expertise and tools, but from the user's perspective, they are interacting with a single capable assistant. Agent Studio provides a visual interface for composing agents: selecting delegate agents, configuring what each delegate can do, and understanding the delegation structure. Templates for common compositions (for example, "Personal Assistant with Scheduler and Research") allow non-technical users to build useful composite agents without understanding the underlying architecture. Delegation is fully governed. Costs from delegate agents roll up to the originating user and team. Delegation depth is limited by policy. Knowledge isolation is maintained between agents.

Channels. Thinklio is channel-agnostic. Agents connect to the communication tools people already use: Telegram, WhatsApp, web chat, voice, email, or custom API integrations. The same agent can be accessible through multiple channels simultaneously. A team might interact with their agent via Telegram during the day and through a web dashboard for more complex tasks. The agent maintains context regardless of how you reach it.

Knowledge. Thinklio agents build and maintain structured knowledge across four layers. Agent knowledge is the domain expertise, skills, and behavioural patterns intrinsic to the agent: this is what makes a particular agent good at what it does. Account knowledge covers policies, procedures, guidelines, and reference material curated by the account: the authoritative "how we do things" layer. Team knowledge is the collective intelligence that grows organically from the team's interactions: project context, client details, decisions made, lessons learned. User knowledge is personal preferences, individual context, and private information that the agent uses to serve each person effectively: this layer is strictly private to the individual. These layers combine to give the agent rich, relevant context for every interaction while maintaining clear boundaries about who can see what.

Deferred work and long-running tasks. Not every task completes in seconds. Thinklio agents can dispatch work that takes minutes or hours: a comprehensive research task, a document generation workflow, a request that needs human review before proceeding. When an agent starts a long-running task, it acknowledges the request and lets you know it is working on it. When results are ready, the agent delivers them in the same chat, picking up where you left off. Multiple agents can observe the same task. A monitoring agent might track progress on a dashboard while the personal assistant waits for the right moment to deliver results to you.

Governance. Every agent operates within a governance framework set by the account. This includes policies (rules about what agents can and cannot do, which tools they can access, what kinds of actions require human approval, what topics are off-limits, how deep delegation chains can go, whether certain delegations need approval), cost controls (budgets at the account, team, and user level, with metered and transparently attributed usage for both immediate and deferred work), trust levels (graduated permissions that control tool access, from broadly available read-only tools through to high-risk actions requiring explicit approval, with the same agent potentially having different effective permissions depending on which team it is serving), and audit trails (every reasoning step, tool call, delegation, job dispatch, and decision is logged, with accounts able to review exactly what an agent did, why it did it, and what it cost). This governance layer is what makes Thinklio suitable for professional and regulated environments. It is not just about what AI can do. It is about maintaining control over what it does.

Reliability. Thinklio's execution engine, the harness, ensures that agent operations are reliable and recoverable. Every step of an agent's reasoning is independently tracked. If something fails partway through a complex task, the system can resume from the last successful step rather than starting over. This means no double-charging for failed operations, no lost work due to transient errors, complete visibility into what happened and where, and predictable costs even when things go wrong.

Integration. Thinklio is designed for integration. Three distinct API surfaces serve different integration needs. The Channel API lets you embed Thinklio agents in your own applications, websites, or internal tools as conversational assistants. The Platform API gives you programmatic control to manage agents, dispatch work, monitor jobs, and access usage data from your own systems. The Integration API lets you connect your existing tools and services (CRM, project management, document systems) so Thinklio agents can work with the systems your organisation already uses.

3. Functional Specification

FR-01: Agent Management

FR-01.1: Agent Creation. Users, teams, and accounts can create agents. Agents can be created from scratch or from templates. Agent configuration includes name, personality and system prompt, domain knowledge, tool assignments (including agent-as-tool delegations), capability level, and behavioural policies. Agents are first-class platform entities with unique identifiers.

FR-01.2: Agent Assignment. Agents can be assigned to users, teams, or accounts. Assignments include scope configuration (which knowledge layers are active). An agent can serve multiple contexts simultaneously with isolated knowledge per context. Assignments can be created, modified, and revoked. Assignments can include per-assignment tool restrictions that narrow (never widen) the agent's configured capabilities.

FR-01.3: Agent Templates. Pre-configured agent templates for common use cases. Templates define default knowledge, tool access, system prompts, delegation relationships, and policies. Templates for composed agents (for example, "Personal Assistant with Scheduler and Research") pre-configure delegation relationships. Accounts can create and share internal templates. Platform-level templates are available for all users.

FR-01.4: Agent Lifecycle. Agents can be active, paused, or archived. Pausing an agent stops all interactions and cancels pending jobs but preserves knowledge and configuration. Archiving retains the audit trail but releases resources. Deletion requires explicit confirmation and triggers data retention procedures.

FR-01.5: Agent Composition (Agent Studio). Users can compose agents by attaching other agents as delegates (agent-as-tool). Agent Studio provides a visual interface for defining delegation relationships, assigning tools, configuring per-delegation restrictions, and viewing the delegation graph. Cycle detection prevents circular delegation at configuration time. Delegation depth limits are configurable at the account level. Composed agent templates allow non-technical users to build useful composite agents.

FR-02: Communication Channels

FR-02.1: Channel Abstraction. All channels produce and consume universal events. Adding a new channel requires only a gateway adapter, with no changes to core services. Agents are channel-unaware: they process events, not channel-specific messages.

FR-02.2: Supported Channels (Initial). Telegram (text, images, documents, voice messages). HTTP API via the Channel API surface (programmatic conversational access). Web chat (embedded widget).

FR-02.3: Channel Capabilities. Each channel declares its capabilities (text, images, audio, video, files, interactive elements). Response formatting adapts to channel capabilities. Rich responses degrade gracefully on limited channels.

FR-02.4: Multi-Channel Continuity. A chat with an agent maintains context across channels. A user can start in Telegram and continue via web chat with full context preserved.

FR-03: Knowledge Management

FR-03.1: Four-Layer Knowledge Model. Agent knowledge covers intrinsic domain expertise, skills, and learned workflows. Account knowledge covers policies, procedures, and reference material (admin-curated, mostly static). Team knowledge covers collective intelligence that grows from team interactions. User knowledge covers personal preferences and context, strictly private.

FR-03.2: Knowledge Extraction. Automatic extraction of structured facts from chats. Classification of extracted facts into the appropriate knowledge layer. Scope determination: is this fact personal (user), shared (team), or procedural (account)? Configurable extraction: accounts can define what types of knowledge to capture. Knowledge extracted by delegate agents during delegation is scoped to the delegate's assignment context, not the invoking agent's.

FR-03.3: Knowledge Precedence. Account policies override all other layers. Agent knowledge takes next precedence. Team knowledge follows. User knowledge has lowest precedence but highest personalisation value. Conflicts are resolved by the precedence hierarchy.

FR-03.4: Knowledge Privacy and Portability. User knowledge is never visible to other users. Team knowledge is isolated between teams within an account. Cross-team knowledge sharing requires explicit configuration. User knowledge is portable: it follows the user if they leave a team. Team knowledge contributions remain with the team.

FR-03.5: Vector Search. Knowledge facts support embedding-based similarity search. Relevant facts are retrieved based on semantic similarity to the current chat. Token-budgeted context injection ensures relevant facts fit within model limits.

FR-04: Durable Execution Harness

FR-04.1: Interaction Lifecycle. Every user message creates an interaction (a tracked unit of work). Interactions consist of one or more steps. Interaction state is derived from its constituent steps. Delegation creates child interactions linked to the parent via parent_interaction_id.

FR-04.2: Step State Machine. Step states: created, running, success, or failed. Steps are persisted before execution begins. Results are persisted on completion. Failure reasons are captured as metadata: timeout, error, governance denial, budget exceeded, user cancellation, system interruption, delegation_depth_exceeded, delegation_cycle_detected.

FR-04.3: Resumability. After a crash or restart, the system identifies incomplete interactions. Interactions resume from the last completed step. No duplicate execution of completed steps (idempotency).

FR-04.4: Step Types. Context assembly gathers knowledge layers, history, tools, and job context (for follow-ups). Think is an LLM call for reasoning and decision-making. Act is tool execution (one step per tool call), with execution mode (immediate, deferred, interactive). Observe is an LLM call to synthesise results and formulate a response. Respond delivers the response to the channel. Extract is asynchronous knowledge extraction post-interaction.

FR-04.5: Cost Tracking Per Step. Each step records its resource consumption (tokens, API calls, compute time). Costs are attributed to the user, team, and account associated with the interaction. Step-level cost data enables granular usage reporting and anomaly detection. Delegation costs roll up through the interaction chain.

FR-04.6: Step Execution Modes. Immediate: synchronous execution within the interaction (default). Deferred: dispatch to external engine, create a Job, step succeeds on dispatch; results arrive later via follow-up interaction. Interactive: result feeds back into a new think step for multi-turn reasoning within a single interaction. Mixed mode: a single interaction can use different modes for different act steps.

FR-05: Tool System

FR-05.1: Tool Registry. Tools are defined in a central registry with metadata: name, description, parameter schema, trust level, rate limits, default execution mode. Tools can be internal (platform-provided), external (webhook or API-based), or agent-type (delegation to another agent). Tool definitions support versioning. External systems can register tools dynamically via the Integration API (with governance approval).

FR-05.2: Tool Access Control. Tools are assigned to agents with specific permission levels (read-only, read-write). The policy engine evaluates every tool execution request. Policies consider: agent configuration, user trust level, team permissions, account rules, session cost, and assignment-level tool restrictions. Policy decisions: allow, deny, or require-approval. Per-assignment tool restrictions can narrow but never widen an agent's configured permissions.

FR-05.3: Tool Execution. Tool calls are executed as individual harness steps. Each execution is subject to timeout, retry, and cost limits. External tool calls include circuit-breaker patterns for resilience. Tool results are cached where appropriate. Agent-type tool calls create child interactions for the delegate agent.

FR-05.4: Approval Workflows. High-risk tool calls can require explicit user or admin approval. Approval requests are delivered through the agent's communication channel. Pending approvals have configurable timeouts. Approval decisions are logged in the audit trail.

FR-06: Governance and Policy

FR-06.1: Account Policies. Accounts define policies that govern all their agents' behaviour. Policies cover: allowed tools, spending limits, data handling, content restrictions, approval requirements, and delegation limits. Policies are enforced at the harness level and cannot be bypassed by agent configuration.

FR-06.2: Cost Governance. Budget limits at account, team, and user levels. Pre-execution budget checks: steps are not started if the budget would be exceeded. Usage alerts at configurable thresholds (for example, 80%, 90%, 100% of budget). Budget periods (daily, weekly, monthly) with automatic reset. Deferred work (jobs) consumes budget from the same pool as immediate work.

FR-06.3: Audit Trail. Every interaction, step, policy decision, tool execution, job lifecycle event, delegation chain, and knowledge modification is logged. Audit logs are immutable and time-stamped. Accounts can query their own audit data. Retention periods are configurable per account.

FR-06.4: Kill Switch. Agents can be paused immediately by account admins or team admins. Pausing stops all new interactions; in-flight interactions complete the current step then halt. Pausing cancels all pending jobs for the paused agent. Resume requires explicit admin action.

FR-06.5: Delegation Governance. Maximum delegation depth is configurable at the account level (default: 3). Cycle detection runs at both configuration time and runtime. Delegation can require approval for high-trust operations. Cost from delegation chains rolls up to the originating user, team, and account.

FR-07: Job System

FR-07.1: Deferred Work. Agents can dispatch work to external execution engines (n8n, human queues, third-party services) as deferred act steps. Dispatched work creates a Job entity with one or more Subjobs. The dispatching interaction completes normally; results arrive via a follow-up interaction.

FR-07.2: Job Observation. Multiple agents or system processes can register as observers on a job. Observers specify notification preferences: completion only, failure only, partial output, or all state changes. Terminal state notifications always reach all observers regardless of preference. Follow-up interactions are triggered by job state change notifications.

FR-07.3: Partial Output. Jobs with multiple subjobs can notify observers when useful partial output is available. The default usefulness rule is "any completed subjob with non-null output". Custom usefulness rules can be defined for sophisticated job types.

FR-07.4: Job Lifecycle. Jobs progress through: pending, dispatched, in_progress, resolved, failed, cancelled, or timed_out. Active jobs are stored for performance; terminal jobs are flushed to durable storage. Timeout monitoring cancels jobs that exceed their deadline. Cancellation is a first-class operation (user-initiated, agent-initiated, or system-initiated).

FR-08: Agent Learning

FR-08.1: Workflow Codification. Agents that successfully solve multi-step problems can codify the workflow as a reusable pattern. Learned workflows are first-class objects: named, versioned, reviewable. Workflows can be approved, edited, or rejected by admins.

FR-08.2: Workflow Sharing. Learned workflows exist in the agent knowledge layer by default. Workflows can be promoted to team or account level by admins. Workflow promotion creates a copy; the original remains with the agent.

FR-08.3: Capability Level Configuration. Each agent's capability level is configurable: tools-only, workflow composition, experimental, or learning. Capability level is a policy setting, enforced by the harness. Higher capability levels require higher trust and are subject to stricter cost controls.

FR-09: User Management

FR-09.1: User Accounts. Users register with email or SSO. Users can belong to multiple accounts and teams. User identity is global; account and team membership is contextual.

FR-09.2: Roles and Permissions. Account level: owner, admin, editor, viewer. Team level: admin, member, read-only. Agent level: admin (configure), user (interact). Role hierarchy is enforced in the policy engine.

FR-09.3: Onboarding. Individual: sign up, then create agent (account scaffolding is invisible). Team: invited by team admin, gains access to team agents. Account: invited by account admin, assigned to teams, accesses team agents.

FR-10: API

FR-10.1: Three API Surfaces. Channel API: conversational access, external systems act as channel adapters. Platform API: orchestration, management, job dispatch, knowledge management, usage reporting. Integration API: bidirectional capability exchange, tool registration, event subscription. All surfaces resolve to the same authorisation and governance model.

FR-10.2: Channel API. Send messages to agents on behalf of users. Receive responses. Access chat history. Same governance as native channels (Telegram, web chat).

FR-10.3: Platform API. CRUD operations for agents, teams, users, tool definitions, and policies. Job dispatch and observation with webhook callbacks. Knowledge management (add, query, bulk import, export). Usage data and cost attribution. Scoped to account context with role-based access. RESTful with JSON payloads. API versioning from day one.

FR-10.4: Integration API. External systems register as tools with parameter and return schemas. Dynamic registration with governance approval. Tool execution follows the standard policy evaluation path. Event subscription with webhook delivery for relevant platform events. Bidirectional: external systems can also invoke Thinklio agents via Platform API job dispatch.

4. Non-Functional Requirements

NFR-01: Performance

Response latency: under 500ms for cached context, under 2s for full LLM interaction (excluding model inference time). Event bus latency: under 10ms from publish to consumer notification. Knowledge retrieval: under 50ms for cached facts, under 200ms for database queries. API response time: under 100ms for management endpoints. Job dispatch latency: under 200ms from act step to job creation.

NFR-02: Scalability

Horizontal scaling by adding service instances. Linear performance improvement with additional instances. Services scale independently based on their load profile. Target: support 10x growth without architectural changes.

NFR-03: Availability

Target: 99.9% uptime for the platform. Graceful degradation: if a non-critical service is down, core messaging continues. Zero-downtime deployments via rolling updates. Automatic restart of failed service instances.

NFR-04: Security

Encryption in transit (TLS) for all external and internal communication. Encryption at rest for database and object storage. Row-level security on all database tables. No plaintext secrets in configuration or logs. Regular dependency vulnerability scanning. Delegation chain validation at runtime (cycle detection, depth limits).

NFR-05: Compliance

GDPR-ready: data export, anonymisation, and deletion capabilities. Configurable data retention per account. Immutable audit logs. Privacy by design: user knowledge isolation is structural, not policy-based.

NFR-06: Observability

Structured logging across all services. Distributed tracing for cross-service request tracking (including delegation chains). Metrics collection (Prometheus-compatible). Health check endpoints on every service. Alerting for service health, error rates, queue depth, budget thresholds, active job counts, and account activity.

NFR-07: Developer Experience

Local development environment setup in under 10 minutes. Docker Compose for single-command local deployment. Comprehensive API documentation across all three surfaces. Clear service boundaries and interface contracts.

5. Pricing, Plans and Enforcement

5.1 Billing Model

Thinklio uses a two-component billing model.

Platform subscription. A fixed monthly (or annual) licence fee that covers agent hosting, the governance engine, knowledge storage, audit trails, and the admin dashboard. This does not vary with usage. The subscription covers everything that makes governed AI operations possible: it is a fixed monthly cost.

Execution credits. Prepaid credits consumed by agent activity. Every task executed draws from the credit pool. Credits roll over indefinitely and never expire. Each plan includes a monthly task allowance. Additional credits can be purchased at any time. Auto top-up keeps agents running without interruption.

These are two distinct line items and should always be presented as such in the billing interface and on the pricing page.

5.2 LLM Costs

LLM costs are passed through to the customer via one of two options.

Managed billing (default and recommended). Thinklio handles LLM API access via OpenRouter. A 2% service margin is applied. This is the simplest option for customers who want a single bill. Thinklio selects the optimal model per task category, updated weekly, balancing capability and cost. Customers on managed billing can either allow Thinklio to select the optimal model or specify their own preferences per category.

BYO API keys. Customers supply their own API keys (for example, Anthropic, OpenAI, or OpenRouter). No margin is applied. LLM costs are incurred directly by the customer outside Thinklio. BYO key customers have full model control. BYOK is restricted to Enterprise plans.

5.3 Credit Top-Up

Credits are prepaid at $0.10 per task. Customers cannot incur a negative balance.

Auto top-up is enabled by default. When the credit balance falls below a configurable threshold (default 20%), the account is automatically topped up by a user-defined amount.

Manual top-up. Customers can add credits at any time, for example before initiating a known high-volume task.

Low balance warnings. Notifications are sent (email and in-app) when the balance reaches 25% of the most recently purchased amount.

Credit pack denominations: $10 (100 tasks), $20 (200 tasks), $50 (500 tasks), $100 (1,000 tasks), $500 (5,000 tasks), $1,000 (10,000 tasks). Higher denominations ($2,000 and $5,000) to be added once $1,000 purchases become common in practice.

5.4 Plan Tiers

Plan Price (Monthly) Price (Annual) Max Users Max Agents BYOK SSO Custom Policies Support
Free Trial $0 n/a 15 3 No No No Community
Solo $19 $190 1 5 No No No Email
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 to start. Trial task allowance: 300 tasks.

Solo ($19/month, early bird; $29/month standard). For individual professionals, consultants, and technical founders who want a capable personal agent. 1 user, 300 tasks included per month (roughly 10 tasks per day), additional tasks via prepaid credits. Email support.

Team ($99/month, early bird; $149/month standard). For small teams that need shared agents, shared knowledge, and coordination across members. Up to 15 users, 2,000 tasks included per month. Priority support. This is the "most popular" tier.

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. For organisations requiring dedicated infrastructure, data region selection, on-premises deployment, custom SLAs, or negotiated terms. Pricing by arrangement.

Annual billing. Discount: 2 months free (approximately 17%). Presented as "X months per year" rather than a percentage. Early bird customers lock in their rate for life (is_early_bird = true).

5.5 Real-World Usage Guidance

A typical research briefing runs 5 to 10 tasks. A daily status summary across your tools runs 2 to 3 tasks. A complex multi-step workflow with several tool calls might use 20 to 30 tasks.

These figures are based on real usage data from Thinklio customers and are updated regularly. Actual usage will vary depending on agent complexity and model selection. This section is treated as a living part of the pricing page, updated as real-world data accumulates.

5.6 Enforcement Data Model

The following account fields support plan enforcement:

Field Type Description
plan TEXT free, solo, team, business, enterprise
subscription_status TEXT trialing, active, past_due, cancelled, expired
billing_period TEXT monthly, annual
is_early_bird BOOLEAN Locked-in early bird pricing
trial_expires_at TIMESTAMPTZ 14 days from account creation (free trial only)
subscription_started_at TIMESTAMPTZ When the paid subscription began
credit_balance NUMERIC(12,6) Prepaid USD balance

Subscription status lifecycle:

Account created -> trialing (14 days)
                     |
                     +-- User upgrades -> active
                     |                     |
                     |                     +-- Payment fails -> past_due
                     |                     |                     |
                     |                     |                     +-- Payment recovered -> active
                     |                     |                     +-- Grace period ends -> cancelled
                     |                     |
                     |                     +-- User cancels -> cancelled
                     |
                     +-- Trial expires -> expired

5.7 Enforcement Points

Enforcement checks happen server-side. The API returns specific error codes so the frontend can show appropriate upgrade prompts.

Action Check Error Code Error Message
Invite user current_users < max_users plan_limit "Team plan allows 15 users"
Create or activate agent current_agents < max_agents plan_limit "Team plan allows 20 agents"
Add BYOK API key plan == enterprise plan_limit "Custom API keys require Enterprise plan"
Any request when trial expired subscription_status != expired trial_expired "Your trial has expired"

Frontend handling: when the API returns a plan_limit or trial_expired error, show an upgrade dialogue rather than a generic error message.

5.8 Plan API

GET /v1/plan?account_id={id}

Returns the current plan, subscription status, limits, and feature flags.

Response:

{
    "plan": "team",
    "subscription_status": "active",
    "billing_period": "annual",
    "is_early_bird": true,
    "trial_expires_at": null,
    "limits": {
        "MaxUsers": 15,
        "MaxAgents": 20,
        "TrialDays": 0,
        "BYOKAllowed": false,
        "SSOAllowed": false,
        "CustomPolicies": false,
        "SupportLevel": "priority"
    }
}

The frontend should call this on app load and cache the result in the account store. Use it to show or hide features based on plan, display plan name and limits in settings, show upgrade prompts when limits are approached, and gate enterprise-only features (BYOK, SSO, custom policies).

5.9 Plan Limits Reference

Plan limits are defined as a configuration structure:

type PlanLimits struct {
    MaxUsers       int     // -1 = unlimited
    MaxAgents      int     // -1 = unlimited
    TrialDays      int
    BYOKAllowed    bool
    SSOAllowed     bool
    CustomPolicies bool
    SupportLevel   string  // community, email, priority, dedicated
}

These are hardcoded, not stored in a table. Plan definitions change infrequently and a code deploy is appropriate for changes. The GET /v1/plan endpoint returns these limits so the frontend does not need to hardcode them separately.

5.10 Frontend Integration

Settings page: Subscription and Billing tab (visible to admin and owner roles). The current plan card shows the plan name and badge, trial countdown with upgrade CTA if trialing, "Early bird pricing locked in" badge if applicable, billing period toggle (monthly or annual with "2 months free" label), and a "Change Plan" button opening a plan comparison modal. The credits card shows USD balance, auto top-up toggle with amount selector, and one-time top-up buttons ($10, $20, $50, $100, $500, $1,000). The plan comparison modal shows all four paid tiers side by side (matching the pricing page design), highlights the current plan, and shows "Upgrade", "Downgrade", or "Current" buttons per tier.

Settings page: Enterprise tab (visible only when account.plan === 'enterprise'). Shows custom API keys (per-service key management), SSO configuration (SAML/OIDC setup, future), custom policies (policy editor, future), and dedicated support contact and SLA info. For non-enterprise accounts, the Services and Keys card in the Organisation tab shows platform services as read-only. If they click where "Add Key" would be, show an upgrade prompt: "Custom API keys are available on the Enterprise plan."

Settings page: Organisation tab. The LLM Models card (visible to editor and above) shows Deep, General, and Mini model selections. All plans can view models but editing preferences may be restricted by plan. The Services and Keys card (visible to admin and above) shows services as read-only for non-enterprise accounts and full key management for enterprise accounts.

Sidebar. Shows credit_balance as USD. If on trial, show "Trial: X days left" instead of balance.

Upgrade prompts. When a plan limit is hit, show contextual upgrade dialogues. User limit: "Your {plan} plan supports up to {max} users. Upgrade to {next_plan} for up to {next_max} users." Agent limit: "You've reached the {max} agent limit. Upgrade to add more agents." BYOK: "Custom API keys are an Enterprise feature. Contact us to upgrade." Trial expired: full-screen modal: "Your 14-day trial has ended. Choose a plan to continue."

Role visibility summary:

Feature viewer editor admin owner app_admin
View plan info Yes Yes Yes
Change plan Yes
Manage credits Yes Yes
Enterprise settings tab Yes* Yes*
App Admin tab Yes

*Enterprise tab only visible when plan === 'enterprise'.

5.11 Account Creation Flow

When a new account is created via POST /v1/accounts:

  1. Account created with plan = 'free'.
  2. subscription_status set to 'trialing'.
  3. trial_expires_at set to NOW() + 14 days.
  4. subscription_started_at set to NOW().
  5. User is the owner.

The app should: after Clerk signup, call GET /v1/accounts; if empty, show the onboarding wizard; the wizard creates the account and the backend initialises the trial; redirect to briefing; show "14-day free trial" banner in sidebar.

5.12 Early Access and Overrides

Early access partners are not part of the profit model. They are a learning asset. The following override capabilities are supported in the admin interface: extend or reset trial periods for specific accounts, apply custom pricing (for example, lifetime early access discounts), flag accounts as early access partners, view per-account usage without requiring direct database access, and manage account-level settings and permissions. Early access pricing and terms can be offered outside the published tiers as commercial arrangements warrant.

5.13 Pricing Page Presentation

The pricing page presents three published tiers plus an Enterprise statement. The Free Trial shows no price and uses a "Start free trial" CTA. Solo, Team, and Business each show early bird pricing with a factual "Early bird pricing" label (no countdown timers or urgency tactics). Enterprise is rendered as a statement below the tier cards, not as a tier card itself: "Organisations with dedicated infrastructure, data region, on-premises, or compliance requirements: get in touch."

The billing model explanation on the pricing page should cover three components in this order: platform subscription (fixed monthly cost), execution tasks (prepaid credit pool with included allowance), and LLM costs (managed billing with 2% margin or BYO keys).

A real-world usage section below the tier cards gives prospective customers a genuine basis for choosing a tier. It is populated initially with estimates and updated with real usage data as early access customers generate it.

The comparison callout is retained: "A Thinklio Business subscription with typical agent usage runs under $600 per month. A single operations coordinator typically costs an organisation $6,000 to $10,000 per month in salary, superannuation, and overhead. Agents don't take leave, forget institutional knowledge, or need onboarding."

Terminology: use "tasks" not "execution cycles" or "execution units". Use "credits" for the prepaid pool. Keep the transparency framing. Retain the footnote: "Pricing shown is indicative and may be adjusted based on early access feedback. Early access partners receive favourable terms."

5.14 Outstanding Items

  1. Paddle integration. Once the Paddle account is active, update page CTAs to point to checkout flows rather than the contact form. Credit pack denominations will need to be configured as six separate one-time purchase products in Paddle alongside the three subscription products.
  2. Usage data. Real-world usage section on the pricing page to be updated once early access customers generate sufficient data.

6. Feature Ideas Backlog

This section captures feature ideas and product concepts that have not yet been committed to the roadmap. It is the holding pen for things worth remembering but not yet worth specifying.

Ideas land here when they are interesting enough to write down but not ready for the functional specification or implementation plan. Each entry is deliberately lightweight: a title, a short description of what it is and why it matters, and a note on which part of the platform it would touch.

There are no effort estimates, no priorities, and no commitments. When an idea matures enough to warrant proper design, it graduates into the functional specification (section 3) and implementation plan (doc 13) through the normal update process. At that point, remove it from this list and note where it landed.

MCP Server for Thinklio

Expose Thinklio's agent capabilities as an MCP (Model Context Protocol) server, allowing external AI tools (Claude Desktop, Claude Code, Cursor, and similar) to interact with Thinklio agents, trigger jobs, query knowledge, and receive results without going through the web UI or REST API. This would position Thinklio as a tool-provider in the broader AI tooling ecosystem rather than only a standalone platform.

Touches: API layer (new surface or extension of Integration API), authentication, agent execution, knowledge retrieval.

Origin: Natural extension of the Integration API strategy; MCP adoption is growing rapidly across AI developer tooling.

Add new ideas above this line. When an idea graduates to the functional specification and implementation plan, remove it from here and note the destination in the changelog.

7. Constraints

Infrastructure. Initial deployment on a single Hetzner Cloud VPS with Coolify, expandable to multi-VPS.

Language. Go for all services (decision made for performance, deployment simplicity, and long-term maintainability). Backend migrating to Convex (TypeScript server functions, reactive database, durable workflows).

Database. Convex reactive database as the primary data store. Supabase Cloud (PostgreSQL 16, Auth, Vault) as legacy, being retired. pgvector extension for embeddings.

Budget. Development by a single developer with AI-assisted tooling; architecture must be buildable incrementally.

Timeline. Working system for personal and team testing within initial development phase; production-ready for broader deployment thereafter.

8. Success Criteria

Phase 1 (Foundation)

Single agent functional via Telegram. Durable execution harness with step-level tracking. Basic knowledge extraction and retrieval. Cost tracking per interaction. Deployable on single VPS.

Phase 2 (Multi-Tenancy)

Multiple agents, users, and teams. Four-layer knowledge model operational. Policy engine enforcing governance rules. API for agent management.

Phase 3 (Production)

Account management and billing. Job system operational (deferred work, observers, partial output). Agent composition via agent-as-tool delegation. Agent Studio for agent configuration and composition. Multiple channels supported (Telegram plus Channel API). Full audit trail and reporting. Horizontal scaling validated.

Phase 4 (Growth)

Platform API fully operational (job dispatch, knowledge management, usage reporting). Integration API for external tool registration and event subscription. Agent learning and workflow codification. Self-service onboarding. Platform marketplace for templates and tools.

9. Revision History

Version Date Description
1.0.0 April 2026 Consolidated from old docs 01 (Product Overview v02), 03 (PRD Specification v02), 22 (Pricing Revision v01), 26 (Feature Ideas Backlog v01), and 38 (Subscription Plans & Enforcement v01).