ind.ai

Product Architecture

The ind.ai Starter Agent Fabric

Free starter agents for 1M+ users — without 1M autonomous runtimes

ind.ai can scale by giving every user an agent identity, compact memory, and access to a shared orchestration fabric — instead of spinning up a dedicated always-on agent for each person.

This architecture allows ind.ai to offer mass-market starter agents at low cost, while reserving deeper autonomy, persistent workflows, and private runtimes for premium or enterprise tiers.

Core Model

The unit of scale

1 User

=

IdentityCompact MemoryShared Orchestration AccessControlled ToolsTier-Based Capabilities

Users should experience ind.ai as "my personal agent system," but the backend should operate as a multi-tenant shared agent fabric — not as millions of separate agent processes.

Strategic Context

Why this model is necessary

This is a scaling choice, not a compromise.

Infrastructure cost explodes

Giving every free user a persistent autonomous runtime is economically unviable at India scale. Shared orchestration keeps unit costs flat.

Orchestration complexity compounds

Millions of independent agent processes create an unmanageable coordination surface. A central router with controlled tool access stays governable.

Monitoring and abuse surface grows

Autonomous agents without centralised policy enforcement become a safety and compliance risk. Shared fabric means shared guardrails.

Free-tier economics break

Without this architecture, free-tier agents become unsustainably expensive — forcing either aggressive rate limits or premature monetisation walls.

Autonomy is wasted on lightweight tasks

Most starter-agent interactions are simple: search, draft, remind, navigate. Full autonomy is unnecessary — and expensive — for these workflows.

Architecture

Layered architecture stack

Seven layers from identity to premium runtimes. The shared orchestration core is what makes the free tier economically viable.

Identity Layer

User handle, language, profile, permissions, consent, and account tier.

Session Layer

Ephemeral sessions spin up only when the user sends a request. No always-on runtime for free users.

Memory Layer

Compact memory store with profile facts, preferences, summaries, saved items, connector permissions, and retrieval-friendly context.

Orchestration Layer

Central router decides intent, selects the right starter-agent mode, chooses allowed tools, and determines model cost tier.

Tool Layer

Shared tool APIs for search, drafting, reminders, service navigation, forms, payments, commerce, and verified workflows.

Worker / Queue Layer

Longer or slower jobs run asynchronously through workers rather than blocking the live conversation.

Premium Runtime Layer

Persistent, more autonomous, or sandboxed runtimes reserved for paid, developer, or enterprise tiers.

Designed for 1M+ identities, not 1M active runtimes.

Starter Agents

Starter agents for free users

Each card represents a product surface — not a separate always-on runtime.

Primary Agent

General-purpose assistant that knows the user profile and routes tasks.

Search & Explain

Finds, summarises, compares, translates, and explains information.

Drafting & Forms

Helps write messages, applications, forms, and structured submissions.

Tasks & Reminders

Handles lightweight planning, reminders, follow-ups, and simple scheduling.

Services Navigator

Helps users discover the right service, workflow, next step, or provider.

Commerce & Payments

Assists with transactions, payment-related flows, and trusted service actions with explicit approval.

These are mostly modes + permissions + workflow packs, not separate dedicated agent runtimes.

All starter agents are built using the ind.ai Agent OS architecture.

Request Flow

How a request flows

Example: "Help me book a fertility appointment"

1

User sends request

2

Identity + permissions loaded

3

Router detects intent

4

Starter-agent mode selected

5

Memory retrieved

6

Model tier chosen

7

Tool / workflow called

8

Response returned

9

Long-running → worker queue

10

Approval before irreversible action

Tier Boundaries

Free vs Pro vs Enterprise

The tier model makes monetisation logic transparent. Free users get useful agents; paying users get depth, persistence, and autonomy.

Free

  • Shared orchestration layer
  • Ephemeral sessions
  • Compact memory
  • Limited daily usage
  • Basic starter agents
  • Restricted tools
  • Approval-gated actions
  • No persistent autonomous runtime

Pro

  • Larger memory
  • More usage
  • Deeper workflows
  • More connectors
  • Richer agent customisation
  • Limited persistent tasks
  • Premium model escalation
  • Optional private runtime features

Enterprise

  • Dedicated isolation
  • Stronger governance controls
  • Deeper workflow automation
  • Team / org policies
  • Auditability
  • Private connectors
  • Advanced autonomy under guardrails
  • Possible OpenClaw-style runtime

Strategic Note

Where OpenClaw fits

OpenClaw is not the default runtime for the ind.ai free tier.

OpenClaw-style runtimes are powerful for developers, power users, and private-agent environments — but not the right economic base layer for a mass-market free tier. For ind.ai, they fit better as:

Pro-tier advanced agent runtimeDeveloper BYOC modeEnterprise private-agent deploymentSandboxed high-trust workflow environment

Cost Discipline

Cost-control principles

Operational discipline that makes the free tier sustainable.

Cheap model first
Escalate only when needed
Tools before expensive reasoning
Memory retrieval over chat replay
No per-user containers (free tier)
Ephemeral sessions only
Long tasks → worker queues
Outbound messaging used selectively
Permissioned actions only
Clear usage quotas by tier

Strategic Advantage

Why this architecture wins

Scalable free-user growth

Millions of identities without proportional infra cost.

Lower cost per user

Shared fabric instead of dedicated runtimes.

Clean monetisation path

Natural progression from free → pro → enterprise.

Better governance & safety

Centralised policies, consent, and audit.

Easier product iteration

One orchestration surface to update, not millions.

Premium upsell path

Deeper autonomy and persistence for paying users.

The right way to scale ind.ai is to productise personal agents — not provision millions of runtimes.

ind.ai should make every user feel like they have a personal AI system, while the backend runs as a shared, policy-driven, multi-tenant agent fabric. That is the architecture that can support India-scale adoption.