The Agent That Refuses

Agents are very good at making weak context sound finished. A retrieval layer can return the nearest chunk, a model can turn it into fluent prose, and the user may never see that the source was stale, unverified, disputed, or only loosely related to the question. That is not only a model problem. It is a memory and governance problem.

Froggit treats that boundary as part of the product. A capsule is not just text. It carries lifecycle state, provenance, source verification, confidence, review status, and answer eligibility. The useful question for an agent is not only whether memory exists. The useful question is whether the current memory is allowed to support an answer.

The Froggit LangChain adapter is a thin bridge for LangChain and LangGraph. It gives applications a FroggitRetriever, FroggitClaimsRetriever, FroggitMemory, and FroggitCheckpointer while keeping all reads and writes on Froggit public HTTP APIs. It does not reimplement Froggit policy locally and it does not connect to internal graph or cache stores.

The default matters. FroggitRetriever asks for the governed search surface and returns answer-eligible documents. Document metadata carries the Froggit URI, capsule title, confidence, confidence explanation, source verification, match status, review state, and provenance fields when the API returns them. An application can render those fields directly instead of hiding the retrieval contract behind a single text blob.

When an application needs durable agent memory, FroggitMemory writes through the reviewed-write profile. The memory lands as a private MEMORY capsule that requires approval and is marked not answer-eligible. The adapter records memory, but it does not promote a model note into canonical knowledge.

The demo agent is deliberately small. In mock mode it ships with fixtures for three cases: an eligible answer, related but ineligible capsules, and a weak match. The second case is the point of the demo. The agent searches Froggit, finds related capsules, and still refuses because none meet the answer-eligibility bar.

The refusal transcript is plain: "Found 3 related capsules; none meet the answer-eligibility bar (unverified sources). I won't guess." That sentence is not an apology. It is product behavior. The agent found something useful to report about the state of knowledge, but it did not convert unverified material into a polished answer.

In the weak-match fixture, the agent can answer from an eligible capsule while showing a visible caution banner. That is a different outcome from refusal. Froggit can separate "this source is allowed to answer" from "this match is strong enough to treat as conclusive." Applications should expose that distinction.

The package follows normal Python packaging: install the adapter, create a FroggitClient, pass it to FroggitRetriever, and invoke it like any LangChain retriever. The demo also supports a zero-infrastructure mock path so a new user can see the answer, refusal, and caution behavior before connecting a real Froggit workspace.

Live mode is intentionally explicit. It requires FROGGIT_API_TOKEN and FROGGIT_BASE_URL or FROGGIT_API_URL. Mock mode is the default for the public demo so nobody accidentally writes anonymous memory into a live Froggit deployment. When live memory is enabled, the user-facing acknowledgement is direct: "Noted - pending review before it joins my knowledge."

Many Froggit deployments are private by design. The adapter accepts a base URL and custom TLS verification path, so the same LangChain surface can talk to a local or airgapped Froggit endpoint. Telemetry is not part of the adapter. Network calls go to the configured Froggit API.

That design keeps the deployment model simple: LangChain remains the application framework, Froggit remains the governed substrate, and the adapter is the narrow bridge between them. If a local Froggit workspace says a capsule is not answer-eligible, the adapter preserves that answer instead of trying to be clever.

The adapter returns normal LangChain Document objects, but the metadata is intentionally not generic. An application can show the capsule title, confidence, confidence explanation, source verification, review state, Froggit URI, match status, and provenance without inventing a parallel schema. That keeps UI behavior close to the retrieval contract.

This is especially useful for product teams that already have LangChain agents in motion. They do not need to replace their agent framework to adopt stricter memory behavior. They can swap the retriever, render the metadata they already receive, and decide how visible the refusal and caution states should be in their own interface.

The same idea applies to LangGraph checkpoints. FroggitCheckpointer stores agent state as private CONFIG capsules, not as answerable knowledge. It is slower than a dedicated database checkpointer, so it is not the right fit for every high-frequency workflow. It is useful when auditability and governed persistence matter more than raw checkpoint throughput.

Generic memory layers are useful when the job is recall. Froggit is aimed at a stricter job: recall with provenance and governance. The adapter exists so LangChain applications can consume that stricter contract without giving up the normal Retriever, chat history, memory, or checkpointer interfaces that developers already use.

The package is small on purpose. It should be boring to install and easy to inspect. The interesting behavior belongs in Froggit: source verification, answer eligibility, reviewed writes, and capsule provenance. The agent that refuses is a narrow demo, but it shows the larger design principle: a governed agent should know when memory exists and still know when not to answer.