docs: include future control tower integration

AGENTS.md

@@ -34,7 +34,8 @@ ecosystem through a unified interface for hosts, agents, and external systems.
 - `agenticlens` as a source of analysis, provenance, and workflow evidence
 - `agentic-chaos` as a source of resilience and degradation workflows
 - `agentic-sidecar` when supervised-decision capabilities need MCP exposure in
-  the future
+  the future. At the ecosystem-role level, Sidecar is the **SUPERVISE** layer,
+  while its concrete functionality spans both supervision and governance.
 
 ### Current Roadmap Focus
 
@@ -124,6 +125,9 @@ objects (`ListToolsResult`, `CallToolResult`, `ListResourcesResult`).
   usage.
 - When a roadmap item or milestone meaningfully changes status, update
   `README.md` and the roadmap document in the same change.
+- If that milestone or release changes the public ecosystem story, also update
+  the shared org-profile docs in the `.github` repository:
+  `profile/README.md` and, when relevant, `profile/ROADMAP.md`.
 - When work is packaged as a release-ready change, also update
   `pyproject.toml`, `src/deep_agentic_core_mcp/__init__.py`, and
   `CHANGELOG.md`.
@@ -146,6 +150,7 @@ not part of `check` itself so the default gate stays fast.
 
 1. Bump version in `pyproject.toml`, `src/deep_agentic_core_mcp/__init__.py`, and `CHANGELOG.md`
 2. Commit: `git commit -am "release: vX.Y.Z"`
-3. Tag: `git tag vX.Y.Z`
+3. Tag: create an annotated `vX.Y.Z` tag and use the latest `CHANGELOG.md`
+   release section as the tag description
 4. Push: `git push origin main --tags`
 5. Create a GitHub Release — the workflow publishes to PyPI and the MCP Registry

README.md

@@ -6,6 +6,7 @@ ecosystem. It is designed to expose a single MCP interface that combines:
 - `agenticlens` style workflow inspection, profiling, and analysis
 - `agentic-chaos` style resilience testing and fault-injection workflows
 - `agentic-sidecar` style supervision-readiness and module-surface discovery
+- future `agenticops-control-tower` style operator-facing control-plane access
 
 It sits above the **AI Operations Workflow Specification**, exposing a unified
 MCP-native control surface over the shared operational model used by the
@@ -24,11 +25,13 @@ libraries:
 - `agenticlens` remains the core profiling and analysis engine
 - `agentic-chaos` remains the core chaos and resilience engine
 - `agentic-sidecar` remains the core decision-supervision and governance engine
+- `agenticops-control-tower` remains the future operator-facing control plane
 - the `AI Operations Workflow Specification` remains the shared data contract
 - `deep-agentic-core-mcp` becomes the MCP-native interface that hosts can call
 
-That means MCP clients can connect once and access observability, chaos, and
-sidecar discovery capabilities through one server.
+That means MCP clients can connect once and access observability, chaos,
+sidecar discovery, and later Control Tower-aligned operations surfaces through
+one server.
 
 ## What This Server Should Eventually Do
 
@@ -39,6 +42,8 @@ Planned capability areas:
 - run controlled chaos experiments against target workflows
 - expose sidecar readiness and scaffold inventory while the upstream runtime
   is still under construction
+- eventually expose Control Tower inventory and operator-facing control
+  surfaces once that sibling package ships them
 - compare normal versus chaos runs
 - expose shared resources such as workflow schemas, run metadata, and saved
   reports
@@ -189,6 +194,9 @@ registry, `core.verify`) and Phase 3b (Agentic Chaos) are complete as of
   work landing first
 - **Phase 4 (Unified Workflows)** — joined observability + chaos workflows,
   incident/readiness reporting, a higher-level control surface
+- **Future Control Tower coordination** — once `agenticops-control-tower`
+  ships real control-plane APIs, MCP should expose those operator-facing
+  surfaces without reimplementing them here
 - **Phase 5/6** — PyPI + MCP Registry publishing, operational intelligence
   features
 

ROADMAP.md

@@ -45,6 +45,10 @@ status should explicitly account for upstream and downstream dependencies.
 - `ai-operations-spec`
   Provides the canonical artifact model and validation rules surfaced through
   `spec.*` tools and used as the ecosystem exchange contract.
+- `agenticops-control-tower`
+  Provides the future operator-facing control plane. Once that sibling package
+  ships real APIs, MCP should expose those surfaces as connectors rather than
+  reimplementing control-plane behavior locally.
 
 For roadmap work, distinguish:
 
@@ -87,6 +91,8 @@ The product boundary should mirror the PyPI ecosystem:
 - `agenticlens` observes, evaluates, explains, and recommends
 - `agentic-chaos` injects, validates, tests, and proves resilience
 - `agentic-sidecar` governs, challenges, and escalates agent decisions
+- `agenticops-control-tower` operates the deployed ecosystem through a control
+  plane
 - `deep-agentic-core-mcp` exposes those capabilities through one MCP-native
   control surface