One assistant over everything bot.auto knows.

A single-tenant conversational AI platform over Confluence and Slack, extensible to the rest of your stack, with every answer cited, current, and complete.

A platform that treats trust as the feature.

Your team asked for three things most AI assistants cannot prove: all the information, the context behind it, and its freshness. This document presents the architecture that delivers each one as an engineered, verifiable property, not a promise.

The platform gives every employee one conversational surface over the organization's knowledge. Answers assemble strictly from retrieved company content with per-claim citations; when confidence is low the system says "I don't know" and shows what it searched. Conversations are shared threads, corrections become team knowledge, and everything runs inside your own cloud account.

Six principles govern every decision in the sections that follow:

Everything runs inside your cloud.

Employees and administrators reach the platform through the web application, authenticated against your identity provider. The platform syncs from your source systems, calls a model endpoint you choose, and streams its audit log to your SIEM.

One core application, two planes.

The core application serves conversations and answers; the sync plane keeps the index complete and fresh. PostgreSQL with pgvector is the single system of record for documents, vectors, keyword search, permissions, threads, and audit.

Data access that proves its coverage.

Each source gets one adapter with two faces sharing auth and client code: a sync face feeding the index continuously, and a runtime face of live tools the assistant calls for point lookups and freshness verification.

This hybrid is deliberate: querying vendor search APIs at question time cannot prove coverage or measure freshness, and an index alone can lag reality. The index provides recall across millions of items; the live tools confirm currency before an answer ships. All transport is HTTPS with cursor pagination, exponential backoff, idempotent upserts, and tombstones for deletions.

Slack sync runs on Socket Mode: the connector holds an outbound persistent WebSocket, so events arrive in real time with no public inbound endpoint and no polling against rate limits. Events are acknowledged instantly, deduplicated, and the whole thread is re-fetched and stored as one unit so conversations are never internally stale.

Ingestion enrichment. Raw conversational text is a poor embedding target, so ingestion is two-tier: raw text becomes keyword-searchable the moment it lands, while the semantic layer builds asynchronously. A distillation pass structures each thread into a normalized artifact (searchable question, summary, resolution, systems touched); a bursting pass additionally embeds high-signal message runs so answers buried in tangents stay findable.

Retrieval where no single scorer is trusted alone.

Four signals each cover the others' blind spots, their rankings fuse by consensus, and a reranker restores surrounding context before a word is generated.

Each signal ranks the permission-filtered candidate set independently; the lists fuse by reciprocal rank fusion so cross-signal consensus beats any single strong vote. A compact reranker scores the fused top set against the actual question, and winners are re-expanded with neighboring context so chunking never severs preconditions from answers. Embedding remains a per-corpus dial: where evaluations show vectors add no recall for a source, that source stops being embedded.

Plan, then execute (Phase 2). For analytical, multi-step questions the orchestrator separates planning from execution: the LLM writes an inspectable step-by-step plan, the platform executes it deterministically with scoped credentials, and results return as artifacts with citations. The plan itself is shown to the user and stored with the answer. Until Phase 2, such questions are declined gracefully rather than answered badly.

Three guarantees, engineered rather than promised.

Each requirement you named maps to load-bearing machinery you can verify in operation, on a dashboard, not in a slide.

Security your reviewers can walk through.

Six layers, each with named controls; the system is designed to pass a security review, not to survive one.

Seven decisions, trade-offs on the table.

Every major choice is recorded with its rationale and the cost we accept, so your team can challenge any of them before a line of code is written.

A phased path to production.

A discovery sprint settles the open questions, foundation follows, a working assistant over Confluence and Slack ships next, intelligence layers on top, and expansion runs on your timetable.