KaryaFlow
Architecture

One platform. Five layers. Zero glue.

How KaryaFlow is built: a shared record layer, an event-driven workflow graph, an AI agent runtime, a modular UI surface, and a typed developer platform.

The stack

One operating system, built in layers.

Each layer exposes the layer below it through a typed interface. You can swap a layer; you cannot replace the contract that holds it together.

Layer L1

Shared record layer

One data model across every module. Accounts, contacts, deals, tickets, jobs, knowledge — every record is typed, indexed, and addressable through the same query surface.

  • Postgres-compatible primary store
  • Row-level multi-tenancy isolation
  • Per-tenant customer-managed keys
  • Read replicas for analytics
Layer L2

Event & workflow graph

Every record change emits an event. A type-safe workflow DSL lets you compose automation across modules without writing glue code.

  • At-least-once event bus with replay
  • Step DSL with retries, parallelism, and idempotency
  • Cross-module triggers (no Zapier tax)
  • Audit log with full re-derivation
Layer L3

AI agent runtime

Agents share the same memory, the same permissions, and the same audit log as the humans on the team. No black boxes, no chat-only sandboxes.

  • Shared memory across agents and humans
  • Scoped permissions per agent role
  • Revertable, explainable actions
  • Token & cost budget per agent
Layer L4

Module surface

CRM, Sales, Marketing, Support, HR, Knowledge, Voice AI, Analytics. Each module is a typed view of the same record layer — not a separate product.

  • One identity, one permissions graph
  • Cross-module reporting without ETL
  • Modules are removable — the OS stays
  • Same record schema across web, mobile, voice
Layer L5

Developer platform

Everything the UI can do, your code can do. Typed SDKs, REST + GraphQL, signed webhooks, a CLI, and a public OpenAPI spec.

  • Typed SDKs: TypeScript, Python, Go
  • REST + GraphQL with stable cursor pagination
  • HMAC-signed webhooks with replay protection
  • Local CLI for migrations and seed data
Cross-cutting concerns

The platform-wide guarantees.

Multi-tenancy, regional residency, integration surface, and observability are not features. They are properties of the platform that every module inherits.

Multi-tenant by default

Every customer runs on isolated infrastructure, with row-level security, dedicated encryption keys, and per-tenant rate limits. Cross-tenant anything is impossible by construction.

Multi-region

Active-active in three regions, with regional data residency for EU, US, and APAC customers. Failover is automatic, recovery is measured in seconds.

Open integration

REST, GraphQL, signed webhooks, CLI, and a public OpenAPI spec. The platform is a product. Integration is not a side feature.

Observable end-to-end

Every agent action, every workflow transition, every API call is logged with the same correlation id. The debug surface is the audit log.

Developer platform

The architecture is the developer surface.

Every layer above is exposed to your code. Typed SDKs in TypeScript and Python, a REST + GraphQL API with cursor pagination, signed webhooks with replay protection, and a CLI that does the work your scripts would otherwise do.

// List contacts created this week
const contacts = await karya.contacts.list({
  filter: {
    createdAt: { gte: oneWeekAgo() },
  },
  sort: "-createdAt",
  limit: 50,
});

// Trigger an agent on the same record
await karya.agents.run("qualify-lead", {
  contactId: contacts[0].id,
  playbook: "inbound-demo",
});
Build on it

Ship the operating system on day one.

The platform is a product. The architecture is the API. Whatever the UI can do, your code can do — and the contracts don't change under you.