DeepAgentLabs builds open operational infrastructure for production AI systems.

• Ecosystem roadmap: ROADMAP.md

The ecosystem can be communicated in six words:

AgenticLens

Understand what agents are doing.

Agentic-Sidecar

Supervise decisions, intent, risk, and policy.

Agentic-Chaos

Validate how agents behave under failure.

Agentic MCP

Provide AI-native access to every DeepAgentLabs capability, including Control Tower.

DeepAgent Control Tower

Discover, configure, manage, and control the ecosystem from one place.

AI Operations Specification

Provide common operational concepts, contracts, and semantics.

The AI Operations Specification is the center of gravity for the ecosystem. It is a language-neutral, versioned operational model for production AI systems.

It defines the shared contract for:

• AI runtime objects such as Workflow, Request, Agent, LLM, Prompt, Context, RAG, Memory, Tool, Evaluation, and Incident
• AI-native semantic events such as workflow.started, agent.step, and llm.call
• workflow artifacts such as workflow.json
• schema validation
• evaluation and incident interoperability
• resilience and degradation evidence
• future extensions across tools and frameworks

This repository contains the specification itself: written rules, versioning guidance, schemas, examples, and extension conventions.

The observability, evaluation, and operational intelligence layer. It helps developers understand what ran, what the model and agent did, what context and tools were involved, what it cost, and whether the output was reliable, safe, and improving over time.

AgenticLens is built around a simple idea:

instrument the AI runtime once, export everywhere

AgenticLens is the flagship Python reference implementation of the AI Operations Specification.

pip install agenticlens

The resilience and failure-validation layer. It deliberately breaks AI workflows so teams can test reliability, recovery, fault tolerance, degraded behavior, and failure impact before production incidents do it for them.

Agentic Chaos produces resilience and degradation artifacts that remain compatible with the shared specification.

pip install agentic-chaos

The unified MCP control surface. It exposes the shared operational model and the capabilities of the ecosystem through one interface for hosts, agents, and external systems. Today that includes AgenticLens workflows, Agentic Chaos experiments, and Agentic Sidecar discovery/readiness surfaces, with deeper sidecar control flows landing as the sidecar runtime ships.

pip install deep-agentic-core-mcp

The decision-supervision layer for autonomous AI agents. It is designed to work alongside any agent framework to preserve user intent, evaluate risky or off-scope actions before they happen, and escalate to a human when needed.

pip install agentic-sidecar

The unified control plane and operations console for the ecosystem. It is the operator-facing layer that centralizes agent inventory, capability discovery, health visibility, configuration, and eventually multi-agent operational actions across deployed DeepAgentLabs capabilities.

Today it is still concept / pre-implementation work: the repo defines the control-plane boundary, package role, and phased build order before a real API, CLI, or console ships.

pip install agenticops-control-tower

At the center of the ecosystem is the AI Operations Specification.

It is not owned by a single package. DeepAgentLabs defines and stewards the specification so multiple tools can share one operational contract.

This turns workflow.json into a first-class artifact rather than an internal implementation detail, with workflow.schema.json and written specification documents defining the contract around it.

The specification is best understood as a shared model of AI runtime objects and semantic events, not as a giant flat list of metrics.

Telemetry is not itself a runtime object. It is a downstream export layer built on top of the shared runtime model.

All ecosystem tools are aligned around the AI Operations Specification as the canonical operational model for production AI systems.

• Spec repo: ai-operations-spec

The ecosystem serves as an open operational framework for production AI systems, similar in spirit to OpenTelemetry but purpose-built for AI systems and agentic workflows. It makes applications observable, testable, and manageable through a structured, shared data model.

At a high level, the ecosystem is organized around a simple split:

• agenticlens answers: what happened, why it happened, what it cost, and whether the system performed well
• agentic-chaos answers: what breaks under stress, how badly it breaks, and whether recovery actually works
• agentic-sidecar answers: is the agent's next action still aligned with user intent, and should it proceed, replan, or escalate
• ai-operations-spec defines the shared contract
• deep-agentic-core-mcp exposes the ecosystem through one MCP-native interface, starting with Lens, Chaos, and Sidecar-aligned surfaces
• agenticops-control-tower answers: what is deployed, where it is running, which capabilities are enabled, what is unhealthy, and how operators manage it from one place

The MCP server and AgenticLens have already delivered sessions, provenance, and verification. The ecosystem is now building toward structured resilience reports and specification-level provenance/conformance as the next foundation layer:

The build order is intentional: MCP server foundations → agenticlens evidence model → agentic-chaos structured reports → sidecar runtime → control-tower registry/discovery → spec formalization of proven patterns.

Each package is independently installable and useful on its own. They compose through the shared specification rather than hard-coded dependencies.

• Architecture-first: the ecosystem is organized around one shared operational model and specification.
• Specification-first: the AI Operations Specification should evolve before package-specific abstractions drift apart.
• Package-first: core capabilities ship as installable Python packages.
• Local-first: artifacts work in local development and CI without a hosted backend.
• Framework-agnostic: the operational model stays broader than any one SDK.
• Composable by default: one shared specification, multiple reference implementations.