pod
Other formats agents might prefer:
markdownjsonllms.txt

Agent? You probably want markdown or json, or Pod over MCP.

Reported issues for kcp-agent — KCP navigation planner

Pod holds 18 of 25 problems reported by people outside the maintainer team. Issues filed by the project's own owners, members and collaborators are excluded entirely — a maintainer's release checklist is not a warning to a prospective user.

Back to kcp-agent — KCP navigation planner.

Most discussed

Post-synthesis confidence gate — gate agent conclusions, not just knowledge access

Problem

We're piloting kcp-agent as the enforcement layer under an internal governance model for a small SaaS org ("Tillitsbro" below — anonymized) that lets human staff and AI agents jointly run customer-facing workflows. The model requires: "critical tasks must halt if the agent's own confidence in its conclusion falls below a calibrated threshold — before the conclusion is acted on."

Concretely: an agent drafts a customer-facing risk assessment. The org's policy says anything below 70%

Read the thread · 2026-07-20 · closed · 5 comments

Phase 7: Network + MCP layer

Phase 7: Network + MCP layer

Epic: #42 — Rust implementation Depends on: #43 (Phase 1), #45 (Phase 3) Port of: src/fetch.ts, src/verify.ts, src/follow.ts, src/mcp.ts, src/replay.ts

Overview

The network-aware layer: HTTPS manifest fetching with SSRF guards, Ed25519 signature verification, federation tree walking, MCP stdio server, and replay (re-fetch + re-plan, compare). This is where the planner meets the network — and where the fail-closed discipline matters most.

Read the thread · 2026-07-06 · closed · 4 comments

Treat a supported x402 method as satisfying access for pay-per-request units

Finding

Running the planner against the Fjordwire manifest from Selling News to Robots with --methods free,x402:

○ 2. subsea-cable-feature (score 7)  stories/subsea-cable-feature.md  0.15 USDC/request
   why: ...; access 'restricted': agent holds no credentials
   not load-eligible

The unit declares access: restricted and an x402 payment method. The agent can pay — but planner.ts:232-234 gates any restricte

Read the thread · 2026-07-04 · closed · 4 comments

kcp-agent serve: emit discovery Link headers (RFC 8288) on /mcp and /health responses

Pattern observed in ch.jassverband/jasswiki (AMCP reference deployment): their MCP endpoint responses carry RFC 8288 Link headers so any client — or crawler — can discover the trust artifacts without prior knowledge:

link: <https://jasswiki.ch/mcp/http>; rel="mcp-server",
      <https://jasswiki.ch/llms.txt>; rel="ai-content-source",
      <https://jassverband.ch/.well-known/mcp-authority.json>; rel="authority-attestation",
      <https://jasswiki.ch/.well-known/mcp.json>; rel="mcp-manife

[Read the thread](https://github.com/Cantara/kcp-agent/issues/88) · 2026-07-14 · closed · 3 comments

### Procedures as governed units — an answer to #99's atomic-unit question

## Problem

#99 ("Action manifests — declare what an agent may DO") is an open problem statement that leaves its central question unanswered: *what is the atomic unit an action manifest declares — a tool call, a named capability, or a workflow?* This issue proposes a concrete candidate answer and the gating that follows from it. (See the procedural-plane framing issue: Cantara/knowledge-context-protocol#132.)

**Proposed answer: the atomic unit is the procedure/skill** — declared like a knowledg

[Read the thread](https://github.com/Cantara/kcp-agent/issues/100) · 2026-07-22 · closed · 2 comments

### Document and version the plan --json contract

> **TL;DR:** The CLI already emits `plan --json`, but downstream integrations need a documented, versioned contract so they can consume plans without parsing human output or coupling to planner internals.

## Acceptance criteria
- Document the JSON shape for single plans and followed plan trees.
- Add an explicit schema/version field or compatibility policy.
- Define stdout/stderr and exit-code behavior for success, planner errors, and malformed output.
- Add fixture/contract tests that downstre

[Read the thread](https://github.com/Cantara/kcp-agent/issues/90) · 2026-07-14 · closed · outside contributor · 2 comments

### Implement RFC-0024 Serving Endpoint Binding (serving block, C18 demotion, C19 serve self-check)

RFC-0024 (Cantara/knowledge-context-protocol@179edae) adds an optional signed `serving` block declaring authoritative manifest URLs and authorized MCP representatives, closing T11 (rogue-representative attack).

kcp-agent reference implementation per the RFC's plan:

- [ ] Parse `serving.manifest` / `serving.mcp` (unknown-field-tolerant as today when absent)
- [ ] **C18**: when the manifest was retrieved over HTTP(S) and `serving.manifest` is declared but the final post-redirect URL is not liste

[Read the thread](https://github.com/Cantara/kcp-agent/issues/87) · 2026-07-14 · closed · 2 comments

### Watch mode — persistent manifest monitoring

# Watch mode — persistent manifest monitoring

## Problem

kcp-agent runs per-invocation: plan, trace, validate, then exit. Enterprise ops and CI workflows expect persistent processes that monitor for changes and react. Inspired by OpenClaw's always-on gateway pattern.

## Proposed solution

`kcp-agent watch` monitors a manifest and its units for changes:

```bash
# Watch a manifest, re-validate on every change
kcp-agent watch --manifest .

# Watch and re-plan a pinned task on every change
kcp-a

[Read the thread](https://github.com/Cantara/kcp-agent/issues/77) · 2026-07-07 · closed · 2 comments

## Most recent

### manifests[].local_mirror is unimplemented — spec says parsers MUST prefer it over fetching

## The gap

SPEC §3.6 defines `manifests[].local_mirror`:

> **`local_mirror`** — OPTIONAL. Relative path (forward slashes, relative to this manifest) to a local copy of the remote manifest. **When present and the file exists, parsers MUST load from that path instead of fetching `url`.**

That is a MUST, and it is not implemented. The identifier appears nowhere in this repository:

$ grep -rn "local_mirror|localMirror" src/ java/ rust/ (no matches)


All three implementations — TypeScrip

[Read the thread](https://github.com/Cantara/kcp-agent/issues/136) · 2026-07-30 · closed · 0 comments

### kind: playbook bypasses the skill_eligibility gate — a composition is less governed than its parts

KCP [v0.29](https://github.com/Cantara/knowledge-context-protocol/releases/tag/v0.29.0) added `kind: playbook` (§4.3b, RFC-0027): an ordered composition of units, governed per step, reaching up to `commit` authority.

The `skill_eligibility` gate fail-closes `kind: skill` (`trace.ts:211`):

```ts
if (unit.kind === "skill" && unit.load_eligible !== true) { ... reject ... }
else pass("skill_eligibility", unit.kind === "skill" ? "..." : "not a skill");

A playbook is not kind: skill, so it ta

Read the thread · 2026-07-27 · closed · 1 comment

Accept --correlation-id and echo it in the --json envelope

Companion to Cantara/pi-kcp#36.

pi-kcp's governed loop mints a W3C traceparent per turn and wants to thread it through every evidence surface: kcp-memory recall (as a traceparent query param — works), the published context messages (works), and the kcp-agent plan invocation — which currently fails, because the CLI parser rejects unknown options:

$ kcp-agent plan "x" --manifest knowledge.yaml --correlation-id 00-abc-def-01
Unknown option: --correlation-id
(exit 2)

pi-kcp is dropping

Read the thread · 2026-07-26 · closed · 1 comment

plan/trace JSON should surface a unit's action_scope (for runtime conformance resolvers)

Unit.action_scope (added in 0.16 for the procedural plane, #100) is parsed but not projected into plan --json or plan --trace --json — PlannedUnit and UnitTrace omit it. Runtime consumers (pi-kcp's conformance ScopeResolver, and any harness-adjacent tool) therefore must re-read knowledge.yaml to get a selected skill's action_scope.

Ask: include the selected/traced unit's action_scope in the plan/trace JSON so a CLI-backed resolver can replace the direct file read. Surfaced

Read the thread · 2026-07-22 · closed · 1 comment

llms.txt bridge — meet publishers where they already are

Problem

KCP's hardest adoption problem is publisher-side: knowledge.yaml needs authors (#76/#78 attack this with init/discover). Meanwhile the world adopted llms.txt — a radically weaker cousin (a flat link list: no audiences, no temporal validity, no signatures, no payment, no federation) — at meaningful scale. That proves the publisher appetite exists; it just landed on the weakest possible format.

Draft behind that adoption instead of competing with it.

Direction

  1. **Conv

Read the thread · 2026-07-21 · closed · 0 comments

Built-in web fetcher — consume and generate knowledge.yaml from URLs

Built-in web fetcher — consume and generate knowledge.yaml from URLs

Problem

kcp-agent can fetch remote manifests over HTTPS (the client already does this), but it has no ability to:

  1. Discover knowledge.yaml manifests on the web (e.g., from a GitHub repo URL or a documentation site)
  2. Generate a knowledge.yaml from an existing website or documentation set
  3. Crawl a bounded set of pages to create a navigable knowledge manifest for web content

Currently, creating a KCP mani

Read the thread · 2026-07-07 · closed · 1 comment

Multi-model synthesis — pluggable LLM layer

Multi-model synthesis — pluggable LLM layer

Problem

The ask command and synthesis layer currently depend on @anthropic-ai/sdk (optional) — making kcp-agent feel like an Anthropic ecosystem play. This undermines the "protocol, not product" positioning. The planner is model-free; the synthesis layer should be model-flexible.

Proposed solution

Abstract the LLM call behind a provider interface:

interface SynthesisProvider {
  synthesize(task: string, units: LoadedUnit[

[Read the thread](https://github.com/Cantara/kcp-agent/issues/74) · 2026-07-07 · closed · 1 comment

### Java implementation — kcp-planner library

# Java implementation — kcp-planner library

> *"The planner as a dependency, not a sidecar."*

## Vision

One Maven artifact — every JVM target:

| Target | What | Integration |
|--------|------|-------------|
| **Core library** | `KcpPlanner.plan(manifest, task)` | Any Java 17+ project |
| **Spring Boot starter** | `@EnableKcpPlanner` + `application.yaml` | Spring Boot 3.x auto-configuration |
| **MCP server** | stdio JSON-RPC tool server | Claude Desktop, Claude Code, custom agents |
| **Quar

[Read the thread](https://github.com/Cantara/kcp-agent/issues/69) · 2026-07-06 · closed · 1 comment

### Java Phase 7: Release pipeline

# Phase 7: Release pipeline

**Parent epic**: #69
**Depends on**: All previous phases (progressively)

## Goal

Automated build, test, conformance, and release pipeline. The Java planner should be published to Maven Central with the same rigor as any Cantara artifact.

## Deliverables

### 1. GitHub Actions CI (`java-ci.yml`)
```yaml
on: [push, pull_request]
jobs:
  build:
    - Java 17 + Java 21 matrix
    - mvn clean verify
    - Conformance vector tests (Phase 2)
    - Code coverage report (J

[Read the thread](https://github.com/Cantara/kcp-agent/issues/68) · 2026-07-06 · closed · 2 comments

### Java Phase 5: MCP server (stdio JSON-RPC)

# Java Phase 5: MCP server (stdio JSON-RPC)

**Epic**: #63 — Java implementation
**Port of**: `src/mcp.ts`

## Overview

A standalone runnable JAR serving the five KCP tools (kcp_plan, kcp_load, kcp_validate, kcp_trace, kcp_replay) over stdio JSON-RPC 2.0 — the MCP transport. Integrates with or replaces the existing Java MCP bridge at `Cantara/knowledge-context-protocol/bridge/java`.

## Deliverables

- [ ] JSON-RPC 2.0 stdio framing (newline-delimited, same as TypeScript)
- [ ] All five MCP too

[Read the thread](https://github.com/Cantara/kcp-agent/issues/65) · 2026-07-06 · closed · 1 comment

The remaining reports are on [the project's issue tracker](https://github.com/Cantara/kcp-agent/issues).