Roadmap
Foundation
- Go runtime
- Docker Compose
- PostgreSQL + pgvector
- health and readiness endpoints
- external app integration, job, Discord, storage, LLM, memory, and agent-runtime interfaces
v0 Discord Surface Slice
- Discord gateway adapter behind
GIGI_DISCORD_ENABLED - slash command registration
- guild mention handling
- DM handling
- permission model
/ping slash handler, opt-in slash publishing, DM routing, guild-mention routing, /ask, capability evaluator, identity resolver contract, DB-backed role-first /permissions command, guild-scoped /llm provider and model controls, agent-backed guild mention chat fallback, startup migration runner, guild memory settings/status/count/search scaffold, dynamic current-channel context fetching, semantic memory/tool routing policy, cited context-pack builder with permitted recent-channel memory, SSRF-filtered public web tool foundation, durable jobs queue/worker foundation, durable agent run/step/confirmation records, aggregate /agent stats guild diagnostics, opt-in reply latency footers, and durable audit-log seam are started. Rich DM conversation, semantic retrieval, assignment/task commands, product-specific job handlers, and restricted action execution remain.
v0 Agent Runtime Core Slice
- multi-owner LLM provider registry foundation
- guild-scoped provider credential UX
- model profiles for chat, reasoning, embedding, and routing
- agent handler behind deterministic Discord/plugin routing
- typed planner contract for intents, context requests, tool calls, clarification, and confirmation
- context broker for current-channel context, permitted guild memory, and enabled plugin catalog context, with stable source IDs, citation labels, stale markers, pinned snippets, omitted-unchanged records, and restore handles
- native tool registry for deterministic capabilities such as
memory.count,memory.search,memory.recent,plugins.plan, andllm.chat - policy layer for capability checks, channel visibility, confirmation, redaction, and audit classification
- token-budgeted context packing with citations/tool result summaries
- durable jobs and durable agent run/step records
- opt-in guild memory policy
- async message ingestion for enabled channels
- deterministic memory count queries
- semantic retrieval with citations
- tasks
- relays with confirmation
- usage tracking and aggregate agent stats
memory.count and memory.search as sources of truth.
Agent runtime work now includes dynamic context fetching for /ask context:channel and guild mentions: the planner can receive current-channel memory context, the broker fetches only permitted retained messages, the packer trims snippets deterministically, context/tool/answer steps emit redacted traces, /agent stats guild reports aggregate server-level run health without exposing raw prompts, snippets, provider payloads, tool arguments, or per-user details, and reply-latency:on|off controls an opt-in elapsed-time footer for guild replies.
Current LLM direction: build the data model and resolver for guild, user, and tenant credential owners from the start, but expose only guild/admin-scoped provider configuration in v0. Personal BYOK remains disabled in v0 product behavior. See LLM And Cognitive Layer Plan.
Current memory direction: memory starts off, is enabled per channel, ingests through a bounded async live queue, and exposes deterministic tools for exact counts and search. Questions such as @Gigi how many times did @sam mention "postgres"? or @Gigi how often do we talk about postgres here? can use the planner to choose memory.count, but SQL computes the count over indexed, permitted messages. Embeddings are batched in workers and use the guild embedding profile, never personal BYOK for shared guild memory.
Recommended Execution Order
Use the LLM And Cognitive Layer Plan as the canonical implementation plan. Build the remaining agent-runtime work in this order:- safety rails
- context broker
- durable agent runs
- memory retrieval
- plugin manifest v1
- Discord UX
- eval and observability harness
v1 Personal BYOK Slice
- optional user-owned provider credentials
- personal-key usage in DMs without guild memory or guild actions
- guild policy for personal keys:
off,dm-only, orguild-allowed - explicit billing-owner choice when a guild permits personal keys
- no automatic fallback between guild, user, or tenant billing owners
- personal keys pay for reasoning but never grant Gigi capabilities
v0 External App Integration Slice
- approved external app catalog
- guild enable/configure flow
- external app declared prefix dry-run matching
- consented opt-in public
send_messageprefix dispatch - external app permissions and audit logs
- external app behavior through approved manifests
/plugins admin commands, deterministic guild mention dry-run matching, semantic dry-run routing, and public send_message prefix dispatch are started. Command publishing, restricted dispatch, confirmed per-message approval, and richer external app execution remain future slices. Any domain behavior only exists if an approved installed external app manifest declares it and the external app supports it.