Python runtime for agentic applications

Build agentic software without mixing UI, tools, storage, and model wiring.

Democr.ai gives developers a runtime for modules, server-driven UI, AI providers, document ingestion, sandbox policies, and audit trails through one SDK boundary.

Read the architecture Explore extensibility

For application developers

Build feature modules in Python and YAML while the runtime handles routing, UI effects, provider access, and scoped persistence.

For AI runtime teams

Configure engines, extractors, knowledge stores, and runtime services outside feature code.

For controlled deployments

Keep extensions behind SDK boundaries with policy checks, task visibility, and observable execution paths.

Why it exists

Agentic applications need runtime layers, not scattered glue code.

A working prototype can be assembled quickly. A maintainable system also needs permissions, UI state, tool contracts, ingestion queues, provider configuration, and traceability. Democr.ai makes those concerns explicit runtime services.

Server-driven UI

Pages are described on the server and rendered by web or desktop clients. Actions return effects and stream incremental updates.

Extension boundary

Modules, engines, and extractors consume public SDK contracts instead of importing core internals.

Document-aware runtime

Uploads can flow through asynchronous extraction, full markdown, chunking, embedding retrieval, and knowledge graph traversal.

Model provider layer

Feature modules ask for objectives or configured models. Provider startup, warmup, and invocation are runtime responsibilities.

Sandbox and access policy

Extensions run behind import and access boundaries. A Python Process Guard is reinforced on Linux by kernel enforcement — Landlock, seccomp-BPF, and cgroup/iptables network egress.

Audit and runtime visibility

Actions, tasks, model calls, tool activity, and data mutations can be correlated into observable execution flows.

Runtime shape

One core, multiple clients, explicit extension points.

Client implementations stay renderers. Application behavior lives in modules and reaches platform services through the SDK.

Module authoring

Feature code stays small because the runtime owns the plumbing.

A module defines models, YAML UI, actions, tools, agents, and skills. It does not need to own frontend state management, direct model loading, media transport, or knowledge indexing.

modules/chat/utils/ui/yaml/index.yaml layout

- kind: Row
  id: chat_page
  stretch: true
  children:
    - kind: ThreadList
      id: chat_thread_list
      action:
        name: chat.open_thread
    - kind: MessageList
      id: chat_message_list
      capabilities:
        - messages.append
        - messages.replace
    - kind: Composer
      id: chat_composer
      send_action:
        name: chat.start_thread
        context:
          composer: chat_composer

modules/chat/actions/conversation.py behavior

@action("submit_message")
@permission_required(["chat.write"])
async def submit_message(ctx, session, module_sdk):
    turn = create_user_turn(module_sdk, ctx)
    stream_id = ctx["stream_id"]

    await module_sdk.effects.publish(
        stream_id,
        module_sdk.effects.ui_collection_append(
            "chat_message_list",
            "messages",
            message_row(turn["message"]),
        ),
    )

    await run_chat_orchestration(
        module_sdk,
        ctx,
        turn["conversation"],
        turn["message"],
    )

Local to distributed

Start with local providers, move services out by configuration.

Democr.ai is local-first, but the same runtime shape can point to external infrastructure when a deployment needs shared services or distributed workers.

Capability	Local setup	Distributed setup
Relational storage	SQLite for core and module data	Postgres or compatible managed database
Media	Local filesystem storage	S3-compatible object storage and optional public delivery endpoint
Knowledge graph	Ladybug local graph store	Neo4j-compatible graph backend
Vector retrieval	sqlite-vec	Milvus or Pinecone-style vector providers, certification varies by provider
Runtime coordination	In-process or local IPC services	Redis, TCP services, remote workers
Observability	SQLite-backed event and audit storage	Postgres, ClickHouse, and optional OTLP export, certification varies by provider

Data and state

SQLite PostgreSQL Redis

Knowledge and vectors

Ladybug Neo4j SQLite Milvus sqlite-vec

Media and observability

S3-compatible ClickHouse OTLP

Provider logos show implementation targets, not certification status. Pinecone and ClickHouse are implemented but still require validation through the current integration pass.

See implemented engines See ingestion pipeline Read configuration overview

System areas

What the runtime gives a developer.

These are the areas that usually become custom glue code in agentic applications. Democr.ai makes them explicit and reusable.

Modules

Application surfaces with models, YAML pages, actions, tools, agents, skills, and locales.

Engines

Installable providers for chat, reasoning, embedding, speech, vision, and local model runtimes.

Extractors

Installable document processors that convert uploads into markdown, chunks, and metadata.

Knowledge

Asynchronous ingestion with retrieval over embeddings, extracted markdown, and graph context.

Security

SDK boundaries, import checks, access policy, a Python Process Guard, and Linux kernel enforcement (Landlock, seccomp, cgroup/iptables egress).

Observability

Runtime task state, agent/tool progress, model calls, and audit trails for data mutations.

Project status

Built for developers who want agentic apps to remain inspectable.

Democr.ai is an active open-source runtime. The goal is not to hide complexity behind generated application code, but to put the common layers around agentic software in one place so feature modules stay understandable.

Architecture overview A2UI protocol Knowledge runtime