Roadmap: Client SDKs and Developer Experience

Gap statement: three good protocols, zero client libraries

Wikantik exposes REST (/api/bundle, /api/briefing, /api/changes), two MCP servers, and an OpenAPI 3.1 tool surface — but ships no client SDK, no framework adapters, no quickstart, and no hosted playground. In 2026, a RAG platform's discoverability runs through the agent-framework ecosystems: developers adopt what drops into their existing LangChain/LlamaIndex code with minimal integration. The retriever adapter is the genuine quick win here; the full developer-experience program (two SDKs, key management, docs site) is a multi-session effort — do not conflate the two.

Market grounding

Bedrock Knowledge Bases integrates natively with LangChain, CrewAI, LlamaIndex, and Strands Agents, and is discoverable as an MCP tool via AgentCore Gateway without custom code (Bedrock KB).
LlamaIndex/LlamaCloud pairs 160+ connectors with enterprise deployment options (private VPC, RBAC, SSO) — the framework ecosystem is both a distribution channel and a competitor (Atlan comparison).
MCP tailwind: practitioners increasingly let the model drive retrieval through MCP rather than server-side pipelines (The New Stack) — Wikantik's MCP servers are already the right architecture; SDKs extend reach to the (still much larger) population of framework-based apps that don't speak MCP yet.
LinkedIn's MCP-based agent knowledge base reported ~20% AI-coding-adoption lift and ~70% triage-time reduction — the outcome benchmark agent-facing knowledge surfaces get sold on (same source; single-company claim, treat as directional).

Current Wikantik state

Surfaces: GET /api/bundle?q= (ranked, de-duplicated, version-pinned-cited sections + coverage block), GET /api/briefing (budgeted session-start context), /api/changes?since= (incremental sync feed), /wiki/{slug}?format=md|json (raw content), 21-tool knowledge MCP, 26-tool admin MCP, /tools/* OpenAPI for non-MCP clients.
Auth: API keys / bearer tokens exist for MCP and tools surfaces (DB-backed api_keys table); no self-service key management UI.
No published API versioning/stability contract; no PyPI/npm presence; docs live in the wiki and repo, not a docs site; marketing site (www.wikantik.com) has no developer section.

Proposed direction

Python SDK first (wikantik-client on PyPI): thin typed client for bundle/briefing/changes/search + WikantikRetriever adapters for LangChain and LlamaIndex that map bundle sections to framework document types with citation metadata intact. The no-synthesis bundle contract fits retriever semantics — frameworks want documents, not answers — but the fit is verified by the acceptance test below, not assumed.
TypeScript client second (same shape), serving the Node/Next agent ecosystem.
Quickstarts: 'RAG over your wiki in 10 minutes' — docker compose up, seed pages, retriever in a LangChain/LlamaIndex snippet; a Claude/MCP quickstart showcasing assemble_bundle + get_briefing as the differentiated path.
Self-service API-key management in the admin UI (create/rotate/scope) — prerequisite for any external developer story.
Developer docs section on the marketing site generated from the OpenAPI spec + MCP tool registry, with a stated API stability/versioning policy.

Phase 1 scope and acceptance criteria

First session scope: a Python package containing a thin /api/bundle client + the LangChain retriever adapter only. No LlamaIndex adapter, no TypeScript, no key-management UI, no docs site.

Phase 1 is done when:

An integration test against a local deployment shows the LangChain retriever returning Document objects whose metadata carries canonicalId, version, headingPath, and spanSha256 intact — and a follow-on test proves the citation metadata survives a RetrievalQA-style chain end-to-end (the "maps perfectly onto retriever semantics" assumption, tested).
The README quickstart executes cleanly from a fresh virtualenv against docker compose up.
Zero server-side changes were required. If the adapter forces an API change, stop and escalate — that is the [OWNER] versioning decision, not an adapter detail.
The package builds and installs locally; publishing to PyPI is a separate [OWNER]-gated step (namespace ownership).

Verify before designing on these

"Developers adopt what drops in in five lines" and "the bundle maps perfectly onto retriever semantics" are plausible assumptions, not facts — acceptance test 1 exists precisely to verify the second; treat the first as a hypothesis the quickstart's real-world reception tests.
The LinkedIn CAPT outcome figures (~20% adoption lift, ~70% triage reduction) are a single-company claim — usable as motivation, never in Wikantik marketing copy as if independently measured.
Check PyPI/npm namespace availability (wikantik-client, wikantik) before writing setup metadata.

Non-goals

No SDK-side answer synthesis or prompt templates — the SDK returns cited evidence, mirroring ADR-0001.
No SDK coverage of admin/write MCP surfaces in Phase 1 — read-path retrieval only.
No generated-from-OpenAPI client until /api/* has spec coverage (the /tools/* spec exists; /api/* does not yet) — hand-write the thin client first, generate later.

Investigation starting points

[AGENT] API contract audit before publishing: which response fields of /api/bundle and /api/briefing are stable vs incidental? Produce the freeze list; [OWNER] ratifies the versioning policy (URL vs header) as part of the RoadmapTargetArchitecture API-stability contract.
[AGENT] LlamaIndex NodeWithScore mapping (Phase 2) — same citation-survival test shape as LangChain.
[AGENT] Key scoping model: read-only retrieval keys vs admin keys — what the existing api_keys store supports and what must be added; [OWNER] accepts the scoping design before external keys are issued.
[AGENT] SDK maintenance cost: generate from OpenAPI where possible once /api/* spec coverage exists, to keep the single-maintainer burden bounded.
[OWNER] PyPI/npm namespace ownership and the publishing decision; [AGENT] the CI publishing pipeline once approved.