Whether you're looking for an angel investor, a growth advisor, or just want to connect — I'm always open to great ideas.
Get in TouchDapr Agents v1.0 reaches general availability with CNCF endorsement — bringing cloud-native patterns like service discovery, state management, and pub/sub messaging to AI agent orchestration at enterprise scale.
AI, startups & growth insights. No spam.
TL;DR: Dapr Agents v1.0 has reached general availability with official CNCF endorsement, bringing proven cloud-native infrastructure patterns — service discovery, distributed state management, and pub/sub messaging — directly to AI agent orchestration. For engineering teams that have struggled to run multi-agent systems reliably in production, this is the missing infrastructure layer the ecosystem has been waiting for.
AI agents are no longer a research curiosity. Engineering teams at companies of every size are shipping autonomous systems that call tools, make decisions, spawn sub-agents, and coordinate long-running workflows — often across dozens of microservices running in Kubernetes clusters that were never designed with agents in mind.
The gap between "agent demo that works on a laptop" and "agent system that stays up in production" has been the defining problem of the agentic AI era. Most frameworks solve the cognitive layer — how agents reason, plan, and use tools — but leave infrastructure entirely to the developer. That means every team reinvents the same distributed systems wheel: how do agents discover each other? Where does state live between turns? How do you fan out work across a pool of specialized agents without losing messages?
Dapr Agents v1.0, now generally available, is the first major framework built from the ground up to answer those questions using patterns the distributed systems community has been refining for over a decade.
Dapr (Distributed Application Runtime) has been a CNCF incubating project since 2021, widely adopted as a sidecar runtime that gives microservices portable APIs for state stores, pub/sub brokers, service invocation, secrets, and observability — regardless of which underlying infrastructure a team uses. The same Redis instance, Kafka topic, or Azure Service Bus that your existing services already rely on can now be the backbone of your agent communication and memory without any additional code.
Dapr Agents v1.0 extends this model to AI. Agents are first-class citizens in the Dapr runtime. They get addresses, they participate in the pub/sub topology, they store and retrieve state through the same Dapr state API your other services use, and they are observable through the same distributed tracing pipeline. The result is that agents stop being a special, fragile thing bolted onto the side of a Kubernetes cluster and become just another well-behaved microservice that happens to use an LLM for decision-making.
That shift in framing is the real headline. v1.0 GA is not just a stability stamp — it is a declaration that production-grade agent infrastructure is a solved problem when you build on top of the right primitives.
To understand why Dapr Agents matters, it helps to look at the specific failure modes that kill agent systems in production and see how cloud-native patterns address each one.
The state persistence problem. Most agent frameworks keep conversational memory and task state in Python dictionaries or SQLite files that live on a single process. When that process restarts — because of a deployment, a crash, or Kubernetes evicting a pod — state is lost. Users have to start over. Long-running tasks silently fail. Dapr Agents solves this by routing all state through the Dapr State Management API, which is backed by whatever durable store your cluster already uses: Redis, PostgreSQL, Cosmos DB, DynamoDB, and over thirty other pluggable components. State is external to the agent process by default, not an afterthought.
The coordination problem. When you have multiple specialized agents that need to hand work to each other — a planning agent that delegates to a research agent that delegates to a writing agent — you need a reliable message delivery mechanism. HTTP calls between pods fail silently when a pod is temporarily unavailable. Dapr's pub/sub API gives agents a topic-based messaging layer backed by a real message broker (Kafka, RabbitMQ, Azure Service Bus, etc.), with at-least-once delivery guarantees, dead-letter handling, and back-pressure support built in.
The discovery problem. How does a planning agent know where to find the research agent? In most frameworks, agents are hardcoded to call specific URLs or are tightly coupled inside a single process. Dapr's service invocation API provides location-transparent addressing: agents call each other by logical name, and Dapr handles service discovery, load balancing across replicas, and mTLS encryption automatically.
The observability problem. When an agent system misbehaves in production, you need to trace the exact sequence of decisions, tool calls, and inter-agent messages that led to the bad outcome. Because Dapr instruments every service invocation and pub/sub event with W3C Trace Context headers, agent interactions automatically appear in your existing distributed tracing system — Jaeger, Zipkin, Datadog, or any OpenTelemetry-compatible backend — with no extra code.
The scalability problem. A single agent process handling all requests is a bottleneck and a single point of failure. Because Dapr Agents are addressable microservices, you can run multiple replicas of any agent type behind a load balancer, scale them independently based on queue depth, and apply the same autoscaling logic you already use for your other services.
These are not novel problems that Dapr invented solutions to. They are the canonical problems of distributed systems, and cloud-native infrastructure has robust answers for all of them. Dapr Agents v1.0 is the bridge that makes those answers available to AI teams without requiring them to become distributed systems experts from scratch.
The CNCF endorsement of Dapr Agents is significant beyond the marketing value. The Cloud Native Computing Foundation is the organizational home of Kubernetes, Prometheus, Envoy, Helm, and the majority of the production infrastructure that runs modern enterprise software. When a project earns CNCF backing, it signals a few concrete things.
First, governance. CNCF projects are required to maintain a vendor-neutral governance model with a Technical Steering Committee, public roadmaps, and contribution processes that are not controlled by a single company. For enterprise buyers evaluating AI infrastructure, this matters enormously — they are not betting on a startup's continued investment in an open-source project.
Second, ecosystem compatibility. CNCF projects are designed to compose with the rest of the CNCF ecosystem. Dapr Agents' integration with Kubernetes, Prometheus metrics, OpenTelemetry traces, and standard Helm charts for deployment is not coincidental — it is a design requirement of operating within the CNCF ecosystem.
Third, longevity signal. CNCF graduation (the next step above incubation for Dapr itself) requires demonstrated production adoption, a healthy contributor base, and a security audit. The endorsement of Dapr Agents signals that the foundation expects this project to follow the same trajectory.
For enterprise AI teams navigating a crowded and rapidly shifting agent framework market, the CNCF provenance of Dapr Agents is one of the few external validation signals that carries real weight. It suggests that the infrastructure patterns here are ones you can commit to for a multi-year horizon — which is the timescale that matters when you are building production systems.
The agent framework landscape is genuinely crowded, and understanding where Dapr Agents fits requires a clear-eyed comparison with the alternatives. See our full breakdown in AI agent frameworks compared, but here is the critical distinction.
LangGraph is a graph-based orchestration framework from LangChain that models agent workflows as stateful directed graphs. It excels at complex, branching reasoning workflows with conditional edges and human-in-the-loop checkpoints. Its state management is more sophisticated than most frameworks, supporting configurable persistence backends. However, it remains primarily a Python library — deployment, scaling, and inter-service communication are left to the developer.
CrewAI focuses on role-based multi-agent systems where agents are assigned distinct personas and collaborate toward shared goals. It is optimized for ease of use and rapid prototyping. Production deployment is an unsolved problem that CrewAI explicitly delegates to the infrastructure layer.
OpenAI Agents SDK (formerly Swarm) is OpenAI's first-party framework for building agent systems on top of the OpenAI API. It is elegant, well-documented, and naturally optimized for GPT-4o and o3 models. Its primary constraint is the tight coupling to OpenAI's API — teams using other LLM providers need adapter layers.
Dapr Agents occupies a different layer entirely. It is not competing with LangGraph's graph-based reasoning model or CrewAI's role-based collaboration patterns — you could build either of those on top of Dapr Agents' infrastructure primitives. The framework is LLM-agnostic by design, using a standard interface that works with OpenAI, Anthropic, Google Gemini, local models via Ollama, and any provider that exposes an OpenAI-compatible API.
The honest framing is that LangGraph, CrewAI, and OpenAI Agents SDK solve the cognitive layer problem — how agents think and coordinate at the application logic level. Dapr Agents solves the infrastructure layer problem — how agents run reliably at scale in production. For teams building serious production systems, these are complementary concerns rather than competing ones, and the Dapr Agents team has explicitly designed the framework to be composable with existing cognitive-layer frameworks.
Let's go deeper on the three core Dapr primitives and how they translate to concrete agent capabilities.
Service Discovery via Dapr Service Invocation
In a Dapr-enabled Kubernetes cluster, every agent registers with a logical name. When a planning agent needs to delegate a research task, it calls the Dapr sidecar with the target agent's logical name and the method to invoke. Dapr's control plane — backed by the mDNS or Kubernetes service resolution depending on your environment — resolves the current location of the target agent's pod, handles load balancing if multiple replicas are running, and delivers the call with automatic retry on transient failures.
This means your agent code never contains IP addresses, port numbers, or environment-specific service URLs. The same agent code that runs in local development with Dapr's self-hosted mode runs in production on Kubernetes with zero changes. Infrastructure portability is a first-class property, not a deployment concern you solve at the end.
State Management
Dapr Agents exposes a unified state API that abstracts the underlying store. Your agent can save and retrieve state with simple key-value calls through the Dapr sidecar, and the actual storage backend — Redis Cluster, PostgreSQL, Azure Cosmos DB, AWS DynamoDB — is configured in a Dapr Component YAML file that lives outside the agent code.
For multi-turn conversational agents, this means conversational history, task progress, and intermediate tool call results are automatically durable. For long-horizon agentic workflows that may run for hours or days — the kind of autonomous research or code generation tasks where persistence is critical — state management is not something you bolt on later; it is part of the foundation.
Dapr also supports state store transactions and optimistic concurrency control, which matters when multiple agent replicas might be reading and writing the same state simultaneously.
Pub/Sub Messaging
The pub/sub model is where Dapr Agents becomes particularly compelling for multi-agent orchestration patterns. Rather than agents calling each other synchronously (which creates tight coupling and cascading failure modes), Dapr enables agents to communicate via topics.
A planning agent publishes a "research-requested" event to a topic. One or more research agents subscribed to that topic pick up the event, do the work, and publish a "research-completed" event to another topic. The planning agent receives that event and continues. If the research agent is temporarily unavailable, the message broker holds the event until the agent is ready — no message is lost, and the planning agent does not fail waiting.
This pattern scales horizontally without code changes: if you need more research throughput, you add replicas of the research agent, and the broker distributes messages across the pool automatically.
Dapr Agents is designed to feel like a native Kubernetes citizen, not a framework that Kubernetes happens to tolerate.
Agents are deployed as standard Kubernetes Deployments with the Dapr sidecar injected via the Dapr Operator — the same pattern used for any Dapr-enabled microservice. Scaling is handled by the Kubernetes Horizontal Pod Autoscaler based on CPU, memory, or custom metrics (like queue depth via KEDA, the Kubernetes Event-Driven Autoscaling project, which is also a CNCF project).
Dapr Components — the YAML configuration files that specify which Redis instance to use for state, which Kafka cluster to use for pub/sub, which secret store to read API keys from — are Kubernetes Custom Resources. This means your entire agent infrastructure configuration is version-controlled in Git, applied via standard kubectl or Helm, and auditable through your existing GitOps pipeline.
RBAC policies for which agents can access which state stores, which topics agents are allowed to publish to or subscribe from, and which external service bindings are available — all of this is expressed in Dapr authorization policies that integrate with Kubernetes RBAC and your existing identity infrastructure.
For enterprises that already run Kubernetes and have invested in CNCF tooling, the operational overhead of adding Dapr Agents is genuinely minimal. The agents look like any other workload from a platform engineering perspective, and the security and governance controls your security team requires already have expression in the Dapr model.
The contrast with agent frameworks that require specialized agent-specific infrastructure — custom orchestration services, proprietary state stores, bespoke deployment tooling — is stark. See also how NVIDIA NemoClaw enterprise agents approached similar enterprise deployment challenges with a different architectural philosophy.
Here is the minimal path to running your first Dapr Agent in a local environment.
Prerequisites: Docker Desktop (with Kubernetes enabled) or a local k3s cluster, the Dapr CLI, and Python 3.11 or later.
Step 1: Initialize Dapr
dapr initThis installs the Dapr control plane components locally and sets up a Redis container for state and pub/sub by default.
Step 2: Install the Dapr Agents SDK
pip install dapr-agentsStep 3: Define your agent
from dapr_agents import Agent, tool
@tool
def search_web(query: str) -> str:
"""Search the web for current information."""
# your search implementation here
return f"Results for: {query}"
agent = Agent(
name="research-agent",
model="openai/gpt-4o",
tools=[search_web],
system_prompt="You are a research assistant. Use tools to find accurate information."
)Step 4: Run with the Dapr sidecar
dapr run --app-id research-agent --app-port 8001 -- python agent.pyThe --app-id flag is the logical name other agents and services use to discover this agent. Dapr handles everything else.
Step 5: Invoke from another service
From any other Dapr-enabled service or agent, invoke the research agent by its logical name:
from dapr.clients import DaprClient
with DaprClient() as client:
result = client.invoke_method(
app_id="research-agent",
method_name="run",
data=b'{"task": "What are the latest developments in quantum computing?"}',
content_type="application/json"
)From here, adding state persistence, pub/sub communication, and Kubernetes deployment follows the standard Dapr patterns with minimal additional code. The Dapr Agents documentation includes ready-to-use Helm charts and example multi-agent workflow configurations for common patterns including supervisor-worker hierarchies, peer-to-peer agent collaboration, and event-driven agent pipelines.
The agent framework market is at an inflection point. The first wave of frameworks — LangChain, AutoGPT, early CrewAI — solved the "can we get agents to do things at all" problem. The second wave, where we are now, is solving the "can we run agents reliably at scale" problem.
Every engineering team that has tried to take an agent system from prototype to production has hit the same wall: the framework that made the demo fast to build is not the framework that makes the system maintainable and observable at scale. State management becomes a fire drill. Inter-agent communication breaks under load. Debugging a multi-agent failure in production is a nightmare when there are no distributed traces.
Cloud-native infrastructure patterns are the right answer to these problems because they have already been battle-tested at scale across thousands of production systems. The distributed systems community spent the last decade solving exactly these problems for microservices, and those solutions — Kubernetes-native deployment, service meshes, message brokers, distributed tracing, GitOps — are robust and well-understood.
Dapr's contribution has been to make those patterns accessible to application developers without requiring deep distributed systems expertise. Dapr Agents extends that contribution to AI teams. The result is a framework where the operational complexity of running agents in production is absorbed by infrastructure with a proven track record, leaving your engineering team to focus on the domain problems that actually differentiate your product.
The CNCF endorsement suggests that the foundation expects cloud-native agent infrastructure to follow the same adoption trajectory as cloud-native application infrastructure. If that trajectory holds, the teams that invest in these patterns now will be building on a foundation that grows more capable and more supported over time, rather than betting on a framework that may not survive the coming consolidation in the AI tooling market.
For enterprise teams in particular — organizations where reliability requirements, security audits, vendor neutrality concerns, and multi-year infrastructure commitments are real constraints — Dapr Agents v1.0 may be the first agent framework that actually fits the way enterprise software engineering works.
Does Dapr Agents require Kubernetes, or can it run locally?
Dapr supports both a self-hosted mode for local development and a Kubernetes mode for production. In self-hosted mode, Dapr runs as a set of local processes and uses local Docker containers for state stores and message brokers. Your agent code is identical in both environments — only the Dapr Component configuration changes. This makes local development fast and the transition to Kubernetes deployment straightforward.
Can I use Dapr Agents with LLM providers other than OpenAI?
Yes. Dapr Agents uses a provider-agnostic LLM interface. Out of the box it supports OpenAI (GPT-4o, o3), Anthropic (Claude), Google (Gemini), and any provider exposing an OpenAI-compatible API endpoint — including local models via Ollama and vLLM. Switching providers is a configuration change, not a code change.
How does Dapr Agents handle long-running agent workflows that span hours or days?
Because all agent state is persisted externally via the Dapr State Management API, agent processes can be stopped and restarted without losing task progress. Dapr Agents supports a workflow continuation pattern where an agent can serialize its current task state, shut down, and resume from that state when relaunched. This is critical for workflows that exceed the typical lifetime of a pod in a Kubernetes cluster.
What does the migration path look like if we already have agents built on LangGraph or CrewAI?
Dapr Agents is designed as an infrastructure layer rather than a replacement for existing cognitive-layer frameworks. The recommended migration approach is additive: wrap your existing LangGraph or CrewAI agents in a Dapr-enabled service that handles the infrastructure concerns (state, messaging, discovery), while keeping your existing orchestration logic intact. Full framework replacement is not required to get the production reliability benefits.
Is Dapr Agents suitable for highly regulated industries with strict data residency requirements?
Yes. Because Dapr is backend-agnostic, you can configure it to use state stores and message brokers that run entirely within your own infrastructure — on-premises or in a specific cloud region. No agent state or message content needs to leave your controlled environment. The Dapr secrets management integration also means LLM API keys and other credentials are stored in your existing secrets management system (HashiCorp Vault, Kubernetes Secrets, Azure Key Vault, AWS Secrets Manager) rather than in agent configuration files.
Jensen Huang calls OpenClaw the most popular open-source project in history and announces NVIDIA OpenShell runtime plus the NemoClaw security stack — enabling enterprise-grade AI agents with a single command.
NVIDIA announces NemoClaw at GTC 2026 — an open-source enterprise AI agent platform that integrates with the Vera Rubin hardware stack, positioning NVIDIA as the full-stack agentic AI infrastructure provider.
Tesla unveils Digital Optimus — a software-based AI agent built with xAI that observes and replicates human computer interactions to automate complex office workflows, targeting September 2026 rollout.