Ecosystem review / AI Assistant
AI Assistant: review and next steps
The assistant should behave consistently across Datazup applications while sharing conversation contracts, capability routing and accounting. The remaining work is chiefly convergence and consumer acceptance, rather than another chat implementation.
What the evidence supports
The retained source-consolidation record reports Codev conversation-detail and capability routing delivered, with source checks. It explicitly keeps package, immutable-install and live-provider acceptance separate. The current programme pointer still lists assistant acceptance work as open.
Reevaluation: Reuse the existing routing and renderer work. A landed route or passing contract suite does not establish an authenticated product journey or deployment.
The next useful outcome
Two named applications complete authenticated, budgeted journeys through the common runtime, including approval, streaming, reconnect and failure handling.
Separate workstream plan
AAI-01 · Proposed / reuse existing work
Refresh the consumer matrix
Record each consuming app, delivered source, package identity, current owner and missing acceptance.
Acceptance: Every named consumer is classified without treating a source candidate as deployed.
AAI-02 · Proposed / reuse existing work
Close the Arabic continuation
Reuse the existing Arabic assistant candidate and its immutable dependency chain.
Acceptance: Independent qualification covers the agreed language journey and exact package set.
AAI-03 · Proposed / reuse existing work
Converge shared contracts
Resolve the demonstrated conversation, capability, package and MCP Gateway seams for the pilot consumers.
Acceptance: Both consumers use the same supported contracts with no parallel runtime.
AAI-04 · Proposed / reuse existing work
Qualify execution and accounting
Verify Codev execution authority, credential isolation, Worker inference and durable usage settlement.
Acceptance: A task cannot exceed its authority or disappear from durable accounting.
AAI-05 · Proposed / reuse existing work
Accept real application journeys
Run granted end-to-end turns for approval, SSE, reconnect, cancellation and failure handling.
Acceptance: Authenticated user-visible outcomes and accounting agree on both pilot consumers.
AAI-06 · Proposed / reuse existing work
Standardize subsequent adoption
Turn the accepted pilot into a small adoption and qualification checklist for additional apps.
Acceptance: A new consumer can demonstrate the same acceptance without duplicating the infrastructure.
Dependencies and sequence
Immutable shared packages, qualified adapter routes, MCP Gateway contracts and explicit grants for any live-provider acceptance.
Start with the first eligible unfinished task above, after checking its existing owner and admission. Later tasks depend on the preceding proof where applicable; this ordering does not override a current implementation plan.
Deferred work
Broad rollout across every app and hosted variants until the first two consumers pass; preserve existing deferrals.
Evidence and updates
This article combines the supplied 8 November ecosystem review with selected current source and retained planning records. It is an editorial snapshot, not a live service census. Detailed revision bindings and task authority remain in Workspace Docs and private execution records. Publish subsequent accepted changes as linked engineering or release notes rather than silently rewriting this baseline.
Shared roadmap · All AI Assistant articles · Explore all areas
