The Timeline is an evidence-derived operating record for teams. It can show up as a Slack or Telegram bot, join calls to take notes and transcribe meetings, ingest forwarded emails and document uploads, and compile the event history into updates, digests, handoffs, answers, and project or client memory. Every answer the agent returns is cited back to the raw event it came from.

Small to mid-sized teams doing work where context loss creates client risk, delivery drag, or leadership noise: agencies, consultancies, implementation teams, account success teams, product teams, and founder-led operations. The kind of team where one person being out of the loop on a client or project conversation creates real friction.

Existing tools punish recording. CRMs require the contact, deal stage, and next step before you can log a single sentence. Wikis demand a page hierarchy. Ticket boards demand a project and status. The Timeline inverts this: capture is unstructured, output is structured. The agent extracts objects (people, companies, projects, deals, tasks, documents), facts, relationships, and changes from raw input, then proposes approval-backed state only when the evidence is durable.

Work surfaces feed one pipeline. Telegram and Slack bots capture chat, voice, files, /ask, and @Timeline context. Meeting bots join Google Meet, Zoom, and Microsoft Teams calls to take notes and transcribe discussions. Email, documents, calendar events, web notes, project tools, code systems, support queues, account systems, and internal tools can become part of the same evidence model through capture surfaces, integrations, and ingest webhooks. GitHub, Linear, Google Drive, Monday.com, Slack workspace history, and Sentry sync as native integrations. MCP servers extend the agent into long-tail systems for live access, and successful tool results are captured as private evidence for later reconciliation.

Chat, embeddings, and transcription run through OpenRouter via a single inference abstraction (llm.chat, llm.embed, llm.transcribe). Chat models are swappable per task. The embedding model is pinned to text-embedding-3-small at 1536 dimensions — changing it invalidates the index, so it only changes via a documented re-embed procedure.

Postgres holds events, facts, objects, tasks, documents, and version history. Qdrant holds vectors in a shared collection with mandatory team_id payload filters on every query. RustFS (S3-compatible) holds original blobs and audio with versioning enabled day one. Every row, every vector, and every byte carries a team_id, enforced at the data layer rather than application logic.

A single raw event ("Met with John from Apple about licensing") produces multiple facts — Tim met John, the topic was licensing, the date was today — each linked back to the source event. When the agent answers a question, it surfaces inline citation chips that resolve to the raw voice memo, email, message, or document version, with the author, timestamp, and source attached. No black-box summaries.

Visibility lives on the event, not the team. Each event carries one of three modes: private (visible only to the author or source owner), team (visible to all team members), or specific_users (a named list). A brain dump captured in a team group chat can still be marked private. Team isolation is enforced at the query layer; per-event visibility is layered on top.

Yes — full team data export is treated as a trust requirement, not a feature flag. Raw events are immutable and append-only, which makes export deterministic. The roadmap places portability ahead of growth-side features.

No. The agent processes content server-side, which is structurally incompatible with end-to-end encryption. Data is encrypted in transit and at rest. The privacy boundary is per-event visibility plus team scoping enforced at the data layer.