# Symbiont Roadmap
**Governance infrastructure for enterprise AI agents — from runtime to operations platform.**
---
## Release Timeline
| Version | Target | Headline | Status |
|---------|--------|----------|--------|
| **v1.0.0** | 2026-02-07 | Production scheduling, RAG, channels | Shipped |
| **v1.1.0** | 2026-02-12 | Security hardening, DSL diagnostics, admin UI (alpha) | Shipped |
| **v1.4.0** | 2026-02-15 | AgentSkills, CLI executor, persistent memory, webhook DX, metrics | Shipped |
| **v1.5.0** | 2026-02-22 | LanceDB, context compaction, Composio MCP, security hardening | Shipped |
| **v1.6.0** | 2026-02-27 | Agentic reasoning loop, knowledge bridge, ClawHavoc expansion | Shipped |
| **v1.6.1** | 2026-02-27 | qdrant-client version pin fix | Shipped |
| **v1.7.0** | 2026-03-08 | Standalone Agent SDK, External Agents, Binary Releases | **Current** |
| **v1.8.0** | Q2-Q3 2026 | A2A Protocol Integration (`symbi-a2a`) | Planning |
| **v1.9.0+** | 2027+ | Operations console (`symbi-a2ui` Phase 2) | Planning |
> **Note:** v1.2.0 (AgentSkills Security) and v1.3.0 (A2A) were originally planned as separate releases. AgentSkills shipped as part of v1.4.0 alongside persistent memory and webhook DX. LanceDB (originally v1.4.1) was merged into v1.5.0 alongside context compaction and Composio MCP integration. The agentic reasoning loop (originally part of v1.5.0 planning) shipped in v1.6.0 alongside the knowledge bridge and scanner expansion.
>
> **Reorder rationale (2026-03-01):** A2A (originally planned for v1.6.0) moves to v1.8.0. v1.7.0 is inserted to address **standalone agent developer experience** — a gap analysis revealed that while the reasoning loop and `ComposioToolExecutor` make it possible to build standalone agents (as demonstrated by the `symbi-examples/twitter-agent`), the experience requires deep internal knowledge, excessive boilerplate, and produces agents that are completely invisible to the coordinator. These DX and integration gaps must be closed before A2A adoption can succeed — A2A is a protocol for agent interop, but if building agents is hard, the protocol has nothing to connect.
---
## Vision
Enterprise AI agents require more than inference — they need governance infrastructure that ensures security, auditability, and operational control at every layer. The ThirdKey trust stack (SchemaPin for tool verification, AgentPin for cryptographic identity, Symbiont for runtime governance) provides this foundation. The next frontier is A2A (Agent-to-Agent) interoperability — Symbiont will be the first runtime to combine Google's A2A protocol with cryptographic identity verification and tool integrity checking, enabling verified multi-agent collaboration across organizational boundaries.
Symbiont v1.0.0 delivered a production-ready runtime with scheduling, RAG pipelines, channel routing, and policy enforcement. v1.1.0 hardened security with per-agent API keys, rate limiting, and sensitive parameter redaction, while shipping an alpha operations console. v1.4.0 shipped AgentSkills security, a universal CLI executor, persistent memory, webhook DX, and a pluggable metrics pipeline. v1.5.0 introduced LanceDB as the default embedded vector backend, context compaction for long-running agents, and Composio MCP integration. v1.6.0 shipped the agentic reasoning loop (ORGA cycle), knowledge bridge, and expanded ClawHavoc scanner coverage. This roadmap extends that foundation with a standalone agent SDK, external agent integration into the coordinator fleet, A2A protocol support for verified inter-agent communication, and a full-featured operations console.
---
## v1.0.0 — Shipped (2026-02-07)
| Capability | Details |
|------------|---------|
| Scheduling | Cron with session isolation, jitter, dead-letter queue, `CronMetrics` observability |
| RAG | Full pipeline — query analysis, retrieval, ranking (`RankingAlgorithm::Hybrid`), augmentation, validation |
| Routing | `AgentRoutingRule` with path-prefix, header, and JSON-field matching |
| HTTP Input | Configurable inbound sources with response control (`HttpInputConfig`) |
| Channels | `ChannelAdapter` trait — Slack, Teams, Discord, Email, SMS, Webhook |
| Security | `AccessLevel`-scoped documents, AgentPin JWT verification, zero-trust policy engine |
| Dev Tools | Symbi DSL, REPL, LSP server, tree-sitter grammar |
| SDKs | JavaScript (`@thirdkey/symbiont-sdk`) and Python (`symbiont-sdk`) |
See [CHANGELOG.md](CHANGELOG.md) for full release notes.
---
## v1.1.0 — Shipped (2026-02-12)
| Capability | Details |
|------------|---------|
| Security Hardening | Per-agent API keys (Argon2), rate limiting (governor), sensitive_params redaction, file locking, safe sandbox defaults |
| DSL Diagnostics | Structured `DslDiagnostic` type, humantime timeout parsing |
| Channel Adapter | jsonwebtoken v10 migration, Teams auth fix |
| Admin UI (Alpha) | `symbi-a2ui` Lit-based dashboard — fleet overview, compliance, audit trail panels (experimental, not published) |
See [CHANGELOG.md](CHANGELOG.md) for full release notes.
---
## v1.4.0 — Shipped (2026-02-15)
v1.4.0 is a major release bundling AgentSkills security, CLI executor, persistent memory, webhook DX, and production metrics. Originally planned as v1.2.0 (skills) and v1.4.0 (memory/webhooks), these were consolidated into a single release.
| Capability | Details |
|------------|---------|
| AgentSkills Security | `SkillLoader` — scan paths, parse SKILL.md frontmatter, verify SchemaPin signatures, yield `LoadedSkill`. `SkillScanner` — content scanning with ClawHavoc defense rules. `SkillsConfig` — `require_signed`, `allow_unsigned_from`, standard load paths. `symbi skills` CLI. |
| CLI Executor | Universal stdin-protected process runner (`CliExecutor`, `OutputWatchdog`, `StdinStrategy`). Feature-gated `cli-executor`. Adapters: `ClaudeCodeAdapter`, `AiderAdapter`, `CodexAdapter`. |
| Persistent Memory | `MarkdownMemoryStore` implementing `ContextPersistence` — Markdown-backed agent memory with Facts/Procedures/Learned Patterns sections, daily log append, retention-based compaction. DSL `memory` block with `humantime` parsing. REPL `:memory` command. |
| Webhook DX | `SignatureVerifier` trait — `HmacVerifier` (HMAC-SHA256, constant-time via `subtle`), `JwtVerifier` (HS256). `WebhookProvider` presets (GitHub, Stripe, Slack, Custom). DSL `webhook` block with filter. Wired into `HttpInputServer`. REPL `:webhook` command. |
| Production Metrics | Pluggable telemetry: OpenTelemetry OTLP (gRPC/HTTP) + atomic file JSON. Feature-gated `metrics`. `MetricsExporter` trait, `CompositeExporter`, 19 gauge instruments. |
| Routing Engine | `RoutingEngine` wired into `DefaultAgentScheduler` — policy evaluation (Deny/UseSLM/UseLLM) before task start, `RouteDecision` on `ScheduledTask`. |
| DSL Enhancements | `memory` and `webhook` top-level blocks, bare identifier values, short-form duration literals (`90d`, `6m`, `1y`). |
| Example Agents | `knowledge_curator.dsl` (memory block), `incident_tracker.dsl` (webhook + memory), updated `webhook_handler.dsl`. |
See [CHANGELOG.md](CHANGELOG.md) for full release notes.
---
## v1.5.0 — Shipped (2026-02-22)
v1.5.0 shipped LanceDB as the default embedded vector backend, context compaction (Tiers 1+4 OSS, Tiers 2+3 enterprise-gated), Composio MCP integration, and security hardening.
| Capability | Details |
|------------|---------|
| LanceDB Vector Backend | `VectorDb` trait abstraction. LanceDB as zero-config default. Qdrant optional behind `vector-qdrant` feature flag. Backend factory with env-var config. |
| Context Compaction | `TokenCounter` trait with tiktoken + heuristic. Tier 1 Summarize + Tier 4 Truncate (OSS). Tiers 2-3 enterprise-gated. `select_tier` pipeline, `check_and_compact` integration, `CompactionMetrics`. |
| Composio MCP | Feature-gated `composio` module — SSE-based connection to Composio MCP server for external tool access. |
| Security Hardening | 5 new structure-aware fuzz targets, API middleware hardening, TOCTOU fix, vault secret heuristic. |
| Cleanup | `SchemaPinCliWrapper` removed (native Rust), `MockLLMClient` test-only, `SlmExecutor` trait extraction, lock-free `RoutingStatistics`. |
See [CHANGELOG.md](CHANGELOG.md) for full release notes.
---
## v1.6.0 / v1.6.1 — Shipped (2026-02-27)
v1.6.0 shipped the agentic reasoning loop (ORGA cycle), knowledge bridge, ClawHavoc scanner expansion, and agent registry. v1.6.1 is a hotfix pinning `qdrant-client <1.16` to fix install breakage (v1.6.0 was yanked from crates.io).
| Capability | Details |
|------------|---------|
| Reasoning Loop | Typestate-enforced ORGA cycle (Observe-Reason-Gate-Act). `ReasoningLoopRunner` with `InferenceProvider`, `ReasoningPolicyGate`, `ActionExecutor` traits. Cloud + SLM providers. Cedar policy gate. Circuit breakers. Durable `BufferedJournal`. Human-in-the-loop critic. Multi-agent `AgentRegistry` + `Saga` patterns. Structured output validation. DSL builtins (`reason`, `llm_call`, `tool_call`, `delegate`). |
| Knowledge Bridge | `KnowledgeBridge` connecting context memory to reasoning loop. `recall_knowledge` + `store_knowledge` LLM-callable tools. `KnowledgeAwareExecutor` wrapper. Post-loop auto-persist. |
| ClawHavoc Expansion | 30 new rules across 7 categories (reverse shells, credential harvesting, exfiltration, injection, escalation, traversal, downloaders). 5-level severity model. |
| Agent Registry | Persistent `AgentRegistry` with delete and re-execute lifecycle. |
| Infrastructure | Docker cargo-chef caching, 6 new fuzz targets (18 total), performance benchmarks. |
See [CHANGELOG.md](CHANGELOG.md) for full release notes.
---
## v1.7.0 — Standalone Agent SDK & External Agent Integration (Q2 2026)
v1.7.0 closes the gap between the runtime's powerful internals and the experience of building standalone agents that integrate with the coordinator fleet. Today, creating a standalone agent (like the `symbi-examples/twitter-agent`) requires 12 imports from 8 modules, 7 mandatory struct fields with no builder, manual tool filtering, a custom `#[async_trait]` policy gate implementation, and produces an agent that is completely invisible to the coordinator. v1.7.0 fixes this.
**Motivation:** The `twitter-agent` example proved that standalone agents built on `ReasoningLoopRunner` + `ComposioToolExecutor` work well — but the DX is hostile to external developers and the resulting agents have zero coordinator visibility. A2A (v1.8.0) will add inter-agent communication, but if standalone agents are hard to build and invisible to the fleet, there is nothing for A2A to connect.
### Phase 1: Runtime Developer Experience
Make it easy to construct and run a standalone reasoning agent.
| Item | Details |
|------|---------|
| **`ReasoningLoopRunner::builder()`** | Builder pattern with sensible defaults. Only `provider` and `executor` required. Defaults: `DefaultPolicyGate::permissive()`, `DefaultContextManager::default()`, `CircuitBreakerRegistry::default()`, `BufferedJournal::new(1000)`, `knowledge_bridge: None`. |
| **`ActionExecutor::tool_definitions()`** | Add `fn tool_definitions(&self) -> Vec<ToolDefinition>` to the `ActionExecutor` trait with a default empty impl. `ComposioToolExecutor` already has this — promote to trait level. Runner auto-populates `LoopConfig.tool_definitions` from executor when the config list is empty. |
| **`symbi_runtime::prelude`** | Re-export the ~15 types every standalone agent needs: `ReasoningLoopRunner`, `Conversation`, `ConversationMessage`, `MessageRole`, `LoopConfig`, `LoopResult`, `LoopDecision`, `LoopState`, `ProposedAction`, `Observation`, `InferenceProvider`, `ToolDefinition`, `ReasoningPolicyGate`, `BufferedJournal`, `DefaultContextManager`, `CircuitBreakerRegistry`, `CloudInferenceProvider`, `AgentId`. |
| **Feature flag cleanup** | Re-gate `CloudInferenceProvider` under a new `cloud-llm` feature (currently requires `http-input`, which is misleading). Re-gate `ComposioToolExecutor` under `composio` only (currently also requires `http-api`). Add a `standalone-agent` meta-feature that enables `cloud-llm` + `composio` — the one feature a standalone agent needs. |
| **`ToolFilterPolicyGate`** | Generic policy gate that restricts tool access by name whitelist. Replaces the need for every agent to hand-roll a custom `#[async_trait]` impl (as the twitter-agent does with `TwitterOnlyPolicyGate`). |
**Touchpoints:** `crates/runtime/src/reasoning/reasoning_loop.rs`, `crates/runtime/src/reasoning/executor.rs`, `crates/runtime/src/reasoning/mod.rs`, `crates/runtime/src/lib.rs` (prelude), `crates/runtime/Cargo.toml` (features), `crates/runtime/src/reasoning/policy_bridge.rs`
**After Phase 1, the twitter-agent becomes:**
```rust
use symbi_runtime::prelude::*;
use symbi_runtime::composio::{ComposioToolExecutor, SseTransport};
let provider = CloudInferenceProvider::from_env().unwrap();
let executor = ComposioToolExecutor::discover(transport).await?;
let runner = ReasoningLoopRunner::builder()
.provider(provider)
.executor(executor)
.policy_gate(ToolFilterPolicyGate::allow(&["TWITTER_CREATE_TWEET"]))
.build();
let result = runner.run(AgentId::new(), conversation, LoopConfig::default()).await;
```
### Phase 2: External Agent Integration
Make standalone agents visible to the coordinator fleet.
| Item | Details |
|------|---------|
| **`External` execution mode** | Add `External` variant to `ExecutionMode`. Extend `POST /api/v1/agents` to accept `{ name, execution_mode: "External", endpoint?, capabilities, metadata, agentpin_domain? }` without requiring a DSL source. The scheduler tracks the agent's existence without trying to run it. The optional `agentpin_domain` field enables the coordinator to fetch the agent's AgentPin identity via `WellKnownResolver` at registration time — not required for v1.7.0 but present in the schema so the upgrade path to A2A (v1.8.0) is smooth. |
| **`POST /api/v1/agents/{id}/heartbeat`** | New endpoint. Body: `{ state: AgentState, metadata?: HashMap<String,String>, last_result?: String }`. Updates the scheduler record, resets `last_activity`. Agents call this periodically (default 60s). If no heartbeat received within 3x the interval, coordinator marks the agent `Unreachable`. |
| **`POST /api/v1/agents/{id}/events`** | New endpoint. Body: `{ event_type: "run_started" | "run_completed" | "run_failed", payload: Value }`. Appends to the `ExecutionLog` ring buffer. The coordinator's `agent_status` tool includes recent events in its response, giving the LLM-powered coordinator full visibility into external agent activity. |
| **`AgentStatusResponse` extension** | Add `metadata: Option<HashMap<String,String>>` and `last_result: Option<String>` fields to `AgentStatusResponse`. Populated from heartbeat data for external agents. |
| **`CoordinatorExecutor` update** | Update `list_agents` and `agent_status` tool outputs to surface external agent data — state, last heartbeat time, recent events, and last result. The coordinator LLM can now answer "what did SymbiBot post last?" |
| **Health check pull** | For external agents with an `endpoint` URL, the coordinator can `GET {endpoint}/health` as a pull-based liveness probe. Optional — heartbeat is the primary mechanism. |
**New trait methods on `RuntimeApiProvider`:** `update_agent_heartbeat()`, `push_agent_event()`.
**Touchpoints:** `crates/runtime/src/types/agent.rs`, `crates/runtime/src/api/types.rs`, `crates/runtime/src/api/server.rs`, `crates/runtime/src/api/coordinator_executor.rs`, `crates/runtime/src/lib.rs`, `crates/runtime/src/scheduler/mod.rs`
**Design note — A2A forward-compatibility:** The heartbeat `state` field should use values compatible with A2A `TaskState` where possible. The events endpoint should structure payloads so they can later be backed by A2A `tasks/send`. When v1.8.0 ships, the heartbeat becomes a convenience wrapper over A2A, not a competing protocol.
### Phase 3: Documentation & Examples
| Item | Details |
|------|---------|
| **"How to Build a Standalone Agent" guide** | Prose documentation covering: (1) choosing an `InferenceProvider` (cloud vs SLM), (2) implementing `ActionExecutor` for custom tools, (3) configuring `ReasoningPolicyGate` (permissive, tool-filtered, Cedar), (4) setting `LoopConfig` (iterations, timeouts, token budgets), (5) parsing `LoopResult` for structured output, (6) registering with the coordinator via heartbeat/events APIs. |
| **Agent scaffold template** | `_template/` directory in `symbi-examples` with TODO markers. Or `cargo-generate` template. Minimal: Cargo.toml with correct features, main.rs skeleton with provider/executor/runner wiring, .env.example, README. |
| **`rest-api-agent/` example** | Standalone agent that implements `ActionExecutor` to call a REST API directly (no MCP/Composio). Shows the simplest possible custom tool integration. |
| **`coordinator-connected-agent/` example** | Standalone agent demonstrating heartbeat, status reporting, and event pushing to the coordinator. Template for any agent that needs fleet visibility. |
| **Update twitter-agent** | Refactor to use new builder, prelude, `ToolFilterPolicyGate`, and coordinator heartbeat. Becomes the canonical "complete example." |
| **SDK heartbeat clients** | Add heartbeat/events client to `symbiont-sdk-js` and `symbiont-sdk-python` so non-Rust agents can register with and report to the coordinator. Minimal surface: `client.agents.register()`, `client.agents.heartbeat()`, `client.agents.pushEvent()`. This is a prerequisite for JS/Python standalone agents to participate in the fleet, and for eventual A2A SDK support in v1.8.0+. |
### OSS / Enterprise Split
All v1.7.0 work is **OSS**. The standalone agent story is table-stakes developer experience — gating it would kill adoption of the entire agent ecosystem including A2A.
---
## v1.8.0 — A2A Protocol Integration (Q2-Q3 2026)
Symbiont becomes the first governance runtime with native A2A (Agent-to-Agent) protocol support, combining Google's interoperability standard with AgentPin cryptographic identity and SchemaPin tool verification. Every A2A interaction is policy-checked, identity-verified, and auditable.
**Foundation:** The reasoning loop (v1.6.0) provides the ORGA cycle. The standalone agent SDK (v1.7.0) provides builder patterns and coordinator integration. The CLI executor and AI tool adapters (v1.4.0) provide process orchestration. Context compaction (v1.5.0) ensures long-running A2A agents don't exhaust context windows.
**New crate:** `crates/symbi-a2a/`
**Dependency:** [`a2a-types`](https://crates.io/crates/a2a-types) v0.1.3 (MIT, ~1.3K SLoC) for protocol types. Transport and server logic built on Symbiont's existing Axum/tokio infrastructure.
### Phase 1: Core Types, AgentCard Serving & Agent Discovery
| Item | Details |
|------|---------|
| AgentCard serving | Serve `/.well-known/agent-card.json` per Symbiont-managed agent |
| Agent discovery | `AgentRegistry` — in-process registry for local agents + HTTP-based discovery for remote agents via `.well-known` fetch. `symbi a2a discover <url>` CLI. Agents resolve peers by domain/URL, with `DiscoveryCache` (already in AgentPin integration) for caching remote AgentCards |
| DSL mapping | Map DSL agent declarations to AgentCard fields (name, description, skills, capabilities) |
| Configuration | `[a2a]` config section in `symbi.toml` — `known_agents` list for pre-configured peers |
| CLI preview | `symbi a2a card --agent <name>` — preview generated AgentCard |
| Types | Depend on `a2a-types` for `AgentCard`, `Task`, `Message`, `Artifact`, `TaskState` |
| Push registration | `POST /api/v1/agents/register` accepts inline AgentCard JSON — push-based alternative to pull-based `.well-known` discovery for agents that don't run their own HTTP server (bridges v1.7.0's external agent model with A2A) |
**Touchpoints:** `crates/symbi-a2a/src/card.rs`, `crates/symbi-a2a/src/server.rs`, `crates/symbi-a2a/src/discovery.rs`
### Phase 2: Task Lifecycle, Remote Transport & Policy Engine
| Item | Details |
|------|---------|
| Remote transport | `A2aClient` — HTTP client for outbound A2A JSON-RPC calls to remote agents. Connection pooling, timeouts, retry with backoff. Bridges the in-process `CommunicationBus` to cross-network agent communication |
| Task manager | `A2aTaskManager` — task state machine (Submitted → Working → Input-Required → Completed/Failed/Canceled) |
| JSON-RPC handlers | `tasks/send`, `tasks/get`, `tasks/cancel` (inbound) |
| JSON-RPC client | `tasks/send` to remote agents (outbound) — agents can delegate tasks to discovered peers |
| Policy integration | Every state transition calls `PolicyEnforcementPoint::check_resource_access` |
| Message bridging | Bridge `a2a_types::Message` / `Part` to `SecureMessage` for internal routing |
| Error handling | Failed tasks → existing `DeadLetterQueue`; reuse governor rate limiter |
| Heartbeat bridge | v1.7.0 heartbeat/events endpoints backed by A2A task updates where applicable — external agents using REST heartbeat get A2A interop for free |
**Touchpoints:** `crates/symbi-a2a/src/task.rs`, `crates/symbi-a2a/src/rpc.rs`, `crates/symbi-a2a/src/client.rs`
### Phase 3: AgentPin-Verified AgentCards & DSL A2A Primitives
*The differentiator — cryptographic identity for A2A, plus DSL-native agent communication.*
| Item | Details |
|------|---------|
| AgentCard extensions | Extend AgentCard metadata with `agentpin_endpoint`, `public_key_jwk`, `agentpin_signature` |
| Auth middleware | `A2aAuthMiddleware` — extract AgentPin JWT from Authorization header, call `AgentPinVerifier` |
| Outbound auth | Attach AgentPin JWT as bearer token when sending tasks to remote agents |
| Capability mapping | Map AgentPin `Capability` to A2A `AgentSkill` |
| Trust policies | `A2aTrustPolicy`: `open` \| `agentpin-required` \| `mutual-auth-required` |
| DSL trust block | `a2a { trust: agentpin_required }` |
| DSL A2A functions | Wire `invoke_agent` and `message_passing` capabilities to DSL built-in functions: `send_task(agent_url, payload)` for delegating tasks to remote agents, `send_message(agent_id, data)` for direct messaging via `CommunicationBus`, `subscribe(topic, handler)` / `publish(topic, data)` for pub/sub, `discover_agent(url)` for runtime peer discovery. These map to the Phase 1 discovery and Phase 2 transport layers |
**Requires:** AgentPin v0.3.0
**Touchpoints:** `crates/symbi-a2a/src/auth.rs`, `crates/symbi-a2a/src/trust.rs`, `crates/dsl/src/builtins/a2a.rs`, `crates/repl-core/src/dsl/evaluator.rs`
### Phase 4: A2A ↔ MCP Bridge
| Item | Details |
|------|---------|
| Inbound bridge | Incoming A2A task triggers MCP tool invocation via `SecureMcpClient` |
| Result wrapping | Tool results wrapped as `a2a_types::Artifact` with `Part::Text` / `Part::Data` |
| Schema verification | SchemaPin verification still applies — tools invoked via A2A bridge are verified |
| Capability check | Caller's AgentPin capabilities must include the MCP tool's required capability |
| Design | Inspired by `a2a-rs` MCP bridge pattern (adapted, not adopted) |
**Requires:** SchemaPin v1.4.0
**Touchpoints:** `crates/symbi-a2a/src/bridge.rs`
### Phase 5: Streaming + Push Notifications
| Item | Details |
|------|---------|
| SSE streaming | `tasks/sendSubscribe` returning `TaskStatusUpdateEvent` and `TaskArtifactUpdateEvent` |
| Push notifications | `tasks/pushNotification/set` and `tasks/pushNotification/get` for webhook registration |
| Dashboard integration | Integration with `symbi-a2ui` dashboard via existing SSE infrastructure |
**Touchpoints:** `crates/symbi-a2a/src/stream.rs`, `crates/symbi-a2a/src/push.rs`
### Cross-Repo Dependencies
```
┌─────────────────┐
│ AgentPin v0.3 │ ←── Phase 3 depends on this
│ (A2A types) │
└────────┬────────┘
│
┌─────────────────┐ │ ┌─────────────────┐
│ SchemaPin v1.4 │──────────┼─────────→│ Symbiont v1.8 │
│ (cross-agent │ │ │ (symbi-a2a) │
│ tool trust) │──── Phase 4 ───────→│ │
└─────────────────┘ └─────────────────┘
```
- **Phases 1-2** can start immediately (no cross-repo deps)
- **AgentPin v0.3.0** should ship before Phase 3
- **SchemaPin v1.4.0** should ship before Phase 4
- **Phase 5** (streaming) is independent
---
## v1.9.0+ — `symbi-a2ui` Phase 2: Operations Console (2027+)
The `symbi-a2ui` alpha shipped in v1.1.0 with a Lit-based thin-client architecture, SSE transport, and three system-agent panels (fleet overview, compliance dashboard, audit trail explorer). Phase 2 extends the console into a full operations platform.
### New Panels & Capabilities
| Panel | Description |
|-------|-------------|
| Approval Workflows | Human-in-the-loop approval queues for sensitive agent actions |
| Policy Editor & Simulator | Edit policies in Symbi DSL with dry-run simulation against historical data |
| AgentPin Trust Map | Visual graph of agent identity chains, trust relationships, and delegation paths |
| A2A Task Monitor | Real-time view of A2A task lifecycle, cross-agent message flow, and policy decisions |
| External Agent Dashboard | Fleet view including external agents (v1.7.0) with heartbeat status, recent events, and last results |
### Channel Adapter Integration
The `ChannelAdapter` trait (in `crates/channel-adapter/src/traits.rs`) gains an A2UI format target, enabling console panels to render natively in:
- **Slack** — Block Kit surfaces
- **Teams** — Adaptive Cards
- **Discord** — Embeds
- **Browser** — Lit web components (native A2UI)
This means the same compliance dashboard that appears in the console can be pushed as a Slack notification or Teams card — consistent governance UX across surfaces.
---
## Beyond (Unscheduled)
These items are under consideration but not yet committed to a release.
| Feature | Description |
|---------|-------------|
| `symbi-agent-sdk` crate | Dedicated crate wrapping prelude, builder, AgentCard helpers, heartbeat client, and A2A task reporting — the single dependency for standalone agent authors |
| Model Failover & Multi-Provider Routing | Failover chains, per-task model overrides, cost budgeting (daily/monthly USD caps), circuit breaker, SLA-aware selection |
| A2A Federation | Cross-organization agent mesh with trust bundles and federated discovery |
| Federated Memory | Cross-agent memory sharing with access-control mediation |
| Plugin Marketplace | Community-contributed channel adapters, policy templates, and DSL extensions |
| On-Prem SLM Fine-Tuning | Fine-tune small language models on agent interaction history for cost reduction |
| Multi-Tenancy | Tenant-isolated agent pools with per-tenant billing and policy enforcement |
| WASM Sandbox | Run untrusted tool code in WebAssembly sandboxes with capability-based permissions |
| Compliance Automation | Auto-generate SOC 2, ISO 27001, and GDPR compliance artifacts from audit logs |
| Distributed State Management | Replace in-memory `DashMap` scheduler state with Redis/Etcd for cluster-wide shared state and restart persistence |
---
## OSS / Enterprise Boundary Notes
Symbiont ships as Apache 2.0 (Community Edition) with a proprietary `enterprise/` crate gated behind `SYMBIONT_ENTERPRISE_LICENSE`. The following notes capture where each roadmap feature should land. Implementation should respect these boundaries from day one — feature-flag separation or `enterprise/` directory placement, not post-hoc extraction.
### v1.4.0 — AgentSkills + Memory + Webhook DX (Shipped)
| Feature | Tier | Notes |
|---------|------|-------|
| SkillLoader (scan paths, parse frontmatter, verify signatures) | OSS | Core security capability |
| SkillScanner (content scanning, default ClawHavoc rules) | OSS | Security basics should be free |
| `symbi skills` CLI commands | OSS | Standard tooling |
| Enterprise policy integration (AccessLevel-scoped skill trust) | Enterprise | Matches existing enterprise security patterns |
| Fleet-wide skill policy enforcement with audit trails | Enterprise | Operations tooling |
| Feature | Tier | Notes |
|---------|------|-------|
| Persistent memory (Markdown store, basic search, auto-compaction) | OSS | Core agent capability |
| `AccessLevel`-scoped memory isolation | Enterprise | Matches existing enterprise security patterns |
| Configurable retention + auto-purge | Split | Basic retention (e.g., 30d default) = OSS. Policy-driven retention with compliance audit = Enterprise |
| Memory inspection via compliance tooling | Enterprise | Compliance = enterprise |
| Webhook basic (register, invoke, immediate delivery) | OSS | Fundamental activation mode |
| Webhook signature verification (HMAC-SHA256) | OSS | Security basics should be free — gating creates insecure free-tier users |
| Webhook delivery policies (queue, batch, retry) | Split | `immediate` = OSS. `queue` and `batch` with configurable retry = Enterprise |
### v1.5.0 — LanceDB, Compaction, Composio MCP (Shipped)
| Feature | Tier | Notes |
|---------|------|-------|
| `VectorDb` trait abstraction | OSS | Core infrastructure |
| LanceDB embedded backend | OSS | Zero-config local deployment is the free-tier story |
| Backend factory + env-var config | OSS | Standard configuration |
| Qdrant backend (feature-gated) | OSS | Existing functionality, just behind a feature flag |
| Basic session compaction (summarize + truncate) | OSS | Necessary for long sessions |
| Tiered compaction pipeline (all 4 tiers) | Enterprise | Sophisticated optimization |
| Policy-aware compaction (Secret/Confidential handling) | Enterprise | AccessLevel enforcement = enterprise pattern |
| Compaction audit trail | Enterprise | Audit = enterprise |
| Multi-model token counting | OSS | Core infrastructure for compaction |
| Composio MCP integration | OSS | External tool access |
### v1.6.0 — Reasoning Loop, Knowledge Bridge, Scanner (Shipped)
| Feature | Tier | Notes |
|---------|------|-------|
| Agentic reasoning loop (ORGA cycle, all phases) | OSS | Core agent capability |
| `CloudInferenceProvider` + SLM support | OSS | Basic inference |
| Cedar policy gate | OSS | Policy enforcement is core |
| Knowledge bridge | OSS | Core agent capability |
| ClawHavoc scanner expansion (30 new rules) | OSS | Security basics should be free |
| Behavioral sandbox (seccomp-bpf) | Enterprise | Advanced runtime analysis |
### v1.7.0 — Standalone Agent SDK & External Agent Integration
All v1.7.0 work is **OSS**. Standalone agent DX is table-stakes — gating it would kill adoption.
| Feature | Tier | Notes |
|---------|------|-------|
| `ReasoningLoopRunner::builder()` | OSS | Core DX |
| `ActionExecutor::tool_definitions()` trait method | OSS | Core trait |
| `symbi_runtime::prelude` | OSS | Convenience |
| Feature flag cleanup (`standalone-agent` meta-feature) | OSS | Core DX |
| `ToolFilterPolicyGate` | OSS | Basic policy |
| External agent registration (`External` execution mode) | OSS | Basic fleet visibility |
| Heartbeat + events endpoints | OSS | Basic fleet visibility |
| Health check pull | OSS | Basic operations |
| Documentation + examples | OSS | Ecosystem growth |
### v1.8.0 — A2A Protocol Integration
The entire `symbi-a2a` crate should be **OSS**. A2A is an open protocol; gating core interop kills adoption. Enterprise value comes from what *wraps* it (fleet policy, audit, dashboard), not the protocol layer itself.
| Feature | Tier | Notes |
|---------|------|-------|
| Phase 1 (AgentCard serving, agent discovery, DSL mapping, config, CLI) | OSS | Basic interop |
| Phase 2 (remote transport client, task state machine, JSON-RPC handlers, message bridging) | OSS | Core protocol compliance |
| Phase 2 (policy enforcement on state transitions) | Split | Basic check = OSS. Advanced enterprise rules = `enterprise/` |
| Phase 3 (AgentPin-verified AgentCards, auth middleware) | OSS | AgentPin is MIT |
| Phase 3 (DSL A2A functions: `send_task`, `send_message`, `subscribe`, `publish`, `discover_agent`) | OSS | Core agent communication primitives |
| Phase 3 (`A2aTrustPolicy`) | Split | `open` and `agentpin-required` = OSS. Fleet enforcement = Enterprise |
| Phase 4 (A2A ↔ MCP bridge, SchemaPin verification) | OSS | SchemaPin is MIT. Bridge is core interop |
| Phase 5 (SSE streaming, push notifications) | OSS | A2A spec compliance |
| Phase 5 (`symbi-a2ui` dashboard integration) | Enterprise | Operations tooling |
### v1.9.0+ — `symbi-a2ui` Phase 2
All Phase 2 panels and channel adapter A2UI format target are **Enterprise**. The Phase 1 alpha (fleet overview, compliance, audit trail) is already "not published" — the entire `symbi-a2ui` crate should live in `enterprise/`.
### Beyond (Unscheduled)
| Feature | Tier |
|---------|------|
| `symbi-agent-sdk` crate | **OSS** — standalone agent adoption driver |
| Model failover & multi-provider routing | Split — basic 2-provider chain = OSS, N-provider + cost budgeting = Enterprise |
| A2A Federation | Enterprise |
| Federated Memory | Enterprise |
| Plugin Marketplace | **OSS** — community ecosystem driver, gating kills the flywheel |
| On-Prem SLM Fine-Tuning | Enterprise |
| Multi-Tenancy | Enterprise |
| WASM Sandbox | **OSS** — security sandbox benefits everyone |
| Compliance Automation | Enterprise |
| Distributed State Management | Enterprise — cluster coordination is an operations concern |
### Implementation Concerns
1. **`symbi-a2ui` placement is ambiguous.** If enterprise-only, it should not appear in the public ROADMAP.md — or must be explicitly marked.
2. **A2A policy integration lines** (Phase 2 policy enforcement, Phase 3 trust policies) must call into the enterprise policy engine via the existing feature-flag boundary rather than embedding enterprise logic in `symbi-a2a`.
3. **No tier labels in feature descriptions.** Consider adding explicit `[OSS]` / `[Enterprise]` markers in the version sections above, or a separate "Enterprise Add-ons" subsection per version.
---
## Contributing to the Roadmap
We welcome input on roadmap priorities. To propose features or discuss planned work:
- **GitHub Discussions** — Open a discussion in the [Symbiont repository](https://github.com/ThirdKeyAI/Symbiont/discussions) for feature proposals and design feedback
- **Contributing Guide** — See [docs/contributing.md](docs/contributing.md) for development setup and contribution workflow
- **Security** — For security-sensitive feedback, follow the responsible disclosure process in SECURITY.md
---
*Last updated: 2026-03-01 (cross-repo alignment pass)*