// Blog / open source discovery
Open-source agent context layer for coding teams
For coding teams, an agent context layer should be inspectable, versionable, and honest about what the agent should not trust.
// direct answer
Short answer
An open-source agent context layer should keep routing, trust, freshness, evidence, repair work, and local tools in the repository so the team can inspect the agent's operating context alongside the code.
Evaluate whether an open core context layer is a better foundation than private prompt memory or hosted-only context.
// real failure mode
The failure mode
Agent context often becomes a private mix of chat history, local scratch files, hosted memory, and one-off prompts.
That makes it hard for a team to review what the agent is relying on, especially when multiple tools touch the same repo.
For coding teams, the context layer should be inspectable, versionable, and able to mark low-trust material instead of hiding it.
// repo-local model
The repo-local fix
.knowledge keeps the core context layer in the repository: routing, module cards, evidence, wiki, repair queue, metrics, and workflows.
The open core runs locally and does not require a hosted service for setup, release checks, search, or the static Inspector.
Commercial Pro2Pilot work can sit above that layer: team Inspector views, multi-repo dashboards, policy overlays, and advanced PR impact workflows.
// concrete example
Where GitHub, .knowledge, and Inspector fit
GitHub keeps the code, issues, PRs, and review history. .knowledge keeps a repo-local operating layer that agents can read before planning.
The local Inspector makes the open core visible as a static dashboard. Pro2Pilot Inspector Pro is the paid workflow layer for teams that want visual repair queues, policies, and PR impact review across real work.
// repo proof
Repo proof to inspect
.knowledge/agent-integrations/
The same local context can be exposed to Codex, Claude Code, OpenCode, and command workflows.
- Multi-agent consistency
- Repeatable onboarding
- Locking the team into one chat product
.knowledge/tools/
Import, release, metrics, search, graph, and inspector commands are inspectable code.
- Auditing how reports are generated
- Running checks in local or CI workflows
- Treating generated output as permanent truth
.knowledge/github-action-templates/
The open core can be copied into repository automation without requiring a hosted control plane.
- PR health checks
- Release evidence
- Assuming CI replaces human review
.knowledge/inspector/
A local read-only dashboard makes trust, graph, and repair state visible.
- Visual sanity checks
- Team discussion around stale modules
- Editing code from the dashboard
- Bypassing source-of-truth rules
// command transcript
Commands and expected checks
node .knowledge/tools/flow.js release --no-color - expected
- The open core regenerates routing, trust, metrics, graph, search, and Inspector outputs.
- inspect next
- .knowledge/maintenance/quality_report.json
node .knowledge/tools/serve-inspector.js - expected
- The local static Inspector can be viewed from the generated artifacts.
- inspect next
- .knowledge/inspector/index.html
node .knowledge/tools/generate-pr-summary.js - expected
- A PR-facing summary of trust, health, and repair state is generated.
- inspect next
- .knowledge/maintenance/pr_summary.md
What ships in the open core
// field guide
Open core vs paid workflow layer
| Open core | Paid Pro2Pilot layer |
|---|---|
| .knowledge routing, trust, freshness, evidence, and local tools. | Team dashboards, policy overlays, and advanced review workflows. |
| Static local Inspector baseline. | Interactive Inspector Pro with repair boards and PR impact views. |
| GitHub Action templates and local command workflows. | Commercial support, team operations, and paid build delivery. |
// guardrails
What the agent should not trust blindly
- Open source matters here because teams can inspect the instructions, commands, generated reports, and trust rules.
- Local-first does not mean isolated from CI. GitHub Action templates can run health, PR summary, and evaluation workflows after they are copied into a repository.
- The static Inspector is a read-only view over .knowledge artifacts. Current code and tests remain the source of truth.
// common mistakes
Common mistakes
- Confusing open-source context with hosted memory that only one vendor can inspect.
- Hiding the free vs paid boundary until the team is already dependent on the workflow.
- Using a visual dashboard as if it were the source of truth instead of a view over repository files.
// quick FAQ
FAQ
Is the open core useful without Pro2Pilot Inspector Pro?
Yes. The open core contains repo-local routing, trust, freshness, tools, integrations, metrics, and a static local Inspector baseline.
Why keep agent context in GitHub?
Because coding teams already review code, tests, docs, and automation there. Keeping agent context in the repo makes it inspectable and versionable.
// page-specific next step
Use this page when evaluating open agent infrastructure
Start with the GitHub repository and the local .knowledge layer. Add Pro2Pilot Inspector when the team needs visual operations on top of the open core.