How It Works

The loop

1. Before work — the agent calls resolve_context with the task description, repo, and optionally a domain and file list. Knowit returns the titles, summaries, and metadata of the most relevant entries.
2. During work — the agent can call search_knowledge for targeted lookups, get_knowledge to fetch full content for specific entry IDs, and store_knowledge to persist something important the moment it's decided.
3. After work — the agent calls capture_session_learnings to batch-store the durable rules, decisions, patterns, and conventions discovered during the session. Entries with the same title, type, scope, repo, and domain are updated rather than duplicated.

Tiered retrieval

Retrieval is deliberately two-phase so agents don't flood their context window. resolve_context and search_knowledge return title, summary, and metadata — not full content. The agent then calls get_knowledge with only the IDs that look relevant, fetching full content just for those entries.

→ resolve_context { task: "add webhook retry handling",
                    repo: "api-gateway", domain: "billing" }
← 5 results: titles + summaries + IDs

→ get_knowledge { ids: ["kn_a1f3", "kn_c88e"] }
← full content for the 2 entries that matter

  ... implementation happens ...

→ capture_session_learnings { learnings: [
    { type: "decision", title: "Webhook retries use exponential
      backoff with jitter", scope: "repo", repo: "api-gateway" }
  ] }

Division of responsibility

In practice, Knowit is a layer for execution context:

• Canonical source code stays in the repository.
• Durable engineering memory stays in Knowit.
• External canonical docs can stay in tools like Notion, with Knowit routing agents to the right source via resolve_source_action when needed.