Proofpress

Inspiration

Agents now produce decisions, summaries, research findings, and operational conclusions faster than teams can safely govern them. The missing layer is not another chat interface or memory store. It is a reliable answer to a harder question: what may the next agent safely rely on?

Proofpress is an agent-produced knowledge management system (AKMS) for that boundary. Agents can propose knowledge and assemble bounded evidence, but proposed knowledge does not become reusable merely because a model generated it or an automated check passed.

What it does

Proofpress gives an owner a governed workspace for agent-produced knowledge:

• agents submit evidence-bound candidate conclusions;
• deterministic checks validate integrity, scope, freshness, and required qualifiers;
• an optional LM judge provides policy advice without receiving approval authority;
• a human owner approves, rejects, or requests a revision;
• successor agents retrieve only admitted, current, in-scope knowledge;
• append-only activity and lineage preserve who proposed, evaluated, and authorized each decision.

Why WebMCP matters

Before WebMCP, an agent could help prepare governance work, but a person still had to navigate the application manually and translate UI state back into instructions. Proofpress now exposes product semantics directly from the web application: workspace summary, review queue, evidence, lineage, deterministic checks, semantic activity, policy configuration, and agent access.

The agent can find the right candidate, inspect its evidence, run checks, prepare a policy or credential form, and open the exact owner decision surface. It cannot approve knowledge, reveal secrets, activate policy, or issue credentials. WebMCP therefore improves the collaboration without erasing the authority boundary.

The end-to-end workflow

1. A connected agent submits bounded evidence and proposes a conclusion.
2. Through WebMCP, the agent inspects the queue and runs deterministic checks.
3. The owner sees a progressive-disclosure review: a quick snapshot first, then full evidence, checks, LM advice, history, and lineage.
4. The owner alone records the decision.
5. Once admitted, the conclusion appears in governed context.
6. A successor agent retrieves it only when its identity and scope are eligible.

Rejected and revision-requested conclusions remain in the append-only history, but are excluded from governed context.

How we built it

Proofpress is a Python-first governance control plane with a canonical operation contract shared by local, HTTP, hosted, and MCP transports. The hosted dogfood runs on Render with persistent storage. The owner workspace renders semantic WebMCP tools from the same product state used by the human UI, rather than exposing coordinates or a parallel demo API.

The WebMCP implementation adds 13 agent-facing tools while deliberately omitting approval and credential authority. Deterministic checks remain fail-closed. The public demo uses an isolated synthetic workspace; our internal hosted workspace exercises the same workflow against real Proofpress development knowledge.

What is new for this challenge

The core Proofpress governance system existed before the challenge. The new challenge work is the WebMCP-native interaction layer and its production UX: semantic workspace, review, evidence, lineage, policy, access, and activity tools; authority-safe preparation flows; a public synthetic demo; and end-to-end production validation. The dated implementation history is in the public repository and release PR.

Challenges and learnings

The hardest design problem was deciding what not to expose. A superficially convenient tool that can approve knowledge or activate credentials would collapse the governance model. We learned to separate preparation from authorization and to make product semantics available to agents without turning the browser into an unbounded control surface.

We also learned that raw audit logs are insufficient for people. The interface needs semantic activity and progressive disclosure, while the underlying ledger remains append-only and inspectable.

What's next

Next we will deepen time-aware lineage, add clearer policy-as-code authoring, and package the hosted workspace for design partners—while preserving the central invariant: agents may propose and evaluate, but only an authorized person may decide what future agents can rely on.

Built With

• mcp
• python
• webmcp