agent-task begin
Start from an explicit task and scope before broad repository exploration.
// .knowledge 3.4.0 · Apache-2.0
AI coding agents need more than memory. They need a trust layer.
.knowledge lives inside your repository and tells connected coding agents what to read, what is evidence-backed, what is stale, what needs repair, and what a reviewer should verify before merge.
Current code and tests remain the source of truth. External memory stays advisory.
routing evidence trust freshness repair PR review local Inspector agent integrations optional memory, secondary to code and tests
Now available: .knowledge 3.4.0
3.4.0 updates
Task routing / focused starting context / real builds and tests / safe reuse of verified results
// one focused workflow
Start with the right files. Verify with real tests.
The 3.4.0 workflow connects task routing and engineering checks while keeping any follow-up work visible for review.
Focused starting context
The workflow records the selected files so finish can confirm that the task used the same starting context.
Agent executes + tests
The primary engineering work is verified with physical commands and tests, not a summary alone.
agent-task finish
Verified results can be reused when the same checks safely cover a repair; retries resume safely and incomplete repairs stay visible.
// the adoption gap
AI adoption is mainstream. Trust is not.
These figures describe developer sentiment and workflow plans, not .knowledge
product performance.
- AI tools
- 84% use or plan to use AI tools
- Accuracy trust
- 46% distrust the accuracy of AI output
- Commit/review
- 58.7% do not plan to use AI for committing and reviewing code
Source: Stack Overflow Developer Survey 2025.
.knowledge exists to change these numbers. Its mission is to make AI-assisted repository work trustworthy enough to review, commit, and merge with evidence instead of guesswork.
// problem
Agents do not fail only because they lack context.
They fail because context has no trust state.
Old summaries sound current
A stale note can be fluent, relevant, and wrong after the code changes.
Memory can outrank evidence
Retrieved context is useful, but it should never silently override current code and tests.
Repository context quietly becomes outdated
Documentation, module summaries, decisions, and handoffs age at different speeds.
PR risk arrives too late
A diff shows changed lines. It does not show which trust boundary or stale knowledge was affected.
Teams cannot explain agent decisions
Without evidence and freshness metadata, reviewers cannot see why an agent believed something.
// agent compatibility
One trust layer. Multiple coding agents.
different agents, same trust rules one shared repository map parallel work across multiple agents visible handoff processes no fragmentation between chats
// 3.4.0 release evidence
Task routing, real tests, and safe reuse of verified results.
.knowledge 3.4.0 joins a task-specific route to its focused starting
context, verification with real builds and tests, and safe reuse of verified results.
Below are the compatibility and routing checks completed for this release.
Integrated task routing
agent-task begin produces an explicit task route before broad exploration begins.
Same starting context
The task finishes against the same set of starting files it began with, making scope changes visible.
Reuse verified test results
A passing test or build can be reused when it safely covers the same follow-up item.
Visible follow-up work
Interrupted work can resume safely, and incomplete items remain open for review.
Repository and task health
Repository-wide health and the readiness of the current task are shown separately.
Inspectable results
Reviewers can see the route, completed checks, and any remaining work as separate results.
Routing figures below are deterministic local first-read byte measurements. They are not provider tokens, API cost, runtime speed, or a model-accuracy result.
| Evidence set | Result | Scope |
|---|---|---|
| OS / Node matrix | 9 / 9 | Windows, Ubuntu, and macOS on Node 18, 20, and 22 |
| Shipped self-test executions | 243 / 243 | 27 shipped self-tests in each of 9 matrix cells |
| Integration bridges | 12 per cell | Each compatibility-matrix cell |
| Exact upgrades | 3 / 3 | 3.2.11 → 3.4.0 on Node 22, once per OS |
| End-to-end verification | All checks passed | Packaging, clean install, upgrade, routing, Inspector, and lock-safety checks |
| Measure | Result | Interpretation |
|---|---|---|
| Routes | 48 / 48 | Every test route kept the expected source and dependencies in view. |
| Module selection | 3,584 → 96 | Modules considered versus selected across the test workspaces. |
| Median first-read reduction | 90.77% | Corrected median of local first-read bytes, not provider tokens or cost. |
// product modules
The trust layer is made of small, inspectable parts.
Routing Bundle
The compact first-read map for agents.
Verified Checks
Claims linked to real project files, builds, and tests.
Confidence + Freshness
Clear status before repository information is used.
Items to Re-check
Outdated or unverified context shown as visible work.
Change Impact Review
Changed files mapped to the repository areas they affect.
Local Visual Inspector
Local dashboard over trust state.
Agent Setup
Instructions and reusable workflows for supported coding agents.
Mem0 / Pinecone Status
Optional memory that remains secondary to current code and tests.
Local Search + Linked Docs
Find relevant repository information without loading everything.
// operating model
Agents execute. .knowledge verifies. Humans review.
Agents
Use the routing bundle, evidence, and current trust state.
.knowledge
Detects drift, grades freshness, records repair work, and builds PR impact.
Humans
See why knowledge is trusted, what needs recheck, and what blocks merge readiness.
Repository
Keeps the artifacts local, inspectable, and reviewable beside the code.
// visual inspector
Inspect trust before agents act on it.
The free, open-source core includes a local read-only Inspector for checking health, confidence, freshness, follow-up work, linked documentation, and PR-review readiness.
// memory providers
External memory is useful. It stays advisory.
Memory providers can help agents remember conversations and retrieved context.
.knowledge keeps that memory behind source, tests, and evidence.
Mem0 OSS
Self-hosted memory for agent conversations and context recall across different agents, kept advisory inside the trust layer.
Pinecone
Optional vector memory status for teams that already use managed retrieval infrastructure.
Graphiti + Zep
Better suited for Pro or Enterprise workflows that need graph memory, managed history, or fleet-level governance.
// FAQ
Trust-layer questions before install.
What is the source-of-truth order?
Current code first, current tests second, then evidence, modules, decisions, wiki, sessions, and external memory last.
Does .knowledge require cloud, login, or telemetry?
No. The free core is repo-local and does not require cloud sync, account login, or telemetry to run.
Is .knowledge an IDE?
No. Coding agents and editors still do the work. .knowledge provides the trust, routing, freshness, repair, and review layer beside the code.
Does it eliminate hallucinations?
No. It does not guarantee correct edits. It makes trust state, evidence gaps, stale context, and repair work visible before agents and reviewers rely on repository knowledge.
Can I install from GitHub Code > Download ZIP?
No. That download is a source snapshot. Use the uploaded Release asset only, then extract it so .knowledge/ sits at the repository root.
Does external memory become source of truth?
No. Code and tests beat summaries. Evidence beats prose. External memory stays advisory.