Post

Dapr (Distributed Application Runtime)

A portable, event-driven runtime that simplifies building resilient microservices and AI agent systems on Kubernetes through a sidecar architecture with pluggable building blocks for state, pub/sub, service invocation, and bindings.

Posted
By
6 min read
Dapr (Distributed Application Runtime)

A portable, event-driven runtime that simplifies building resilient microservices and AI agent systems on Kubernetes through a sidecar architecture with pluggable building blocks for state, pub/sub, service invocation, and bindings.

Why Dapr Matters for AI Systems

Building AI agent systems in production means dealing with the same distributed systems problems as any microservice architecture – service discovery, state management, async messaging, retries, observability – plus AI-specific concerns like model routing, tool invocation, and agent-to-agent communication. Dapr abstracts the infrastructure plumbing so your agent code stays clean and portable across clouds.

The key insight: Dapr is not an AI framework. It is infrastructure middleware that happens to solve many of the exact problems AI agent orchestration faces. If you are deploying agents as microservices on Kubernetes, Dapr eliminates a significant amount of boilerplate.

Architecture

Sidecar Pattern

Dapr runs as a sidecar container (daprd) alongside your application container in the same Kubernetes pod. Your app communicates with Dapr over localhost HTTP or gRPC. Dapr handles all external communication.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

+--------------------------------------------------+
|  Kubernetes Pod                                   |
|  +--------------+     +----------------------+   |
|  |  Your App     |---->|  Dapr Sidecar (daprd)|   |
|  |  (Agent Code) |<----|  localhost:3500      |   |
|  +--------------+     +----------+-----------+   |
|                                  |                |
+----------------------------------+----------------+
                                   |
                    +--------------+---------------+
                    |              |               |
               +----v----+  +-----v----+  +-------v----+
               |  Redis   |  |  Kafka   |  |  CosmosDB  |
               |  (State) |  |  (PubSub)|  |  (State)   |
               +----------+  +----------+  +------------+

This is powerful because your agent code never imports Redis, Kafka, or cloud-specific SDKs. You call Dapr’s API, and Dapr handles the backend. Swap Redis for Cosmos DB by changing a YAML component spec, not your code.

Control Plane Components

On Kubernetes, Dapr installs four system services:

Component Role
dapr-operator Manages Dapr component CRDs and sidecar injection
dapr-sidecar-injector Injects daprd sidecar into annotated pods
dapr-placement Hash-consistent placement for virtual actors
dapr-sentry mTLS certificate authority for service-to-service encryption

Building Blocks

Dapr provides eight building blocks, each with a stable HTTP/gRPC API and pluggable backend components.

1. Service Invocation

Direct service-to-service calls with automatic mTLS, retries, and distributed tracing. For agent systems, this is how Agent A calls Agent B.

1
2
3
4

# Agent A invokes Agent B's /process endpoint
curl http://localhost:3500/v1.0/invoke/agent-b/method/process \
  -H "Content-Type: application/json" \
  -d '{"task": "summarize", "context": "..."}'

Built-in service discovery via Kubernetes DNS – no need for a separate service mesh for basic scenarios.

2. State Management

Key-value state with concurrency control (ETags), transactions, and TTL. Backed by 25+ state stores (Redis, PostgreSQL, CosmosDB, DynamoDB, etc.).

For AI agents: store conversation history, agent memory, tool execution results, session state.

1
2
3

# Save agent state
curl -X POST http://localhost:3500/v1.0/state/statestore \
  -d '[{"key": "agent-session-123", "value": {"history": [], "step": 3}}]'

3. Pub/Sub Messaging

Async event-driven communication between services. Critical for agent-to-agent communication where you do not want blocking calls.

1
2
3

# Publish an event (agent completed a subtask)
curl -X POST http://localhost:3500/v1.0/publish/pubsub/task-completed \
  -d '{"agentId": "research-agent", "result": "...", "taskId": "t-42"}'

Subscribe declaratively in a component YAML or programmatically. Supports at-least-once delivery, dead letter queues, and message TTL.

4. Bindings (Input/Output)

Connect to external systems (databases, queues, SaaS APIs, cron schedules) without importing their SDKs. Input bindings trigger your app; output bindings let your app push data out.

For AI agents: trigger agent execution on a schedule (cron binding), read from an S3 bucket (AWS S3 binding), send results to Slack (Slack binding).

5. Actors (Virtual Actors)

Stateful, single-threaded units of computation. The runtime handles activation, deactivation, and placement across the cluster. Based on the Orleans virtual actor model.

For AI agents: model each agent instance as an actor. The runtime guarantees single-threaded execution per actor, eliminating concurrency bugs in stateful agent logic. Actors can set reminders and timers for delayed execution.

1
2
3
4

Agent Actor "research-42"
  +-- State: {task, memory, step, tools_used}
  +-- Methods: process(), use_tool(), reflect()
  +-- Timers: timeout after 5 min if no progress

6. Other Building Blocks

  • Secrets Management – read secrets from Kubernetes secrets, Vault, AWS Secrets Manager, Azure Key Vault
  • Configuration – dynamic app configuration with change subscriptions
  • Distributed Lock – coordinate exclusive access across agent instances
  • Workflows – durable, long-running workflows with compensation (added in Dapr 1.10+)

Dapr for AI Agent Orchestration

Pattern: Multi-Agent System on Kubernetes

1
2
3
4
5
6
7
8
9
10

+--------------+    pub/sub     +--------------+
| Orchestrator  |-------------->| Research      |
| Agent + Dapr  |               | Agent + Dapr  |
+------+--------+               +------+--------+
       | invoke                        | state
       v                              v
+--------------+               +--------------+
| Writer        |               | Redis /      |
| Agent + Dapr  |               | PostgreSQL   |
+---------------+               +--------------+
  • Orchestrator agent decomposes tasks and publishes subtasks via pub/sub
  • Worker agents subscribe to topics, execute, store intermediate results in state store
  • Service invocation for synchronous tool calls (e.g., agent calls a retrieval service)
  • Actors for stateful agents that need guaranteed single-threaded execution
  • Workflows for multi-step pipelines with retries and compensation

What Dapr Does NOT Do

Dapr is infrastructure, not an AI framework. It does not provide:

  • LLM API abstractions or prompt management
  • Agent reasoning loops (ReAct, chain-of-thought)
  • Tool/function-calling schemas
  • Model routing or load balancing to GPU inference endpoints
  • Evaluation or guardrails

You still need an agent framework (LangGraph, CrewAI, Semantic Kernel, etc.) for the AI logic. Dapr handles the distributed systems layer underneath.

Kubernetes Deployment

Installation

1
2
3
4
5
6
7
8
9

# Install Dapr CLI
curl -fsSL https://raw.githubusercontent.com/dapr/cli/master/install/install.sh | bash

# Install Dapr on Kubernetes (Helm-based)
dapr init -k --runtime-version 1.14

# Or via Helm directly
helm repo add dapr https://dapr.github.io/helm-charts/
helm install dapr dapr/dapr --namespace dapr-system --create-namespace

Annotate Pods for Sidecar Injection

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

apiVersion: apps/v1
kind: Deployment
metadata:
  name: research-agent
spec:
  template:
    metadata:
      annotations:
        dapr.io/enabled: "true"
        dapr.io/app-id: "research-agent"
        dapr.io/app-port: "8080"
        dapr.io/log-level: "info"
    spec:
      containers:
      - name: agent
        image: myregistry/research-agent:v1
        ports:
        - containerPort: 8080

Resource Overhead

The Dapr sidecar adds roughly 50-100 MB of memory and minimal CPU per pod. For GPU-heavy inference pods where every MB matters, evaluate whether the tradeoff is worth it versus using Dapr only on orchestration/coordination pods.

When to Use Dapr

Use Dapr when:

  • You are building multi-agent systems as Kubernetes microservices and want portable, SDK-agnostic infrastructure
  • You need async agent communication (pub/sub) without locking into Kafka/RabbitMQ/NATS directly
  • You want to swap state backends (Redis in dev, Cosmos DB in prod) without code changes
  • Your agents need durable workflows with retries and compensation
  • You want mTLS between services without a full Istio service mesh

Skip Dapr when:

  • You are running a single monolithic agent service – Dapr adds complexity for no gain
  • You are already deep in a service mesh (Istio/Linkerd) that covers your needs
  • Your AI system is purely batch/offline and does not need real-time service communication
  • You need sub-millisecond latency on every call – the sidecar adds ~1-2ms of overhead

References

  • Dapr documentation: https://docs.dapr.io
  • Dapr GitHub: https://github.com/dapr/dapr
  • CNCF incubating project page: https://www.cncf.io/projects/dapr/
  • Dapr Workflow documentation: https://docs.dapr.io/developing-applications/building-blocks/workflow/
  • Dapr Actors overview: https://docs.dapr.io/developing-applications/building-blocks/actors/
AI & Agents, AI Ops
system-design
This post is licensed under CC BY 4.0 by the author.